O365 Identity – SourceAnchor e ImmutableID: o que são e para que servem estes atributos?
By: Cesar Hara and Caio Cesar
O intuito deste artigo é auxiliar no entendimento geral do conceito por trás dos atributos “SourceAnchor” e “ImmutableID” em contas de usuários, utilizados em ambientes sincronizados via AD Connect.
Definição
SourceAnchor: um atributo imutável durante o tempo de vida de um objeto. Este atributo identifica um objeto sendo o mesmo no Active Directory On-Premises (Source of Authority) e no Azure AD. O sourceAnchor também é conhecido como ImmutableID.
Qual a diferença dos dois atributos? Nenhuma, além da nomenclatura. Os valores são idênticos – “sourceAnchor” geralmente é relacionado quando mencionamos o atributo na base de dados do AADConnect (metaverse), quando “ImmutableID” no Azure AD.
A palavra imutável significa não alterável, sendo assim o atributo deve ser escolhido com muito critério uma vez que o mesmo não pode ser alterado quando definido no Azure AD.
Pontos importantes
- “Sourceanchor” e “ImmutableId” se referem ao mesmo atributo;
- Este atributo é responsável por vincular um objeto do Active Directory local com o objeto que foi sincronizado/criado na nuvem (Azure AD);
- Uma vez definido no Azure AD, o mesmo não pode ser alterado (se torna “Read Only” em contas sincronizadas).
ObjectGUID como sourceAnchor
Por padrão, até a versão de AD Connect 1.1.486.0, o atributo ObjectGUID era escolhido como o sourceAnchor no momento da instalação.
Isto significa que o Azure ADConnect criaria o valor de sourceAnchor (e respectivamente ImmutableId) fazendo uma conversão para base64 do atributo ObjectGUID dos objetos.
O ObjectGUID também é um atributo imutável, por esse motivo foi um bom candidato por muito tempo para ser o valor de ImmutableId das contas do Azure AD.
Podemos comprovar os valores exportando os dados das contas dos objetos. Neste exemplo, iremos utilizar uma conta de testes “ user01@o365identity.com ”:
ObjectGUID: 771a06cd-a5dc-4d9a-a5e2-6b6c6690326b
ImmutableID: zQYad9ylmk2l4mtsZpAyaw==
Conforme informado anteriormente, o valor de Sourceanchor/ImmutableID é uma conversão do valor de ObjectGuid.
Podemos utilizar os cmdlets nativos do módulo do Active Directory para descobrir o ImmutableID que deve ser definido no Azure AD*:
$guid = (get-Aduser sAmAccountname).ObjectGuid
$immutableID = [System.Convert]::ToBase64String($guid.tobytearray())
$immutableID
Após a sincronização da conta, confirmamos o valor no Azure AD:
Como podemos observar, a conta está corretamente vinculada, ou seja, o valor de ObjectGUID do objeto local convertido para base64 é exatamente o mesmo valor do objeto da nuvem.
Impacto na escolha do sourceAnchor
Vamos supor um cenário onde o atributo “displayName” foi escolhido como sourceAnchor no setup do AD Connect. Após a sincronização inicial, o ImmutableID na nuvem ficaria com o valor “User01”**.
Após um período de tempo, há a necessidade de alterar o displayName para “User”. Se este valor for alterado, na próxima tarefa de sincronização o AD Connect tentará alterar o ImmutableID de “User01” para “User”.
A consequência será um erro de duplicidade de atributos, pelo fato de que para o AD Connect e Azure AD, agora estamos lidando com duas contas diferentes - com diferentes valores de ImmutableID (a primeira “User01” e a segunda “User” ).
Ou seja, uma vez definido o ImmutableID no AAD o mesmo se torna “Read-Only” sem a possibilidade de alteração. Isto significa o valor de sourceAnchor, deve ser sempre imutável.
Conclusão
O ImmutableID é muito importante e deve ser compreendido para evitar problemas futuros.
Se não houver um bom planejamento do ambiente sincronizado, problemas complexos surgirão.
* Algumas pessoas optam pela utilização do ps1 “ GUID2ImmutableID ”. O resultado final é o mesmo.
** Se o sourceAnchor selecionado não for do tipo de cadeia de caracteres, o Azure AD Connect usará Base64Encode no valor do atributo para assegurar que nenhum caractere especial será exibido.If you use another federation server than ADFS, make sure your server can also Base64Encode the attribute.
Comments
- Anonymous
December 08, 2017
Imprescindível o entendimento deste assunto em ambientes sincronizados com o Azure AD. Parabéns e obrigado pelo artigo, Cesar!