Configurar a origem da autoridade do usuário (SOA)

Este artigo explica os pré-requisitos e as etapas para configurar o Usuário e o Contato, Fonte de Autoridade (SOA). Este artigo também explica como reverter as alterações e as limitações de recursos atuais. Para obter uma visão geral completa do SOA do usuário, consulte Adotar a postura de primeira nuvem: transferir a fonte de autoridade do usuário para a nuvem.

Pré-requisitos

Requirement	Description
Funções	O Administrador Híbrido é necessário para chamar as APIs do Microsoft Graph para ler e atualizar o SOA dos usuários. O Administrador de Aplicativos ou Administrador de Aplicativos na Nuvem é necessário para conceder consentimento do usuário às permissões necessárias ao Microsoft Graph Explorer ou ao aplicativo usado para chamar as APIs do Microsoft Graph.
Permissões	Para aplicativos que chamam a onPremisesSyncBehavior API do Microsoft Graph, é necessário conceder o escopo de User-OnPremisesSyncBehavior.ReadWrite.All permissão. Para obter mais informações, confira como consentir com essa permissão usando o Centro de Administração do Microsoft Entra.
Licença necessária	Licença do Microsoft Entra Free.
Conectar cliente de sincronização	A versão mínima é 2.5.76.0. Para usar Contact SOA, versão 2.5.79.0.
Cliente de Sincronização de Nuvem	A versão mínima é 1.1.1370.0

Configuração

Você precisa configurar o cliente connect sync e o agente de provisionamento do Microsoft Entra.

Conectar cliente de sincronização

1. Baixe a versão mais recente do build do Connect Sync.

2. Verifique se o build do Connect Sync foi instalado com êxito. Acesse Programas no Painel de Controle e confirme se a versão do Microsoft Entra Connect Sync é 2.5.76.0.

Cliente de sincronização de nuvem

Baixe o agente de Provisionamento do Microsoft Entra com a versão build 1.1.1370.0 ou posterior.

1. Siga as instruções para baixar o cliente do Cloud Sync.

2. Saiba como identificar a versão atual do agente.

3. Siga as instruções para configurar o provisionamento do AD DS para a ID do Microsoft Entra.

Permissão de consentimento para aplicativos

Você pode consentir a permissão no Centro de administração do Microsoft Entra. Essa operação altamente privilegiada requer a função Administrador de Aplicativos ou Administrador de Aplicativos na Nuvem. Você também pode conceder consentimento usando o PowerShell. Para obter mais informações, consulte Conceder consentimento em nome de um único usuário.

Aplicativos personalizados

Siga estas etapas para conceder User-OnPremisesSyncBehavior.ReadWrite.All permissão ao aplicativo correspondente. Para obter mais informações sobre como adicionar novas permissões ao registro do aplicativo e conceder consentimento, consulte Atualizar as permissões solicitadas de um aplicativo na ID do Microsoft Entra.

Observação

Para transferir SOA de um Contato, a permissão necessária é Contacts-OnPremisesSyncBehavior.ReadWrite.All.

Usar o Centro de administração do Microsoft Entra para consentir a permissão para aplicativos

1. Entre no Centro de administração do Microsoft Entra como administrador de aplicativos ou administrador de aplicativos na nuvem.

2. Navegue para Aplicativos Empresariais>nome do aplicativo.

3. Selecione Permissões>Conceder consentimento do administrador para o nome do locatário.

4. Entre novamente como administrador de aplicativos ou administrador de aplicativos na nuvem.

5. Examine a lista de permissões que exigem seu consentimento e selecione Aceitar.

6. Você pode ver a lista de permissões concedidas:

Conceder permissão ao Explorador do Graph

1. Abra o Explorador do Graph e entre como Administrador de Aplicativos ou Administrador de Aplicativos na Nuvem.

2. Selecione o ícone de perfil e selecione Consentimento para permissões.

3. Pesquise user-OnPremisesSyncBehavior e selecione Consentimento para a permissão.

Transferir SOA para um usuário de teste

Observação

Você também pode transferir o SOA de contato usando o endpoint da https://graph.microsoft.com/v1.0/contacts API.

Siga estas etapas para transferir o SOA para um usuário de teste:

1. Crie um usuário no AD. Você também pode usar um usuário existente sincronizado com a ID do Microsoft Entra usando o Connect Sync.

2. Execute o seguinte comando para iniciar a Sincronização de Conexão:

   Start-ADSyncSyncCycle
   

3. Verifique se o usuário aparece no Centro de administração do Microsoft Entra como um usuário sincronizado.

4. Use a API do Microsoft Graph para transferir o SOA do objeto de usuário (isCloudManaged=true). Abra o Microsoft Graph Explorer e entre com uma função de usuário apropriada, como o administrador do usuário.

