Práticas recomendadas para proteger os Serviços de Federação do Ative Directory

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

Este documento aplica-se ao AD FS e 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 AD FS na rede corporativa interna.
• Um ou mais servidores WAP (Web Application Proxy) em uma rede DMZ ou extranet.

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

Proteger os servidores AD FS

Segue-se uma lista de práticas recomendadas e sugestões para reforçar e proteger a implantação do AD FS:

• Certifique-se de que apenas os Administradores do Ative Directory e os Administradores do AD FS têm direitos de administrador para o sistema AD FS.
• Reduza a associação ao grupo Administradores local em todos os servidores AD FS.
• Exija que todos os administradores de nuvem usem autenticação multifator (MFA).
• Capacidade mínima de administração através de agentes.
• Limite o acesso na rede através do firewall do host.
• Certifique-se de que os administradores do AD FS usam estações de trabalho de administração para proteger suas credenciais.
• Coloque os objetos de computador do servidor AD FS em uma UO de nível superior que não hospede também outros servidores.
• Todos os GPOs que se aplicam a servidores AD FS devem aplicar-se apenas a eles e não a outros servidores também. Isso limita o possível escalonamento de privilégios por meio da modificação do 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 (certificados expirados quebram a autenticação de federação). Além disso, recomendamos proteger chaves/certificados de assinatura em um módulo de segurança de hardware (HSM) conectado ao AD FS.
• Defina o registo para o nível mais elevado e envie os registos do AD FS e segurança para um SIEM para correlação com a autenticação do AD, bem como com o AzureAD (ou similar).
• Remova protocolos desnecessários e recursos do Windows.
• Use uma senha longa (>25 caracteres) complexa para a conta de serviço do AD FS. Recomendamos o uso de uma Conta de Serviço Gerenciado de Grupo (gMSA) como a conta de serviço, pois elimina a necessidade de gerenciar a senha da conta de serviço ao longo do tempo, gerenciando-a automaticamente.
• Atualize para a versão mais recente do AD FS para melhorias de segurança e registro em log (como sempre, teste primeiro).

Portas necessárias

O diagrama abaixo mostra as portas de firewall que devem ser habilitadas entre e entre os componentes da implantação do AD FS e WAP. Se a implantação não incluir o Microsoft Entra ID / Office 365, os requisitos de sincronização podem 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 WAP (Proxy de Aplicativo Web) por meio da porta HTTP 80 para sincronização de configuração. Certifique-se de que apenas esses servidores podem se comunicar uns com os outros e nenhum outro é uma medida de defesa em profundidade.

As organizações podem atingir esse estado, configurando regras de firewall em cada servidor. As regras só devem permitir a comunicação de entrada dos endereços IP dos servidores no farm e nos servidores WAP. Alguns balanceadores de carga de rede (Network Load Balancers, NLB) utilizam a porta HTTP 80 para verificar o estado de saúde dos servidores de federação individuais. Certifique-se de incluir os endereços IP do NLB nas regras de firewall configuradas.

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

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

WAP e servidores de federação

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

WAP e Utilizadores

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

Para obter informações sobre portas e protocolos necessários para implantações híbridas, consulte 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 do Office 365, consulte o documento URL e intervalos de endereços IP do Office 365.

Endpoints ativados

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 comumente exigidos e usados e não é necessário alterá-los.

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

As organizações que implantam AD FS e WAP apenas para cenários de ID do Microsoft Entra e Office 365 podem limitar ainda mais o número de pontos de extremidade do AD FS habilitados no proxy para conseguir uma superfície de ataque ainda mais reduzida. Abaixo está a lista de pontos de extremidade que devem ser habilitados no proxy nesses cenários:

Os pontos de extremidade do AD FS podem ser desativados 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 ataques man in the middle (MITM) e é habilitada por padrão com o AD FS. A configuração pode ser verificada usando o cmdlet PowerShell abaixo:

Get-ADFSProperties

A propriedade é ExtendedProtectionTokenCheck. A configuração padrão é Permitir, para que os benefícios de segurança possam ser alcançados sem as preocupações de compatibilidade com navegadores que não suportam o recurso.

Gestão 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 AD FS de uma enxurrada de solicitações. O Proxy de Aplicativo Web rejeitará solicitações de autenticação de cliente externo se o servidor de federação estiver sobrecarregado conforme detetado pela latência entre o Proxy de 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. Inicie uma janela de comando com privilégios elevados no computador que tem o Proxy de Aplicações Web.
2. Navegue até o diretório do AD FS, em %WINDIR%\adfs\config.
3. Altere as configurações de controle de congestionamento de seus 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 orientação sobre esse recurso, consulte Configurar o acesso à extranet para 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 relação a todo o tráfego:

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

Configurações de segurança recomendadas

