Dois novos serviços híbridos da Microsoft simplificam drasticamente a ligação do Active Directory ao Azure

A Microsoft anunciou recentemente a pré-visualização pública de duas novas funcionalidades importantes que tornarão a integração do seu Active Directory local com o Azure AD muito, muito mais fácil. A autenticação de passagem (PTA) e o Início de Sessão Único Sem Interrupções (vou chamá-lo de 3SO) permitirão que os seus utilizadores acedam facilmente a aplicações do Azure AD, como o Office 365, sem terem de instalar um complexo conjunto de servidores do Active Directory Federation Services (AD FS) no seu centro de dados nem sincronizar os hashes das palavras-passe dos utilizadores com o Azure AD.

Ou, no caso do 3SO, instalar qualquer coisa extra.

Opções de autenticação híbrida até agora (e as suas limitações)

A grande maioria das empresas utiliza hoje o Active Directory como serviço de identidade fundamental, e este não vai desaparecer tão cedo. Assim, uma primeira tarefa básica ao planear a utilização de qualquer um dos serviços online da Microsoft consiste em integrar o Active Directory local com o Azure AD para obter duas funcionalidades. Em primeiro lugar, é necessário sincronizar as contas e os grupos do AD com o Azure AD utilizando o Azure AD Connect. Em segundo lugar, assim que as contas estiverem no Azure AD, deve escolher como autenticar os utilizadores nesse serviço. Neste artigo, vou centrar-me nos aspetos relacionados com a autenticação de utilizadores.

Atualmente, a Microsoft oferece duas opções de autenticação: o AD FS, que proporciona federação de identidades (e várias outras funcionalidades) para o SSO, e a sincronização de palavras-passe («PHS» nos gráficos abaixo). Esta segunda opção, conhecida entre os especialistas em tecnologia como sincronização de hash de palavras-passe (daí o «H»), oferece uma funcionalidade de «início de sessão único», em que o utilizador tem de introduzir as credenciais uma segunda vez para iniciar sessão no Azure AD, mas trata-se do mesmo nome de utilizador e da mesma palavra-passe que utiliza no Active Directory.

O gestor do programa de autenticação de passagem da Microsoft, Ross Adams, representa as diferenças entre estas soluções neste gráfico inteligente de benefícios/dores (Figura 1):

Por ordem crescente de complexidade e valor, temos

• Contas exclusivamente na nuvem: as contas de utilizador são geridas e autenticadas no Azure AD. Como neste artigo estamos a falar de soluções híbridas, não vamos aprofundar este assunto.
• AAD Connect / Contas na nuvem: É possível utilizar o Azure AD Connect para sincronizar contas de utilizador com o Azure AD, de modo a que o ID de início de sessão (normalmente o endereço de e-mail do utilizador) seja o mesmo, mas os utilizadores têm de gerir as suas próprias palavras-passe no serviço na nuvem. Não vejo ninguém a fazer isto.
• AAD Connect + PHS: Quando activa a funcionalidade opcional de sincronização de hash de palavra-passe no Azure AD Connect, os hashes de palavra-passe do utilizador armazenados no Active Directory local serão sincronizados no Azure AD, permitindo assim o mesmo início de sessão.
• AAD Connect + AD FS: A solução mais completa e mais complexa por uma boa margem, esta combinação fornecerá SSO ao Azure AD, autenticando as contas no seu Active Directory local.

Como se pode ver, existe uma grande lacuna na complexidade da implementação para integrar um verdadeiro SSO na sua organização. As soluções de terceiros da Okta, Ping Identity, OneLogin, Centrify, OptimalIDM e outras oferecem métodos mais simples de autenticação que preenchem essa lacuna, e essa é uma das razões da sua popularidade.

Windows ligado ao domínio... e tudo o resto

Para compreender o que estas duas novas soluções, atualmente em pré-visualização pública, oferecem, é útil agrupar os casos de utilização de autenticação em duas categorias: ou o cliente a ser autenticado pelo Azure AD possui um bilhete Kerberos, ou não o possui.

O primeiro é o cenário clássico de autenticação corporativa do Windows, conhecido como Autenticação Integrada do Windows (IWA). Um utilizador que tenha iniciado sessão na sua estação de trabalho Windows, integrada no domínio, com uma conta do AD, na rede corporativa (ou seja, a estação de trabalho consegue localizar um controlador de domínio) e que, por isso, possua um bilhete Kerberos, obtém acesso imediato a recursos compatíveis com o AD sem que lhe seja solicitado que introduza a sua palavra-passe. Este cenário existe desde que o Active Directory foi criado.

