KDC-Proxy Deployment – Kerberos

Im letzten Artikel zu diesem Thema haben wir bereits die Grundlagen zum KDC-Proxy geklärt. In diesem Post konzentrieren wir uns auf das Deployment der Rolle auf einem Windows Server und betrachten außerdem die Konfiguration der Clients. Abschließend werfen wir noch einen kleinen Blick auf mögliche Debugging-Schritte, falls der KDC-Proxy nicht so funktioniert, wie wir das gerne hätten.

Theorie

Wie ein KDC-Proxy funktioniert, welche Fragen aus Sicht der Security vorab beantwortet werden sollten und welche Vorteile ein solcher Proxy im Unternehmensnetzwerk bieten kann, habe ich bereits im ersten Part erläutert. Wer sich also dafür interessiert, sollte zuerst dort vorbeischauen. Möchtest du zu aller erst überhaupt die Grundlagen von Kerberos verstehen, solltest du dich vorab hier einlesen.

Praxis

Voraussetzungen

Um einen KDC-Proxy innerhalb einer bestehenden Active Directory Domäne zu betreiben, gibt es ein paar wenige Voraussetzungen:

• Windows Server (empfohlen Windows Server 2025 oder neuer)
• Server muss der Active Directory Domäne beitreten können
• Der KDC-Proxy sollte nicht auf einem Domain Controller installiert werden
• Stattdessen sollte dafür eine zusätzliche VM in der DMZ verwendet werden
• Public IP die via Port 443 auf den KDC-Proxy genattet wird
• Öffentliche Domain (bspw. kdc.contoso.com)
• Zertifikat einer vertrauenswürdigen Certificate Authority (Wildcard Zertifikate sind in Ordnung)

Im Idealfall deployen wir also eine zusätzliche VM in einer DMZ, installieren dort Windows Server 2025 (oder neuer) und treten der AD-Domäne bei. Der Clientflow schaut dabei im Optimalfall wie folgt aus:

Deployment

Infrastruktur

Unsere Umgebung sieht wie folgt aus:

• AD-Domäne: schweigerstechblog.local
• Domain Controller: dc01.schweigerstechblog.local (10.0.1.1)
• KDC-Proxy (Windows Server 2025):
  • Intern: kdc01.schweigerstechblog.local (10.0.2.1)
  • Extern: kdc.schweigerstechblog.de (96.16.16.16)
• Wildcard Zertifikat für schweigerstechblog.de

Serverkonfiguration

Wir haben eine neue Windows Server 2025 VM bereitgestellt und sind unserer AD-Domäne beigetreten. Außerdem haben wir das Wildcard Zertifikat zu einem PFX-File konvertiert und im Computer Zertifikatsstore importiert.

Nun beginnen wir mit der Konfiguration unseres Proxies. Dafür öffnen wir eine PowerShell als Administrator und führen folgende CMDLETS aus:

$kdcCert = "schweigerstechblog.de"      ### SET ROOT DOMAIN
$kdcFQDN = "kdc.schweigerstechblog.de"  ### CHANGE TO YOUR PUBLIC DOMAIN
$kdcPort = 443                          ### IT'S NOT RECOMMENDED BUT YOU CAN CHANGE THE PORT

Install-WindowsFeature -Name Web-Scripting-Tools, Web-Mgmt-Console
Import-Module -Name WebAdministration
 
$setACL = 'netsh http add urlacl url=https://+:{0}/KdcProxy user="NT AUTHORITY\Network Service"' -f $kdcPort
cmd /c  $setACL
 
$kdcCertObject = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object -FilterScript { $_.Subject -like "*$($kdcCert)*" }
$randomGuid = [Guid]::NewGuid().ToString("B")
 
$setCert = 'netsh http add sslcert hostnameport={0}:{1} certhash={2} appid={3} certstorename=MY' -f $kdcFQDN, $kdcPort, $kdcCertObject.Thumbprint, $randomGuid
cmd /c $setCert
 
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings -Name HttpsClientAuth -Type Dword -Value 0x0 -Force
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings -Name DisallowUnprotectedPasswordAuth -Type Dword -Value 0x0 -Force
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings -Name HttpsUrlGroup -Type MultiString -Value "+:$kdcPort" -Force

