Práticas recomendadas para proteção dos Serviços de Federação do Active Directory

Este documento fornece as melhores práticas para planejamento e implantação seguros dos Serviços de Federação do Active Directory (AD FS) e do WAP (Proxy de Aplicativo Web). Ele contém as recomendações para configurações de segurança adicionais, casos de uso específicos e requisitos de segurança.

Este documento se aplica ao AD FS e ao WAP no Windows Server 2012 R2, 2016 e 2019. Essas recomendações podem ser usadas para uma rede local ou em um ambiente hospedado na nuvem, como o Microsoft Azure.

Topologia de implantação padrão

Para implantação em ambientes locais, recomendamos uma topologia de implantação padrão que consiste em:

• Um ou mais servidores do AD FS na rede corporativa interna.
• Um ou mais servidores WAP (Proxy de Aplicativo Web) em uma rede DMZ ou extranet.

Em cada camada, AD FS e WAP, um balanceador de carga de hardware ou software é colocado na frente do farm de servidores e lida com o roteamento de tráfego. Os firewalls são colocados na frente do endereço IP externo do balanceador de carga, conforme necessário.

Como blindar seus servidores do AD FS

Veja a seguir uma lista de melhores práticas e recomendações para blindar e proteger sua implantação do AD FS:

• Verifique se somente os Administradores do Active Directory e os Administradores do AD FS têm direitos de administrador para o sistema do AD FS.
• Reduza a associação de grupo de Administradores locais em todos os servidores do AD FS.
• Exija que todos os administradores de nuvem usem a MFA (autenticação multifator).
• Capacidade mínima de administração usando agentes.
• Limite o acesso na rede usando o firewall do host.
• Verifique se os Administradores do AD FS usam as Estações de Trabalho de Administrador para proteger as credenciais.
• Coloque os objetos de computador do servidor do AD FS em uma UO de nível superior que não hospede outros servidores também.
• Todos os GPOs que se aplicam aos servidores do AD FS só devem ser aplicados a eles e não a outros servidores também. Isso limita o possível escalonamento de privilégios por meio da modificação de GPO.
• Verifique se os certificados instalados estão protegidos contra roubo (não os armazene em um compartilhamento na rede) e defina um lembrete de calendário para garantir que eles sejam renovados antes de expirar (o certificado expirado interrompe a autenticação de federação). Além disso, recomendamos proteger chaves/certificados de assinatura em um HSM (módulo de segurança de hardware) anexado ao AD FS.
• Defina o registro em log para o nível mais alto e envie os logs do AD FS (e segurança) para um SIEM, para se correlacionar com a autenticação do AD, bem como com o AzureAD (ou semelhante).
• Remova os protocolos desnecessários e os recursos do Windows.
• Use uma senha longa (>25 caracteres) e complexa para a conta de serviço do AD FS. É recomendável usar uma gMSA (Conta de Serviço Gerenciado de Grupo) como a conta de serviço, pois isso elimina a necessidade de gerenciar a senha da conta de serviço ao longo do tempo gerenciando a mesma automaticamente.
• Atualize para a versão mais recente do AD FS para obter aprimoramentos de segurança e log (como sempre, teste primeiro).

Portas necessárias

O diagrama abaixo descreve as portas de firewall que devem ser habilitadas entre os componentes da implantação do AD FS e do WAP. Se a implantação não incluir o Microsoft Entra ID/Office 365, os requisitos de sincronização poderão ser desconsiderados.

Comunicação entre Servidores de Federação

Os servidores de federação em um farm do AD FS se comunicam com outros servidores no farm e com os servidores do WAP (Proxy de Aplicativo Web) por meio da porta HTTP 80 para sincronização de configuração. Certifique-se de que somente esses servidores possam se comunicar entre si e que nenhum outro seja uma medida de defesa em profundidade.