5. Vamos verificar o status soa existente. Ainda não atualizamos o SOA, portanto, o valor do atributo isCloudManaged deve ser falso. Substitua o {ID} nos exemplos a seguir pela ID do objeto do usuário. Para obter mais informações sobre essa API, consulte Get onPremisesSyncBehavior. /graph/api/onpremisessyncbehavior-update

   GET https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior?$select=isCloudManaged
   

   

6. Confirme que o usuário sincronizado está em modo somente leitura. Como o usuário é gerenciado localmente, todas as tentativas de gravação para o usuário na nuvem falham. A mensagem de erro é diferente para usuários habilitados para email, mas as atualizações ainda não são permitidas.

   Observação

   Se essa API falhar com o 403, use a guia Modificar permissões para conceder consentimento à permissão User.ReadWrite.All necessária.

   PATCH https://graph.microsoft.com/v1.0/users/{ID}/
      {
        "DisplayName": "User Name Updated"
      }   
   

   

7. Pesquise pelo usuário no centro de administração do Microsoft Entra. Verifique se todos os campos de usuário estão esmaeçados e se essa origem é o AD DS do Windows Server.

8. Agora você pode atualizar o SOA do usuário para ser gerenciado na nuvem. Execute a operação a seguir no Microsoft Graph Explorer para o objeto de usuário que você deseja transferir para a nuvem. Para obter mais informações sobre essa API, consulte Update onPremisesSyncBehavior.

   PATCH https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior
      {
        "isCloudManaged": true
      }   
   

   

9. Para validar a alteração, chame GET para verificar se isCloudManaged é verdadeiro.

   GET https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior?$select=isCloudManaged
   

   

10. Confirme a alteração nos Logs de Auditoria. Para acessar logs de auditoria no portal do Azure, abra GerenciarLogs de Auditoria de> de > do Microsoft Entra ou pesquise logs de auditoria. Selecione Alterar Fonte de Autoridade do AD para a nuvem como a atividade.

11. Verifique se o usuário pode ser atualizado na nuvem.

    PATCH https://graph.microsoft.com/v1.0/users/{ID}/
       {
         "DisplayName": "Update User Name"
       }   
    

    

12. Abra o Centro de administração do Microsoft Entra e confirme se a propriedade habilitada para sincronização local do usuário é Sim.

Conectar cliente de sincronização

1. Execute o seguinte comando para iniciar a Sincronização de Conexão:

   Start-ADSyncSyncCycle
   

2. Para examinar o objeto de usuário com SOA transferido, no Gerenciador de Serviços de Sincronização, acesse Conectores:

   

3. Clique com o botão direito do mouse no Conector do Active Directory Domain Services. Pesquise o usuário pela configuração de nome de domínio relativo (RDN) "CN=<UserName>":

   

4. Dê um clique duplo na entrada pesquisada e selecione Linhagem>Propriedades de Objeto do Metaverso.

   

5. Selecione Conectores e clique duas vezes no objeto da ID do Microsoft Entra com "CN={<Caracteres> Alfanuméricos}".

6. Você pode ver que a propriedade blockOnPremisesSync está definida como true no objeto ID do Microsoft Entra. Esse valor de propriedade significa que todas as alterações feitas no objeto AD DS correspondente não fluem para o objeto da ID do Microsoft Entra:

   

7. Vamos atualizar o objeto de usuário local. Alteramos o nome de usuário de TestUserF1 para TestUserF1.1:

   

8. Execute o seguinte comando para iniciar a Sincronização de Conexão:

   Start-ADSyncSyncCycle
   

9. Abra o visualizador de eventos e filtre o log de aplicativos para a ID do evento 6956. Essa ID de evento é reservada para informar aos clientes que o objeto não está sincronizado com a nuvem porque o SOA do objeto está na nuvem.

   

Status dos atributos após a transferência do SOA

A tabela a seguir explica o status dos atributos isCloudManaged e onPremisesSyncEnabled depois de transferir o SOA de um objeto.

