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:
- Obter a relação de UserPrincipalName e ms-ds-consistencyguid do AD Local.
- Traduzir o valor obtido no passo anterior para base64 usando Translate_ImmutableID.ps1
- Usar comando Set-Msoluser -userprincipalname XXX -ImmutableId YYYY
- 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
