ADFS Zertifikate

Wenn Sie glauben, dass ADFS 2012R2 und der ADFS-Proxy  als Teil des Web Application Proxy Servers problemlos sind, dann stimmt das für die Installation aber nicht mehr ohne weiteres etwas später. Im Juni 2015 stand bei uns der Austausch des SSL-Zertifikats an. Unsere bisherige CA bat uns das SHA1-Zertifikat durch ein SHA256-Zertifikat zu ersetzen und dann das alte Zertifikat zurückzuziehen oder es wäre eh ausgelaufen. So reibungslos lief der Wechsel dann aber doch nicht.

Wo kommen Zertifikate zum Einsatz ?

Eine normale Kette von Servern und Dienste für die Bereitstellung von ADFS mit Office 365 und externen Clients besteht aus einen ADFS-Proxy und dem ADFS-Server. Der ADFS-Server ist dabei Mitglied der Domäne um die Authentifizierung durchzuführen. Der ADFS-Proxy steht aber in der Regel in einer gesonderten Netzwerkzone, damit er von extern erreichbar ist und die Anfragen nach innen weiter gibt. Der ADFS-Server erwartet dabei aber eine Authentifizierung des ADFS-Proxy per Zertifikat.

Bei der Einrichtung es Windows 2012R2 Web Application Proxy werden Sie daher nach "Anmeldedaten" für den ADFS-Server gefragt. Dies dient dazu, ein Clientzertifikat des ADFS-Proxy-Servers im ADFS-Server als Authentifizierung zu hinterlegen. Die Zertifikate kann man gut in den verschiedenen Management Konsolen sehen. Hier auf einem ADFS-Server.

Falls ihnen mal ein ADFS-Proxy "abhanden" kommt, können Sie mit einem Mausklick die Clientzertifikate des Reverse Proxy auf dem ADFS-Server entfernen.

In dem Zuge ist die folgende Seite sehr lesenswert:

Tauschen auf dem ADFS Server

Da der ADFS-Server per HTTPS angesprochen wird, muss hier natürlich ein Zertifikat für den ADFS-FQDN installiert sein. Alternativ kann auch ein Wildcard-Zertifikat genutzt werden. Sie sehen das Zertifikat einfach in der Management Console des ADFS-Servers.

Sie können hier zwar kein Zertifikat importieren aber mit "Set Service Communication Certificate" angeblich ein bereits installierte Zertifikat dafür aktivieren. Das haben wir natürlich alles gemacht aber es hat selbst nach einem Neustart nicht funktioniert. Irritierend war dabei, dass die MMC sehr wohl das richtige neue Zertifikat angezeigt hat aber wohl die Bindungen vom HTTP.SYS-Treiber nicht gegriffen haben.

Wenn Sie die Gültigkeit von Zertifikaten überprüfen, dann sollte ihr Monitoring-Tool dies auch melden:

Natürlich meldet der ADFS-Server solche Probleme auch im Eventlog. Sie könnten es also rechtzeitig erfahren. Hier hat aber alles per GUI nicht geholfen und erst die PowerShell hat die Falschkonfiguration bestätigt.

PS C:\> Get-AdfsSslCertificate

HostName                           PortNumber  CertificateHash
--------                           ----------  ---------------
localhost                             443      762C27B177BA5048ECED54C9250A0174D845412C
adfs.msxfaq.de                        443      762C27B177BA5048ECED54C9250A0174D845412C
adfs.msxfaq.de                      49443      762C27B177BA5048ECED54C9250A0174D845412C

Erst das Setzen des Zertifikats per PowerShell hat die gewünschte Änderung bewirkt:

PS C:\> set-AdfsSslCertificate -Thumbprint 3f65896b1e2102515fc7942bd1fc6d9f3603c04a
PS C:\> Get-AdfsSslCertificate

HostName                           PortNumber  CertificateHash
--------                           ----------  ---------------
localhost                             443      3F65896B1E2102515FC7942BD1FC6D9F3603C04A
adfs.msxfaq.de                        443      3F65896B1E2102515FC7942BD1FC6D9F3603C04A
adfs.msxfaq.de                      49443      3F65896B1E2102515FC7942BD1FC6D9F3603C04A

Vielleicht war auch nur irgendwas auf diesem Server anders. Aber es Bewahrheitet sich wieder, dass Sie jede Änderung auch durch einen zweiten Weg überprüfen sollten. Das neue Zertifikat wurde sogar ohne Neustart des ADFS-Servers aktiv.

Tauschen auf dem ADFS Proxy

Dann blieb noch der ADFS-Proxy, der aus dem Internet auch per HTTPS mit einem Zertifikat erreichbar ist. Hier wird es etwas kniffliger, da es keine GUI gibt um das Zertifikat zu ändern. Da hier das Zertifikat bereits abgelaufen war, konnte der Web Application Proxy gar nicht mehr starten und die GUi war noch mehr beschränkt. Also war hier gleich PowerShell angesagt. Auch hier war der IST-Stand schnell analysiert:

PS C:\ > Get-WebApplicationProxySslCertificate

HostName          PortNumber CertificateHash -------- ---------- ---------------
adfs.msxfaq.de    443        762C27B177BA5048ECED54C9250A0174D845412C
adfs.msxfaq.de    49443      762C27B177BA5048ECED54C9250A0174D845412C

