Blog do Chesley

O Cenário parece o fim do mundo, cliente com centenas de contas criadas no Azure Active Directory deseja ter o SSO com o Active Directory!

Mas e se você já possui contas de usuário na nuvem que correspondem a objetos de usuário já existentes no diretório local e a Sincronização de Diretórios ainda não foi configurada entre eles? Por exemplo, se sua organização migrou anteriormente caixas de correio para o Office 365 usando o método de transição ou uma ferramenta de terceiros. Ou, se você tinha usuários provisionados para outro serviço online da Microsoft, como o TEAMS, antes de tentar a migração da caixa de correio.

Em casos como esses, pode ser necessário criar um mecanismo de correspondência entre as contas locais e as baseadas na nuvem, para que o Azure AD Connect saiba que se refere ao mesmo usuário. 

Existem dois métodos básicos para criar essa “correspondência”:

1. Soft match (também conhecida como correspondência SMTP )
2. Hard match (por immutableID ).

Soft match – usando o endereço SMTP

Para criar correspondências simples, que serão adequadas em 95% das situações, você deverá garantir, em primeiro lugar, que os sufixos UPN correspondam entre contas locais e baseadas na nuvem. 

O que queremos dizer com isso? Isso significa que o logon dos usuários precisa estar vinculado ao domínio do seu endereço de email principal no AD local e no Azure AD.

No Active  Directory local

Primeiro, quando você abre as propriedades de um objeto de conta de usuário, esse objeto deve ter o campo de endereço de email preenchido (o endereço SMTP principal do usuário) – para ter certeza de que esse é o primeiro caso. Agora dê uma olhada na guia Conta e você verá o nome de logon do usuário seguido por um sufixo.

O objetivo é fazer com que esse nome de logon Seja nomedeusuário@domínio.com – ou seja, o endereço de email – e não o nome de domínio local  nomedeusuário@domínio.local . Observe que você também pode selecionar contas em massa e fazer com que esse sufixo seja alterado em muitos objetos ao mesmo tempo.

Ou seja, nada mais é do que alterar o Sufixo do usuário para que o mesmo também seja correspondido no ambiente de nuvem, ambos precisam estar iguais, neste caso uma curiosidade, no ambiente de nuvem o sufixo precisa ser roteavel.

Em muitos casos não existe um sufixo criado, já vi clientes que possuem apenas a indentidade interno (.local). Nestes casos é possivel adcionar o sufixo com facilidade e rapidez, usando o console MMC de domínios e relações de confiança do Active Directory. 

Clique com o botão direito do mouse em Domínios e Relações de Confiança do Active Directory e selecione Propriedades . Digite seu nome de domínio de email e clique em Adicionar . Clique em OK .

Na nuvem do Azure AD / Office 365

No Office 365, você também deseja garantir que o nome de entrada seja o mesmo local, usando o sufixo UPN correto para o nome de domínio do email. 

Portanto, o objetivo é ter essa correspondência nomedeusuário@domínio.com novamente e não nomedeusuário@tenant.onmicrosoft.com .

No Portal do Office 365, encontre seus Usuários Ativos , selecione um usuário e edite o nome de usuário.

No Exemplo acima eu estou escolhendo o meu nome UPN valido.

Ainda é possivel visualizar essas informações e também altera-lás pelo Exchange Online, se estiver disponivel em sua organização.

No Exchange Online, você também pode ver que o endereço SMTP principal corresponde ao que listamos na conta local. 

Centros de administração> Exchange> destinatários . Edite um destinatário e clique em endereços de email .

Você também pode exportar listas em massa para comparação do Active Directory da seguinte maneira:

Get-ADUser -SearchBase “DC=chesley,DC=local” -Filter * -Properties * | Select-Object -Property Name,SamAccountName,EmailAddress | Sort-Object -Property Name | Export-Csv -path C:\temp\usuariosAD.csv

Get-MsolUser | select-object -property userprincipalname,displayname,islicensed | export-csv -path c:\export\365usuarios.csv

Tudo muito perfeito! mas… sempre tem um mas….

Quando não possivel que a identidade do ambiente local seja a mesma do ambiente de nuvem? o que fazer???

Hard Match usando o GUID / immutableID

Em algumas circunstâncias, a Soft Mach pode falhar e as contas locais não são correspondidas corretamente. Às vezes, uma conta na nuvem existente anteriormente pode ter determinados campos já preenchidos (por exemplo, immutableID) que confundirão a ferramenta de sincronização de diretório, mesmo que os endereços SMTP estejam correspondentes.

Nesses cenários, você pode optar por uma “correspondência forçada”, que é realizada usando o GUID local, convertendo esse valor no que é conhecido na nuvem do Azure AD como um “immutableID” e gravando esse valor convertido diretamente no Azure AD. Quando a Sincronização de Diretórios for executada, não haverá pontos de interrogação sobre se esse é o mesmo objeto, porque isso está sendo explicitamente informado.

Antes de prosseguir com isso, você ainda desejará garantir que os sufixos UPN correspondam ao domínio de email principal local e na nuvem, como fizemos acima. Em seguida, quando você identificar todas as contas que falharam na sincronização, poderá executar o seguinte para cada conta afetada (certifique-se de preencher as variáveis ​​adequadamente):

E, é claro, isso também pode ser generalizado para alterações em massa, por exemplo, se você usar as variáveis ​​como campos em um arquivo CSV e importar o CSV, com um loop para cada. Você pode até fazer isso com uma única variável em alguns casos:

Param(
$username
)
$365User="$username@emaildomainname.com"
$guid=(get-ADUser $username).Objectguid
$immutableID=[system.convert]::ToBase64String($guid.tobytearray())
Set-MsolUser -UserPrincipalName "$365User" -ImmutableId $immutableID 

O script acima será salvo como HMatch.ps1, e você poderá executar o loop for-each da seguinte maneira:

Connect-MsolService 
Import-Csv -Caminho C: \ scripts \ users.csv | Para cada {C: \ scripts \ HMatch.ps1 -Username $ _. Username}

Isso deve cuidar praticamente de todos os que estão tendo problemas para obter correspondências com a sincronização de diretórios (tenho recebido muitas consultas ultimamente). 

Conclusão

Sempre planeje sua ida para a Nuvem, idependente de qual nuve for! trabalhar com identidade é o foco basico de uma infraestrutura de nuvem. Se sua organização ainda não está preparada para utilizar os recursos de nuvem então começe desde já a prepara-la!

Utilizar recursos em nuvem é uma realidade, não é o futuro é o presente! e se você não fizer o seu papel como Analista ou Consultor o mundo passará por cima de você!