Noções básicas sobre usuários e contatos na sincronização do Ative Directory do Azure
Atualizado: July 22, 2015
Importante
Este tópico será arquivado em breve.
Há um novo produto chamado "Azure Ative Directory Connect" que substitui o AADSync e o DirSync.
O Azure AD Connect incorpora os componentes e a funcionalidade lançados anteriormente como Dirsync e AAD Sync.
Em algum momento no futuro, o suporte para Dirsync e AAD Sync terminará.
Essas ferramentas não estão mais sendo atualizadas individualmente com aprimoramentos de recursos e todas as melhorias futuras serão incluídas nas atualizações do Azure AD Connect.
Há vários motivos diferentes pelos quais você teria várias florestas do Ative Directory e há várias topologias de implantação diferentes. Os modelos comuns incluem uma implantação de recursos de conta e florestas sincronizadas com GAL após uma fusão & aquisição. Mas mesmo que existam modelos puros, os modelos híbridos também são comuns. A configuração padrão no AADSync não assume nenhum modelo em particular, mas dependendo de como a correspondência do usuário foi selecionada no guia de instalação, diferentes comportamentos podem ser observados.
Neste documento, analisaremos como a configuração padrão se comporta em determinadas topologias. Vamos passar pela configuração e o Editor de Regras de Sincronização pode ser usado para examinar a configuração.
Existem algumas regras gerais que a configuração assume:
Independentemente da ordem em que lemos os diretórios ativos de origem, o resultado final deve ser sempre o mesmo.
Uma conta ativa sempre contribuirá com informações de login, incluindo userPrincipalName e sourceAnchor.
Uma conta desabilitada contribuirá com userPrincipalName e sourceAnchor, a menos que seja uma caixa de correio vinculada.
Uma conta com uma caixa de correio vinculada nunca será usada para userPrincipalName e sourceAnchor. Presume-se que uma conta ativa será encontrada mais tarde.
Um objeto de contato pode ser provisionado para o Azure AD como um contato ou como um usuário. Você realmente não sabe até que todas as florestas de origem do Ative Directory tenham sido processadas.
Contatos
Os contatos que representam um usuário em uma floresta diferente são comuns após uma fusão & aquisição em que uma solução GALSync está fazendo a ponte entre duas ou mais florestas do Exchange. O objeto de contato está sempre se unindo do espaço do conector ao metaverso usando o atributo mail. Se já houver um objeto de contato ou objeto de usuário com o mesmo endereço de email, os objetos serão unidos. Isso está configurado na regra In do AD – Contact Join. Há também uma regra chamada In do AD – Contact Common com um fluxo de atributo para o atributo do metaverso sourceObjectType com a constante Contact. Esta regra tem uma precedência muito baixa, portanto, se qualquer objeto de usuário estiver unido ao mesmo objeto do metaverso, a regra In do AD – User Common contribuirá com o valor User para esse atributo. Com essa regra, esse atributo terá o valor Contact se nenhum usuário tiver sido associado e o valor User se pelo menos um usuário tiver sido encontrado.
Para provisionar um objeto para o AAD, a regra de saída out to AAD – Contact Join criará um objeto de contato se o atributo do metaverso sourceObjectType estiver definido como Contact. Se esse atributo estiver definido como Usuário, a regra out to AAD – User Join criará um objeto de usuário. É possível que um objeto seja promovido de Contato para Usuário quando mais diretórios ativos de origem forem importados e sincronizados.
Por exemplo, em uma topologia GALSync, encontraremos objetos de contato para todos na segunda floresta quando importarmos a primeira floresta. Isso preparará novos objetos de contato no AAD Connector. Quando mais tarde importarmos e sincronizarmos a segunda floresta, encontraremos os usuários reais e os uniremos aos objetos do metaverso existentes. Em seguida, excluiremos o objeto de contato no AAD e criaremos um novo objeto de usuário.
Se você tiver uma topologia em que os usuários e representados como contatos, certifique-se de selecionar para corresponder aos usuários no atributo mail no guia de instalação. Se você selecionar outra opção, então você terá uma configuração dependente da ordem. Os objetos de contato sempre ingressarão no atributo de email, mas os objetos de usuário só ingressarão no atributo de email se essa opção tiver sido selecionada no guia de instalação. Você pode acabar com dois objetos diferentes no metaverso com o mesmo atributo mail se o objeto de contato tiver sido importado antes do objeto de usuário. Durante a exportação para o Azure AD, um erro será lançado. Esse comportamento é por design e indicaria dados incorretos ou que a topologia não foi identificada corretamente durante a instalação.
Contas desativadas
As contas desabilitadas também são sincronizadas com o Azure AD. Contas desabilitadas são comuns para representar recursos no Exchange, por exemplo, salas de conferência. A exceção são os usuários com uma caixa de correio vinculada; como mencionado anteriormente, eles nunca provisionarão uma conta para o Azure AD.
A suposição é que, se uma conta de usuário desabilitada for encontrada, não encontraremos outra conta ativa mais tarde e o objeto será provisionado para o Azure AD com o userPrincipalName e sourceAnchor encontrados. Caso outra conta ativa se junte ao mesmo objeto do metaverso, seu userPrincipalName e sourceAnchor serão usados.
Chaning sourceAnchor
Quando um objeto é exportado para o Azure AD, não é mais permitido alterar o sourceAnchor. Quando o objeto tiver sido exportado, o atributo do metaverso cloudSourceAnchor será definido com o valor sourceAnchor aceito pelo Azure AD. Se sourceAnchor for alterado e não corresponder cloudSourceAnchor, a regra out to AAD – User Join lançará o erro atributo sourceAnchor foi alterado. Neste caso, a configuração ou os dados devem ser corrigidos para que o mesmo sourceAnchor esteja presente no metaverso novamente antes que o objeto possa ser sincronizado novamente.