ADFS TLS Verschlüsselungsprotokolle – Best Practice

Windows Server bietet standardmäßig eine breite Palette an Verschlüsselungsprotokollen an. Administratoren sollten daher darauf achten, welche Protokolle gegebenenfalls deaktiviert werden sollten. So werden mittlerweile TLS 1.0 & TLS 1.1 als unsicher eingestuft und sollten in Produktivumgebungen nicht mehr verwendet werden. Aus diesem Grund schauen wir uns in diesem Post an, wie wir unsere ADFS (Active Directory Federation Services) Umgebung entsprechend absichern können.

Vorwort

Wie so oft kann eine Änderung auf einem bereits produktiven System im Nachhinein Probleme verursachen und sollte entsprechend vorab geplant und getestet werden. Beim Deaktivieren von Verschlüsselungsprotokollen wie TLS 1.1 kann es durchaus passieren, dass veraltete Clients keine sichere Verbindung mehr aufbauen können.

Ab Windows 8, sowie Windows Server 2012 wird TLS 1.2 clientseitig standardmäßig unterstützt und ist auch out-of-the-box aktiviert. Hat man noch Windows 7 oder Windows Server 2008R2 im Einsatz, muss das Betriebssystem auf den letztmöglichen Patchstand gebracht, sowie TLS 1.2 manuell aktiviert werden. Siehe dazu den Artikel von Microsoft.

TLS Version & Ciphers

TLS 1.0 & TLS 1.1 werden mittlerweile als nicht mehr sicher angesehen. Daher lautet die klare Empfehlung, ausschließlich TLS 1.2 (und neuer) zu verwenden. Ist ADFS auf einem Windows Server 2022 (oder neuer) installiert, unterstützt das Betriebssystem sogar TLS 1.3. Meine Empfehlung lautet hierbei ganz klar einen Mix aus Sicherheit, sowie Kompatibilität zu wählen:

• TLS 1.2, sowie TLS 1.3 (falls unterstützt) zu aktivieren
• TLS 1.1 und älter zu deaktivieren
• Unsichere Cipher zu deaktivieren

Um diese Änderung durchzuführen, gibt es verschiedene Vorgehensweisen. So können die am Server verwendeten Protokolle manuell via Registry Key gesetzt werden. Hierzu gibt es seitens Microsoft eine sehr ausführliche Dokumentation.

Standardkonfiguration von Windows

Wie bereits erwähnt ist Windows standardmäßig sehr großzügig und auf maximale Kompatibilität ausgelegt. Lässt man beispielsweise einen SSL Qualys Test durchführen, fällt das Ergebnis entsprechend ernüchternd aus:

In einer produktiven Umgebung möchte man allerdings das Sicherheitsrisiko minimieren. Somit müssen wir als Administrator selbst Hand anlegen.

Konfigurieren von TLS

Wie schon im Artikel „Exchange Verschlüsselungsprotokolle – Best Practices“ greife ich auf das Tool IIS Crypto zurück. Wer die genaue Funktionsweise dieses Toolings verstehen möchte, sollte daher einen kurzen Blick in den zuvor genannten Artikel werfen – hier gehe ich nicht mehr darauf ein.

Wir öffnen das Tool, wechseln in den Menüpunkt „Templates“ und wählen dort „PCI 4.0“ aus.

Mit diesem Template werden TLS 1.1 (und älter) deaktiviert, sowie ausschließlich sichere Ciphers aktiviert. Um zu überprüfen welche TLS Versionen nun tatsächlich aktiviert werden, kann man noch einen Blick in den Menüpunkt „Schannel“ werfen.

Die hier gezeigten Einstellungen werden beim Klick auf „Apply“ via Registry Keys im System gesetzt. Da wir die Änderungen auf einem Produktivsystem setzen und wir im Fehlerfall einen Rollback machen müssen, empfehle ich, vorab einen Export der betroffenen Registry Einträge zu erstellen. Auch hierfür bietet IIS Crypto eine entsprechende Funktion. Dazu wechseln wir vorab in den Menüpunkt „Advanced“ und klicken auf „Backup Registry„.

Sollten nach dem Setzen der neuen Einstellungen irgendwelche Inkompatibilitäten mit wichtigen Clients auftreten, kann man durch das Registry Backup sehr einfach zu den vorherigen Settings zurückkehren.

Abschließend müssen die Einstellungen noch am System konfiguriert werden. Dazu klicken wir auf „Apply“ und starten das System einmal neu.

Hat man mehrere ADFS Server oder betreibt WAPs (Web Application Proxies) als Frontend, müssen diese Schritte auf allen Nodes wiederholt werden.

Blick hinter die Kulissen

Einen kleinen Exkurs in die Funktionsweise von IIS Crypto möchte ich an dieser Stelle allerdings nicht auslassen – denn ein Administrator sollte stets wissen, welche Toolings wie in ein System eingreifen. Im Grunde stellt IIS Crypto nur eine einfache GUI zum Setzen von Registry Keys dar. Geübte Administratoren, die sich mit der Thematik auseinander setzen möchten, können gewiss auf ein solches Tool verzichten und die notwendigen Änderungen direkt in der Registry durchführen. So spielen sich die SSL Einstellungen auf Windows in folgenden Registry Key ab:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders

Microsoft stellt auch eine ausführliche Dokumentation bereit, wie man diese Keys selbstständig setzen kann und welche Bedeutung sie haben.

Fazit

Gerade bei einem so wichtigen Service wie einem Identity Provider sollten bestimmte Sicherheitskriterien eingehalten werden. Dazu zählt auch das Hardening des ADFS Frontends. Durch das Tool IIS Crypto müssen sich Administratoren nicht einmal durch Registry Keys wühlen sondern können mittels GUI sehr einfach veraltete und unsichere TLS Protokolle, sowie Ciphers deaktivieren. Auch das Ergebnis von SSL Qualys spricht für sich: