Die ADFS Server gehören zu den Tier-0 Servern und sollten daher besonders geschützt sein. Paradoxerweise sind trotzdem viele ADFS Server über Reverse Proxys vom Internet her erreichbar. Das Härten dieser ADFS Infrastruktur ist unabdingbar und wird auch von Microsoft empfohlen. Wir beschreiben, auf was man achten sollte.


Warum sind die ADFS Server besonders zu schützen?

Die ADFS Server gehören zu den Identity Servern und sind daher wie oben geschrieben im Tier-0 anzusiedeln. Eine Kompromittierung von Tier-0 Servern hat immer den Verlust der Authentizität von Identitäten zur Folge. Wenn das SAML Token Signing Zertifikat der ADFS Server kompromittiert wird, kann ein Angreifer eigene SAML Response erstellen und signieren. Dadurch kann er sich unautorisierten Zugriff bei den Service Providern ergaunern. Da der ADFS Server meist Zugriff auf den Private Key des SAML Token Signing Zertifikates hat, ist das Serverkonto besonders zu schützen.

Das Bild von Microsoft beschreibt eine typische ADFS Installation für die Azure Dienste. Die Reverse-Proxys / Web Application Proxys (WAP) sind im Bild als Federation Proxy beschrieben.

Quelle: docs.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn, abgerufen am 24.02.21

In diesem Artikel schauen wir uns an, wie wir die ADFS & WAP Dienste härten können. Dazu zählen folgende Punkte:

Trotz Härtung der ADFS Server sollten Die 7 Golden Rules für eine sichere IT auch hier angewendet werden.


Zertifikatsanforderungen

Da mit dem Token Signing Zertifikat das SAML Token signiert wird, sollte dafür ein dediziertes Zertifikat eingesetzt werden. Wildcard Zertifikate können technisch zwar eingesetzt werden, aber sind aus dem oben genannten Grund nicht zu empfehlen. Zudem sollte beim Token Signing Zertifikat mindestens der gleiche Standard gesetzt werden wie bei den Webzertifikaten:

    • Lifetime max. 1 Jahr
    • RSA 4096
    • SHA-256

Da bei den Webserver Zertifikaten & den Token Singing Zertfikaten der ADFS Server die gleichen Standards angewendet werden, kann man für die beiden Zwecke auch das gleiche Zertifikat einsetzen. Bei höheren Schutzanforderungen kommt der nächste Absatz zum Tragen.


Schutz des Token-Signing Zertifikates

Microsoft hat den Windows Systemen einen geschützten Bereich für das Hinterlegen von Zertifikaten mit Private Keys gegeben. Dieser Schutz ist Software basiert und daher anfälliger für Angriffe wie Hardware geschützte Speicher. Als Beispiel kann genannt werden, dass jeder lokale Administrator des Systems an das Maschinenzertifikat mit dem Private Key herankommt und entwenden kann. So auch beim ADFS Server. Zum Schutz des Token-Signing Zertifikats kann es auf ein Hardware Security Modul, kurz HSM, ausgelagert werden. Ein HSM ist für den hohen Schutz von Zertifikaten und der Ausführung von kryptographischen Operationen gemacht. Tiefere Einblicke des HSMs ist im Blog-Post meines Kollegen beschrieben: Was ist ein Hardware Security Module. Wenn die sichere Auslagerung des Token-Signing Zertifikates gewünscht ist, sollte sich natürlich das Webserver Zertifikat vom Token Signing Zertifikat unterscheiden. Die Implementierung des HSMs ist herstellerspezifisch. Daher stellen in der Regel die Hersteller Anleitungen zur Verfügung, wie das SAML Token Signing Zertifikat des ADFS Servers zum HSM ausgelagert werden kann.


TLS Protokoll & Cipher-Suites Erzwingung

Wie bei allen Webservern sollte die TLS & Cipher-Suite Auswahl nicht dem Hersteller überlassen werden. Die gezielte Auswahl von TLS Protokollen und Cipher-Suites erhöht die Vertraulichkeit und Integrität der HTTPS Verbindung zum Webserver.

ADFS wurde mit Hilfe von Microsoft .NET Framework entwickelt. Daher sind die TLS Protokolle und Cipher-Suites Steuerung im Microsoft .NET Framework zu finden. SSL, RC4, TLS 1.0 und TLS 1.1 sollten deaktiviert werden. Aktuell (Stand Februar 2021) kann TLS 1.3 für ADFS nicht aktiviert werden. Denn das Windows 10 v21H1 wird die erste Windows Version sein, welche TLS 1.3 unterstützt. Ähnlich wie die Protokolle können auch die Cipher-Suites gesteuert werden.

Wer will, kann zudem seine WAP Server einem SSL Server Test unterziehen lassen. Dieser Online Test (www.ssllabs.com/ssltest/) wird von Qualys angeboten und ist kein Produkt der AVANTEC AG. Er überprüft und bewertet das Web Zertifikat, SSL / TLS Protokolle sowie die verwendeten Cipher-Suites. Zudem werden unterschiedliche Handshakes simuliert. Die zeigen auf, auf welchem System und mit welchem Browser welches Protokoll und Cipher-Suite ausgehandelt wird. Damit kann auch die Abwärtskompatiblität überprüft werden.


ADFS Überlastschutz

Mithilfe der WAP Server kann vom Internet her die Dienstleistung der ADFS Server genutzt werden. Ein Angreifer kann das Ausnutzen und somit die ADFS Server zur Überlast zwingen. Die Mitarbeiter könnten sich dann nicht mehr bei ihren Applikationen, Webseiten und anderen Diensten anmelden. Hier wird einem plötzlich die Abhängigkeit solch zentraler Dienste wie die der ADFS Server bewusst. Um das zu verhindern, bietet der WAP Server einen sogenannten ADFS Überlastschutz an. Dabei untersucht der WAP Server wie viel Zeit der ADFS Server für seine Anfrage benötigt. Wird der Schwellwert überschritten, leitet der WAP Server seine Anfragen von extern nicht mehr weiter.


Sperrungsschutz von Konten

Eine ähnliche Angriffsmethode soll nicht die ADFS Server zur Überlast zwingen, sondern das AD Benutzer Konto sperren. Für den Benutzer X werden so viele Authentisierungsversuche über die WAP Server durchgeführt, bis das AD Konto gesperrt wird. Um dies zu verhindern, kann eingestellt werden, nach wie vielen Versuchen keine weiteren Anmeldungen mehr über die WAP Server für das entsprechende Konto gemacht werden können. Nicht nur die Anzahl der Authentisierungsversuche, sondern auch die Sperrfrist kann entsprechend eingestellt werden. Bei der Konfiguration des Sperrungsschutzes von Konten sollte die Security Konfiguration vom Active Directory berücksichtigt werden.


Authentisierungsrichtlinien

Auf dem ADFS Server kann gesteuert werden, dass für externe Benutzer, die sich über die WAP Server anmelden, strengere Authentisierungsrichtlinien gefordert sind, als wenn die Benutzer sich von intern anmelden. Beispielsweise reicht es, wenn der interne Benutzer sich am ADFS Server per Kerberos authentisiert, aber für die Authentisierung über den WAP Server Two Factor Authentication (2FA) notwendig ist. Es kann sein, dass bei den externen Benutzern in diesem Beispiel Smart Card Authentication gefordert ist. Die Unterscheidung kann auch pro Relaying Party Trust also pro Service Provider gemacht werden.


Schlusswort

Wie eine sichere Authentisierung in einer Azure Hybrid Umgebung konfiguriert wird, ist im Artikel Azure Hybrid – wie wird sicher authentisiert beschrieben. Da die ADFS Server im Tier-0 sind, sollten diese Server, wie alle anderen Server, nur den notwendigen Risiken ausgesetzt werden. Wenn die Authentisierung über die ADFS Server nur von internen Netzwerken benötigt wird, so kann auf die WAP Infrastruktur verzichtet werden, sodass die ADFS Server nicht vom Internet her erreichbar sind.

Das Härten ist aber nur ein Aspekt. Schliesslich sollte wie bei allen Tier-0 Systemen nicht nur deren Verfügbarkeit, sondern auch die Authentizität von Systemen und Diensten überwacht werden. Ganz nach dem Prinzip: „Vetrauen ist gut, Kontrolle ist besser.“