As organizações podem atingir esse estado configurando as regras de firewall em cada servidor. As regras devem permitir somente a comunicação de entrada dos endereços IP dos servidores no farm e nos servidores WAP. Alguns NLBs (Balanceadores de Carga de Rede) usam a porta HTTP 80 para investigar a integridade nos servidores de federação individuais. Inclua os endereços IP do NLB nas regras de firewall configuradas.

Microsoft Entra Connect e Servidores de Federação/WAP

Essa tabela descreve as portas e protocolos que são necessários para a comunicação entre o servidor do Microsoft Entra Connect e os servidores de Federação/WAP.

Servidores de Federação e WAP

Esta tabela descreve as portas e protocolos que são necessários para a comunicação entre os servidores de Federação e servidores WAP.

WAP e Usuários

Esta tabela descreve as portas e protocolos que são necessários para a comunicação entre os usuários e os servidores WAP.

Para obter informações sobre as portas e protocolos necessários para implantações híbridas, confira Portas de conexão de referência híbrida.

Para obter informações sobre portas e protocolos necessários para uma implantação do Microsoft Entra ID e Office 365, confira o documento URL do Office 365 e intervalos de endereços IP.

Pontos de extremidade habilitados

Quando o AD FS e o WAP são instalados, um conjunto padrão de pontos de extremidade do AD FS é habilitado no serviço de federação e no proxy. Esses padrões foram escolhidos com base nos cenários mais comuns necessários e usados, e não é preciso alterá-los.

Conjunto mínimo de proxy de pontos de extremidade habilitado para Microsoft Entra ID/Office 365 (opcional)

As organizações que implantam o AD FS e o WAP somente para cenários do Microsoft Entra ID e do Office 365 podem limitar ainda mais o número de pontos de extremidade do AD FS habilitados no proxy, para obter uma superfície de ataque mínima. Veja abaixo a lista de pontos de extremidade que devem estar habilitados no proxy nesses cenários:

Os pontos de extremidade do AD FS podem ser desabilitados no proxy usando o seguinte cmdlet do PowerShell:

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

Proteção Estendida para Autenticação

A proteção estendida para autenticação é um recurso que atenua os ataques de MITM (man in the middle) e está habilitada por padrão com o AD FS. A configuração pode ser verificada usando o cmdlet do PowerShell abaixo:

Get-ADFSProperties

A propriedade é ExtendedProtectionTokenCheck. A configuração padrão é Permitir, para que os benefícios de segurança possam ser obtidos sem as preocupações de compatibilidade com navegadores que não dão suporte à funcionalidade.

Controle de congestionamento para proteger o serviço de federação

O proxy do serviço de federação (parte do WAP) fornece controle de congestionamento para proteger o serviço do AD FS contra uma sobrecarga de solicitações. O Proxy do Aplicativo Web rejeitará solicitações de autenticação de clientes externos se o servidor de federação estiver sobrecarregado como detectado pela latência entre o Proxy do Aplicativo Web e o servidor de federação. Esse recurso é configurado por padrão com um nível de limite de latência recomendado. Para verificar as configurações, você pode fazer o seguinte:

1. Em seu computador Proxy do Aplicativo Web, abra uma janela de comando privilegiado.
2. Navegue até o diretório do AD FS em %WINDIR%\adfs\config.
3. Altere as configurações de controle de congestionamento a partir dos valores padrão para <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
4. Salve e feche o arquivo.
5. Reinicie o serviço AD FS executando net stop adfssrv e depois net start adfssrv.

Para obter diretrizes sobre essa funcionalidade, confira Configurar o acesso à extranet para o AD FS no Windows Server 2012 R2.

Verificações de solicitação HTTP padrão no proxy

O proxy também executa as seguintes verificações padrão em todo o tráfego:

