Configurar manualmente o ingresso no Microsoft Entra híbrido

Se o uso do Microsoft Entra Connect for uma opção para você, confira as diretrizes descritas em Configurar o ingresso no Microsoft Entra híbrido. Usar a automação no Microsoft Entra Connect simplifica significativamente a configuração de ingresso híbrido do Microsoft Entra.

Este artigo aborda a configuração manual dos requisitos para o ingresso no Microsoft Entra híbrido, incluindo etapas para domínios gerenciados e federados.

Pré-requisitos

  • Microsoft Entra Connect
    • Para que o ingresso de sincronização de registro de dispositivo tenha sucesso, como parte da configuração de registro de dispositivo, não exclua os atributos de dispositivo padrão da configuração de sincronização do Microsoft Entra Connect. Para saber mais sobre os atributos de dispositivo padrão sincronizados com o Microsoft Entra ID, confira Atributos sincronizados pelo Microsoft Entra Connect.
    • Se os objetos de computador dos dispositivos que você deseja ingressar no Microsoft Entra híbrido pertencerem a UOs (unidades organizacionais) específicas, configure as UOs corretas para sincronização no Microsoft Entra Connect. Para saber mais sobre como sincronizar objetos de computador usando o Microsoft Entra Connect, veja Filtragem baseada em unidade organizacional.
  • Credenciais do administrador corporativo para cada uma das florestas do Active Directory Domain Services local.
  • (Para domínios federados) Windows Server com os Serviços de Federação do Active Directory (AD FS) instalados.
  • Os usuários podem registrar seus dispositivos com o Microsoft Entra ID. Mais informações sobre essa configuração podem ser encontradas no título Definir configurações do dispositivo, no artigo Definir configurações do dispositivo.

O ingresso no Microsoft Entra híbrido requer que os dispositivos tenham acesso aos seguintes recursos da Microsoft dentro da rede da organização:

  • https://enterpriseregistration.windows.net
  • https://login.microsoftonline.com
  • https://device.login.microsoftonline.com
  • https://autologon.microsoftazuread-sso.com (se você usa ou pretende usar o logon único contínuo)
  • STS (Serviço de Token de Segurança) da sua organização (para domínios federados)

Aviso

Se a sua organização usa servidores proxy que interceptam o tráfego SSL para cenários como prevenção de perda de dados ou restrições de locatário do Microsoft Entra, verifique se o tráfego para essas URLs foi excluído do TLS de interrupção e inspeção. A falha ao excluir esses URLs pode causar interferência com a autenticação de certificado de cliente, problemas com o registro de dispositivo e Acesso Condicional com base no dispositivo.

Se a sua organização exigir acesso à Internet por meio de um proxy de saída, você pode usar a WPAD (Descoberta Automática de Proxy Web) para permitir que computadores Windows 10 ou mais recente registrem-se no dispositivo com o Microsoft Entra ID. Para solucionar problemas encontrados ao configurar e gerenciar a WPAD, veja Solucionando problemas de detecção automática.

Se você não usa a WPAD, pode configurar as definições de proxy WinHTTP no computador com o Windows 10 1709 e versões posteriores. Para obter mais informações, confira Configurações de proxy WinHTTP implantadas por Objeto de Política de Grupo (GPO).

Observação

Se você definir as configurações de proxy em seu computador usando as configurações de WinHTTP, qualquer computador que não possa se conectar ao proxy configurado não conseguirá se conectar à Internet.

Se a organização exigir acesso à Internet por meio de um proxy de saída autenticado, certifique se de que os computadores com Windows 10 ou mais recente possam ser autenticados com êxito no proxy de saída. Como computadores com Windows 10 ou mais recente executam o registro de dispositivos usando o contexto do computador, configure a autenticação de proxy de saída usando o contexto do computador. Acompanhe com o provedor de proxy de saída nos requisitos de configuração.

Verifique se os dispositivos podem acessar os recursos necessários da Microsoft na conta do sistema usando o script de Conectividade de Registro de Dispositivo de Teste.

Configuração

Você pode configurar dispositivos adicionados ao Microsoft Entra híbrido para vários tipos de plataforma de dispositivo Windows.

Depois que essas configurações forem concluídas, siga as diretrizes para verificar o registro.

Configurar um ponto de conexão de serviço

O objeto de SCP (ponto de conexão de serviço) é usado pelos seus dispositivos durante o registro para descobrir informações de locatário do Microsoft Entra. Na instância local do Active Directory, o objeto SCP para dispositivos ingressados no Microsoft Entra híbrido precisa existir na partição do contexto de nomenclatura da configuração da floresta do computador. Há apenas um contexto de nomeação de configuração por floresta. Em uma configuração de várias florestas do Active Directory, o ponto de conexão de serviço precisa existir em todas as florestas que contêm computadores ingressados no domínio.

