Freigeben über

Alternative Hostnamenbindung für zertifikatbasierte Authentifizierung in AD FS unter Windows Server

In vielen Netzwerken lassen die lokalen Firewallrichtlinien möglicherweise keinen Datenverkehr über nicht standardmäßige Ports wie 49443 zu. Nicht standardmäßige Ports können Probleme bei der Zertifikatauthentifizierung mit AD FS unter Windows Server für frühere Versionen von Windows darstellen. Unterschiedliche Bindungen für die Geräteauthentifizierung und die Authentifizierung von Benutzerzertifikaten auf demselben Host sind nicht möglich.

Für Windows-Versionen vor Windows Server 2016 ist der Standardport 443 an den Empfang von Gerätezertifikaten gebunden. Dieser Port kann nicht geändert werden, um mehrere Bindungen im selben Kanal zu unterstützen. Die Smartcard-Authentifizierung funktioniert nicht, und es gibt keine Benachrichtigung an Benutzer, die die Ursache dafür erläutert.

Unterstützung der alternativen Hostnamenbindung durch AD FS in Windows Server

AD FS unter Windows Server unterstützt die Bindung alternativer Hostnamen mithilfe von zwei Modi:

  • Der erste Modus verwendet denselben Host (adfs.contoso.com) mit unterschiedlichen Ports (443 und 49443).

  • Der zweite Modus verwendet verschiedene Hosts (adfs.contoso.com und certauth.adfs.contoso.com) mit demselben Port (443). Dieser Modus erfordert ein TLS/SSL-Zertifikat zur Unterstützung von certauth.\<adfs-service-name> als alternativer Antragstellername. Die Bindung alternativer Hostnamen kann zum Zeitpunkt der Farmerstellung oder später mithilfe von PowerShell konfiguriert werden.

Konfigurieren der alternativen Hostnamenbindung für die Zertifikatauthentifizierung in AD FS

Es gibt zwei Möglichkeiten, die alternative Hostnamenbindung für die Zertifikatauthentifizierung hinzuzufügen:

  • Die erste besteht darin, eine neue AD FS-Farm mit AD FS für Windows Server 2016 einzurichten. Wenn das Zertifikat einen alternativen Antragstellernamen (Subject Alternative Name, SAN) enthält, wird das Zertifikat automatisch für die Verwendung des zuvor beschriebenen zweiten Modus eingerichtet. Zwei verschiedene Hosts (sts.contoso.com und certauth.sts.contoso.com) werden automatisch mit demselben Port eingerichtet.

    Wenn das Zertifikat keinen SAN enthält, wird in einer Warnmeldung darauf hingewiesen, dass alternative Namen des Zertifikatantragstellers certauth.* nicht unterstützen:

    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.

    Bei einer Installation, bei der das Zertifikat einen SAN enthält, wird nur der zweite Teil der Nachricht angezeigt:

    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.

  • Das zweite Verfahren ist möglich, nachdem Sie AD FS unter Windows Server bereitgestellt haben. Sie können das PowerShell-Cmdlet Set-AdfsAlternateTlsClientBinding verwenden, um die alternative Hostnamenbindung für die Zertifikatauthentifizierung hinzuzufügen. Weitere Informationen finden Sie unter Set-AdfsAlternateTlsClientBinding.

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

Wählen Sie bei der Aufforderung zur Bestätigung der Zertifikatkonfiguration die Option Ja oder Ja, alle aus.