• O próprio FS-P se autentica no AD FS por meio de um certificado de curta duração. Em um cenário de suspeita de comprometimento dos servidores DMZ, o AD FS pode "revogar a confiança do proxy" para que ele não confie mais em nenhuma solicitação de entrada de proxies possivelmente comprometidos. Revogar a relação de confiança do proxy revoga o próprio certificado de cada proxy para que ele não possa ser autenticado com êxito para qualquer finalidade para o servidor do AD FS.
• O FS-P encerra todas as conexões e cria uma nova conexão HTTP com o serviço do AD FS na rede interna. Isso fornece um buffer no nível da sessão entre dispositivos externos e o serviço do AD FS. O dispositivo externo nunca se conecta diretamente ao serviço do AD FS.
• O FS-P executa a validação de solicitação HTTP, que filtra especificamente os cabeçalhos HTTP que não são exigidos pelo serviço do AD FS.

Configurações de segurança recomendadas

Verifique se todos os servidores do AD FS e do WAP recebem as atualizações mais recentes. A recomendação de segurança mais importante para sua infraestrutura do AD FS é garantir que você tenha meios para manter seus servidores do AD FS e do WAP atuais com todas as atualizações de segurança, bem como as atualizações opcionais especificadas como importantes para o AD FS nesta página.

A maneira recomendada para os clientes do Microsoft Entra monitorarem e manterem atualizada sua infraestrutura é por meio do Microsoft Entra Connect Health para AD FS, um recurso do Microsoft Entra ID P1 ou P2. O Microsoft Entra Connect Health inclui monitores e alertas que disparam se um computador do AD FS ou do WAP não tiver uma das atualizações importantes especificamente para o AD FS e o WAP.

Para saber mais sobre o monitoramento de integridade do AD FS, confira Instalação do agente do Microsoft Entra Connect Health.

Melhor prática para proteger e monitorar a relação de confiança do AD FS com o Microsoft Entra ID

Ao federar seu AD FS com o Microsoft Entra ID, é essencial que a configuração de federação (relação de confiança configurada entre o AD FS e o Microsoft Entra ID) seja monitorada de perto, e qualquer atividade incomum ou suspeita seja capturada. Para fazer isso, recomendamos a configuração de alertas o envio de notificações sempre que qualquer alteração for feita na configuração de federação. Para aprender a configurar alertas, confira Monitorar alterações na configuração de federação.

Configurações de segurança adicionais

Os recursos adicionais a seguir podem ser configurados para fornecer mais proteção.

Proteção de bloqueio "reversível" da extranet para contas

Com o recurso de bloqueio de extranet no Windows Server 2012 R2, um administrador do AD FS pode definir um número máximo permitido de solicitações de autenticação com falha (ExtranetLockoutThreshold) e um período observation window (ExtranetObservationWindow). Quando esse número máximo (ExtranetLockoutThreshold) de solicitações de autenticação é atingido, o AD FS para de tentar autenticar as credenciais de conta fornecidas no AD FS para o período definido (ExtranetObservationWindow). Essa ação protege essa conta contra um bloqueio de conta do AD, ou seja, protege essa conta contra perda de acesso a recursos corporativos que dependem do AD FS para autenticação do usuário. Essas configurações se aplicam a todos os domínios que o serviço do AD FS pode autenticar.

Você pode usar o seguinte comando do Windows PowerShell para configurar o bloqueio de extranet do AD FS (exemplo):

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

Para obter referência, confira Como configurar o bloqueio de extranet do AD FS para saber mais sobre esse recurso.

Desabilitar pontos de extremidade do WS-Trust Windows no proxy da extranet

Os pontos de extremidade do WS-Trust Windows (/adfs/services/trust/2005/windowstransport e /adfs/services/trust/13/windowstransport) devem ser apenas pontos de extremidade voltados para a intranet que usam a associação WIA em HTTPS. Expor esses pontos de extremidade à extranet pode permitir que as solicitações contra eles ignorem as proteções de bloqueio. Esses pontos de extremidade devem ser desabilitados no proxy (ou seja, desabilitados na extranet) para proteger o bloqueio da conta do AD usando os comandos do PowerShell a seguir. Não há um impacto conhecido do usuário final ao desabilitar esses pontos de extremidade no proxy.

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

Diferenciar políticas de acesso para acesso à intranet e à extranet