Certifique-se de que todos os servidores AD FS e 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 um meio para manter seus servidores AD FS e WAP atualizados 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 uma máquina AD FS ou WAP estiver faltando uma das atualizações importantes especificamente para AD FS e WAP.

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

Práticas recomendadas para proteger e monitorar a confiança do AD FS com a ID do Microsoft Entra

Quando você federa seu AD FS com a ID do Microsoft Entra, é fundamental que a configuração de federação (relação de confiança configurada entre o AD FS e a ID do Microsoft Entra) seja monitorada de perto e qualquer atividade incomum ou suspeita seja capturada. Para fazer isso, recomendamos configurar alertas e ser notificado sempre que forem feitas alterações na configuração da federação. Para saber como configurar alertas, consulte Monitorar alterações na configuração da federação.

Configurações de segurança adicionais

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

Proteção de "bloqueio suave" para contas na extranet

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 observation window período de tempo (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 pelo período de tempo definido (ExtranetObservationWindow). Essa ação protege essa conta de um bloqueio de conta do AD, ou seja, protege essa conta contra a 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 AD FS pode autenticar.

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

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

Para referência, consulte Configurando o bloqueio de extranet do AD FS para saber mais sobre esse recurso.

Desativar pontos de extremidade do Windows WS-Trust no proxy na extranet

WS-Trust endpoints do Windows (/adfs/services/trust/2005/windowstransport e /adfs/services/trust/13/windowstransport) destinam-se apenas a ser endpoints voltados para a intranet que usam a ligação WIA em HTTPS. Expor-lhes à extranet pode permitir que solicitações contra estes endpoints ignorem as proteções de bloqueio de conta. Estes endpoints devem ser desabilitados no proxy (isto é, desabilitados da extranet) para proteger as contas AD de bloqueio, usando os seguintes comandos do PowerShell. Não há nenhum impacto conhecido sobre o utilizador final ao desativar 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 solicitações originadas na rede corporativa local das solicitações que chegam da Internet por meio do proxy. Esta diferenciação pode ser feita por aplicação ou globalmente. Para aplicativos de alto valor comercial ou aplicativos com informações confidenciais, considere exigir autenticação multifator. A autenticação multifator pode ser configurada por meio do snap-in de gerenciamento do AD FS.

Exigir a autenticação multifator (MFA)

O AD FS pode ser configurado para exigir autenticação forte (como autenticação multifator) especificamente para solicitações recebidas por meio do proxy, para aplicativos individuais e para acesso condicional ao Microsoft Entra ID / Office 365 e recursos locais. Os métodos suportados de MFA incluem o Microsoft Azure MF e fornecedores de terceiros. O usuário é solicitado a fornecer as informações adicionais (como um texto SMS contendo 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 com suporte incluem aqueles listados na página Configurar métodos de autenticação adicionais para AD FS .

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

Ative a proteção para prevenir a evasão da autenticação multifator do Microsoft Entra quando federado com o Microsoft Entra ID e utilizando a mesma autenticação multifator para os seus utilizadores federados.

Habilitar a proteção para um domínio federado em seu 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 que é regido por uma política de acesso condicional que requer MFA. Isso inclui a execução da autenticação multifator do Microsoft Entra, mesmo quando o provedor de identidade federada tenha indicado (por meio de declarações de token federado) que a autenticação multifator local foi executada. A imposição constante da autenticação multifator pelo Microsoft Entra assegura que uma conta local comprometida na infraestrutura não possa contornar a autenticação multifator do Microsoft Entra, simulando que essa autenticação já foi realizada pelo provedor de identidade. Esta prática é altamente recomendada, exceto se realizar MFA para os seus utilizadores federados através de um provedor de MFA terceiro.

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

Os administradores podem escolher um dos seguintes valores:

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

MS GRAPH API

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

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

} 

Example:

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

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

Example:

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

Example:

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

Módulo de Segurança de Hardware (HSM)

Em sua configuração padrão, as chaves que o AD FS usa para assinar tokens nunca saem dos servidores de federação na intranet. Eles nunca estão presentes na DMZ ou nas máquinas proxy. Opcionalmente, para fornecer mais proteção, recomendamos proteger essas chaves em um módulo de segurança de hardware (HSM) conectado ao AD FS. A Microsoft não produz um produto HSM, no entanto, existem vários no mercado que suportam AD FS. Para implementar essa recomendação, siga as orientações do fornecedor para criar os certificados X509 para assinatura e criptografia e, em seguida, use os commandlets 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>

where:

• CertificateThumbprint é o seu certificado SSL
• SigningCertificateThumbprint é o seu certificado de assinatura (com chave protegida HSM)
• DecryptionCertificateThumbprint é o seu certificado de encriptação (com chave protegida HSM)