New-NetFirewallRule -DisplayName "Allow KDCProxy TCP $kdcPort" -Direction Inbound -Protocol TCP -LocalPort $kdcPort

Set-Service -Name KPSSVC -StartupType Automatic
Start-Service -Name KPSSVC

Ich möchte noch einen besonderes Augenmerk auf die gesetzten Registry Keys setzen, da sich diese je nach Umgebung und Anforderungen unterscheiden können:

*Laut meinen Erfahrungen hat das Aktivieren des HttpsClientAuth Registry Keys zu Fehlern geführt. Auch bei einem Wert von 0x0 funktioniert die SmartCard Authentifizierung problemlos, daher muss hier ggf. etwas getestet werden.

Mit diesen Einstellungen steht der KDC-Proxy nun für Anfragen bereit. Im nächsten Schritt müssen wir den Clients eine Policy zur Verfügung stellen, damit sie überhaupt wissen, dass ein KDC-Proxy zur Verfügung steht.

Clientkonfiguration

Zur Konfiguration am Client haben wir zwei Möglichkeiten:

• Wir bereiten eine GPO vor und deployen sie automatisiert auf allen Clients
• Oder wir setzen die notwendigen Registry Keys manuell am Client

Fangen wir mit der GPO an:

Die notwendigen Richtlinien befinden sich unter „Computer\Administrative Templates\System\Kerberos\Specify KDC proxy servers for Kerberos clients„:

Dabei werden folgende Einstellungen gesetzt:

Die GPO müssen wir anschließend auf jener OU anwenden, in der sich auch die jeweiligen Computer Objekte befinden.

Möchte man keine GPO verwenden, sondern die Einstellungen direkt via Registry am Client setzen, ist das auch möglich. Hierfür werden folgende Registry Keys benötigt:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos]
"KdcProxyServer_Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxy\ProxyServers]
".schweigerstechblog.de"="<https kdc.schweigerstechblog.de:443:kdcproxy />"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxy\ProxyServers]
".schweigerstechblog.local"="<https kdc.schweigerstechblog.de:443:kdcproxy />"

Somit haben wir alle notwendigen Einstellungen getroffen und nach einem Reboot des Clients, sollte dieser bereits mit dem KDC-Proxy Kontakt aufnehmen, wenn keine Line-of-Sight zu einem Domain Controller besteht.

Debugging

Sollte etwas nicht wie gewünscht funktionieren, dürfen wir unsere Debugskills aus dem Repertoire holen. Ich sags gleich vorweg: sowohl der KDC-Proxy, als auch der Client stellen Logs bereits, die sind aber nicht immer sehr hilfreich aber bieten meist einen ersten Anhaltspunkt. Stellen wir uns aber zuerst folgende Fragen:

• Hat der Client die notwendigen Registry Keys entweder via GPO oder manuell gesetzt bekommen?
• Kann der Client den KDC Proxy unter der von uns konfigurierten Domain erreichen?
• Vertraut der Client dem Zertifikat (am besten einfach einmal die Domain im Browser öffnen)?
• Geben die Eventviewer Logs am Client oder am KDC-Proxy weitere Informationen?

Der Client bietet für Verbindungsversuche über den Proxy ein eigenes Eventlog:

Am KDC-Proxy selbst werden auch die Verbindungsversuche in einer Light-Variante im Eventviewer geloggt:

Fazit

Kommen wir zu einem Fazit. Der KDC-Proxy ist in Unternehmen, die weiterhin nicht auf Windows Hello for Business setzen möchten und die Möglichkeit von Kerberos außerhalb des internen Netzwerks benötigen, eine brauchbare Alternative. Trotzdem sollte man sich gut überlegen, welche Risiken damit einhergehen und ob ein Deployment für die eigene Infrastruktur sinnvoll ist. Des Weiteren kann man nicht davon ausgehen, dass Microsoft dem KDC-Proxy zukünftig noch viel Aufmerksamkeit schenken wird. Das bedeutet, dass wir voraussichtlich nicht mit neuen Features, einem besseren Logging oder anderweitigen Tooling rechnen sollten.