Auch hier war noch der alte Hashwert zu sehen. Ein Blick in die MMC für Zertifikate hat natürlich gezeigt, dass auch auf diesem Server schon das neue Zertifikat mit privatem Schlüssel und auch die neue Zwischenzertifizierungsstelle bereits richtig eingespielt worden waren. Und das neue Zertifikat war sogar schon beim Direct Access Service eingebunden. Hier gibt es ja eine GUI für. Aber wer geglaubt hat, dass die Verwaltung "Remote Access Management" so einen Wechsel auch für andere Dienste einrichtet oder dass der Dienst alleine das "passende Zertifikat" sucht, der irrt. Exchange verhält sich hier sehr viel konstruktiver, indem Exchange aus den verfügbaren Zertifikaten alleine das "beste" Zertifikat bindet. Bei ADFS-Proxy-Servern muss der Administrator von Hand die Bindung ändern.

PS C:\ > set-WebApplicationProxySslCertificate `
   -Thumbprint 3f65896b1e2102515fc7942bd1fc6d9f3603c04a
The configuration completed successfull
 DeploymentSucceeded Success

PS C:\> Get-WebApplicationProxySslCertificate

HostName          PortNumber CertificateHash
--------          ---------- ---------------
adfs.msxfaq.de 443           3F65896B1E2102515FC7942BD1FC6D9F3603C04A
adfs.msxfaq.de 49443         3F65896B1E2102515FC7942BD1FC6D9F3603C04A

PS C:\> net stop adfssrv
The Active Directory Federation Services service is stopping.
The Active Directory Federation Services service was stopped successfully.

PS C:\> net start adfssrv
The Active Directory Federation Services service is starting.
The Active Directory Federation Services service was started successfully.

Danach wäre alles richtig gewesen, aber dennoch konnte der ADFS-Proxy sich nicht am ADFS-Server anmelden. Manchmal verschwören sich alle Bits gegen den Administrator und in dem Fall war auch noch das Clientzertifikat abgelaufen. Wie man hier auf dem ADFS-Proxy sieht, haben sich schon einige Zertifikate angesammelt:

Das wusste ich aber zu der Zeit noch nicht und der Assistent zur Einrichtung des ADFS-Proxy kommt nur bei der Installation der Rolle. Sie finden daher verschiedene Quellen, die einfach zur Deinstallation und Neuinstallation der Rolle raten. Das muss aber nicht sein. Hier eine Quelle, die die Funktion beschreibt

...The proxy trust relationship between a Web Application Proxy server and the AD FS 2012 R2 server is client certificate based. ...
When the client certificate authentication is negotiated, the AD FS server sends a Certificate Trust List (CTL) based on the contents of the AdfsTrustedDevices store. A CTL allows a client to filter valid client certificates from all the client certificates that may be present. If the CTL list of filtered certificates returns only a single certificate which is presented without the user needing to manually select a certificate.
Quelle: http://blogs.technet.com/b/applicationproxyblog/archive/2014/05/28/understanding-and-fixing-proxy-trust-ctl-issues-with-ad-fs-2012-r2-and-web-application-proxy.aspx

Achten Sie also einfach darauf, dass auf dem ADFS-Proxy ein SelfSigned Zertifikat vorliegt und diese auf dem ADFS-Server im "AdfsTrustedDevices"-Store liegt. Der korrekte Weg zur Einrichtung erfolgt wieder über ein PowerShell Commandlet. Der Befehl "Install-WebApplicationProxy" installiert allerdings nicht den Web Application Proxy, sondern konfiguriert ihn für die Benutzung mit einem Backend System".

# Anmeldedaten für den Zugriff auf den ADFS-Server angeben
$cred = Get-Credential

# lokale Zertifikat im angegeben ADFS-Server als "TrustProxy"-Zertifikat installieren und lokalen ADFSProxy konfigurieren.
Install-WebApplicationP$cred$credroxy `
   -FederationServiceName "adfs.msxfaq.de" `
   -FederationServiceTrustCredential $cred `
   -CertificateThumbprint "0a1b2c3d0a1b2c3d0a1b2c3d0a1b2c3d0a1b2c3d"

Der Zertifikat, mit welchem sich der ADFS-Proxy Server beim ADFS-Server authentifiziert, müssen Sie in dem Fall selbst bereitstellen:

Tipp: Wie wäre es, wenn Sie dem Computer ein Computerzertifikat ihrer internen PKI geben, welches z.B. 5 Jahre gilt. Sie können es für die Sicherung des RDP-Zugriffs etc. Und für die ADFS-Authentifizierung nutzen. Nebenbei könnten Sie über die PKI erkennen, wann es abläuft. Denn die Überwachung dieses Zertifikats auf Ablauf geht nur über das Eventlog.

Checks

Abgesehen davon, dass Sie alle Dienste mit einem Zertifikat von beiden Seiten überwachen sollten, d.h. einmal durch einen synthetischen TLS-Handshake um das Zertifikat über das Netzwerk zu prüfen aber auch über die Eventlogs, um z.B. das Ablaufen von Client-Zertifikaten zu erkennen.

Da ADFS2012R2 nicht mehr auf dem IIS basiert, sondern ein eigener Webservice ist, der sich aber des HTTP.SYS bedient, sollten Sie auch die dazu passende Kommandozeile können:

netsh http show sslcert

Damit sollten Sie alle aktuellen Bindungen samt Zertifikate sehen. Diese sind maßgeblich, da Sie direkt aus der Konfiguration der HTTP-Listeners stammen.

Aber auch mit der PowerShell können Sie die Zertifikate anzeigen und auch ändern. Hier am Beispiel des ADFS-Proxy

PS C:\> Get-WebApplicationProxyHealth

Component          : AD FS Proxy
RemoteAccessServer : DA
HealthState        : OK
Heuristics         : {}
TimeStamp          : 6/4/2015 12:55:29 AM

Component          : Web Application Proxy Core
RemoteAccessServer : DA
HealthState        : OK
Heuristics         : {}
TimeStamp          : 6/4/2015 12:55:29 AM

Weitere Links