Ist ein KDC-Proxy sinnvoll – Kerberos

Wie sinnvoll ist der Einsatz der KDC-Proxy-Rolle innerhalb einer Windows Active Directory Umgebung und welche Rahmenbedingungen gelten? In diesem Beitrag werfen wir einen Blick auf den KDC-Proxy aus theoretischer Sicht und zeigen auf, warum der Einsatz auch in deinem Netzwerk von Vorteil sein kann. Außerdem beleuchte ich die Funktionsweise, Anwendungsfälle und Voraussetzungen für den erfolgreichen Einsatz der KDC-Proxy-Rolle in deiner AD-Infrastruktur. Falls du den Theorie-Teil überspringen und direkt zur technischen Umsetzung wechseln möchtest, kannst du hier (COMING SOON) zum zweiten Part springen.

Vorwort

Windows AD Authentifizierung

In einer On-Premises Active Directory Umgebung basiert die Benutzer-Authentifizierung hauptsächlich auf zwei Protokollen: Kerberos und NTLM. Dabei ist Kerberos das bevorzugte und primäre Authentifizierungsprotokoll, da es höhere Sicherheit und bessere Performance bietet. NTLM wird immer dann verwendet, wenn Kerberos nicht verfügbar ist. Ein typisches Beispiel ist, wenn der Client keine direkte Verbindung (Line-of-Sight) zu einem Domain Controller herstellen kann. In solchen Fällen sorgt NTLM für eine zuverlässige Authentifizierung, auch wenn die Netzwerkbedingungen eingeschränkt sind. Wie Kerberos im Detail funktioniert, habe ich bereits in diesem Artikel näher beschrieben – daher gehe ich hier nicht weiter darauf ein.

Kann also ein Client keine Verbindung zu einem Domain Controller aufbauen, so wird auch ein Authentifizierungsversuch über Kerberos fehlschlagen.

Login ohne Line-of-Sight zum DC

Nun stellt sich die Frage, wie ein Login auf einer Windows Workstation funktionieren kann, wenn der Client temporär gar nicht mit dem internen Firmennetzwerk verbunden ist? Das funktioniert nur, weil Windows die letzten User, die sich erfolgreich authentifizieren konnten, im Cache zwischenspeichert. Standardmäßig werden die letzten 10 Anmeldungen in der Registry abgelegt und somit funktioniert der Login für diese 10 Benutzer auch ohne Verbindung zur Active Directory Domäne.

Jeder Windows Administrator wird auch schon einmal den Fall erlebt haben, dass das Kennwort eines AD-Users geändert wurde, der Login auf der Workstation trotzdem noch mit dem alten Kennwort durchgeführt werden muss. Hier treffen genau folgende Bedingungen zu:

• Der Client hat in diesem Moment keine direkte Verbindung zu einem Domain Controller.
• Der User hat sich bereits zuvor einmal mit dem alten Kennwort am Client authentifiziert. Somit sind die Anmeldedaten in der Registry abgelegt.

Erst wenn sich der User wieder im internen Netzwerk befindet, wird beim nächsten Logon der Cache erneuert und die neuen Anmeldedaten abgespeichert.

Domain Controller im Internet

Wieso provisionieren wir dann nicht einfach einen Domain Controller in ein öffentliches Netz? Das ist nicht nur aus Sicht der Sicherheit eine sehr schlechte Idee. Active Directory und die zugehörige Domain Controller Rolle wurden in einer Zeit entwickelt, in der sich Clients grundsätzlich immer im Intranet befanden. Die Infrastruktur ging davon aus, dass alle Clients eine stabile, vertrauenswürdige und dauerhafte Verbindung zum Domain Controller besaßen. Mobile Geräte, Home-Office oder Cloud-Anbindungen waren damals noch nicht relevant.

Das Active Directory-Vertrauensmodell basiert auf der Annahme, dass der Domain Controller innerhalb eines sicheren und geschützten Netzwerks steht. Das öffentliche Internet entspricht nicht diesen Sicherheitsanforderungen, da es vielen Angriffen und unkontrollierten Zugriffen ausgesetzt ist.

Alternativen

Glücklicherweise existieren für solche Anforderungen an die Infrastruktur valide und vor allem sichere Alternativen. Neben dem allbekannten VPN gibt es eine relativ unbekannte Windows Rolle, namens KDC-Proxy. Mit dieser Rolle möchte ich mich in diesem Blogpost näher beschäftigen – und das gilt anscheinend auch für dich.

Der Vollständigkeithalber möchte ich aber trotzdem noch erwähnen, dass sich die moderne IT weg von Kerberos/NTLM und weiter in Richtung von modernen Authentifizierungs- und Autorisierungsprotokollen bewegt. Als Beispiel aus der Microsoft Umgebung wäre Windows Hello for Business zu nennen.

KDC-Proxy

Theorie

Der KDC-Proxy bietet, wie es der Name bereits vermuten lässt, einen Proxy für das Kerberos Protokoll.

1. Clients verbinden sich dabei über das unsichere Internet mithilfe einer verschlüsselten TLS-Verbindung sicher mit einem Proxy.
2. Dieser Proxy übernimmt anschließend die Kommunikation mit dem Domain Controller im internen Netzwerk und sorgt so für eine geschützte und kontrollierte Authentifizierung, ohne den Domain Controller direkt dem Internet auszusetzen.

Somit können von nun an auch Clients außerhalb des gesicherten Unternehmensnetzwerks Kerberos Tickets über eine sichere Verbindung anfragen. Ursprünglich wurde diese Rolle von Microsoft übrigens für das Remote Desktop Gateway und DirectAccess entwickelt.

Der KDC-Proxy sollte auf einem Server innerhalb der DMZ installiert werden und benötigt folgende Voraussetzungen:

• Kommunikation zwischen KDC-Proxy und Domain Controller (standard Windows Ports)
• Externe Freischaltung vom Internet auf den KDC-Proxy für Port 443
• Ein gültiges TLS Zertifikat inklusive öffentlicher Domain
• Aktuelles Windows Server OS

Damit der Client überhaupt über den zur Verfügung stehenden KDC-Proxy in Kenntnis gesetzt wird, wird auch noch eine GPO benötigt. Dazu aber später mehr.

Ein Wort zur Security

Bevor wir nun mit der Installation des KDC-Proxies beginnen, möchte ich noch kurz über den damit einhergehenden zusätzlichen Angriffsvektor sprechen.

Da sich die Clients ausschließlich über HTTPs mit dem Proxy verbinden, ist zumindest die Verbindung zwischen Client und Proxy abgesichert. Trotzdem können sich auch Angreifer problemlos mit dem Proxy verbinden und ggf. Schwachstellen ausnützen oder Brute-Force-Attacken durchführen. Da der Domain Controller mit dem Active Directory das Herzstück eines Unternehmensnetzwerk bildet, sollte vorab eine Evaluierung stattfinden. Aus meiner Sicht müssen mindestens folgende Fragen berücksichtigt werden:

• Kann ich gewährleisten, dass der Proxy immer mit den aktuellen Security-Patches ausgestattet ist?
• Habe ich ein SIEM, mit dem ich die Events des KDC-Proxies überwachen kann um ggf. Attacken frühzeitig zu erkennen?
• Kann ich Alerts aus dem SIEM zeitnah und bestenfalls tagesunabhängig bearbeiten?
• Kann ich ggf. den Zugriff auf den KDC-Proxy via Geo-IP auf der Firewall einschränken (bspw. für bestimmte Länder) und so zumindest den Angriffsvektor etwas reduzieren?
• Bringt mir der KDC-Proxy einen Benefit oder arbeiten ohnehin alle Nutzer ausschließlich im Firmennetzwerk oder via VPN?

Erst wenn diese Fragen beantwortet wurden und die Evaluierung als positiv angesehen wird, sollte man mit dem Deployment beginnen. Wie das funktioniert, schauen wir uns im nächsten Post genauer an.

*COMING SOON*