Como Instalar e Personalizar o ADFS 3.0

 

O serviço de Active Directory Federation Service nunca esteve tão em evidência como nestes últimos anos devido à adoção de serviços na nuvem pelas empresas. Conectar a identidade do Active Directory on-premises com serviços na nuvem pode ser uma desafio. Diferente dos protocolos NTLM e Kerberos que não foram desenvolvidos para a Internet o ADFS atua como um provedor de identidade para aplicações web modernas. Os desenvolvedores de software estão trabalhando com frameworks de desenvolvimento que remove do código a sua identidade e delega para um terceiro esta função. Você já deve ter acessado algum site de compra na Internet que além de permitir de criar uma usuário e senha também a opção de autenticar com sua conta do Facebook, Google ou Microsoft Live ID, estas empresas tem seus serviços de provedor de identidade. Na Microsoft exitem 3: Microsoft Live ID, Azure AD e ADFS.

O ADFS 3.0 suporta três protocolos de sign-in:

WS-Federation

• Desenvolvido por um grupo de empresas, incluindo Microsoft;
• Utilizado para integração com a plataforma .NET e produtos Microsoft (SharePoint, Azure, Dynamics CRM);
• Token no formato SAML 1.1;
• Mais informações em https://msdn.microsoft.com/en-us/library/ms951235.aspx e https://msdn.microsoft.com/en-us/library/bb498017.aspx.

SAML-P

• Desenvolvido por um comitê técnico do OASIS;
• Sigla de Security Assertion Markup Language (Linguagem de Marcação de Assertivas de Segurança);
• Padrão para intercâmbio de informações de autenticação e autorização entre diferentes domínios de segurança;
• Implementado como um protocolo baseado na troca de mensagens XML, atende a diversos cenários de aplicação web, incluindo SSO e propagação de identidade;
• Utilizado para integração com aplicações terceiras como: Oracle WebLogic, Lotus Notes e SAP;
• Token no formato SAML 2.0;
• Mais informações em https://go.microsoft.com/fwlink/?LinkId=193996.

OAuth

• Desenvolvido pelo Internet Engineering Task Force (IETF);
• Utilizado para integração com aplicações Single Page Application (SPA), Universal Windows Plataform (UWP) e mobile WindowsPhone, IOS e Android;
• Token no formato JWT – JSON Web Token;
• Mais informações em https://oauth.net/ e https://msdn.microsoft.com/en-us/library/dn633593.aspx.

 

Neste artigo vou explicar passo a passo e dar dicas para você instalar da melhor maneira o ADFS 3.0 no seu ambiente.

O ADFS 3.0 exige pouca memória, disco e processador e em 100% dos casos que trabalhei com ADFS as máquinas eram virtuais. 2 processadores, 4 GB de memória e 100 GB de disco são suficientes. O Windows Internal Database ( nativo no Windows Server ) também é uma barata e eficiente escolha como banco de dados e será usada neste exemplo.

O ADFS é totalmente sensível e dependente de certificados digitais, você precisará de 3, mas só um deles o Service Communications precisará ser público, confiável e válido na Internet. Não use certificados emitidos por Certificates Authorities Internas como o ADCS nem certificados autoassinados para esta finalidade, além de não confiável e não estar na lista de Trust Root Certificate Authorities das máquinas a lista de certificados revogados raramente estão disponíveis para consulta.

NÃO ECONOMIZE AQUI, COMPRE UM CERTIFICADO ! No meu laboratório usarei o certificado *.labpfe.com que foi emitido pela DigiCert válido por um ano. Importe o certificado na máquina com o respectiva chave privada. (já dá para notar que certificados Wild Card são suportados)

Se o seu Active Directory está no nivel functional WS 2012 / R2 poderá utilizar uma conta de serviço chamada gMSA ( Group Managed Service Accounts ). Diferente de uma conta de usuário que é usada como serviço a gMSA você não define uma senha explicitamente, existe uma negociação direta entre o serviço e o serviço de KDC ( key distributed center ) do Domain Controller correspondente. O principal benefício deste modelo é não afetar o serviço quando a senha expira ou é alterada. Fica a dica. Mas procure saber se o seu serviço suporta este tipo de conta, o ADFS suporta e vamos ensiná-lo/a como configure-lo.

Para habilitar o gMSA no Active Directory você precise executar o seguinte commando:

C:\Add-KdsRootKey

Você poderá ter que esperar até 10 horas depois deste commando para que este serviço esteja disponível em todos os controladores de domínio da floresta, não tenha pressa, aguarde este período.

No meu laboratório eu executei o commando forçandoa hora como se fosse 10 horas atrás permitindo que eu continuasse o setup do ambiente. NÃO FAÇA ISSO EM PRODUÇÃO. Faça por fases, execute o commando em um dia e o resto do setup no outro.

Uma dica rápida para ver o nível functional da floresta é executar o commando Get-ADForest

Instale a função Active Directory Federation Services

Aguarde o fim da instalação e em seguida clique no ícone para iniciar o setup de configuração. Escolha a opção Create the first federation server in a federation server farm.

