HardMatch de Ms-Ds-ConsistencyGuid e ImmutableId

Em uma implantação de AADConnect, me deparei com um tenant do Office 365 que possuía usuários de produção criados na nuvem, no Office 365. E mais, ao colocar somente 1 conta para ser sincronizada com o AADConnect, o SoftMatch não acontecia, ocasionando a criação de uma conta sincronizada, porém diferente da que o usuário já utilizava no Office 365.

Durante a instalação do AADConnect tomei o cuidado de não permitir a sincronização inicial ao final do wizard de configuração. Isto me poupou o trabalho de ter que remover todas as contas duplicadas que teriam sido criadas pela sincronização inicial.

Vemos abaixo um de nossos usuários que já haviam sido criados na nuvem antes da instalação do AADConnect:

Análise do ambiente para aplicar o HardMatch

======================

O AADConnect foi instalado na versão 1.4.38.0 e o SourceAnchor escolhido na instalação foi o campo mS-Ds-ConsistencyGuid.

Caso o SourceAnchor de sua implementação seja diferente, não prossiga com o passo a passo deste blog.

Verificando os usuários de nuvem no Office 365, notei que não possuíam ImmutableID. Isto é normal pois foram criados on-line. Veja abaixo:

Verifiquei também, no Active Directory (AD) local, que as contas que eu queria fazer o HardMatch possuiam o campo Ms-Ds-ConsistencyGuid com valores. Veja abaixo:

Estratégia Adotada

======================

Adotada a seguinte estratégia:

1. Obter a relação de UserPrincipalName e ms-ds-consistencyguid do AD Local.
2. Traduzir o valor obtido no passo anterior para base64 usando Translate_ImmutableID.ps1
3. Usar comando Set-Msoluser -userprincipalname XXX -ImmutableId YYYY
4. No AADConnect, colocar o usuário em uma OU marcada para ser sincronizada pelo AADCnnect e então fazer o delta sync.

Com a estratégia em mente, mãos à obra!

=======================

• Passo 1 - Obter a relação de UserPrincipalName e ms-ds-consistencyguid do AD Local.
• Loguei em um controlador de domínio e abri o powershell
• Executado o comando abaixo para obter o ms-ds-consistencyguid do usuário

Get-ADUser -Filter "UserPrincipalName -eq 'fio@maier.eti.br'" -Properties Ms-Ds-ConsistencyGuid |select userprincipalname,@{name='ms-ds-consistencyguid';expression={[guid]$_.'ms-ds-consistencyguid'}}

• Com o valor do campo em mãos, pude partir para o passo 2, que seria converter este valor para que pudesse ser inserido no campo ImmutableId da conta correspondente no Office 365

• Passo 2 - Traduzir o valor do campo ms-ds-consistencyguid, para o valor correspondente do ImmutableID, utilizando o script Translate_ImmutableID.ps1
• Este versátil script permite converter qualquer uma das bases vindas do campo ms-ds-consistencyguid para o ImmutableId e o contrário também
• Segue exemplo da utilização do script. E observe o valor do ImmutableID

• Obtive este script do site https://blog.jumlin.com/2018/09/powershell-script-convert-immutableid/

• Passo 3 - Usar comando Set-Msoluser -userprincipalname fio@maier.eti.br -ImmutableId YYYY
• Agora que já temos o valor do ImmutableID correspondente ao valor do campo ms-ds-consistencyguid do AD local, vamos inseri-lo à conta do Office 365.

Set-MsolUser -UserPrincipalName fio@maier.eti.br -ImmutableId 0cqchBysdU6a7ZsPodvuoA==

 

• O processo até aqui ficou assim:

Agora que o ms-ds-consistencyguid da conta do AD local está de acordo com o ImmutableId da conta do Office 365, basta colocar o usuário do AD local em uma OU que é sincronizada pelo AADConnect e efetuar um delta sync.

• Passo 4 - No AADConnect, colocar o usuário em uma OU marcada para ser sincronizada pelo AADCnnect e então fazer o delta sync.

 

• Acessando o portal do Office 365, podemos ver que a conta agora aparece como "Sincronizado" e sem duplicatas.

 

Até a próxima,

Daniel Maier