Etapa de administrador	valor isCloudManaged	valor onPremisesSyncEnabled	Descrição
O administrador sincroniza um objeto do AD DS com a ID do Microsoft Entra	false	true	Quando um objeto é originalmente sincronizado com a ID do Microsoft Entra, o atributo onPremisesSyncEnabled é definido true como e isCloudManaged é definido como false.
O administrador transfere a origem da autoridade (SOA) do objeto para a nuvem	true	null	Depois que um administrador transfere o SOA de um objeto para a nuvem, o atributo isCloudManaged se torna definido true e o valor do atributo onPremisesSyncEnabled é definido como null.
O administrador reverte a operação SOA	false	null	Se um administrador transferir a SOA de volta para o AD, o isCloudManaged será definido como false e o onPremisesSyncEnabled será definido como null até que o cliente de sincronização assuma o objeto.
O administrador cria um objeto nativo de nuvem na ID do Microsoft Entra	false	null	Se um administrador criar um novo objeto nativo de nuvem na ID do Microsoft Entra, isCloudManaged será definido false como e onPremisesSyncEnabled será definido como null.
O administrador cria um objeto nativo de nuvem na ID do Microsoft Entra	false	null	Se um administrador criar um novo objeto nativo de nuvem na ID do Microsoft Entra, isCloudManaged será definido false como e onPremisesSyncEnabled será definido como null.

Reverter a atualização soa

Importante

Verifique se os usuários que você reverte não têm referências de nuvem. Remova os usuários de nuvem de grupos transferidos do SOA e remova esses grupos dos pacotes de acesso antes de reverter os usuários para o AD DS. O cliente de sincronização assume o objeto no próximo ciclo de sincronização.

Você pode executar essa operação para reverter a atualização SOA e reverter o SOA para o local.

PATCH https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior
   {
     "isCloudManaged": false
   }   

Observação

A alteração do isCloudManaged permite false que um objeto do AD DS que esteja no escopo da sincronização seja assumido pelo Connect Sync na próxima vez que ele for executado. Até a próxima vez que a Sincronização de Conexão for executada, o objeto poderá ser editado na nuvem. A reversão do SOA é concluída somente depois que a chamada à API e a próxima execução agendada ou forçada do Connect Sync forem concluídas.

Validar a alteração nos logs de auditoria

Selecione a atividade como Desfazer alterações na Fonte de Autoridade do AD DS para a nuvem:

Validar no cliente do Connect Sync

1. Execute o seguinte comando para iniciar a Sincronização de Conexão:

   Start-ADSyncSyncCycle
   

2. Abra o objeto no Gerenciador do Servidor de Sincronização (os detalhes estão na seção Conectar Cliente de Sincronização ). Você pode ver que o estado do objeto conector da ID do Microsoft Entra está aguardando confirmação de exportação e blockOnPremisesSync = false, o que significa que o objeto SOA é tomado pelo local novamente.

   

Limpar atributos locais para usuários transferidos pelo SOA

Veja a seguir a lista de propriedades locais presentes no objeto de usuário de nuvem que são usadas para acessar recursos locais:

• onPremisesDistinguishedName
• onPremisesDomainName
• onPremisesSamAccountName
• onPremisesSecurityIdentifier
• onPremisesUserPrincipalName

Se os administradores quiserem acessar recursos locais após a transferência do SOA, você deverá manter manualmente esses atributos usando o Microsoft Graph e não excluir esses atributos.

Definir o escopo de um usuário para operações SOA em uma Unidade Administrativa

Para definir o escopo de um usuário para operações de Fonte de Autoridade em uma Unidade Administrativa, execute as seguintes etapas:

1. Crie uma unidade para usar como escopo para o usuário. Para obter etapas sobre como criar uma unidade, consulte: Criar uma unidade administrativa.

2. Adicione o usuário como administrador de identidade híbrida dentro do escopo.

3. Adicione usuários à unidade. Para obter informações sobre isso, consulte: Adicionar usuários, grupos ou dispositivos a uma unidade administrativa.

4. Transfira o SOA dos usuários dentro do escopo da unidade. Para obter um guia sobre como transferir o SOA dos usuários, consulte: Transferir SOA para um usuário de teste.

Configurar Contato SOA

Você também pode transferir o SOA de contatos de usuários usando os exemplos fornecidos neste artigo. Contatos são itens no Outlook em que você pode organizar e salvar informações sobre as pessoas e organizações com as quais você se comunica. Os exemplos a seguir são de como você transferiria o SOA dos contatos.

Observação

Para transferir SOA de um Contato, a permissão necessária é Contacts-OnPremisesSyncBehavior.ReadWrite.All.

Para confirmar se o SOA de contato é gerenciado na nuvem, execute a seguinte chamada à API:

GET https://graph.microsoft.com/v1.0/contacts/{ID}/onPremisesSyncBehavior?$select=isCloudManaged

Para atualizar o contato gerenciado pela nuvem, você pode fazer a seguinte chamada à API:

   PATCH https://graph.microsoft.com/v1.0/contacts/{ID}/
      {
        "DisplayName": "Contact Name Updated"
      }   

Conteúdo relacionado

• Como auditar e monitorar a SOA (Fonte de Autoridade do Usuário) na ID do Microsoft Entra
• Configurar a Origem da Autoridade do Grupo (SOA)