IMPORTANTE: Não existe mais a opção em instalar em Standalone ( um único servidor ) mesmo que você tenha uma única máquina a criação em Farm Mode é mandatória.

Você precisa ser um Domain Admin configurar o ADFS não basta ser um Local Admin. Por padrão ele sugere o mesmo usuário que está “logado” na máquina.

No campo SSL Certificate escolha seu certificado, informe o nome da sua farm, no meu caso adfs.labpfe.com e o nome amigável que aparecerá na tela de login do ADFS Forms Based Authentication.

Aqui chegou a hora de informar a conta de serviço gMSA, só escolha este modelo se atendeu os requisites explicados no início deste artigo ( nivel functional da floresta e o Root Key habilitado e aguardado no mínimo 10 horas). No campo informe um nome para a conta, observe que não é necessário digitar uma senha. Caso contrário escolha a opção “Use an existing domain user account or group MSA” e informe uma conta e senha previamente criada no AD ( este conta pode ser Domain Users somente ).

Deixe a opção Create a database on this server using Windows Internal Database. Se preferir utilize um servidor SQL server existente. Lembre-se ! Se o seu SQL Server não estiver em Cluster e ficar indisponível toda autenticação no ADFS será comprometida.

Opcionalmente instale tudo pelo PowerShell, este é um exemplo do commando. Simples mas não muito usual porque você precisará ter o ThumbPrint do certificado em mãos.

Aguarde o fim do setup, em seguida abra o DNS Manager e crie um registro A com o nome da sua farm que foi definida no setup apontando para o IP do servidor.

IMPORTANTE : NÃO USE TIPO DE REGISTRO CNAME ( APELIDO ) POIS NÃO É SUPORTADO. SE EXISTIR UM BALANCEADOR DE CARGA DE REDE NA FRENTE APONTE PARA O ENDEREÇO IP VIP

Faça um teste simples de ping e veja se o novo da farm esta respondendo com sucesso.

DICA : Quando acessar o ADFS pela primeira vez inevitavelmente terá a segunte experiência : um pop up será aberto para autenticação e o single sign on não acontecerá. Isso acontece não por um problema no AFDS mas sim por uma característica do Internet Explorer que pelo fato de estar acessando um serviço com nome público neste caso adfs.labpfe.com o navegador acredita que não esta na intranet e sim na Internet. Para corrigir isso faça o seguinte : Abra o internet explorer na máquina do usuário ou na sua, escolha opções de Internet, guia security, escolha local intranet e clique no botão Sites, e depois em Advanced. Adicine aqui o endereço do seu ADFS iniciando em https:

É claro que aqui estará pensando em como fazer isso em massa/lote para vários computadores da rede, afinal todos eles terão que ter esta configuração. Recomendo este artigo que explica como fazer isso.

https://blog.thesysadmins.co.uk/group-policy-internet-explorer-security-zones.html

Uma vez configurado, acesse o endereço https://fqdnadfsname/adfs/ls/idpinitiatedsignon.aspx. No meu caso https://adfs.labpfe.com/adfs/ls/idpinitiatedsignon.aspx. Clique em Sign In. ( todo ADFS bem configurado precisa expor este endpoint na Internet).

Ao clicar em Sign In você deve ser autenticado diretamente ( isso é logon único, sso, foi aproveitado o token Kerberos da sua máquina). Se abrir um Pop up você não configurar o local intranet sites no item acima corretamente.

Dica agora sobre o certificado. Por padrão o certificado gerado para Token Signing e Decrypting é auto-assinado e válido por um ano. Um ano é muito pouco tempo em especial para o Token Signing.

Vamos definir um periodo maior de tempo para estes certificados, vamos alterar para 5 anos ou 1825 dias.

Podemos ver o resultado da alteração executando o commando Get-ADFSProperties

Execute os commandos abaixo para forçar de maneira urgente a alteração dos certificados Token Signing e Decrypting

Ao abrir a console do ADFS/Certificates, a data de expiração do certificado foi alterado para 2021 e não mais 2017 como originalmente ( 5 anos )

Outra dica bacana é alterar o logo de ilustração padrão do ADFS, aquela imagem grande Azul a esquerda do formulário.

Copie uma imagem com resolução 1420 x 1080 pixesls da sua preferência e execute o commando acima referenciando a imagem. Veja o resultado como ficou legal. Se você quer saber todos os commandos para alterar outras áreas do formulário leia este artigo: https://technet.microsoft.com/en-us/library/dn280950.aspx

DICA: O ADFS Proxy no ADFS 3.0 não existe mais. O serviço que expôe o ADFS na Internet agora se chama Web Appliction Proxy (WAP) e é uma subfeature do Remote Access e não mais do ADFS.

Não publique diretamente o ADFS na rede local diretamente na Internet. O WAP é alvo para um artigo dedicado somente para ele, pois além de atuar como ADFS Proxy ele tem outra função de publicação muito interessante que explicarei em um novo artigo. Até lá.