Partager via

Liaison d'autres noms d’hôte pour l’authentification par certificat dans AD FS sur Windows Server

Sur de nombreux réseaux, il est possible que les stratégies de pare-feu locales n'autorisent pas le trafic via des ports non standard tels que 49443. Les ports non standard peuvent générer des problèmes lors de l’authentification par certificat avec AD FS sur Windows Server pour les versions antérieures de Windows. Il n’est pas possible d’établir des liaisons différentes pour l’authentification d’appareil et l’authentification par certificat utilisateur sur le même hôte.

Pour les versions de Windows antérieures à Windows Server 2016, le port par défaut 443 est lié à la réception de certificats d’appareil. Ce port ne peut pas être modifié pour prendre en charge plusieurs liaisons dans le même canal. L’authentification par carte à puce ne fonctionne pas et aucune notification aux utilisateurs n'en explique la cause.

AD FS dans Windows Server prend en charge la liaison d’un autre nom d’hôte

AD FS dans Windows Server prend en charge la liaison d’autres noms d’hôte à l’aide de deux modes :

  • Le premier mode utilise le même hôte (adfs.contoso.com) avec différents ports (443, 49443).

  • Le deuxième mode utilise des hôtes différents (adfs.contoso.com et certauth.adfs.contoso.com) avec le même port (443). Ce mode nécessite un certificat TLS/SSL pour prendre en charge certauth.\<adfs-service-name> en tant qu'autre nom d’objet. La liaison d'autres noms d’hôte peut être configurée au moment de la création de la batterie de serveurs ou ultérieurement à l’aide de PowerShell.

Comment configurer une autre liaison de nom d’hôte pour l’authentification par certificat

Il existe deux façons d’ajouter la liaison d'autres noms d’hôte pour l’authentification par certificat :

  • La première approche consiste à configurer une nouvelle batterie de serveurs AD FS avec AD FS pour Windows Server 2016. Si le certificat contient un autre nom d’objet (SAN), il est automatiquement configuré pour utiliser le deuxième mode décrit précédemment. Deux hôtes différents (sts.contoso.com et certauth.sts.contoso.com) sont configurés automatiquement avec le même port.

    Si le certificat ne contient pas de SAN, un message d’avertissement indique que les autres noms d’objet du certificat ne prennent pas en charge 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.

    Pour une installation où le certificat contient un san, seule la deuxième partie du message n'est visible :

    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.

  • La deuxième approche est disponible après le déploiement d’AD FS sur Windows Server. Vous pouvez utiliser l’applet de commande PowerShell Set-AdfsAlternateTlsClientBinding pour ajouter la liaison d'autres noms d’hôte pour l’authentification par certificat. Pour plus d’informations, consultez : Set-AdfsAlternateTlsClientBinding.

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

À l’invite demandant de confirmer la configuration du certificat, sélectionnez Oui ou Oui pour tout.