Sean Deuby

A Microsoft anunciou recentemente a pré-visualização pública de duas novas capacidades importantes que tornarão a integração do seu Active Directory local no Azure AD muito, muito mais fácil. A autenticação de passagem (PTA) e o início de sessão único contínuo (opto por lhe chamar 3SO) permitirão que os seus utilizadores acedam facilmente a aplicações do Azure AD, como o Office 365, sem instalar um complicado farm dos Serviços de Federação do Active Directory (AD FS) no seu centro de dados ou sincronizar hashes de palavras-passe de utilizador 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)

Actualmente, a grande maioria das empresas tem o Active Directory como um serviço de identidade de base, e não vai desaparecer tão cedo. Assim, uma primeira tarefa básica quando se planeia utilizar qualquer um dos serviços online da Microsoft é integrar o Active Directory local com o Azure AD para duas capacidades. 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, depois de as contas estarem no Azure AD, tem de escolher a forma de autenticar os utilizadores. Nesta publicação, vou concentrar-me nos bits de autenticação do utilizador.

Actualmente, existem duas opções de autenticação da Microsoft: O AD FS, que fornece a federação de identidades (e várias outras capacidades) para o SSO, e a sincronização de palavras-passe ("PHS" nos gráficos abaixo). Esta segunda opção, conhecida pelos digerati como sincronização de hash de palavra-passe (daí o "H"), fornece uma capacidade de "mesmo início de sessão" em que o utilizador tem de introduzir credenciais uma segunda vez para iniciar sessão no Azure AD, mas são o mesmo ID de utilizador e palavra-passe que utiliza para o 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):

Figura 1: Opções de autenticação herdadas do Azure AD (Microsoft)
Figura 1: Opções de autenticação herdadas do Azure AD (Microsoft)

Por ordem crescente de complexidade e valor, temos

  • Contas apenas na nuvem: As contas de utilizador são mantidas e autenticadas no Azure AD. Estamos a falar de soluções híbridas neste post, por isso vamos deixar isto em paz.
  • Contas do AAD Connect / Nuvem: Pode utilizar o Azure AD Connect para sincronizar contas de utilizador no Azure AD para que o ID de início de sessão (normalmente o endereço de correio electrónico do utilizador) seja o mesmo, mas os utilizadores têm de manter as suas próprias palavras-passe no serviço de nuvem. Não estou a ver 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 pode ver, existe uma grande lacuna na complexidade da implementação para obter 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 se enquadram nesta 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 em pré-visualização pública estão a fornecer, é útil agrupar os casos de utilização de autenticação em dois grupos: o cliente a ser autenticado pelo Azure AD tem um bilhete Kerberos ou não tem.

O primeiro é o cenário clássico de autenticação empresarial do Windows, conhecido como Autenticação Integrada do Windows (IWA). Um utilizador que tenha iniciado sessão na sua estação de trabalho Windows ligada ao domínio com uma conta AD, na rede empresarial (ou seja, a estação de trabalho pode encontrar um controlador de domínio) e que, por conseguinte, tenha um bilhete Kerberos, obtém acesso contínuo a recursos com reconhecimento AD sem que lhe seja pedido que introduza a sua palavra-passe. Este cenário existe desde que o Active Directory foi inventado.

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 no navegador, quer seja num computador de secretária ou num cliente móvel (o navegador Web)
  • Um cliente baseado em API, como uma aplicação do Office (a aplicação móvel)

Vejamos primeiro o cenário da estação de trabalho ligada ao domínio e a solução elegante da Microsoft utilizando 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. Resumido à sua essência, o principal objectivo do AD FS é transformar um bilhete Kerberos num token de segurança SAML ou OAuth moderno que uma parte confiável, como o Azure AD, pode utilizar. Se o Azure AD conseguir compreender um bilhete Kerberos - especificamente um bilhete de serviço para um recurso Azure - não precisa do intermediário AD FS para fazer a tradução.

A Figura 2 mostra como isto é feito. O Azure AD é representado no seu AD local como apenas outro computador; o AD não sabe a diferença. É adicionada uma conta de computador (AZUREADSSOACCT) ao seu AD e, com ela, dois SPNs (nomes de entidades de serviço) que contêm os URLs necessários para efectuar a autenticação. A chave secreta Kerberos para a 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 podem aceder a um servidor IIS no seu centro de dados local.

Figura 2: SSO sem descontinuidades para o Azure AD (Microsoft)
Figura 2: SSO sem descontinuidades para o Azure AD (Microsoft)
  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 concessã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 está autorizado a aceder ao recurso; apenas que autenticou a sua identidade. O resultado é que não é pedido a um utilizador do Windows empresarial na rede que introduza uma palavra-passe para aceder aos recursos do Azure AD, e o AD FS não é necessário. Bastante elegante, não é?

A instalação do 3SO é tão simples quanto possível; basta marcar uma caixa de verificação "Activar início de sessão único" na configuração personalizada da versão mais recente do AD Connect.

Clientes apoiados

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

O que é a autenticação de passagem?

O PTA foi concebido para o caso de utilização em que o cliente não tem um bilhete Kerberos, quer porque o cliente Kerberos não consegue aceder a um DC (por exemplo, quando um funcionário está a trabalhar a partir de casa no seu portátil empresarial) ou porque o cliente não suporta Kerberos (por exemplo, um browser móvel ou uma aplicação que não suporta autenticação moderna).

Não vou falar sobre como instalar o PTA aqui, mas essencialmente implanta um ou mais conectores leves no local, muito parecidos com o conector Proxy de Aplicativo do Azure AD, em servidores unidos por domínio onde eles podem se 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).

Figura 3: Fluxo do processo de autenticação de passagem (Microsoft)
Figura 3: Fluxo do processo de autenticação de passagem (Microsoft)
  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 ir 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, tem de ter o AD FS se tiver partes confiáveis configuradas localmente para fornecer SSO que não pretende mover 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):

Figura 4: Opções de autenticação do Azure AD (Microsoft)
Figura 4: Opções de autenticação do Azure AD (Microsoft)

As opções originais ainda estão disponíveis, mas agora pode obter um grande valor com muito pouca complexidade extra. Se estiver a utilizar a sincronização de palavras-passe, a adição de 3SO eliminará os desafios de palavras-passe para os seus utilizadores empresariais na rede. Se, em vez disso, activar a 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 de passagem, a Microsoft reduziu drasticamente a barreira à adopção de uma estratégia de identidade híbrida utilizando as ferramentas nativas da empresa. De facto, estas ferramentas são ainda mais simples de utilizar do que as ofertas de terceiros que têm tirado 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 de nuvem Azure. A empresa pretende tornar a adopção destes serviços tão fácil quanto possível e, no mundo actual centrado no Active Directory, isso significa tornar a integração do AD com o Azure AD rápida e indolor. Demorou uma eternidade a trazer estas capacidades à luz do dia, mas prevejo que se tornarão rapidamente na ponte de identidade mais popular entre a identidade Microsoft no local e a identidade Microsoft na nuvem.