Thomas Ward's questions

Relacionado: MS365: O envio criptografado para locatários remotos ocasionalmente falha com "usuário não inquilino"

Como na mensagem anterior, estamos enviando mensagens criptografadas de saída via MS365 e alguns locatários remotos não conseguem visualizar as mensagens.

Antes da mudança forçada para o Azure Purview em julho de 2023, ao aceder a e-mails encriptados tinha a opção de solicitar um OTP em vez de iniciar sessão com o seu inquilino para aceder às coisas.

Temos a opção de OTPEnabled: Trueconfigurar o OME (de acordo com o PowerShell, Get-OMEConfigurationmas desde a migração para o Purview, não podemos forçar todos a usar o OTP ou até mesmo ver a opção "Obter código OTP por email".

Alguém descobriu uma maneira de forçar o código OTP por e-mail em vez do login do MS365 para obter acesso a uma determinada mensagem criptografada? Se pudermos forçar todos a precisar de códigos OTP em vez de usar o login integrado ao MS365, isso seria ótimo, mas não tenho certeza de onde impor isso, alguém sabe como fazer isso na criptografia do Purview, já que as configurações herdadas do OME não são mais presente?

Estamos tentando substituir uma solução de gateway de e-mail segura pela criptografia de mensagens de e-mail integrada do MS365.

Temos uma regra de fluxo de mensagens configurada para forçar a criptografia de um endereço de envio específico para qualquer destinatário, como segue:

CONDIÇÕES :
Aplicar regra se:
O remetente for '[email protected]'

Faça o seguinte: Modificar a segurança das mensagens - Aplicar criptografia de mensagens do Office 365 e proteção de direitos

• Os direitos protegem a mensagem com 'Criptografar' (política de criptografia padrão)

Agora, quando enviamos de alwaysencrypt- que é uma conta licenciada Business Basic neste locatário - temos resultados estranhos.

1. Ao enviar para uma conta/locatário/domínio que não seja MS365, as mensagens de e-mail são entregues como propriedade e exigem o envio de um código OTP para validar o acesso. Isso funciona bem.
2. Para alguns destinatários de locatários do MS365, mas NÃO fazem parte do locatário de origem, o gerenciamento de direitos funciona corretamente e identifica adequadamente esse locatário externo como um destinatário e o usuário tem acesso permitido.
3. Para outros destinatários do locatário MS365 que NÃO fazem parte do locatário de origem, o sistema não permite que o usuário faça login e use a autenticação do locatário MS365 para acessar o documento e falha com uma mensagem semelhante aSelected user account does not exist in tenant 'Example Tenant' and cannot access the application 'UUID' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account.

É muito novo que essa terceira opção aconteça, e o MS365 NÃO oferece aos locatários externos a opção de código OTP.

Não vejo uma maneira de resolver isso e permitir o acesso ao sistema de direitos para inquilinos externos sem adicioná-los manualmente ao nosso inquilino de origem, e isso é um problema porque este é um sistema automatizado que envia dados de mensagens criptografadas como parte dos sistemas de alerta para destinatários externos.

Alguém viu isso e tem alguma ideia de como podemos resolver isso para forçá-lo a NÃO usar a autenticação de locatário MS365 para acessar mensagens criptografadas e ser apenas a verificação do código OTP se estiverem fora da organização?

Devo observar que o MS365 agora está forçando o uso do Microsoft Purview para que as soluções OME herdadas não funcionem e não há documentação sobre como alterar isso ou fazer essas revisões conforme necessário.

Observe que tenho acesso a um administrador global no locatário de origem, portanto DEVO ter acesso a todas as opções do Powershell, se necessário.

Então, uma das empresas com quem trabalho encontrou algum caos em sua implantação híbrida do MS365/on-prem.

Há uma lista de distribuição (chamaremos de [email protected]) que está presente tanto no lado local quanto no MS365 dos consoles de gerenciamento. No entanto, enquanto o painel de controle local do Exchange mostra distlist1como aceitar emails de dentro e de fora da organização, o MS365 decidiu ignorar isso e aceitar SOMENTE emails de 'internos' para a empresa.

Como resultado, distlist1usado para receber faturas, etc. para uma equipe específica está recebendo rejeições de e-mail e não recebendo seus e-mails.

Isso não pode ser alterado no lado do MS365 e PARECE algum tipo de desconexão ou dessincronização entre o Exchagne local e o MS365.

Não sei por onde começar a procurar o que poderia causar isso no MS365, mas se alguém tiver alguma indicação de onde procurar e corrigir isso, no MS365 ele realmente aceita a configuração local de "permitir que todos enviem para a lista "isso seria maravilhoso.

Temos um problema muito estranho acontecendo aqui.

Veja este e-mail de exemplo (formato bruto, higienizado):

To: [email protected]
From: Thomas Ward via TestList <[email protected]>
Subject: Test Message
Date: Wed, 4 Aug 2021 19:44:49 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------------EFA1B8DAB3C4E625DD16F705"
Content-Language: en-US
Sender: [email protected]
Reply-To: Thomas Ward <teward@NOPE>
CC: Thomas Ward <teward@NOPE>
Message-ID: <162812069430.22940.8470019517074758016@listserv-server>
List-Id: TestList <[email protected]>
List-Post: <mailto:[email protected]>

--------------EFA1B8DAB3C4E625DD16F705
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Test


--------------EFA1B8DAB3C4E625DD16F705
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Test<br>
    </p>
  </body>
</html>

--------------EFA1B8DAB3C4E625DD16F705--

Isso está sendo enviado via SMTP direto para um conector de envio no MS365 configurado para receber e retransmitir emails de nosso servidor de email local para o MS365 para retransmissão para a Internet.

Exceto... enquanto o e-mail é retransmitido para os destinatários externos de destino... ele na verdade apenas envia o Para, De, Assunto, etc., mas ignora completamente o conteúdo real da mensagem. Isso foi replicado com o envio direto de um e-mail de teste MIMEText() em Python também.

O mesmo e-mail, porém, quando enviado diretamente para os servidores de e-mail externos onde estou recebendo isso (onde @NOPEestaria meu domínio e servidor real), transmite e retransmite bem, com todo o conteúdo. A mesma coisa acontece também quando transmitimos através de um relé Postfix local que passa por um dispositivo Sophos, que então vai diretamente para o servidor destinatário.

Portanto, parece que o roteamento de qualquer email via Exchange Online dessa maneira com um sistema local enviando emails via MS365 não funciona. Independentemente da mensagem enviada.

Alguém mais tem algum tipo de sistema de e-mail local ou soluções aqui que precisam ser roteadas via MS365 e simplesmente não conseguem sem que a Microsoft coma a mensagem em sua totalidade?

O e-mail acima foi enviado para a lista de teste de externo, roteado para um servidor Exchange local (configuração híbrida do Exchange devido a listservs locais), modificado para conformidade com DMARC e, em seguida, retransmitido para dois endereços externos como uma nova mensagem, mesmo problema nas extremidades do destinatário. Também o mesmo problema para destinatários internos do MS365 (na organização).

Novamente, a entrega funciona bem via Postfix no local, mas não quando retransmitida via MS365 (que claramente ACEITOU os e-mails e retransmitiu tudo, EXCETO a mensagem real).

Então, temos uma configuração estranha aqui. Onde eu trabalho, temos dois switches Nexus 9k executando nossa rede principal - A e B nomeados respectivamente, e eles têm portas de extensão que enviam tráfego para um Catalyst 2960-X que, por sua vez, retransmite para outro sistema para monitoramento de tráfego (que tem apenas um NIC infelizmente)

Inicialmente, estávamos usando uma VLAN intermediária no switch Catalyst da VLAN 1000 para tentar entregar o tráfego de uma maneira que fosse detectada corretamente e passada para o sistema de monitoramento de tráfego, de modo que as portas 46, 46 e 47 tivessem:

switchport mode access
switchport access vlan 1000

... e isso estava funcionando. No entanto, depois de mudar para um novo datacenter, mantendo as conexões de porta idênticas, isso não funciona mais.

Também tentamos fazer isso como uma porta SPAN local do Catalyst, como mostra este diagrama, depois de desconfigurar os modos de acesso da porta do switch para ir para o comportamento SPAN direto:

Nem o método VLAN/porta de acesso nem os métodos SPAN parecem funcionar para passar o tráfego para o sistema de monitoramento. As estatísticas de interface de show int gig 1/0/45ou show int gig 1/0/46no Catalyst mostram o aumento do tráfego e o número de pacotes recebidos como incrementando constantemente com os contadores de pacotes. Mas, isso não retransmite mais tráfego pelo SPAN no Cataylst para a porta 48 - seus contadores mostram zero atividade de pacote e o sistema de monitoramento de tráfego downstream não vê tráfego vindo disso.

Alguém tem alguma ideia de como podemos fazer isso funcionar novamente? O sistema de monitoramento de tráfego é um dispositivo dedicado que possui apenas uma porta de uplink, portanto, não podemos lançar uma NIC extra na equação para bombear tráfego direto para o monitor de tráfego de cada switch por meio de NICs individuais, infelizmente ...

Configuração do intervalo do catalisador:

monitor session 1 source int gig 1/0/45 both
monitor session 1 source int gig 1/0/46 both
monitor session 1 dest int gig 1/0/48

Configuração de extensão local do Nexus (idêntica para ambos, observe que esta não é uma configuração RSPAN):

monitor session 1
    source vlan 20-21,121,150,160,270,300,400,500 both
    destination interface Ethernet1/15
    no shut

Observe que podemos confirmar com base nas taxas de 'recebimento' nas portas 45 e 46 do Catalyst que o tráfego está vindo do NEXUS e atingindo as portas 45 e 46 no Catalyst, apenas não está passando o tráfego para abranger a porta 48 no Catalyst dessas duas portas.

Observe também que a VLAN 1000 não existe em nenhum outro lugar na rede e, neste momento, não está em jogo; as configurações do accessswitchport foram excluídas em uma tentativa de usar o SPAN padrão, embora nenhum mecanismo funcione. (A VLAN 1000 foi usada como uma VLAN direta somente interna do switch para tentar enganar o sistema para passar os pacotes não marcados dos Nexuses para a porta onde o sistema de monitoramento estava instalado)

Saída solicitada show monitor session 1 detailno Catalyst:

#show monitor session 1 detail
Session 1
---------
Type                     : Local Session
Description            : -
Source Ports             :
    RX Only              : None
    TX Only              : None
    Both                 : Gi1/0/45-46
Source VLANs             :
    RX Only              : None
    TX Only              : None
    Both                 : None
Source RSPAN VLAN      : None
Destination Ports      : Gi1/0/48
    Encapsulation      : Native
          Ingress      : Disabled
Filter VLANs           : None
Dest RSPAN VLAN        : None

Configuração atual do Catalyst 2960-X em execução show run(parcialmente higienizada para ocultar informações confidenciais):

Current configuration : 8036 bytes
!
! Last configuration change at 17:13:19 UTC Thu Apr 4 2019 by admin
! NVRAM config last updated at 16:20:59 UTC Mon Apr 1 2019 by admin
!
version 15.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname catalyst
!
boot-start-marker
boot-end-marker
!
!
[username data snipped]
aaa new-model
!
!
aaa authentication login default local
aaa authentication enable default none
aaa authorization commands 15 default local
!
!
!
!
!
!
aaa session-id common
switch 1 provision ws-c2960x-48fps-l
!
!
!
!
!
!
!
!
!
crypto pki trustpoint TP-self-signed-2307906176
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-2307906176
 revocation-check none
 rsakeypair TP-self-signed-2307906176
!
!
crypto pki certificate chain TP-self-signed-2307906176
 certificate self-signed 01
  [SNIP]
        quit
spanning-tree mode pvst
spanning-tree extend system-id
!
!
!
!
vlan internal allocation policy ascending
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0
 no ip address
!
interface GigabitEthernet1/0/1
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/2
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/3
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/4
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/5
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/6
 description exagrid mgmt
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/7
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/8
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/9
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/10
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/11
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/12
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/13
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/14
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/15
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/16
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/17
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/18
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/19
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/20
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/21
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/22
 description WAN Switch
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/23
 description Core 9K A
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/24
 description Core 9K B
 switchport access vlan 255
 switchport mode access
!
interface GigabitEthernet1/0/25
 description UPLINK TO MGT NETWORK
 switchport trunk allowed vlan 255
 switchport mode trunk
!
interface GigabitEthernet1/0/26
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/27
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/28
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/29
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/30
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/31
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/32
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/33
 description esx500 console
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/34
 description esx501 Console
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/35
 description esx502 Console
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/36
 description esx503 Console
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/37
 description esx504 Console
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/38
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/39
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/40
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/41
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/42
 switchport access vlan 255
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/43
!
interface GigabitEthernet1/0/44
!
interface GigabitEthernet1/0/45
 description Core A Monitor Port
!
interface GigabitEthernet1/0/46
 description Core B Monitor Port
!
interface GigabitEthernet1/0/47
!
interface GigabitEthernet1/0/48
 description Monitor Ports to Monitoring System
!
interface GigabitEthernet1/0/49
!
interface GigabitEthernet1/0/50
!
interface GigabitEthernet1/0/51
!
interface GigabitEthernet1/0/52
!
interface Vlan1
 no ip address
!
interface Vlan255
 ip address 10.1.255.21 255.255.255.0
!
interface Vlan1000
 description SPAN collection
 no ip address
!
ip http server
ip http secure-server
!
!
!
!
!
!
!
line con 0
line vty 0 4
 timeout login response 300
 transport input telnet ssh
line vty 5 15
 timeout login response 300
 transport input telnet ssh
!
!
monitor session 1 source interface Gi1/0/45 - 46
monitor session 1 destination interface Gi1/0/48
end

Isso provavelmente já foi perguntado em outro lugar, mas não consigo encontrar uma pergunta que atenda ao critério exato que temos.

Temos um sistema Windows Server 2016 Standard que executa compartilhamentos de arquivos. Dentro de um dos compartilhamentos, temos uma pasta (para os propósitos deste exemplo, o compartilhamento é chamado de "GeneralShare" e a pasta é "ControlledFolder"). Gostaríamos de ter a própria pasta listada no compartilhamento, mas não permitir que nenhum usuário que não esteja no grupo "ControlledFolderAccess" no AD tenha acesso aos dados. Portanto, qualquer usuário que não esteja no grupo "ControlledFolderAccess" saberá que a pasta existe, mas não poderá ver o conteúdo dentro dela. (Também temos regras de acesso implícitas, como o sistema e os administradores locais (e administradores de domínio) que também têm permissão.)

Experimentamos um conjunto de permissões, ajustando leitura/gravação/execução e todas as iterações de permissões especiais intermediárias, e também experimentamos as permissões 'negar'. No entanto, não encontramos o conjunto adequado de regras que abrangeria adequadamente as regras.

Alguém conhece as regras específicas que precisamos definir para impedir que os usuários entrem no diretório, mas ainda vejam que o diretório existe no próprio compartilhamento?

Isto é o que fizemos em um diretório de teste para tentar replicar:

Permissões gerais de compartilhamento:

PERMITIR REGRAS:

• Administradores de domínio: controle total
• Administradores do sistema local: controle total
• Usuários do domínio: modificar
• Usuário do SISTEMA: Controle total

REGRAS DE NEGAÇÃO:

• NENHUM

Regras Gerais de Compartilhamento/Pasta Controlada:

(SEM HERANÇA)

PERMITIR REGRAS:

• Administradores de domínio: controle total
• Administradores do sistema local: controle total
• Acesso à pasta controlada: controle total

Pelo que entendi, essas permissões devem funcionar ... está faltando uma regra de negação em algum lugar ou o comportamento padrão do Server 2016 acabou de ser alterado ? (Essas mesmas permissões em um servidor 2012R2 que possui outros compartilhamentos funcionam conforme o esperado, podemos ver a pasta, mas não acessá-la se não formos um administrador e não tivermos acesso explícito ou não estivermos no grupo ControlledFolderAccess. . mas em 2016, essas pastas simplesmente não aparecem com essas permissões definidas)

Isso vai parecer um pouco de dor de cabeça, mas estamos migrando de um servidor Sendmail para um servidor Postfix para lidar com o roteamento de e-mail em nossa rede, determinando seletivamente quais endereços fazem com que o e-mail seja roteado para locais diferentes (ou simplesmente reescrito para um @domínio diferente). Assim, os domínios que são processados ​​por este sistema estão na virtual_alias_domainslista.

O problema é que temos um punhado de endereços que queremos sempre rejeitar e também vemos os endereços nos virtual_alias_domainscatch-alls no final da configuração. Fazemos o seguinte, essencialmente, e nos referimos a este arquivo na virtual_alias_mapsdiretiva:

/etc/postfix/virtusertable:
    ...
    @domain.tld            @internal.domain.tld

Queremos poder fazer um REJECTcom a mensagem de "Destinatário rejeitado pela política" junto com ele, então tentamos colocar da seguinte forma:

/etc/postfix/recipient-access:
    [email protected]    REJECT Recipient rejected by policy.
    baduser@              REJECT Recipient rejected by policy.

e o arquivo referido na configuração para ambos smtpd_recipient_restrictionse smtp_relay_restrictionscom... check_recipient_access hash:/etc/postfix/recipient-access ...

O problema é que esperamos que ele retorne uma resposta "Rejeitado" ou similarmente "Não permitido" quando o e-mail destinado a esse destino for entregue ao servidor de e-mail e antes que ele seja reescrito e retransmitido para o próximo link da cadeia. Quando processado, no entanto, testando com sendmail -bv [email protected], o Postfix diz que o e-mail foi entregue (mesmo que a entrega não tenha sido tentada) - não 'rejeitado' ou algo assim.

Não tenho certeza de onde avançar para configurar essas regras de 'rejeição'. Parece que estamos 'trabalhando' no sistema Sendmail, mas queremos nos livrar desse sistema maligno e substituí-lo por um sistema Postfix.

Observe que estamos tentando combinar a configuração do Sendmail o mais próximo possível. No momento , temos tudo funcionando, exceto a rejeição de determinados endereços, e não temos certeza de como proceder...

Isso soará um pouco complicado e complexo, mas temos uma configuração muito ruim atualmente para e-mail em um dos ambientes de meus clientes.

Do sistema mais interno para o externo temos:

Exchange Server -> Sendmail Server -> McAfee Email Gateway -> OUTSIDE

Isso é um pouco ruim porque e-mails fora do escritório de destino externo (de alguém dentro do sistema para fora) não funcionam, eles são aparentemente capturados no McAfee Email Gateway e não são retransmitidos para fora.

O que estou tentando fazer é configurar um servidor Postfix como retransmissor E um servidor SMTP e, dependendo do que está sendo recebido:

1. Enviar e-mail diretamente (usando SMTP, apenas para respostas de ausência temporária)
2. Retransmita o correio para o servidor Sendmail, para o resto de suas funções de retransmissão, como normalmente aconteceria.

Isso então se pareceria um pouco com o seguinte:

Exchange Server -> Postfix Relay --- Out of Office messages only ---> OUTSIDE
                         |
                   All other mail
                         |
                         ---> Sendmail Server/Relay ---> McAfee Email Gateway ---> OUTSIDE

Estou um pouco confuso sobre como configurar o Postfix para a opção de retransmissão seletiva. Existe alguém que possa dar alguma dica sobre como conseguir isso?