O segundo balde representa os outros cenários de autenticação que evoluíram desde então:

• Uma estação de trabalho ligada ao domínio a tentar autenticar-se a partir do exterior da rede (o computador portátil)
• Um cliente baseado num navegador, quer se trate de um computador ou de um dispositivo móvel (o navegador da Web)
• Um cliente baseado em API, como uma aplicação do Office (a aplicação móvel)

Vamos analisar primeiro o cenário das estações de trabalho integradas no domínio e a elegante solução da Microsoft que utiliza o 3SO.

O que é o início de sessão único sem descontinuidades?

A solução 3SO foi concebida para funcionar com o primeiro "bucket" - o PC ligado ao domínio na rede empresarial. A elegância da solução 3SO pode ser resumida em apenas algumas palavras: O Azure AD pode agora suportar a autenticação Kerberos.

É isso mesmo. Em essência, o principal objetivo do AD FS é transformar um bilhete Kerberos num token de segurança SAML ou OAuth moderno que uma entidade confiável, como o Azure AD, possa utilizar. Se o Azure AD for capaz de interpretar um bilhete Kerberos – especificamente um bilhete de serviço para um recurso do Azure –, não é necessário que o AD FS atue como intermediário para efetuar essa conversão.

A Figura 2 mostra como isto é feito. O Azure AD é representado no seu AD local como mais um computador; o AD não percebe a diferença. É adicionada uma conta de computador (AZUREADSSOACCT) ao seu AD e, com ela, dois SPNs (nomes de entidade de serviço) que contêm os URLs necessários para realizar a autenticação. A chave secreta Kerberos da conta da estação de trabalho é partilhada de forma segura com o Azure AD. A partir deste momento, os clientes utilizam o IWA para aceder aos recursos do Azure, tal como fariam para aceder a um servidor IIS no seu centro de dados local.

1. Um utilizador tenta aceder a um recurso do Azure AD, como o Office 365. O Azure AD desafia o utilizador a fornecer um bilhete de serviço Kerberos.
2. O cliente apresenta o seu TGT (bilhete de concessão de bilhete) e o SPN do servidor de destino (um URL do Azure AD, neste caso) ao seu controlador de domínio.
3. O serviço de emissão de bilhetes (TGS) no centro de distribuição de chaves (KDC) do controlador de domínio cria um bilhete de serviço para o recurso do Azure AD e devolve-o ao cliente.
4. O cliente apresenta o bilhete de serviço ao Azure AD. Assumindo que o bilhete é válido, o utilizador é autenticado.

Note que este processo não significa que o utilizador esteja autorizado a aceder ao recurso; significa apenas que confirmou a sua identidade. O resultado é que um utilizador Windows da empresa que se encontre na rede não é solicitado a introduzir uma palavra-passe para aceder aos recursos do Azure AD, e o AD FS não é necessário. Muito prático, não é?

A instalação do 3SO não poderia ser mais simples; basta marcar a caixa de seleção «Ativar início de sessão único» na configuração personalizada da versão mais recente do AD Connect.

Clientes apoiados

Existem algumas configurações compatíveis com o 3SO. Em primeiro lugar, tem de ser um cliente compatível com Kerberos, como o Windows. Em segundo lugar, funciona para aceder a recursos do Azure AD através de um navegador (por exemplo , https://outlook.office.com) ou a partir de um cliente do Office que suporte a autenticação moderna. Pode consultar a lista de clientes suportados, mas, essencialmente, é suportado em todos os principais navegadores (IE, Chrome, Firefox), exceto o Edge, e em todos os sistemas operativos cliente da Microsoft suportados. A Microsoft recomenda ativar o 3SO em todos os clientes; se o utilizador estiver numa configuração não suportada, o pior que pode acontecer é receber um pedido de introdução da palavra-passe.

O que é a autenticação de passagem?

O PTA foi concebido para situações em que o cliente não dispõe de um bilhete Kerberos, quer porque o cliente Kerberos não consegue estabelecer ligação a um DC (por exemplo, quando um colaborador está a trabalhar a partir de casa no seu portátil da empresa), quer porque o cliente não suporta Kerberos (por exemplo, um navegador móvel ou uma aplicação que não suporta autenticação moderna).

Não vou abordar aqui a forma de instalar o PTA, mas, essencialmente, implementa-se um ou mais conectores «lightweight» no local, muito semelhantes ao conector do Azure AD Application Proxy, em servidores integrados no domínio, onde possam comunicar com um DC.

A um nível elevado, o processo de autenticação PTA é muito semelhante ao processo de autenticação AD FS: O Azure AD reconhece que o pedido de autenticação é delegado a um Active Directory no local através de um proxy. Para o AD FS, actua como o proxy. Para o PTA, os conectores actuam como proxy (Figura 3).

1. O Azure AD pede ao utilizador para se autenticar e este introduz o seu endereço de correio electrónico e a palavra-passe.
2. O Azure AD determina que o domínio do utilizador está configurado para PTA; o Azure AD notifica o conector, que recupera as credenciais.
3. O conector autentica o utilizador em relação ao AD utilizando a mesma API do Windows que o AD FS utiliza.
4. A resposta é devolvida ao conector.
5. O conector encaminha a resposta para o Azure AD.
6. O Azure AD emite um token para o utilizador.

Pode ver que isto tem muitas vantagens em relação ao AD FS:

• Os conectores podem ser instalados em servidores ou DCs existentes, ligados ao domínio.
• Quando estão instalados vários conectores (recomendado), o PTA equilibra automaticamente a carga entre eles
• Todas as ligações Azure são de saída e nenhum ponto final não autenticado é exposto à Internet
• É muito simples de gerir a partir do Portal do Azure e não há certificados para gerir

Quando é que ainda quer utilizar o AD FS?

Não se engane; o AD FS não foi de forma alguma posto de lado. O PTA é uma seta muito especializada para um único alvo: permite que o Azure AD autentique utilizadores do Active Directory em relação ao AD empresarial, ponto final. Ainda precisa do AD FS se

• Pretende utilizar cartões inteligentes para autenticação
• Pretende utilizar fornecedores de MFA de terceiros
• A política de segurança da sua empresa exige que as palavras-passe permaneçam sempre nas instalações (ao contrário do AD FS, no PTA a palavra-passe do utilizador é introduzida no Azure AD antes de ser transferida para as instalações)
• Utiliza as regras de autenticação adicionais do AD FS para impor o acesso condicional
• Utiliza o acesso condicional do Windows 10 no local com base no dispositivo

E, claro, é necessário ter o AD FS se tiver partes confiantes configuradas localmente para fornecer o SSO e não pretender migrá-las para o Azure AD.

O AD FS 2016 também oferece novas funcionalidades, como o suporte Azure MFA incorporado; se tiver uma implementação AD FS existente, analise cuidadosamente as suas necessidades futuras e o que o AD FS pode fazer antes de considerar a sua eliminação como medida de poupança de custos.

Opções de autenticação híbrida agora

A Microsoft oferece agora um conjunto muito mais completo de opções de autenticação híbrida (Figura 4):

As opções originais continuam disponíveis, mas agora é possível obter um excelente valor acrescentado com muito pouca complexidade adicional. Se estiver a utilizar a sincronização de palavras-passe, a adição do 3SO eliminará os desafios de autenticação para os utilizadores corporativos na rede. Se, em vez disso, ativar o PTA juntamente com o 3SO, terá praticamente o mesmo valor que o AD FS para o caso de utilização específico da autenticação do Azure AD.

Com a pré-visualização pública do 3SO e da autenticação passthrough, a Microsoft reduziu drasticamente as barreiras à adoção de uma estratégia de identidade híbrida utilizando as ferramentas nativas da empresa. Na verdade, estas ferramentas são ainda mais simples de utilizar do que as soluções de terceiros que têm vindo a tirar partido da complexidade do AD FS.

E, caso não tenha ficado claro, tudo isto é gratuito. A Microsoft apostou o seu futuro nos seus serviços na nuvem Azure. A empresa pretende facilitar ao máximo a adoção destes serviços e, no mundo atual centrado no Active Directory, isso significa tornar a integração do AD com o Azure AD rápida e simples. Demorou uma eternidade a concretizar estas funcionalidades, mas prevejo que se tornarão rapidamente a ponte de identidade mais popular entre a identidade Microsoft local e a identidade Microsoft na nuvem.