O365 - Utilizando o HardMatch para recuperação de objetos sincronizados

Por: Caio Ribeiro Cesar

Hoje irei abordar o processo de recuperação de objetos sincronizados entre ambientes on-premises e on-cloud com a feature nativa de sincronização do DirSync (ou até as novas versões, AADSync ou ADConnect).

Este procedimento pode ser aplicado quando não existe um backup do objeto no ambiente on-premises (Active Directory). Infelizmente, muitos cenários de suporte ainda se iniciam com a seguinte frase: “não existe backup”.

Vamos iniciar com o entendimento de como os objetos são sincronizados. No processo de sincronização de objetos, temos:

a) Source of Authority (Active Directory On-premises)

Se um usuário for removido do ambiente on-premises e o sync for efetuado, esta alteração será efetuada no O365. Se um atributo for alterado no objeto local e o sync for efetuado, este atributo será atualizado no O365.

Isso significa que quando falamos de um ambiente sincronizado, o AD é o dono das informações que são populadas para os objetos no Windows Azure Active Directory (WAAD). Basicamente temos a necessidade uma gerência de objetos simples e objetiva com o AD, e por isso habilitamos os objetos como “sincronizados”.

b) ObjectGUID

“What year is it?” 2015 - e ainda utilizamos o atributo ObjectGuid para muitas coisas.

O objectGUID é um atributo único, utilizado pelo AD para identificar objetos (unique-identifier) .

c) SourceAnchor:

Como não podemos ter ObjectGUIDs iguais para objetos entre diferentes ADs (AD/WAAD), existe a necessidade de um atributo gerado por este valor.

Então, é gerado o SourceAnchor baseado no ObjectGUID do objeto on-premises (AD). Um hash é gerado com o valor de ObjectGUID e atribuído ao SurceAnchor.

Utilizamos o SourceAnchor como “identificador” para qualquer objeto sincronizado pelo ambiente on-premises <>O365.

d) ImmutableID

Mesmo valor do SourceAnchor, atributo nomeado no WAAD para identificar objetos sincronizados e também utilizado por produtos como o ADFS.

Agora que entendemos a teoria, vamos validar como é feito o sincronismo:

Temos o Objeto1 criado no AD:

Consequentemente, Objeto1 possui um objectGUID atribuído:

O SourceAnchor criado pelo DirSync, tendo em base este ObjectGUID. Os valores não são iguais, devido ao fato que o hash foi efetuado:

Em outras palavras, o DirSync consome o ObjectGuid e cria o SourceAnchor – que fica na base do DirSync esta informacao, fazendo match do objeto.

E finalmente, quando falamos deste valor no WAAD, ou seja, no AD da nuvem, falamos de Immutable ID. Se voce validar, o ImmutableID e o mesmo valor de SourceAnchor.

No WAAD, este mesmo valor populado como ImmutableID:

Para atualizações de atributos, o Web Service do DirSync identifica como fazer “match” de objetos onprem vs. oncloud:

HardMatch:

• Valida se o objeto já existe com o mesmo valor de SourceAnchor on-premises

SoftMatch (caso o objeto não seja encontrado em processo de HardMatch):

• Efetua match de objetos no O365 com o AD on-premises pelo valor de ProxyAddresses
• Se existe um match neste processo (ProxyAddress), então o WAAD é alimentado com o valor de SourceAnchor, novamente gerado pelo ObjectGUID

Vamos então a um cenário comum de suporte – objeto “sumiu” ou foi removido.

• Administrador deleta acidentalmente um objeto no AD que está sendo sincronizado;
• A alteração é sincronizada para o WAAD, que consequentemente remove o objeto;
• Em um cenário de Exchange Online, o objeto de usuário é removido da nuvem e a mailbox é “perdida”.

O que fazer?

Como o artigo foca em recuperar objetos da nuvem, não irei discutir algumas práticas administrativas de Exchange Admins, como validação de Soft Deleted Mailbox.

Partindo do princípio que o SoA e o Active Directory, para recuperar este objeto temos que recuperar o que existe no ambiente local. Basicamente, o objeto deve existir novamente no Active Directory.

Algumas opções são:

• AD Recycle Bin (W2K8 R2 Forest Functional Level)
• AD restore autoritativo dos objetos removidos
• Backup utilizando outras ferramentas

Recovery manual:

• Administrador identifica o objeto que deve ser recuperado on-premises e utiliza o recycle bin ou o restore autoritativo do objeto;
• Assim que o administrador recuperar o objeto on premises, ele é automaticamente recuperado na nuvem – mailbox é “linkada” ao objeto;
• O recovery depende do valor de atributo de objeto SourceAnchor (ImmutableID);
• Um valor diferente de SourceAnchor não irá recuperar o usuário, ao invés disso irá criar um novo objeto.

Vamos então ao segundo cenário, foco principal do artigo – não existe backup. Não existe backup no SoA e mesmo assim o objeto foi removido.

Inicialmente, obtenho a informação do objeto removido no WAAD

Para obter a informação de ObjectId, execute (Get-MsolUser -ReturnDeletedUsers |fl UserPrincipalName,ObjectId)

Executo o comando para recuperar o objeto (ou acesso o portal>deleted users) e recupero esta conta no O365.

Apos recuperar o objeto, sera transformado para “InCloud” no O365. Ou seja, o objeto nao vai ser recriado automaticamente no AD local.

Como não possuímos o backup deste objeto, temos que fazer um Hard ou SoftMatch de atributos - para recuperar possíveis dados e poder gerenciar o objeto no SoA.

Recriando um objeto “diretor2” no Active Directory, como esperado, temos um ObjectGUID diferente do antigo.

Primeiro obtenho o valor de GUID do novo objeto e converto o hash de GUID para ImmutableID (que seria o mesmo valor de SourceAnchor) com o GUID2ImmutableID.ps1.

Entao sabemos que o hash para o novo ObjectGuid (valor de SourceAnchor e ImmutableID) deve ser alterado. Adicionamos manualmente o ImmutableID neste objeto para forcar HardMatch com o novo objeto do AD Local.

Efetuo o sync e finalmente o objeto aparece “synced with AD”.

Se logarmos no objeto, a mailbox será a mesma e os dados preservados.