O AD FS tem a capacidade de diferenciar as políticas de acesso para as solicitações originadas na rede corporativa local versus as solicitações que vêm da Internet por meio do proxy. Essa diferenciação pode ser feita por aplicativo ou globalmente. Para aplicativos de alto valor empresarial ou aplicativos com informações confidenciais, considere a necessidade de autenticação multifator. A autenticação multifator pode ser configurada por meio do snap-in de gerenciamento do AD FS.

Exigir MFA (autenticação multifator)

O AD FS pode ser configurado para exigir uma autenticação forte (como a autenticação multifator) especificamente para solicitações que chegam por meio do proxy, para aplicativos individuais e para acesso condicional a recursos locais e do Microsoft Entra ID/Office 365. Os métodos com suporte da MFA incluem o Microsoft Azure MF e provedores de terceiros. O usuário é solicitado a fornecer as informações adicionais (como um texto SMS que contém um código único) e o AD FS funciona com o plug-in específico do provedor para permitir o acesso.

Os provedores de MFA externos compatíveis incluem os listados na página Configurar métodos de autenticação adicionais para o AD FS.

Habilite a proteção para evitar o desvio da autenticação multifator do Microsoft Entra na nuvem quando federada com o Microsoft Entra ID

Habilite a proteção para evitar ignorar a autenticação multifator do Microsoft Entra na nuvem, quando federada com Microsoft Entra ID, e usar a Autenticação Multifator do Microsoft Entra como autenticação multifator para seus usuários federados.

Habilitar a proteção para um domínio federado no locatário do Microsoft Entra garantirá que a Autenticação Multifator do Microsoft Entra seja sempre executada, quando um usuário federado acessar um aplicativo regido por uma política de acesso condicional que exija a MFA. Isso inclui a execução da autenticação multifator do Microsoft Entra, mesmo quando o provedor de identidade federado tiver indicado (via tokens federados) que afirmem que a MFA no local foi executada. Impor a Autenticação Multifator do Microsoft Entra sempre garante que uma conta local comprometida não possa ignorar a Autenticação Multifator do Microsoft Entra, imitando que uma autenticação multifator já foi executada pelo provedor de identidade, e é altamente recomendada, a menos que você execute a MFA para seus usuários federados usando um provedor de MFA de terceiros.

A proteção pode ser habilitada usando uma nova configuração de segurança, federatedIdpMfaBehavior, que é exposta como parte dos cmdlets da API do MS Graph de Federação Interna ou do PowerShell do MS Graph. A configuração federatedIdpMfaBehavior determina se o Microsoft Entra ID aceita a MFA executada pelo provedor de identidade federada, quando um usuário federado acessa um aplicativo regido por uma política de acesso condicional que exige a MFA.

Os administradores podem escolher um dos seguintes valores:

Você pode habilitar a proteção definindo federatedIdpMfaBehavior como rejectMfaByFederatedIdp usando o comando a seguir.

API DO MS GRAPH

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

} 

Exemplo:

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

Exemplo:

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

Exemplo:

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

Módulo de segurança de hardware (HSM)

Na configuração padrão, as chaves que o AD FS usa para assinar tokens nunca deixam os servidores de federação na intranet. Eles nunca estão presentes no DMZ ou nos computadores de proxy. Opcionalmente, para fornecer mais proteção, recomendamos proteger essas chaves em um HSM (módulo de segurança de hardware) anexado ao AD FS. A Microsoft não faz um produto HSM. No entanto, há vários no mercado que dão suporte ao AD FS. Para implementar essa recomendação, siga as diretrizes do fornecedor para criar os certificados X509 para assinatura e criptografia e, em seguida, use os comandos do PowerShell de instalação do AD FS, especificando seus certificados personalizados da seguinte maneira:

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

onde:

• CertificateThumbprint é o certificado SSL
• SigningCertificateThumbprint é o certificado de autenticação (com chave protegida por HSM)
• DecryptionCertificateThumbprint é o certificado de criptografia (com chave protegida por HSM)