A Microsoft continua a trabalhar num ponto sensível da sua estratégia de identidade híbrida: O desafio de implementar a sua ponte de identidade entre os Serviços de Domínio do Active Directory (AD DS) no local e o Azure Active Directory na nuvem. Esta ponte consiste no AD FS para federação e numa sucessão de utilitários, que culminam no Azure AD Connect, para sincronização de identidades. O Azure AD Connect foi recentemente disponibilizado de forma generalizada e torna a experiência de ligar o seu AD DS local (e outros tipos de bases de dados de identidade, como o SQL Server ou LDAP) ao Azure AD mais fácil do que os seus antecessores DirSync e Azure AD Sync.
Novas funcionalidades do AD Connect
AD Connect (pode obter mais informações sobre o mesmo aqui) é um utilitário de configuração que simplifica a configuração da sincronização de identidades entre uma pequena lista de fontes de identidade populares (incluindo os Serviços de Domínio do Active Directory, claro) e, opcionalmente, o início de sessão único com o AD FS. Simplifica muito o processo de configuração e também fornece novos recursos, como o writeback de atributos relacionados ao dispositivo do Azure AD para o AD DS.
No entanto, uma nova funcionalidade que não tem sido muito mencionada é aquela que praticamente todos os meus clientes empresariais solicitam: a opção do servidor de preparação do Azure AD Connect. Para compreender esta opção, vamos primeiro analisar a situação que se destina a resolver.
Como funciona a sincronização de identidades da Microsoft
Esta evolução das ferramentas de sincronização — o DirSync, o seu sucessor, o AADSync, e, por fim, o AD Connect — utiliza uma versão simplificada do serviço de metadiretório da Microsoft, conhecido por vários nomes: MIIS, ILM, FIM e, desde há alguns meses, Microsoft Identity Manager (MIM). Estes serviços de metadiretório dispõem de conectores tanto para o AD DS como para o Azure AD, para extrair atributos para os espaços dos conectores. Um conjunto de regras de sincronização determina se esses atributos são adicionados a um metaverso que contém a união dos atributos de identidade locais e dos atributos do Azure AD. Por fim, as regras de sincronização de saída determinam quais os atributos que são gravados no Azure AD.
Figura 1: Arquitectura do serviço AD Connect (Imagem cortesia da Microsoft)
Isto requer um servidor com conectores configurados, regras definidas e um motor de base de dados (SQL Server Express ou SQL Server completo) para alojar os espaços dos conectores e o metaverso. Não existe tolerância a falhas nem redundância incorporadas nesta base de dados no servidor, e o clustering não é recomendado. E se estiver a pensar: «Basta restaurar a base de dados a partir dos cópias de segurança que faço», isso também não é suportado. Basicamente, se o servidor deixar de funcionar, terá de desinstalar e reinstalar o serviço de sincronização ou recuperar todo o servidor a partir das cópias de segurança.
Isto não é tão grave como parece. A Microsoft afirma, com razão, que, embora a sincronização seja certamente um serviço essencial, não é um serviço particularmente sensível ao tempo; o intervalo de sincronização predefinido e recomendado é de três horas. Isto significa que, embora possa demorar algumas horas a restabelecer o serviço de sincronização em caso de falha, no máximo provavelmente perderá apenas um ciclo de sincronização. Os departamentos de TI empresariais, no entanto, não gostam de zonas cinzentas no tempo de recuperação dos seus sistemas de produção. Na maioria das grandes empresas, se um sistema for considerado de elevada importância, tem de ter algum tipo de tolerância a falhas ou disponibilidade reforçada incorporada. «Estás a falar a sério?» é um comentário que já recebi mais do que uma vez quando uma empresa estava a ponderar as capacidades de alta disponibilidade do DirSync ou do AADSync.
Como funciona a opção do servidor de teste
A opção do servidor de teste foi desenvolvida para resolver esta lacuna. Embora não se trate de verdadeira alta disponibilidade, a implementação do servidor de teste permitirá retomar a sincronização de identidades em poucos minutos (assim que se decidir efetuar a transição para esse servidor).
Para configurar um servidor de teste (Figura 2), deve seguir um processo de configuração do Azure AD Connect idêntico ao que realizou para o servidor AD Connect principal, com uma exceção: no último passo, deve selecionar a opção de servidor de teste. Isto impede que os resultados da sincronização gerados no serviço do servidor de teste sejam gravados no Azure AD ou de volta no AD DS. Isto também significa que a gravação de palavras-passe e a sincronização de hashes de palavras-passe estão desativadas, uma vez que a primeira requer que as alterações sejam gravadas no AD DS, enquanto a segunda requer que as alterações sejam gravadas no Azure AD.
Figura 2: Arquitectura AD Connect com servidor de teste
Recuperação de uma falha no AD Connect
No caso de uma falha do servidor AD Connect principal, basta executar novamente o assistente de configuração do AD Connect e desmarcar a opção do servidor de preparação (e a opção de reescrita de palavras-passe ou sincronização de hash, caso as esteja a utilizar). Isto permite que sejam efetuadas atualizações no Azure AD e no AD DS. Obviamente, é importante ter cuidado para que apenas um servidor AD Connect esteja totalmente ativado de cada vez!
A opção de servidor de preparação no AD Connect é uma nova funcionalidade que será bem-vinda pelas grandes empresas. Proporciona um tempo de recuperação do serviço muito mais curto do que as versões anteriores e é simples de implementar, sem requisitos especiais de hardware ou software. Estou certo de que se tornará uma prática de implementação padrão para muitas empresas.
