Verwendung des KDC-Proxys (Kerberos) in AD für den Fernzugriff

/de/images/group-policy-option-specify-kdc-proxy-servers-for.png

Der Kerberos Key Distribution Center (KDC)-Proxydienst fungiert als sichere Brücke, die es Remote-Clients ermöglicht, die Kerberos-Authentifizierung zu verwenden, wenn sie Active Directory-Domänencontroller nicht direkt erreichen können. Der KDC-Proxy wird für Kerberos-Authentifizierungsszenarien verwendet, an denen externe Benutzer (d. h. Benutzer, die eine Verbindung über das Internet herstellen) oder Arbeitsgruppenbenutzer beteiligt sind. Der KDC-Proxydienst wurde ursprünglich für DirectAccess, Remote Desktop Gateway, Azure Virtual Desktop (AVD) und SMB über QUIC-Dateizugriff entwickelt. Aufgrund der geplanten Abschaffung der Authentifizierungsprotokolle NTLM v1 und v2 durch Microsoft kann es jedoch erforderlich sein, einen KDC-Proxy für zusätzliche Fernzugriffsdienste zu verwenden.

Die folgenden Ports müssen geöffnet sein, um die Kerberos-Authentifizierung zwischen dem Client und dem KDC-Dienst auf dem Active Directory (AD)-Domänencontroller durchzuführen.

  • UDP/TCP 88 – Kerberos-Authentifizierung, Erhalt von Ticket Granting Tickets (TGT)

  • UDP/TCP 464 – Ändern des Passworts eines Benutzers über Kerberos

Das Öffnen dieser Ports für Domänencontroller für externe Benutzer ist nicht sicher, daher kann stattdessen ein KDC-Proxydienst am Benutzerverbindungspunkt erstellt werden. Der KDC-Proxy wird auf einem in die Domäne eingebundenen Server ausgeführt, lauscht auf Kerberos-Anfragen am HTTPS-Port (TCP/443) von externen Clients und tunnelt diese sicher zum Domänencontroller.

Stellen Sie sich das folgende einfache Szenario vor: Ein Remotedesktop-Gateway-Server wird innerhalb des internen Perimeters bereitgestellt und externe Benutzer stellen eine Verbindung zu ihm her. Externe Benutzer auf Nicht-Domänencomputern können keine Verbindung herstellen, da die NTLM-Authentifizierung auf dem RD-Gateway-Host deaktiviert ist, der im Nur-Kerberos-Modus betrieben wird. Dies führt zu einem RDP-Fehler:


An authentication error has occurred.The function requested is not supportedRemote computer: xxxxThis could be due to CredSSP encryption oracle remediation.

/de/images/rdp-connection-error-when-ntlm-disabled-the-funct.png

Da sich der Client in dieser Situation nicht über Kerberos beim DC authentifizieren kann, wird versucht, auf NTLM zurückzugreifen, das auf dem Host deaktiviert ist. Dies führt dazu, dass sich der Benutzer nicht aus der Ferne anmelden kann.

Um externen Clients die Authentifizierung auf diesem RDP-Host über Kerberos zu ermöglichen, wird der KDC Proxy Service (KPSSVC) auf dem RDGW-Host bereitgestellt.

Der KDC-Proxy-Diensthost muss über ein installiertes Zertifikat zur Verschlüsselung des Datenverkehrs und zur Serverauthentifizierung verfügen. Die erweiterte Schlüsselverwendung (Extended Key Usage, EKU) des Zertifikats muss Serverauthentifizierung, Clientauthentifizierung und Kerberos-Authentifizierung umfassen. Der alternative Antragstellername („SAN“) des Zertifikats muss den vollqualifizierten Domänennamen (FQDN) des KDC-Proxys enthalten, den Clients für die Verbindung verwenden. Ein solches Zertifikat kann von einer internen oder kommerziellen Zertifizierungsstelle ausgestellt werden (für Test-und Nicht-Produktionsbereitstellungen kann ein selbstsigniertes Zertifikat verwendet werden).

Das Zertifikat muss zum Zertifikatspeicher des Servers hinzugefügt werden. Kopieren Sie den Fingerabdruck Ihres Zertifikats:

Get-ChildItem-Path Cert:\LocalMachine\My | Where-Object { $\_.Subject-like "*CN=rds01.woshub.com*"} | Select-Object-ExpandProperty Thumbprint

/de/images/powershell-copy-cert-localmachine-my-certificat.png

Wenn Sie ein selbstsigniertes Zertifikat oder eines von einer internen Zertifizierungsstelle verwenden, installieren Sie den öffentlichen Schlüssel des Zertifikats auf den Windows-Geräten der Clients, damit diese ihm vertrauen.

Fahren wir nun mit der Konfiguration des KDC-Proxy-Dienstes fort.

Erstellen Sie einen Verbindungs-URL-Endpunkt:

NETSH http add urlacl url=https://+:443/KdcProxy user="NT Authority\Network Service"


URL reservation successfully added

/de/images/netsh-http-add-urlacl-url443-kdcproxy.png

Generieren Sie eine eindeutige GUID:

$appguid=Guid::NewGuid().ToString("B")

Legen Sie den Fingerabdruckwert des Zertifikats fest:

$kdccert="F00AB752B63F3B840A44BF6A20F6EF0E25DEF4D4"

Binden Sie das Zertifikat an den Verbindungsendpunkt:

netsh http add sslcert ipport=0.0.0.0:443 certhash=$kdccert appid=$appguid


SSL Certificate successfully added

/de/images/netsh-http-add-sslcert-bind-ssl-cert-kdc-proxy.png

Da ich nicht beabsichtige, Smartcard- oder Windows Hello-Authentifizierung zu verwenden, werde ich die Authentifizierungsanforderungen für HTTPS-Clientzertifikate für KDC-Proxy-Vorgänge deaktivieren. Dadurch können alternative Methoden wie Passwörter oder Kerberos über HTTPS ohne Smartcards verwendet werden.

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings"/v HttpsClientAuth/t REG\_DWORD/d 0x0/f

Passwortauthentifizierung aktivieren:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings"/v DisallowUnprotectedPasswordAuth/t REG\_DWORD/d 0x0/f

Aktivieren Sie den KDC-Proxydienst (KPSSVC):

Set-Service kpssvc-StartupType Automatic

Start-Dienst kpssvc

Lassen Sie eingehenden Datenverkehr auf TCP-Port 443 auf dem Server zu, damit Clients eine Verbindung zum KDC-Proxy herstellen können. Erstellen Sie mit PowerShell eine Windows-Firewall-Zulassungsregel:

New-NetFirewallRule-DisplayName „KDCProxy TCP\_In“-Direction Inbound-Protocol TCP-LocalPort 443

Nehmen wir nun einige Änderungen auf der Clientseite vor, sodass sie den KDC-Proxy für Verbindungen verwenden.

KDC-Proxy-Einstellungen auf Clients können über die Gruppenrichtlinie „KDC-Proxyserver für Kerberos-Clients angeben“ im Abschnitt „Computerkonfiguration“ -> „Richtlinien“ -> „Administrative Vorlagen“ -> „System“ -> „Kerberos“ konfiguriert werden.

Aktivieren Sie die Richtlinie, klicken Sie auf die Schaltfläche „Anzeigen“ und fügen Sie eine Verbindungszeichenfolge für Ihren KDC-Proxy hinzu. Die Zeichenfolge sollte das folgende Format haben:

  • Wertname: Ihr AD-Domänenname, „woshub.com“.

  • Wert: KDC-Proxy-Verbindungszeichenfolge für diese Domäne (mehrere Server können angegeben werden): „“.

/de/images/group-policy-option-specify-kdc-proxy-servers-for.png

Oder Sie können die KDC-Proxy-Einstellungen direkt auf dem Client über die Registrierung konfigurieren.

` reg add „HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos“/v KdcProxyServer_Enabled/t REG_DWORD/d 1/f

reg add „HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxy\ProxyServers“/v woshub.com/t REG_SZ/d „“/f `

Um die GPO-Einstellungen zu übernehmen, muss der Client-Computer neu gestartet werden.

Versuchen Sie nun, sich vom Client aus beim RDP-Gateway anzumelden. Der Client sollte den KDC-Proxy verwenden, um sich beim Domänencontroller zu authentifizieren und ein Kerberos-Ticket zu erhalten. Um zu überprüfen, ob ein Kerberos-Ticket über „kdcproxy“ ausgestellt wurde, führen Sie den folgenden Befehl aus:

klist get krbtgt

/de/images/klist-get-krbtgt-view-kerberos-tickets.png

Die Kerberos-Proxy-Authentifizierungsprotokolle finden Sie im folgenden Abschnitt der Ereignisanzeige: Ereignisanzeige -> App und Dienste -> Microsoft -> KDCProxy -> Operational.

In zukünftigen Windows-Versionen plant Microsoft, die KDC-Proxy-Bereitstellung über die Windows Admin Center (WAC)-Weboberfläche zu automatisieren und zu vereinfachen.

*️⃣ Quelllink:

Remotedesktop-Gateway, SMB über QUIC-Dateizugriff, Abschaffung der NTLM v1- und v2-Authentifizierungsprotokolle, Ändern des Kennworts eines Benutzers, deaktivierte NTLM-Authentifizierung, Es ist ein Authentifizierungsfehler aufgetreten, selbstsigniertes Zertifikat, Installieren des öffentlichen Schlüssels des Zertifikats auf den Windows-Geräten der Clients, Windows-Firewall-Zulassungsregel mit PowerShell, Anwenden der GPO-Einstellungen,