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 capacidades 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 capacidade que não foi muito mencionada é uma que praticamente todos os meus clientes empresariais pedem: A opção de servidor de preparação do Azure AD Connect. Para compreender esta opção, vamos primeiro rever a situação que foi concebida para mitigar.
Como funciona a sincronização de identidades da Microsoft
Esta evolução dos utilitários de sincronização - DirSync, o seu sucessor AADSync e, por fim, o AD Connect - utiliza uma versão reduzida do serviço de metadirectório da Microsoft, denominado MIIS, ILM, FIM e, desde há alguns meses, Microsoft Identity Manager (MIM). Estes serviços de metadirectório têm conectores para o AD DS e o Azure AD para puxar atributos para espaços de conectores. Um conjunto de regras de sincronização determina se esses atributos são adicionados a um metaverso que contém a junção de atributos de identidade locais e atributos do Azure AD. Por fim, as regras de sincronização de saída determinam quais atributos são gravados no Azure AD.
Figura 1: Arquitectura do serviço AD Connect (Imagem cortesia da Microsoft)
Isso requer um servidor com conectores configurados, regras definidas e um mecanismo de banco de dados (SQL Server Express ou SQL Server completo) para manter os espaços do conector e o metaverso. Não existe tolerância a falhas ou redundância incorporada nesta base de dados no servidor e não se recomenda a criação de clusters. E se estiver a pensar, vou simplesmente restaurar a base de dados a partir de cópias de segurança que fiz, isso também não é suportado. Basicamente, se o servidor morrer, terá de desinstalar e reinstalar o serviço de sincronização ou recuperar todo o servidor a partir de cópias de segurança.
Isto não é tão mau como parece. A Microsoft diz, com razão, que embora a sincronização seja certamente um serviço de missão crítica, 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 reconstruir o serviço de sincronização em caso de falha, no máximo, irá provavelmente perder um ciclo de sincronização. No entanto, as lojas de TI empresariais não gostam de áreas cinzentas no tempo de recuperação dos seus sistemas de produção. Na maioria das grandes empresas, se for considerado um sistema de elevada importância, deve ter algum tipo de tolerância a falhas ou disponibilidade melhorada incorporada. Está a falar a sério? é um comentário que recebi mais do que uma vez quando uma empresa estava a considerar 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 essa falha. Embora não seja uma verdadeira alta disponibilidade, a implementação do servidor de teste permite-lhe retomar a sincronização de identidades em poucos minutos (assim que decidir fazer a transição para ele).
Para configurar um servidor de teste (Figura 2), procede a uma configuração idêntica do Azure AD Connect, tal como fez para o servidor AD Connect principal, com uma excepção: No último passo, selecciona a opção do servidor de teste. Isto impede que os resultados da sincronização desenvolvidos no serviço do servidor de teste sejam escritos no Azure AD ou no AD DS. Isto também significa que a sincronização de write-back e hash de palavra-passe está desactivada, porque a primeira requer alterações escritas no AD DS e a segunda requer alterações escritas 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 primário do AD Connect, basta executar novamente o assistente de configuração do AD Connect e desmarcar a opção do servidor de teste (e o writeback de palavra-passe ou a sincronização de hash, se a estiver a utilizar). Isto permite actualizar o Azure AD e o AD DS. Obviamente, é necessário ter cuidado para que apenas um servidor AD Connect esteja totalmente activado de cada vez!
A opção de servidor de preparação no AD Connect é uma nova capacidade que será bem recebida pelas grandes empresas. Proporciona um tempo de recuperação de serviço muito mais curto do que os seus antecessores 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.
