ADFS Zertifikate

Im Verbund mit ADFS arbeiten Clients, Service und ADFS eng miteinander zusammen und da es dabei um Authentifizierung geht, sollte eine Fälschung der Identität unmöglich sein. Stellen Sie sich vor ein Anwender könnte von einem ADFS-Server ein Ticket erhalten, mit dem er sich als jemand anderes ausgeben könnte. Um das zu verhindern werden Verbindungen aber auch Daten verschlüsselt und signiert. Dies erfolgt klassische mit den üblichen kryptografischen Verfahren und das erforderliche Schlüsselmaterial wird als Zertifikate gespeichert.

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.

Zudem gibt es natürlich den Dienst wie z.B. Exchange oder SharePoint, die den Zugriff eines Anwenders nur zulassen, wenn dieser sich erfolgreich authentifiziert hat.

Auf dem Bild sehen sie folgende Zertifikate:

Nummer Einsatz Beschreibung

1

WebServer

Alle Dienste, die per HTTPS angesprochen werden, benötigen natürlich ein klassisches "Web Server Zertifikat. Solch ein Zertifikate finden Sie auf SharePoint, Exchange aber auch auf immer mehr anderen Webdiensten, die per ADFS und Browser genutzt werden können.

Die Verschlüsselung ist wichtig um die übertragenen Daten z zu schützen. Gerade beim ADFS mit "Form Based"-Anmeldung könnte jemand ansonsten die Anmeldedaten erhalten.

2

Token Signing

Die vom ADFS-Server ausgestellten SAML-Informationen sind digital signiert. Dazu braucht der ADFS-Server einen privaten Schlüssel und der öffentliche Schlüssel wird als Zertifikat gespeichert. Dieses Zertifikat müssen Sie bei allen Diensten einspielen, damit diese die Gültigkeit des Tokens verifizieren können.

Dies ist üblicherweise ein "Self Signed"-Zertifikat. Machen Sie sich also Gedanken, wie sie ein ablaufendes Zertifikat auf dem ADFS-Server aber auch den vertrauenden Systemen aktualisieren.

Im Bild sehen sie die grünen HTTP-Pfeile. Der Service kann sich das Zertifikat nach einem RollOver selbst holen

Umgekehrt kann Admin beim Einrichten des Relying Party Trust per https die Konfiguration beziehen.

3

Token Decryption

Optional kann das Token auch noch verschlüsselt werden.

4

Token Signing

Auf dem Service-System können auch Zertifikate für ADFS addiert werden, damit z.B. die Anfrage des Clients an den ADFS-Server ebenfalls signiert wird.

5

Client Certificate

Zuletzt habe ich noch Zertifikate auf dem Client eingezeichnet, mit denen sich der Anwender am ADF-Server authentifizireren kann. So kann ein zweiter Faktor genutzt werden. Es sind aber auch andere Wege einer Multi Faktor Authentifizierung möglich.

Zertifikate haben die unangenehme Eigenschaft nur eine endliche Gültigkeit zu haben. Sie sollten auf jeden Fall eine Überwachung einrichten, um hier informiert zu werden.

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-WebApplicationProxy `
   -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.

Client Zertifikate

Anstatt sich per Benutzername und Kennwort anzumelden, kann ADFS auch X.509-Zertifikate nutzen. Die Option ist sehr einfach auf den Authentifizierungseinstellungen aktiviert:

Und wenige Sekunden später erscheint dann auch in der Anmeldemaske unter dem Kennwort der Link zur Anmeldung mittels Zertifikat. Das ist natürlich aber nur der ersten Schritt. Sie müssen sich schon selbst noch darum kümmern, dass Sie mit einer PKI für die Anwender entsprechende Client-Zertifikate ausstellen, die der Anwender dann vorweisen kann. Über die Eigenschaften der Zertifikate selbst können Sie damit aber z.B. Endgeräte identifizieren und beschränken. Sie können z.B. die Zertifikate für eine bestimmte Benutzergruppe auch als zweiten Faktor verpflichtend machen.

Aber auch auf dem ADFS-Server müssen Sie noch etwas einrichten. Die Anmeldung per Zertifikat ist Teil des HTTP-Handshake und kann nicht mit der normalen Anmeldung mittels Benutzername und Kennwort vermischt werden. Daher muss der ADFS-Server hierfür auch noch über Port 49443 erreichbar sein. Von Intern ist dies in der Regel problemlos aber von extern wird ein ADFS-Server ja über einen WAP-Server oder anderen Reverse Proxy veröffentlicht. Hier ist dann Port 49443 ebenfalls mit frei zuschalten.

Prüfungen

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