Configuración manual de la unión a Azure Active Directory híbrido

  • Artículo

Si usar Azure AD Connect es una opción, consulte las instrucciones de Configuración de la unión a Azure AD híbrido. Mediante la automatización en Azure AD Connect, puede simplificar considerablemente la configuración de la unión de Azure AD híbrido.

En este artículo se trata la configuración manual de los requisitos para la unión a Azure AD híbrido, incluidos los pasos para dominios administrados y federados.

Requisitos previos

  • Azure AD Connect, versión 1.1.819.0 o posterior
    • Para que la combinación de sincronización de registro de dispositivos se realice correctamente, como parte de la configuración de registro del dispositivo, no excluya los atributos de dispositivo predeterminados de la configuración de sincronización de Azure AD Connect. Para más información sobre los atributos de dispositivo predeterminados sincronizados con Azure AD, consulte Sincronización de Azure AD Connect: Atributos sincronizados con Azure Active Directory.
    • Si los objetos de equipo de los dispositivos que desea mantener unidos a Azure AD híbrido pertenecen a unidades organizativas (UO) específicas, configure las OU correctas para sincronizarlas en Azure AD Connect. Para más información acerca de cómo sincronizar objetos de equipo con Azure AD Connect, consulte Filtrado basado en la unidad organizativa.
  • Credenciales de administrador de empresa para su inquilino de Azure AD.
  • Credenciales de administrador de empresa para cada uno de los bosques locales de Active Directory Domain Services.
  • (Para dominios federados) Windows Server 2012 R2 con Servicios de federación de Active Directory (AD FS) instalado.
  • Los usuarios pueden registrar sus dispositivos con Azure AD. Dispone de información complementaria sobre esta configuración en el apartado Configuración de dispositivo del artículo Administración de identidades de dispositivo mediante Azure Portal.

La unión a Azure AD híbrido requiere que los dispositivos tengan acceso a los siguientes recursos de Microsoft desde dentro de la red de su organización:

  • https://enterpriseregistration.windows.net
  • https://login.microsoftonline.com
  • https://device.login.microsoftonline.com
  • https://autologon.microsoftazuread-sso.com (si usa o planea usar SSO de conexión directa)
  • El servicio de token de seguridad (STS) de su organización (para dominios federados)

Advertencia

Si su organización usa servidores proxy que interceptan el tráfico SSL en escenarios tales como la prevención de pérdida de datos o las restricciones de inquilino de Azure AD, asegúrese de que el tráfico a estas direcciones URL se excluya de la interrupción e inspección de TLS. Si no excluye estas direcciones URL, pueden surgir interferencias con la autenticación de los certificados de cliente, lo que causaría problemas con el registro de dispositivos y el acceso condicional basado en dispositivos.

Si la organización necesita acceso a Internet mediante un proxy de salida, puede usar la detección automática de proxy web (WPAD) para que los equipos con Windows 10 o versiones posteriores efectúen el registro de dispositivos con Azure AD. Para solucionar problemas de configuración y administración de WPAD, consulte Solución de problemas de la detección automática.

Si no usa WPAD, puede configurar el proxy en WinHTTP a partir de la versión 1709 de Windows 10. Para más información, consulte Configuración del servidor proxy WinHTTP implementado por GPO.

Nota:

Si configura el proxy en el equipo mediante WinHTTP, todos los equipos que no se puedan conectar al proxy configurado no podrán conectarse a Internet.

Si la organización requiere acceso a Internet mediante un servidor proxy saliente autenticado, asegúrese de que los equipos con Windows 10 o versiones posteriores pueden autenticarse correctamente en el proxy de salida. Debido a que los equipos con Windows 10 o versiones posteriores ejecutan el registro de dispositivos mediante el contexto del equipo, configure la autenticación del proxy de salida mediante el contexto del equipo. Realice un seguimiento con su proveedor de proxy de salida en relación a los requisitos de configuración.

Compruebe si el dispositivo tiene acceso a los recursos de Microsoft anteriores con la cuenta del sistema. Para ello, utilice el script para probar la conectividad del registro de dispositivos.

Configuración

Puede configurar dispositivos híbridos unidos a un dominio de Active AD para varios tipos de plataformas de dispositivos Windows.

Una vez completadas estas configuraciones, siga las instrucciones para la comprobación del registro y habilitar los sistemas operativos de nivel inferior cuando sea necesario.

Configurar un punto de conexión de servicio

El objeto de punto de conexión de servicio (SCP) lo usan los dispositivos durante el registro para detectar la información del inquilino de Azure AD. En la instancia de Active Directory local, el objeto SCP para los dispositivos unidos a Azure AD híbrido debe existir en la partición del contexto de nomenclatura de la configuración del bosque del equipo. Hay solo un contexto de nomenclatura de configuración por bosque. En una configuración de Active Directory de varios bosques, el punto de conexión debe existir en todos los bosques que contienen equipos unidos al dominio.

El objeto SCP contiene dos valores de palabra clave: azureADid:<TenantID> y azureADName:<verified domain>. El valor <verified domain> de la palabra clave azureADName determina el tipo de flujo de registro del dispositivo (federado o administrado) que el dispositivo seguirá después de leer el valor de SCP de la instancia de Active Directory local. Puede encontrar más información sobre los flujos administrados y federados en el artículo Funcionamiento del registro de dispositivos de Azure AD.

Se puede usar el comando Get ADRootDSE para recuperar el contexto de nomenclatura de configuración del bosque.

En el caso de un bosque con el nombre de dominio de Active Directory fabrikam.com, el contexto de nomenclatura de configuración es:

CN=Configuration,DC=fabrikam,DC=com

En el bosque, el objeto de SCP para el registro automático de los dispositivos unidos a un dominio se encuentra en:

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

En función de cómo se haya implementado Azure AD Connect, el objeto SCP puede que ya se haya configurado. Con el siguiente script de Windows PowerShell se puede comprobar la existencia del objeto y recuperar los valores de detección:

$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;

La salida de $scp.Keywords muestra la información del inquilino de Azure AD. Este es un ejemplo:

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

Configurar la emisión de notificaciones

En una configuración de Azure AD federada, los dispositivos usan AD FS, o un servicio de federación local de un asociado de Microsoft para autenticarse en Azure AD. Los dispositivos se autentican para obtener un token de acceso para registrarse en Azure Active Directory Device Registration Service (Azure DRS).

Los dispositivos de Windows actuales se autentican mediante la autenticación integrada de Windows en un punto de conexión de WS-Trust activo (versiones 1.3 o 2005) hospedado por el servicio de federación local.

Cuando use AD FS, debe habilitar los siguientes puntos de conexión de WS-Trust

  • /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

Advertencia

Tanto adfs/services/trust/2005/windowstransport como adfs/services/trust/13/windowstransport se deben habilitar como puntos de conexión accesibles desde la intranet y NO deben exponerse como accesible desde la extranet mediante el Proxy de aplicación web. Para más información sobre cómo deshabilitar los puntos de conexión de Windows de WS-Trust, consulte Deshabilitar los puntos de conexión de Windows de WS-Trust en el proxy. Para ver qué puntos de conexión están habilitados, vaya a ServicioPuntos de conexión en la consola de administración de AD FS.

Nota:

Si AD FS no es el servicio de federación local, siga las instrucciones de su proveedor para asegurarse de que admite puntos de conexión de WS-Trust 1.3 o 2005 y que estos se publican a través del archivo de intercambio de metadatos (MEX).

Para que se complete el registro del dispositivo, las siguientes notificaciones deben existir en el token que recibe Azure DRS. Azure DRS creará un objeto de dispositivo en Azure AD con parte de esta información. Después, Azure AD Connect utiliza esta información para asociar el objeto de dispositivo recién creado con la cuenta de equipo 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

Si necesita más de un nombre de dominio comprobado, es preciso proporcionar la siguiente notificación para los equipos:

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

Si ya se emite una notificación de ImmutableID (por ejemplo, mediante mS-DS-ConsistencyGuid u otro atributo como valor de origen para ImmutableID), será preciso proporcionar una notificación correspondiente para los equipos:

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

En las siguientes secciones encontrará información acerca de:

  • Los valores que deben tener todas las notificaciones.
  • El aspecto de una definición en AD FS.

La definición le ayuda a comprobar si los valores están presentes o si debe crearlos.

Nota:

Si no usa AD FS como servidor de federación local, siga las instrucciones de su proveedor para crear la configuración apropiada para emitir estas notificaciones.

Emisión de notificación de tipo de cuenta

La notificación http://schemas.microsoft.com/ws/2012/01/accounttype debe contener un valor de DJ, que identifica el dispositivo como equipo unido a un dominio. En AD FS, puede agregar una regla de transformación de emisión como esta:

@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"
);

Emisión de objectGUID de la cuenta local del equipo

La notificación http://schemas.microsoft.com/identity/claims/onpremobjectguid debe contener el valor objectGUID de la cuenta local del equipo. En AD FS, puede agregar una regla de transformación de emisión como esta:

@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
);

Emisión de objectSID de la cuenta local del equipo

La notificación http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid debe contener el valor objectSid de la cuenta de equipo local. En AD FS, puede agregar una regla de transformación de emisión como esta:

@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);

Emisión de issuerID para el equipo cuando hay varios nombres de dominio comprobados en Azure AD

La notificación http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid debe contener el identificador uniforme de recursos (URI) de cualquiera de los nombres de dominio comprobados que se conectan al servicio de federación local (AD FS o uno de asociados) que emite el token. En AD FS, puede agregar reglas de transformación de emisión que se parecen a las que verá a continuación en ese orden específico después de las anteriores. Se necesita una regla que emita explícitamente la regla para los usuarios. En las siguientes reglas se agrega una primera regla que identifica al usuario, en lugar de la autenticación del equipo.

@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/"
);

En la notificación anterior, <verified-domain-name> es un marcador de posición. Reemplace el marcador de posición por uno de los nombres de dominio comprobados en Azure AD. Por ejemplo, use Value = "http://contoso.com/adfs/services/trust/".

Para más información sobre nombres de dominios comprobados, consulte Incorporación de su nombre de dominio personalizado a Azure Active Directory.

Para obtener una lista de los dominios comprobados de la compañía, puede usar el cmdlet Get-MsolDomain.

Lista de dominios de la compañía

Emisión de ImmutableID para el equipo cuando existe uno para los usuarios (por ejemplo, mediante mS-DS-ConsistencyGuid como origen de ImmutableID)

La notificación http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID debe contener un valor válido para los equipos. En AD FS, se puede crear una regla de transformación de emisión como se indica a continuación:

@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 crear reglas de transformación de emisión de AD FS

El siguiente script le ayuda con la creación de las reglas de transformación de emisión que se han descrito 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

Observaciones

  • Este script anexa las reglas a las reglas existentes. No ejecute el script dos veces porque el conjunto de reglas se agregaría dos veces. Asegúrese de que no existe ninguna regla correspondiente para estas notificaciones (en las condiciones correspondientes) antes de volver a ejecutar el script.

  • Si tiene varios nombres de dominio comprobados (como se muestra en Azure Portal o mediante el cmdlet Get-MsolDomain), establezca el valor de $multipleVerifiedDomainNames en el script en $true. Además, asegúrese de que quita cualquier notificación issuerid existente que pueda haber creado Azure AD Connect o a través de otros medios. Este es un ejemplo de esta regla:

    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/"));

Si ya ha emitido una notificación ImmutableID para las cuentas de usuario, establezca el valor de $immutableIDAlreadyIssuedforUsers en el script en $true.

Configuración del servicio de federación para dispositivos de nivel inferior

Los dispositivos de nivel inferior requieren que el servicio de federación local emita notificaciones para admitir la autenticación integrada de Windows (IWA) para el registro de dispositivos.

El servicio de federación local debe admitir la emisión de las notificaciones authenticationmehod y wiaormultiauthn al recibir una solicitud de autenticación para el usuario de confianza de Azure AD que contiene un parámetro resource_params con el siguiente valor codificado:

eyJQcm9wZXJ0aWVzIjpbeyJLZXkiOiJhY3IiLCJWYWx1ZSI6IndpYW9ybXVsdGlhdXRobiJ9XX0

which decoded is {"Properties":[{"Key":"acr","Value":"wiaormultiauthn"}]}

Cuando llega una solicitud de este tipo, el servicio de federación local debe autenticar al usuario mediante la autenticación integrada de Windows. Una vez que la autenticación se haya realizado correctamente, el servicio debe emitir las dos notificaciones siguientes:

http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows http://schemas.microsoft.com/claims/wiaormultiauthn

En AD FS, debe agregar una regla de transformación de emisión que atraviesa el método de autenticación. Para agregar esta regla:

  1. En la consola de administración de AD FS, vaya a AD FS>Relaciones de confianza>Relaciones de confianza para usuario autenticado.

  2. Haga clic con el botón derecho en el objeto de confianza para usuario de confianza de la Plataforma de identidad de Microsoft Office 365 y seleccione Editar reglas de notificación.

  3. En la pestaña Reglas de transformación de emisión, seleccione Agregar regla.

  4. Seleccione Enviar notificaciones con una regla personalizada en la lista de plantillas Regla de notificación.

  5. Seleccione Next (Siguiente).

  6. En el cuadro de texto Nombre de regla de notificación, escriba Regla de notificación del método de autenticación.

  7. En el cuadro Regla de notificación, escriba la siguiente regla:

    c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] => issue(claim = c);

  8. En el servidor de federación, escriba el siguiente comando de PowerShell. Reemplace <RPObjectName> por el nombre del objeto de usuario de confianza para su objeto de confianza de usuario de confianza de Azure AD. Normalmente, este objeto se llama Plataforma de identidad de Microsoft Office 365.

    Set-AdfsRelyingPartyTrust -TargetName <RPObjectName> -AllowedAuthenticationClassReferences wiaormultiauthn

Solución de problemas de la implementación

Si tiene problemas para completar la unión a Azure AD híbrido para los dispositivos Windows unidos a un dominio, consulte:

Pasos siguientes