O Microsoft Active Directory Federation Services (AD FS) permite que organizações que hospedam aplicativos no Windows Server estendam o acesso de logon único (SSO) a funcionários de parceiros comerciais confiáveis por meio de uma extranet. O compartilhamento de informações de identidade entre parceiros comerciais é chamado de federação .
Na prática, usar o AD FS significa que os funcionários de empresas em uma federação só precisam efetuar login em seu ambiente local. Quando eles acessam um aplicativo da Web pertencente a um parceiro comercial confiável, o servidor AD FS local passa suas informações de identificação para o servidor AD FS do parceiro na forma de um token de segurança. O token consiste em várias declarações , que são atributos individuais do funcionário (nome de usuário, função comercial, ID do funcionário e assim por diante) armazenados no Active Directory local. O servidor AD FS do parceiro mapeia as declarações no token para declarações entendidas pelos aplicativos do parceiro e, em seguida, determina se o funcionário está autorizado para o tipo de acesso solicitado.
Para o AD FS 2.0 e versões posteriores, você pode habilitar alta disponibilidade (HA), adicionando resiliência e escala aos serviços de autenticação para seus aplicativos. Em um cluster de alta disponibilidade do AD FS, também conhecido como farm do AD FS, vários servidores do AD FS são implantados em um único data center ou distribuídos entre data centers. Um cluster configurado para HA totalmente ativo precisa de um balanceador de carga para distribuir o tráfego uniformemente entre os servidores do AD FS. Em uma implantação de HA ativa-passiva, o balanceador de carga pode fornecer failover para o servidor AD FS de backup quando o primário falha.
Esta postagem explica como configurar o NGINX Plus para fornecer HA em ambientes executando AD FS 3.0 e AD FS 4.0 Server 2012 R2 e Windows Server 2016 , respectivamente.
Esta postagem usa uma topologia de farm padrão do AD FS para fins de ilustração. Não se pretende que seja uma recomendação nem que abranja todos os cenários de implantação possíveis. Para implantações locais, um farm padrão consiste em um ou mais servidores AD FS na intranet corporativa, liderados por um ou mais servidores Web Application Proxy (WAP) em uma rede DMZ. Os servidores WAP atuam como proxies reversos que permitem que usuários externos acessem os aplicativos da web hospedados na intranet corporativa.
No entanto, o WAP não tem uma maneira integrada de configurar um cluster de servidores ou oferecer suporte a HA, portanto, um balanceador de carga deve ser implantado na frente dos servidores WAP. Um balanceador de carga também é colocado na fronteira entre a DMZ e a intranet, para habilitar HA para o AD FS. Em um farm padrão do AD FS, o recurso de balanceamento de carga de rede (NLB) do Windows Server 2012 e 2016 atua como balanceador de carga. Por fim, os firewalls geralmente são implementados na frente do endereço IP externo do balanceador de carga e entre zonas de rede.
Conforme observado, o NLB pode executar o balanceamento de carga para um farm do AD FS. No entanto, seu conjunto de recursos é bastante básico (apenas verificações básicas de integridade e recursos limitados de monitoramento). O NGINX Plus tem muitos recursos essenciais para HA em ambientes de produção do AD FS e ainda é leve.
Na implantação da topologia padrão descrita aqui, o NGINX Plus substitui o NLB para balancear a carga do tráfego para todos os farms WAP e AD FS. Observe, no entanto, que não fazemos com que o NGINX Plus encerre as conexões SSL para os servidores AD FS, porque a operação correta do AD FS exige que ele veja o certificado SSL real do servidor WAP (para obter detalhes, consulte este artigo do Microsoft TechNet ).
Recomendamos que em ambientes de produção você também implemente HA para o próprio NGINX Plus, mas não mostre isso aqui; para obter instruções, consulte Suporte de alta disponibilidade para NGINX Plus em implantações locais no Guia de administração do NGINX Plus.
A configuração do NGINX Plus para balanceamento de carga de servidores AD FS é simples. Conforme mencionado acima, um servidor AD FS deve ver o certificado SSL real de um servidor WAP, então configuramos a instância do NGINX Plus na fronteira da intranet DMZ para passar tráfego criptografado SSL para os servidores AD FS sem encerrá-lo ou processá-lo de outra forma.
Além das diretivas obrigatórias, incluímos estas diretivas na configuração:
zona
aloca uma área na memória compartilhada onde todos os processos de trabalho do NGINX Plus podem acessar informações de configuração e estado de tempo de execução sobre os servidores no grupo upstream.O hash
estabelece a persistência da sessão entre clientes e servidores AD FS, com base no endereço IP de origem (do cliente). Isso é necessário mesmo que os clientes estabeleçam uma única conexão TCP com um servidor AD FS, porque sob certas condições alguns aplicativos podem sofrer vários redirecionamentos de login se a persistência de sessão não estiver habilitada.status_zone
significa que a API NGINX Plus coleta métricas para este servidor, que podem ser exibidas no painel de monitoramento de atividades ao vivo integrado (a API e o painel são configurados separadamente ).fluxo { upstream adfs_ssl { zona adfs_ssl 64k ; servidor 10.11.0.5:443; # servidor AD FS 1 servidor 10.11.0.6:443; # servidor AD FS 2 hash $remote_addr ; } servidor { status_zone adfs_ssl ; ouvir 10.0.5.15:443; proxy_pass adfs_ssl; } }
Para que o tráfego dos servidores WAP flua através do NGINX Plus para os servidores AD FS, também precisamos mapear o nome do serviço de federação ( fs.example.com em nosso exemplo) para o endereço IP que o NGINX Plus está escutando. Para implantações de produção, adicione um registro DNS Host A
na DMZ. Para implantações de teste, é suficiente criar uma entrada no arquivo hosts em cada servidor WAP; é isso que estamos fazendo aqui, vinculando fs.example.com a 10.0.5.15 em um arquivo hosts :
Para testar se o tráfego dos servidores WAP chega aos servidores AD FS, executamos o comando ipconfig
/flushdns
para liberar o DNS e, em seguida, em nosso navegador, efetuamos login no AD FS na página SSO, https://fs.example.com/adfs/ls/idpinitiatedsignon.htm :
Agora configuramos o NGINX Plus para balancear a carga de conexões HTTPS de clientes externos para os servidores WAP. As práticas recomendadas determinam que o tráfego ainda seja criptografado por SSL quando chega aos servidores AD FS, então usamos uma das duas abordagens para configurar o NGINX Plus para passar tráfego HTTPS para os servidores WAP: Passagem SSL ou recriptografia SSL.
A configuração mais fácil é fazer com que o NGINX Plus encaminhe o tráfego TCP criptografado por SSL inalterado para os servidores WAP. Para isso, configuramos um servidor virtual no contexto de fluxo
semelhante ao anterior para balanceamento de carga dos servidores AD FS .
Aqui, o NGINX Plus escuta o tráfego externo em um endereço IP exclusivo diferente, 10.0.5.100. Para ambientes de produção, o FQDN externo do aplicativo publicado deve apontar para esse endereço na forma de um registro DNS Host A
na zona pública. Para testes, uma entrada no arquivo hosts da sua máquina cliente é suficiente.
Observação: Se você for configurar serviços HTTPS adicionais no contexto de fluxo
para escutar no mesmo endereço IP que este servidor, deverá habilitar a Indicação de Nome do Servidor (SNI) usando a diretiva ssl_preread
com um mapa para rotear o tráfego para diferentes upstreams corretamente. Isso está fora do escopo deste blog, mas a documentação de referência do NGINX inclui exemplos .
fluxo { upstream wap {
zona wap 64k;
servidor 10.11.0.5:443; # servidor WAP 1
servidor 10.11.0.6:443; # servidor WAP 2
conexão de menor_tempo;
}
servidor {
zona_de_status wap_adfs;
ouvir 10.0.5.100:443;
senha_proxy wap;
}
}
Como alternativa ao SSL pass‑through, podemos aproveitar todos os recursos da Camada 7 do NGINX Plus configurando um servidor virtual no contexto http
para aceitar tráfego HTTPS. O NGINX Plus encerra as conexões HTTPS dos clientes e cria novas conexões HTTPS com os servidores WAP.
Os arquivos de certificado e chave secreta, example.com.crt e example.com.key , contêm o FQDN externo do aplicativo publicado na propriedade Nome Comum ( CN
) ou Nome Alternativo do Assunto ( SAN
); neste exemplo, o FQDN é fs.example.com .
As diretivas proxy_ssl_server_name
e proxy_ssl_name
habilitam o cabeçalho Server Name Indication (SNI) necessário, especificando um nome de host remoto a ser enviado no SSL Client Hello. O cabeçalho deve corresponder ao FQDN externo do aplicativo publicado, neste exemplo fs.example.com .
Usamos diretivas proxy_set_header
para passar informações relevantes aos servidores WAP e também para que possamos capturá-las nos logs:
X-Real-IP
contém o endereço IP de origem (cliente) conforme capturado na variável $remote_addr
.X-Forwarded-For
transmite esse cabeçalho da solicitação do cliente, com o endereço IP do cliente anexado a ele (ou apenas esse endereço, se a solicitação do cliente não tiver o cabeçalho).x-ms-proxy
indica que o usuário foi roteado por meio de um servidor proxy e identifica a instância do NGINX Plus como esse servidor.Além das diretivas mostradas aqui, o NGINX e o NGINX Plus fornecem uma série de recursos que podem melhorar o desempenho e a segurança do SSL/TLS. Para mais informações, consulte nosso blog .
http { upstream wap { zona wap 64k; servidor 10.0.5.11:443; servidor 10.0.5.10:443; cabeçalho least_time; } servidor { escuta 10.0.5.100:443 ssl; zona_de_status fs.example.com; nome_do_servidor fs.example.com; certificado_ssl /etc/ssl/example.com/example.com.crt; chave_do_certificado_ssl /etc/ssl/example.com/example.com.key; localização / { proxy_pass https://wap; # 'https' habilita a recriptografia proxy_ssl_server_name em ; proxy_ssl_name $host ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Encaminhado-Para $proxy_add_x_forwarded_for; proxy_set_header x-ms-proxy $server_name; } } }
Ao permitir que clientes externos acessem seus servidores AD FS, é uma prática recomendada encerrar o tráfego externo na fronteira entre a DMZ e a intranet corporativa e também identificar tentativas de autenticação externa inserindo o cabeçalho x-ms-proxy
. Os servidores WAP executam ambas as funções, mas, conforme configurado na seção anterior, o NGINX Plus também o faz.
Os servidores WAP não são necessários para alguns casos de uso – por exemplo, quando você não usa regras de reivindicação avançadas, como rede IP e níveis de confiança. Nesses casos, você pode eliminar servidores WAP e colocar o NGINX Plus na fronteira entre a DMZ e a intranet para autenticar solicitações para servidores AD FS internos. Isso reduz seus custos de hardware, software e operacionais.
Esta configuração substitui as da topologia HA padrão . É quase idêntico à configuração de reencriptação HTTPS para balanceamento de carga de servidores WAP, mas aqui o NGINX Plus balanceia a carga de solicitações externas diretamente para os servidores AD FS na rede interna.
upstream adfs { zona adfs 64k;
servidor 192.168.5.5:443; # Servidor AD FS 1
servidor 192.168.5.6:443; # Servidor AD FS 2
cabeçalho least_time;
}
servidor {
escuta 10.0.5.110:443 ssl;
zona_de_status adfs_proxy;
nome_do_servidor fs.example.com;
certificado_ssl /etc/ssl/example.com/example.com.crt;
chave_do_certificado_ssl /etc/ssl/example.com/example.com.key;
localização / {
senha_proxy https://adfs;
nome_do_servidor_proxy_ssl on;
nome_do_servidor_proxy $host;
cabeçalho_do_conjunto_de_proxy Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header x-ms-proxy $server_name;
}
}
Experimente o NGINX Plus na sua implantação do AD FS – comece hoje mesmo uma avaliação gratuita de 30 dias ou entre em contato conosco para discutir seu caso de uso.
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."