O objeto SCP contém dois valores de palavras-chave, azureADid:<TenantID> e azureADName:<verified domain>. O valor <verified domain> na palavra-chave azureADName determina o tipo do fluxo de registro do dispositivo (federado ou gerenciado) que o dispositivo seguirá depois de ler o valor SCP de sua instância do Active Directory local. Mais informações sobre os fluxos gerenciados e federados podem ser encontrados no artigo Como o registro de dispositivos do Microsoft Entra funciona.

Você pode usar o cmdlet Get-ADRootDSE para recuperar o contexto de nomenclatura de configuração da sua floresta.

Para uma floresta com um nome de domínio do Active Directory fabrikam.com, o contexto de nomenclatura de configuração é:

CN=Configuration,DC=fabrikam,DC=com

Na sua floresta, o objeto de SCP para o registro automático de dispositivos conectados no domínio está localizado em:

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,[Your Configuration Naming Context]

Dependendo de como você implanta o Microsoft Entra Connect, o objeto SCP já pode estar configurado. Você pode verificar a existência do objeto e recuperar os valores da descoberta usando o seguinte script do PowerShell:

$scp = New-Object System.DirectoryServices.DirectoryEntry;

$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";

$scp.Keywords;

A saída $scp.Keywords mostra as informações de locatário do Microsoft Entra, por exemplo. Veja um exemplo:

azureADName:microsoft.com
azureADId:72f988bf-86f1-41af-91ab-2d7cd011db47

Configurar a emissão de declarações

Em uma configuração do Microsoft Entra federada, os dispositivos dependem do AD FS ou de um servidor de federação local de um parceiro da Microsoft para autenticarem-se no Microsoft Entra ID. Os dispositivos são autenticados para obter um token de acesso para se registrar com o Serviço de Registro de Dispositivo do Microsoft Entra (Azure DRS).

Os dispositivos atuais do Windows são autenticados usando a autenticação integrada do Windows com um ponto de extremidade WS-Trust ativo (versões 1.3 ou 2005) hospedado pelo serviço de federação local.

Quando você estiver usando o AD FS, será necessário habilitar os pontos de extremidade WS-Trust a seguir:

  • /adfs/services/trust/2005/windowstransport
  • /adfs/services/trust/13/windowstransport
  • /adfs/services/trust/2005/usernamemixed
  • /adfs/services/trust/13/usernamemixed
  • /adfs/services/trust/2005/certificatemixed
  • /adfs/services/trust/13/certificatemixed

Aviso

O adfs/services/trust/2005/windowstransport e o adfs/services/trust/13/windowstransport devem ser habilitados como pontos de extremidade voltados para a intranet e NÃO devem ser expostos como pontos de extremidade voltados a uma extranet por meio do proxy de aplicativo Web. Para saber mais sobre como desabilitar os pontos de extremidade do Windows do WS-Trust, confira Desabilitar pontos de extremidade do Windows do WS-Trust no proxy. Veja quais pontos de extremidade estão habilitados por meio do console de gerenciamento do AD FS em Serviço>Pontos de extremidade.

Observação

Se o AD FS não for seu serviço de federação local, siga as instruções do fornecedor para garantir que ele dê suporte aos pontos de extremidade WS-Trust 1.3 ou 2005 e que sejam publicados por meio do MEX (Arquivo de Troca de Metadados).

Para que o registro do dispositivo seja concluído, as seguintes declarações precisam existir no token recebido pelo DRS do Azure. O DRS do Azure cria um objeto de dispositivo no Microsoft Entra ID com algumas dessas informações. Em seguida, o Microsoft Entra Connect usará essas informações para associar o objeto de dispositivo recém-criado à conta de computador local.

  • http://schemas.microsoft.com/ws/2012/01/accounttype
  • http://schemas.microsoft.com/identity/claims/onpremobjectguid
  • http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid

Se você precisar ter mais de um nome de domínio verificado, precisará fornecer a seguinte declaração para os computadores:

  • http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid

Se você já estiver emitindo uma declaração ImmutableID (por exemplo, usando mS-DS-ConsistencyGuid ou outro atributo como o valor de origem para a ImmutableID), será necessário fornecer uma declaração correspondente para computadores:

  • http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID

Nas seções a seguir, você encontrará informações sobre:

  • Os valores que cada declaração deve ter.
  • Como uma definição seria no AD FS.

A definição ajuda você a verificar se os valores estão presentes ou se você precisa criá-los.

Observação

Se você não usar o AD FS para o servidor de federação local, siga as instruções do fornecedor para criar a configuração adequada para emitir essas declarações.

Emitir declaração de tipo de conta

A declaração http://schemas.microsoft.com/ws/2012/01/accounttype precisa conter um valor de DJ, que identifica o dispositivo como um computador ingressado no domínio. No AD FS, você pode adicionar uma regra de transformação de emissão que se parece com o seguinte:

@RuleName = "Issue account type for domain-joined computers"
c:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value = "DJ"
);

Emita o objectGUID da conta do computador local

A declaração http://schemas.microsoft.com/identity/claims/onpremobjectguid precisa conter o valor de objectGUID da conta do computador local. No AD FS, você pode adicionar uma regra de transformação de emissão que se parece com o seguinte:

@RuleName = "Issue object GUID for domain-joined computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$", 
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   store = "Active Directory",
   types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
   query = ";objectguid;{0}",
   param = c2.Value
);

Emita o objectSid da conta do computador local

A declaração http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid precisa conter o valor de objectSid da conta do computador local. No AD FS, você pode adicionar uma regra de transformação de emissão que se parece com o seguinte:

@RuleName = "Issue objectSID for domain-joined computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(claim = c2);

Emita a issuerID do computador quando houver vários nomes de domínio verificados no Microsoft Entra ID

A declaração http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid precisa conter o URI (Uniform Resource Identifier) de qualquer um dos nomes de domínio verificados que se conectam ao serviço de federação local (AD FS ou terceiros) que emite o token. No AD FS, você pode adicionar regras de transformação de emissão como as seguintes na ordem específica, após as mostradas acima. É necessário ter uma regra para emitir explicitamente a regra para os usuários. Nas regras a seguir, é adicionada uma primeira regra que identifica o usuário, em vez da autenticação do computador.

@RuleName = "Issue account type with the value User when its not a computer"
NOT EXISTS(
[
   Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value == "DJ"
]
)
=> add(
   Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value = "User"
);

@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
   Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value == "User"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
   Value = regexreplace(
   c1.Value,
   ".+@(?<domain>.+)",
   "http://${domain}/adfs/services/trust/"
   )
);

@RuleName = "Issue issuerID for domain-joined computers"
c:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
   Value = "http://<verified-domain-name>/adfs/services/trust/"
);

Na declaração anterior, <verified-domain-name> é um espaço reservado. Substitua-o por um de seus nomes de domínio verificados no Microsoft Entra ID. Por exemplo, use Value = "http://contoso.com/adfs/services/trust/".

Para obter mais informações sobre nomes de domínio verificados, confira Adicionar um nome de domínio personalizado ao Microsoft Entra ID.

Para obter uma lista dos domínios da empresa verificados, você pode usar o cmdlet Get-MgDomain.

Lista de domínios da empresa

Emitir ImmutableID para o computador quando houver um para os usuários (por exemplo, usando mS-DS-ConsistencyGuid como a origem da ImmutableID)

A declaração http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID precisa conter um valor válido para computadores. No AD FS, você pode criar uma regra de transformação de emissão da seguinte maneira:

@RuleName = "Issue ImmutableID for computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   store = "Active Directory",
   types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
   query = ";objectguid;{0}",
   param = c2.Value
);

Script auxiliar para criar regras de transformação de emissão do AD FS

O script a seguir ajuda você com a criação das regras de transformação de emissão descritas anteriormente.

$multipleVerifiedDomainNames = $false
$immutableIDAlreadyIssuedforUsers = $false
$oneOfVerifiedDomainNames = 'example.com'   # Replace example.com with one of your verified domains

$rule1 = '@RuleName = "Issue account type for domain-joined computers"
c:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value = "DJ"
);'

$rule2 = '@RuleName = "Issue object GUID for domain-joined computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   store = "Active Directory",
   types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
   query = ";objectguid;{0}",
   param = c2.Value
);'

$rule3 = '@RuleName = "Issue objectSID for domain-joined computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(claim = c2);'

$rule4 = ''
if ($multipleVerifiedDomainNames -eq $true) {
$rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
NOT EXISTS(
[
   Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value == "DJ"
]
)
=> add(
   Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value = "User"
);

@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
   Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value == "User"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
   Value = regexreplace(
   c1.Value,
   ".+@(?<domain>.+)",
   "http://${domain}/adfs/services/trust/"
   )
);

@RuleName = "Issue issuerID for domain-joined computers"
c:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
   Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
);'
}

$rule5 = ''
if ($immutableIDAlreadyIssuedforUsers -eq $true) {
$rule5 = '@RuleName = "Issue ImmutableID for computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   store = "Active Directory",
   types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
   query = ";objectguid;{0}",
   param = c2.Value
);'
}

$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules

$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5

$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules

Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString

Comentários

  • Esse script acrescenta as regras às regras existentes. Não execute o script duas vezes porque o conjunto de regras será adicionado duas vezes. Certifique-se de que não exista nenhuma regra correspondente para essas declarações (sob as condições correspondentes) antes de executar o script novamente.

  • Se você tiver diversos nomes de domínio verificados, configure o valor de $multipleVerifiedDomainNames no script como $true. Além disso, certifique-se de remover qualquer declaração issuerid existente criada pelo Microsoft Entra Connect ou outros meios. Aqui está um exemplo dessa regra:

    c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
    => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)",  "http://${domain}/adfs/services/trust/")); 
    

Se você já tiver emitido uma declaração ImmutableID para contas de usuário, defina o valor de $immutableIDAlreadyIssuedforUsers no script como $true.

Solucionar problemas de implementação

Se estiver com problemas para concluir o ingresso no Microsoft Entra híbrido de dispositivos Windows unidos ao domínio, confira: