Integración de la identidad de AD FS con Azure Stack Hub en el centro de datos

Artículo
03/29/2024

Puede implementar Azure Stack Hub mediante Microsoft Entra id. o Servicios de federación de Active Directory (AD FS) (AD FS) como proveedor de identidades. Debe tomar la decisión antes de implementar Azure Stack Hub. En un escenario conectado, puede elegir Microsoft Entra id. o AD FS. Para un escenario desconectado, se admite solo AD FS. En este artículo se muestra cómo integrar AD FS de Azure Stack Hub con AD FS del centro de datos.

Importante

No se puede cambiar el proveedor de identidades sin volver a implementar la solución completa de Azure Stack Hub.

Servicios de federación de Active Directory y Graph

La implementación con AD FS que las identidades de un bosque de Active Directory existente se autentiquen con los recursos de Azure Stack Hub. Este bosque de Active Directory existente requiere una implementación de AD FS para permitir la creación de una confianza de federación de AD FS.

La autenticación es parte de la identidad. Para administrar el control de acceso basado en rol (RBAC) de Azure Stack Hub, se debe configurar el componente Graph. Cuando se delega el acceso a un recurso, el componente de Graph busca la cuenta de usuario en el bosque de Active Directory existente mediante el protocolo LDAP.

Arquitectura de AD FS de Azure Stack Hub

La instancia existente de AD FS es el servicio de token de seguridad (STS) de la cuenta que envía notificaciones a AD FS de Azure Stack Hub (el STS del recurso). En Azure Stack Hub, la automatización crea la relación de confianza del proveedor de notificaciones con el punto de conexión de metadatos de la instancia de AD FS existente.

En la instancia de AD FS existente, se debe configurar una relación de confianza para usuario autenticado. Este paso no se realiza mediante la automatización y debe estar configurado por el operador. El punto de conexión VIP de Azure Stack Hub para AD FS se puede crear con el patrón https://adfs.<Region>.<ExternalFQDN>/.

La configuración de la relación de confianza para usuario autenticado también requiere que configure las reglas de transformación de notificaciones que proceden de Microsoft.

Para la configuración de Graph, se debe proporcionar una cuenta de servicio que tenga permiso de "lectura" en la instancia de Active Directory existente. Esta cuenta es necesaria como entrada para que la automatización habilite escenarios RBAC.

Para el último paso, se configura un nuevo propietario para la suscripción del proveedor predeterminado. Esta cuenta tiene acceso completo a todos los recursos cuando se inicia sesión en el portal del administrador de Azure Stack Hub.

Requisitos:

Componente	Requisito
Grafo	Microsoft Active Directory 2012/2012 R2/2016/2019
AD FS	Windows Server 2012/2012 R2/2016/2019

Configuración de la integración de Graph

Graph solo permite realizar la integración con un único bosque de Active Directory. Si existen varios bosques, solamente el bosque especificado en la configuración se utilizará para capturar los usuarios y grupos.

Se requiere la siguiente información como entrada para los parámetros de automatización:

Parámetro	Parámetro de hoja de cálculo de implementación	Descripción	Ejemplo
`CustomADGlobalCatalog`	FQDN del bosque de AD FS	FQDN del bosque de Active Directory de destino con el que desea realizar la integración	Contoso.com
`CustomADAdminCredentials`		Un usuario con permiso de lectura de LDAP	graphservice

Configuración de los sitios de Active Directory

En las implementaciones de Active Directory con varios sitios, configure el sitio de Active Directory más cercano a la implementación de Azure Stack Hub. La configuración evita que el servicio Graph de Azure Stack Hub resuelva las consultas con un servidor de catálogo global desde un sitio remoto.

Agregue la subred de la red VIP pública de Azure Stack Hub al sitio de Azure Active Directory más cercano a Azure Stack Hub. Por ejemplo, supongamos que su instancia de Active Directory tiene dos sitios: Seattle y Redmond. Si Azure Stack Hub está implementado en el sitio de Seattle, agregaría la subred de la red VIP pública de Azure Stack Hub al sitio de Active Directory de Seattle.

Para más información sobre los sitios de Active Directory, consulte Diseño de la topología de sitio.

Nota:

Si su instancia de Active Directory consta de un único sitio, puede omitir este paso. Si tiene una subred comodín configurada, valide que la subred de la red VIP pública de Azure Stack Hub no forme parte de ella.

Creación de una cuenta de usuario en Active Directory existente (opcional)

Si lo desea, puede crear una cuenta para el servicio Graph en la instancia de Active Directory existente. Realice este paso si ya no tiene una cuenta que desea utilizar.

En la instancia de Active Directory existente, cree la siguiente cuenta de usuario (recomendación):
- Nombre de usuario: graphservice
- Contraseña: Utilice una contraseña segura y configúrela para que no expire nunca.
No se necesita ningún permiso especial ni pertenencia.

Automatización de un desencadenador para configurar un grafo

Para este procedimiento, use un equipo de la red del centro de datos que pueda comunicarse con el punto de conexión con privilegios de Azure Stack Hub.

Abra una sesión de Windows PowerShell con privilegios elevados (ejecútela como administrador) y conéctese a la dirección IP del punto de conexión con privilegios. Use las credenciales para la autenticación con CloudAdmin.
```
$creds = Get-Credential
$pep = New-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)
```
Ahora que dispone de una sesión con el punto de conexión con privilegios, ejecute el siguiente comando:

Ejecute el siguiente script para la compilación 2008 de Azure Stack Hub y versiones posteriores.
```
 $i = @(
        [pscustomobject]@{ 
                  CustomADGlobalCatalog="fabrikam.com"
                  CustomADAdminCredential= Get-Credential -Message "Do not include the domain name of the graphservice account in the username."
                  SkipRootDomainValidation = $false 
                  ValidateParameters = $true
                }) 

 Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -customCatalog $using:i} 
```
Ejecute el siguiente script para compilaciones de Azure Stack Hub anteriores a la compilación 2008.
```
Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -CustomADGlobalCatalog contoso.com} 
```
Cuando se le solicite, especifique la credencial para la cuenta de usuario que desea utilizar para el servicio Graph (por ejemplo, graphservice). La entrada para el cmdlet Register-DirectoryService debe ser el nombre de bosque o la raíz del dominio del bosque en lugar de cualquier otro dominio del bosque.

Importante

Espere las credenciales emergentes (no se admite Get-Credential en el punto de conexión con privilegios) y escriba las credenciales de cuenta del servicio Graph.

El cmdlet Register-DirectoryService tiene parámetros opcionales que puede usar en determinados escenarios donde se produce un error en la validación de Active Directory existente. Cuando se ejecuta este cmdlet, valida que el dominio proporcionado es el dominio raíz, permite acceder a un servidor de catálogo global y la cuenta proporcionada concede acceso de lectura.

Parámetro	Descripción
`SkipRootDomainValidation`	Especifica que se debe usar un dominio secundario, en lugar del dominio raíz recomendado.
`ValidateParameters`	Omite todas las comprobaciones de validación.

Puertos y protocolos de Graph

El servicio Graph de Azure Stack Hub usa los siguientes protocolos y puertos para comunicarse con un servidor de catálogo global (GC) de escritura permitida y un centro de distribución de claves (KDC) que pueda procesar solicitudes de inicio de sesión en el bosque de Active Directory de destino.

El servicio Graph de Azure Stack Hub usa los protocolos y puertos siguientes para comunicarse con la instancia de Active Directory de destino:

Tipo	Port	Protocolo
LDAP	389	TCP y UDP
SSL de LDAP	636	TCP
GC DE LDAP	3268	TCP
SSL de GC de LDAP	3269	TCP

Configuración de la integración de AD FS mediante la descarga de metadatos de federación

Se requiere la siguiente información como entrada para los parámetros de automatización:

Parámetro	Parámetro de hoja de cálculo de implementación	Descripción	Ejemplo
CustomAdfsName	Nombre de proveedor de AD FS	Nombre del proveedor de notificaciones. Aparece de este modo en la página de aterrizaje de AD FS.	Contoso
CustomAD FSFederationMetadataEndpointUri	URI de metadatos de AD FS	Vínculo de metadatos de federación	https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml
SigningCertificateRevocationCheck	N/D	Parámetro opcional para omitir la comprobación de CRL	None

Desencadenamiento de la automatización para configurar la confianza del proveedor de notificaciones en Azure Stack Hub (mediante la descarga de metadatos de federación)

En este procedimiento usará un equipo que pueda comunicarse con el punto de conexión con privilegios de Azure Stack Hub. Se espera que el certificado usado por la instancia de AD FS de STS de la cuenta sea de confianza para Azure Stack Hub.

Abra una sesión de Windows PowerShell con privilegios elevados y conéctese al punto de conexión con privilegios.

$creds = Get-Credential
Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds

Ahora que está conectado al punto de conexión con privilegios, ejecute el comando siguiente con los parámetros adecuados para su entorno:

Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataEndpointUri "https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml"

Ejecute el siguiente comando para actualizar el propietario de la suscripción del proveedor predeterminado, con los parámetros adecuados para su entorno:
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
```

Configuración de la integración de AD FS mediante el archivo de metadatos de federación

A partir de la versión 1807, utilice este método si se cumple alguna de las condiciones siguientes:

La cadena de certificados es diferente para AD FS, en comparación con todos los demás puntos de conexión de Azure Stack Hub.
No hay conectividad de red al servidor de AD FS existente desde la instancia de AD FS de Azure Stack Hub.

Se requiere la siguiente información como entrada para los parámetros de automatización:

Parámetro	Descripción	Ejemplo
CustomAdfsName	Nombre del proveedor de notificaciones. Aparece de este modo en la página de aterrizaje de AD FS.	Contoso
CustomADFSFederationMetadataFileContent	Contenido de los metadatos.	$using:federationMetadataFileContent

Creación de un archivo de metadatos de federación

Para el siguiente procedimiento, debe usar un equipo que tenga conectividad de red a la implementación de AD FS existente, que se convierte en el servicio de token de seguridad de la cuenta. También deben instalarse los certificados necesarios.

Abra una sesión de Windows PowerShell con privilegios elevados y ejecute el comando siguiente con los parámetros adecuados para su entorno:

 $url = "https://win-SQOOJN70SGL.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml"
 $webclient = New-Object System.Net.WebClient
 $webclient.Encoding = [System.Text.Encoding]::UTF8
 $metadataAsString = $webclient.DownloadString($url)
 Set-Content -Path c:\metadata.xml -Encoding UTF8 -Value $metadataAsString

Copie el archivo de metadatos en un equipo que pueda comunicarse con el punto de conexión con privilegios.

Desencadenamiento de la automatización para configurar la confianza del proveedor de notificaciones en Azure Stack Hub (mediante el archivo de metadatos de federación)

En este procedimiento use un equipo que pueda comunicarse con el punto de conexión con privilegios de Azure Stack Hub y que tenga acceso al archivo de metadatos que creó en el paso anterior.

Abra una sesión de Windows PowerShell con privilegios elevados y conéctese al punto de conexión con privilegios.

$federationMetadataFileContent = get-content c:\metadata.xml
$creds=Get-Credential
Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds

Ahora que está conectado al punto de conexión con privilegios, ejecute el comando siguiente con los parámetros adecuados para su entorno:
```
Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataFileContent $using:federationMetadataFileContent
```
Ejecute el siguiente comando para actualizar el propietario de la suscripción del proveedor predeterminado. Use los parámetros apropiados para su entorno.
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
```
Nota:

Al rotar el certificado en la versión existente de AD FS (servicio de token de seguridad de la cuenta) debe configurar la integración de AD FS nuevamente. Debe configurar la integración incluso si el punto de conexión de metadatos es accesible o se ha configurado mediante el archivo de metadatos.

Configuración del usuario de confianza en la implementación de AD FS existente (STS de cuenta)

Microsoft proporciona un script que configura la relación de confianza para usuario autenticado, incluidas las reglas de transformación de notificaciones. El uso del script es opcional, ya que se pueden ejecutar los comandos manualmente.

Puede descargar el script auxiliar desde las herramientas de Azure Stack Hub en GitHub.

Si decide ejecutar manualmente los comandos, siga estos pasos:

Copie el siguiente contenido en un archivo .txt (por ejemplo, guardado como c:\ClaimIssuanceRules.txt) en la instancia de AD FS o como miembro de la granja de servidores del centro de datos:

@RuleTemplate = "LdapClaims"
@RuleName = "Name claim"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"), query = ";userPrincipalName;{0}", param = c.Value);

@RuleTemplate = "LdapClaims"
@RuleName = "UPN claim"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);

@RuleTemplate = "LdapClaims"
@RuleName = "ObjectID claim"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
=> issue(Type = "http://schemas.microsoft.com/identity/claims/objectidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Family Name and Given claim"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"), query = ";sn,givenName;{0}", param = c.Value);

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Group SID claims"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all windows account name claims"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(claim = c);

Confirme que está habilitada la autenticación basada en Windows Forms para extranet e intranet. Compruebe si ya está habilitada mediante la ejecución de este cmdlet:
```
Get-AdfsAuthenticationProvider | where-object { $_.name -eq "FormsAuthentication" } | select Name, AllowedForPrimaryExtranet, AllowedForPrimaryIntranet
```
Nota:

Es posible que las cadenas del agente de usuario compatibles con la autenticación integrada de Windows (WIA) estén obsoletas para la implementación de AD FS y que sea necesario actualizarlas para que sean compatibles con los clientes más recientes. Puede leer más sobre cómo actualizar las cadenas del agente de usuario compatibles con WIA en el artículo Configuración de la autenticación basada en formularios de la intranet para dispositivos que no admiten WIA.

Para conocer los pasos para habilitar la directiva de autenticación basada en formularios, consulte Configuración de directivas de autenticación.
Para agregar la relación de confianza para usuario autenticado, ejecute el siguiente comando de Windows PowerShell en la instancia de AD FS o un miembro de la granja de servidores. Asegúrese de actualizar el punto de conexión de AD FS y seleccione el archivo creado en el paso 1.

Importante

Para los clientes que ejecutan Azure Stack Hub, versión 2002 y posteriores, TLS 1.2 se aplica en el punto de conexión de ADFS de Azure Stack Hub. Por lo tanto, TLS 1.2 también debe estar habilitado en los servidores de ADFS del cliente. De lo contrario, se producirá el siguiente error al ejecutar Add-ADFSRelyingPartyTrust en el host o granja de ADFS propiedad del cliente:

Add-ADFSRelyingPartyTrust : The underlying connection was closed: An unexpected error occurred on a send.

Para AD FS 2016/2019
```
Add-ADFSRelyingPartyTrust -Name AzureStack -MetadataUrl "https://YourAzureStackADFSEndpoint/FederationMetadata/2007-06/FederationMetadata.xml" -IssuanceTransformRulesFile "C:\ClaimIssuanceRules.txt" -AutoUpdateEnabled:$true -MonitoringEnabled:$true -enabled:$true -AccessControlPolicyName "Permit everyone" -TokenLifeTime 1440
```
Para AD FS 2012/2012 R2
```
Add-ADFSRelyingPartyTrust -Name AzureStack -MetadataUrl "https://YourAzureStackADFSEndpoint/FederationMetadata/2007-06/FederationMetadata.xml" -IssuanceTransformRulesFile "C:\ClaimIssuanceRules.txt" -AutoUpdateEnabled:$true -MonitoringEnabled:$true -enabled:$true -TokenLifeTime 1440
```
Importante

Debe usar el complemento MMC de AD FS para configurar las reglas de autorización de emisión cuando se usa AD FS de Windows Server 2012 o 2012 R2.
Cuando se usa el explorador Internet Explorer o Microsoft Edge para acceder a Azure Stack Hub, debe omitir los enlaces de token. En caso contrario, se producirá un error al intentar iniciar sesión. En la instancia de AD FS o en un miembro de la granja de servidores, ejecute el siguiente comando:

Nota:

Este paso no es aplicable cuando se usa AD FS con Windows Server 2012 o 2012 R2. En este caso, no pasa nada si omite este comando y continúa con la integración.
```
Set-AdfsProperties -IgnoreTokenBinding $true
```

Creación de SPN

Hay muchos escenarios que requieren el uso de un nombre de entidad de seguridad de servicio (SPN) para la autenticación. A continuación se muestran algunos ejemplos.

Uso de la CLI de Azure con la implementación de AD FS de Azure Stack Hub.
Módulo de administración de System Center para Azure Stack Hub cuando se implementa con AD FS.
Proveedores de recursos de Azure Stack Hub cuando se implementan con AD FS.
Varias aplicaciones.
Se requiere un inicio de sesión no interactivo.

Importante

AD FS solo admite sesiones de inicio de sesión interactivo. Si necesita un inicio de sesión no interactivo para un escenario automatizado, debe utilizar un nombre de entidad de seguridad de servicio.

Para más información sobre cómo crear un nombre de entidad de seguridad de servicio, consulte la sección Creación de una entidad de servicio para AD FS.

Solución de problemas

Reversión de la configuración

Si se produce un error que deja el entorno en un estado donde ya no se puede realizar la autenticación, está disponible una opción de reversión.

Abra una sesión de Windows PowerShell con privilegios elevados y ejecute el siguiente comando:

$creds = Get-Credential
Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds

Después, ejecute el siguiente cmdlet:
```
Reset-DatacenterIntegrationConfiguration
```
Tras ejecutar la acción de reversión, todos los cambios de configuración se revierten. Solo es posible la autenticación con el usuario CloudAdmin integrado.

Importante

Debe configurar el propietario original de la suscripción del proveedor predeterminado.
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "azurestackadmin@[Internal Domain]"
```

Recopilación de registros adicionales

Si se produce un error en cualquiera de los cmdlets, puede recopilar registros adicionales mediante el cmdlet Get-Azurestacklogs.

Abra una sesión de Windows PowerShell con privilegios elevados y ejecute el siguiente comando:

$creds = Get-Credential
Enter-pssession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds

Después, ejecute el siguiente cmdlet:

Get-AzureStackLog -OutputPath \\myworkstation\AzureStackLogs -FilterByRole ECE

Pasos siguientes

Integración de soluciones de supervisión externa

Integración de la identidad de AD FS con Azure Stack Hub en el centro de datos

Servicios de federación de Active Directory y Graph

Configuración de la integración de Graph

Configuración de los sitios de Active Directory

Creación de una cuenta de usuario en Active Directory existente (opcional)

Automatización de un desencadenador para configurar un grafo

Puertos y protocolos de Graph

Configuración de la integración de AD FS mediante la descarga de metadatos de federación

Desencadenamiento de la automatización para configurar la confianza del proveedor de notificaciones en Azure Stack Hub (mediante la descarga de metadatos de federación)

Configuración de la integración de AD FS mediante el archivo de metadatos de federación

Creación de un archivo de metadatos de federación

Desencadenamiento de la automatización para configurar la confianza del proveedor de notificaciones en Azure Stack Hub (mediante el archivo de metadatos de federación)

Configuración del usuario de confianza en la implementación de AD FS existente (STS de cuenta)

Creación de SPN

Solución de problemas

Reversión de la configuración

Recopilación de registros adicionales

Pasos siguientes

Comentarios

Comentarios

Recursos adicionales