sábado, 1 de fevereiro de 2020

Filtrar Sincronização por Atributo no AADConnect


Introdução
=============
Existem cenários em que a sincronização do AADConnect precisa ser filtrada com maior granularidade que a filtragem por Unidade Organizacional.

Neste post irei mostrar como filtrar a sincronização por atributo.

Em nosso exemplo, utilizaremos o atributo msExchExtensionAttribute39 e para que a conta seja sincronizada, o valor Sync deverá estar presente.


Ambiente
============
AADConnect versão 1.4.38.0 instalado em um Windows Server 2012 R2


Passos
============
Iniciar abrindo o Synchronization Rules Editor.


Na Janela "Synchronization Rules Editor" clicar em "Add new rule".



Digitar um nome para a regra;
No campo "Conected System" selecionar o domínio do AD local;
Em "Connected System Object Type" selecionar "user";
Em "Metaverse Object Type" selecionar "person";
Em "Link Type" "Join";
Alterar o "Precedence" para "50" ou outro valor abaixo de "99";
Clicar em "Next".



Em "Scoping Filter" adicionar uma "clause", selecionar o atributo desejado, neste caso é o atributo "msExchExtensionAttribute39", Operator "EQUAL" e valor "Sync".



Em "Join rules" não fazemos alteração e simplesmente clicamos em "next".

Em "Transformations":
Selecionar campo "Constant", "cloudFiltered";
No campo "Source" inserir o valor "false";
Clicar em "Add".




Clicar novamente em "add new rule" para criar uma nova regra.




Escolher o nome da segunda regra;
Inserir as mesmas informações da regra anterior, exceto o campo "Precedence" que deve estar com valor entre regra recém criada e a próxima regra. No caso 99 é um número satisfatório.



Seguir para "Transformations" sem inserir nada em "Scoping filter" nem em "Join rules";
Inserir os mesmos dados da regra anterior, exceto o campo "Source" que terá valor "true";
Clicar em "Add".




Para que as alterações tenham efeito, um full sync será realizado na próxima janela de sincronização.



Lembre-se que a OU ainda deverá estar selecionada, nas configurações do conector, para que os objetos dentro dela sejam sincronizados.






Mais Informações
============
Positive filtering: "only sync these"


Azure AD Connect sync: Understanding Declarative Provisioning

sexta-feira, 31 de janeiro de 2020

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




  • 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

terça-feira, 29 de setembro de 2015

Forçar ativação do Office 2010 Pro Plus (o365)



Caso o office 2010 Pro Plus exiba mensagem que o produto não está ativado, mesmo quando o usuário está logado no mesmo, pode-se rodar um comando para forçar a reativação do produto.
1-      Acessar o prompt de comando
2-      Navegar até a pasta 
%ProgramFiles(x86)%\Common Files\Microsoft Shared\OFFICE14\
3-      Executar o comando
OSAUI.exe /F

Quando o comando é executado, exibe a tela de usuário e senha para ativação do produto.


Fonte: https://support.microsoft.com/en-us/kb/2390460


Caso mesmo assim, após inserir as credenciais, ainda não seja possível ativar o office, pode ser necessário alterar uma chave de registro, especialmente se a estação de trabalho já teve a versão por volume do office instalada anteriormente.


1- Acessar o editor de registro executando o comando"regedit.exe".
2- Navegar até a chave
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform\UserOperations
3- Alterar o valor de 0 para 1.


Fonte: https://support.microsoft.com/pt-br/kb/982756