Compartir a través de

Enlace de nombre de host alternativo para la autenticación de certificado en AD FS en Windows Server

  • Artículo

Se aplica a: Windows Server 2016 y versiones posteriores

En muchas redes, es posible que las directivas de firewall local no permitan el tráfico a través de puertos no estándar como el 49443. Los puertos no estándar pueden crear problemas durante la autenticación de certificados con AD FS en Windows Server para versiones anteriores de Windows. No son posibles enlaces diferentes para la autenticación de dispositivos y la autenticación de certificados de usuario en el mismo host.

En el caso de las versiones de Windows anteriores a Windows Server 2016, el puerto predeterminado 443 está enlazado para recibir certificados de dispositivo. Este puerto no se puede modificar para admitir varios enlaces en el mismo canal. La autenticación con tarjeta inteligente no funciona y no hay ninguna notificación a los usuarios que explique la causa.

AD FS en Windows Server admite el enlace de nombres de host alternativo

AD FS en Windows Server proporciona compatibilidad con el enlace de nombres de host alternativos mediante dos modos:

  • El primer modo usa el mismo host (adfs.contoso.com) con puertos diferentes (443, 49443).

  • El segundo modo utiliza diferentes hosts (adfs.contoso.com y certauth.adfs.contoso.com) con el mismo puerto (443). Este modo requiere un certificado TLS/SSL que admita certauth.\<adfs-service-name> como nombre alternativo del firmante. El enlace de nombre de host alternativo se puede configurar en el momento de la creación de la granja de servidores o más adelante mediante PowerShell.

Configuración del enlace de nombre de host alternativo para la autenticación de certificado

Existen dos formas de agregar el enlace del nombre de host alternativo para la autenticación de certificado:

  • El primer enfoque es al configurar una nueva granja de AD FS con AD FS para Windows Server 2016. Si el certificado contiene un nombre alternativo del firmante (SAN), el certificado se configura automáticamente para usar el segundo modo descrito anteriormente. Dos hosts diferentes (sts.contoso.com y certauth.sts.contoso.com) se configuran automáticamente con el mismo puerto.

    Si el certificado no contiene un SAN, un mensaje de advertencia indica que los nombres alternativos del firmante del certificado no admiten certauth.*:

    The SSL certificate subject alternative names do not support host name 'certauth.adfs.contoso.com'. Configuring certificate authentication binding on port '49443' and hostname 'adfs.contoso.com'.

The SSL certificate does not contain all UPN suffix values that exist in the enterprise. Users with UPN suffix values not represented in the certificate will not be able to Workplace-Join their devices. For more information, see http://go.microsoft.com/fwlink/?LinkId=311954.

    Para una instalación en la que el certificado contiene un SAN, solo verá la segunda parte del mensaje:

    The SSL certificate does not contain all UPN suffix values that exist in the enterprise. Users with UPN suffix values not represented in the certificate will not be able to Workplace-Join their devices. For more information, see http://go.microsoft.com/fwlink/?LinkId=311954.

  • El segundo enfoque está disponible después de implementar AD FS en Windows Server. Puede usar el cmdlet Set-AdfsAlternateTlsClientBinding de PowerShell para agregar el enlace de nombre de host alternativo para la autenticación de certificados. Para más información, consulte Set-AdfsAlternateTlsClientBinding.

    Set-AdfsAlternateTlsClientBinding -Member ADFS1.contoso.com -Thumbprint '<thumbprint of cert>'

En el mensaje para confirmar la configuración del certificado, seleccione Sí o Sí a todo.