MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

LocalKdc und IAKerb

Wer NTLM abschalten will, muss alternative Anmeldewege bereitstellen. Die Übermittlung von Benutzername und Kennwort per Klartext gehört auch nicht dazu aber Kerberos und SAML benötigen eine entsprechende Infrastruktur. LocalKdc und IAKerb sind die Bausteine, mit denen ein Client ohne direkte Verbindung zum KDC dennoch Kerberos nutzen kann.

Hinweis:
Auch im Feb 2026 konnte die Funktion noch nicht mit Windows genutzt werden. Zwar ist der "LocalKdc"-Dienst schon seit Windows 2022 Server vorhanden sind aber funktioniert noch nicht funktionieren.

Anmelden mit Kerberos

Überall wird darüber geschrieben, dass NTLM abgeschaltet werden muss und stattdessen sicherere Anmeldeverfahren genutzt werden sollen. Das ist in einem Active Directory mit einem DomainController und KDC auch kein Problem und wird umfangreich genutzt. Das gilt zumindest, solange der Client und Service im gleichen Active Directory unterwegs sind, der Client einen Namen anspricht für den er ein Kerberos-Ticket anfordert und der DC das passende Computerobjekt des Service findet und ein Ticket ausstellt. In einem Active Directory funktioniert dies meist automatisch aber in vielen Fällen auch wieder nicht, z.B. wenn Sie mehrere Exchange Server hinter einen Loadalancer und einen eigenen Namen erreichbar machen. Siehe dazu auch E2010CAS und Kerberos. Ohne entsprechende Vorarbeiten wird der KDC für den virtuellen Namen kein Computerkonto finden.

Ein weitere Fall, bei dem Kerberos nicht funktioniert, ist ein "Offline"-Mode. Sie sind mit ihrem Client im HomeOffice oder unterwegs und haben kein VPN gestartet und kommen gar nicht direkt an den Domain Controller. Da kann ihnen der im Internet erreichbare Service die Kerberos-Anmeldung lange anbieten. Ihr Client bekommt kein Ticket. Das gleiche Problem haben Clients, die gar nicht in der Domain Mitglied sind. Denken Sie an Smartphones, Tablets etc. Daher nutzen viele Dienste sogar noch "Basic Auth", d.h. eine Anmeldung mit Username/Kennwort, die hoffentlich TLS-verschlüsselt übertragen wird.

Also halten wir noch einmal fest, was alles für Kerberos gegeben sein muss

  • Client muss den Server auflösen und erreichen
    Nur dann verbindet sich der Client mit dem Server und fängt sich auf eine anonyme Anfrage dann eine Meldung ein, wie er sich anmelden kann.
  • Der Server muss für den Service Kerberos anbieten
    Dazu muss im Anmeldeprozess auch "Negotiate" möglich sein und der Server muss natürlich die ihm zugesendeten Tickets entschlüsseln und die Signatur prüfen können und dem Aussteller vertrauen. Für "Domain Mitglieder" ist dies in der Regel der Fall. Andere Systeme brauchen z.B. eine KEYTAB-Datei mit den kryptografischen Informationen zum Entschlüsseln der Tickets.
  • Der Client muss Kerberos unterstützen
    Die verwendete Software muss das "Negotiate"-Angebot des Servers verstehen und für die Domain auch eine Anfrage an den KDC senden. Ein Windows Client vertraut den Domains seines Forest und der Browser allen Webseiten, die als "Intranet" klassifiziert werden.
  • KDC muss Ticket ausstellen
    Dazu muss der Client den KDC auflösen und erreichen können. Zudem muss er sich vorher natürlich authentifiziert haben, um ein TGT vorweisen zu können. Der KDC schaut dann in seiner Datenbank (Active Directory) nach einem Objekt mit dem Service Principal Name und stellt ein Ticket aus, welches der Client erhält und dann zum Dienst sendet
  • Infrastruktur, Uhrzeit und DNS
    Natürlich funktioniert das ganze System nur, wenn die Teilnehmer per DNS sich auflösen können, die Systemzeiten halbwegs synchron sind und Firewalls und IP-Routing eine Verbindung zustande kommen lassen.

Wenn auch nur eine Komponente nicht funktioniert, dann ist keine Anmeldung per Kerberos möglich und andere Verfahren, z.B. NTLM kommen wieder zum Einsatz.

KDCProxy

Das Szenario, dass ein Client z.B. im Home Office arbeitet und ohne VPN den KDC auf dem Domain Controller nicht erreichen kann, lässt sich durch einen KDCProxy lösen. Diese Komponente wird zwischen dem bösen Internet und dem internen KDC gestellt und nimmt Anfragen von Clients aus dem Internet an, die er dann mit einigen Prüfungen an den internen KDC weiterreicht. Der KDCProxy ist ein klassische Application Proxy, der von extern durch entsprechende Programme genutzt werden kann. technisch ist es ein Webserver, der auf der URL "https://+:443/kdcproxy " lauscht und die per HTTPS eintreffenden Anfragen an den internen KDC weitergibt. Da die Kommunikation zwischen externem Client und KDCPRoxy damit nicht das klassische Kerberos-Protokoll über Port 88/UDP/TCP ist, muss der Client damit kompatibel sein.

Microsoft hat den KDCProxy primär für RDP-Verbindungen, RDP-Gateway und DirectAccess geplant. Eine andere Nutzung müssen geprüft werden.

Wenn ich Home Office-User habe, dann würde ich eher über ein VPN nachdenken, bei denen sich der Client z.B. per Zertifikat authentifiziert, ehe dann der DC erreichbar ist.

Beide Wege eignen aber weiterhin für den Einsatz von Kerberos auch über das Internet und sind sicherer und leistungsfähiger als NTLM. Bei NTLM muss der Service die übermittelten Daten jedes mal an den Domaincontroller zur Überprüfung senden, da nur der DC die Hashwerte des Kennworts hat. Bei Kerberos prüft der Service selbst und ist damit robuster gegen DoS-Angriffe auf Anmeldedaten.

Kerberos mit IAKerb und LocalKdc

Schon 1997 haben sich die Entwickler um MIT Kerberos" aber auch Gedanken gemacht, wie Sie Kerberos nutzen können, wenn es keine direkte Verbindung zwischen dem Client und dem KDC geben kann und der Client nur die Verbindung zu seinem Server aufbauen kann. Die Kerberos-Spezifikation enthält eine Beschreibung, wie ein Client über das Client-Protokoll nicht nur eine Anmeldung am Server selbst per Kerberos-Ticket durchführen kann, sondern quasi als Tunnel oder Proxy sich zum KDC Verbinden und sogar anmelden kann.

Bei der normalen Anmeldung authentifiziert sich der Client direkt mit dem KDC, erhält ein Ticket Granting Ticket (TGT), fängt sich dann beim ersten Zugriff auf den eigentlichen Service ein "Access Denied" mit der Information über die Anmeldeoptionen ein. Damit fordert der Client dann wieder direkt vom KDC ein Ticket Granting Server (TGS) an, mit dem er sich dann am Dienst authentifizieren kann.

Ohne eine direkte Verbindung von Client zum KDC und mit Unterstützung von IAKerb und LocalKdc kann ein entsprechend konfigurierter Client seine Kerberos Anmeldung aber über das gleichen Protokolle zum Server senden, der dann auch die Authentifizierung am dahinter stehenden KDC über den "LocalKdc"-Dienst umsetzt.

Der Client kann so auch ein TGS bekommen um sich am Service per Kerberos anzumelden.

Damit dies  aber möglich ist, muss natürlich sowohl der Client als auch der Server die passende Erweiterung unterstützen.

  • IAKerb
    Auf dem Client ist das die IAKerb-Funktion, die auf dem Windows Betriebssystem die Kerberos-Kommunikation ohne direkte Verbindung zum KDC durch die Anmeldung an der Service-Gegenstelle ermöglicht.

Microsoft Schreibt dazu  

IAKerb is a public extension to the industry standard Kerberos protocol that allows a client without line-of-sight to a Domain Controller to authenticate through a server that does have line-of-sight. This works through the Negotiate authentication extension and allows the Windows authentication stack to proxy Kerberos messages through the server on behalf of the client. IAKerb relies on the cryptographic security guarantees of Kerberos to protect the messages in transit through the server to prevent replay or relay attacks. This type of proxy is useful in firewall segmented environments or remote access scenarios.
https://techcommunity.microsoft.com/blog/windows-itpro-blog/the-evolution-of-windows-authentication/3926848  

Die zweite Komponente ist LocalKdc 

  • LocalKdc
    Diese Funktion auf der Gegenstelle nimmt die im Authentifizierungspaket enthaltenen Aktionen entgegen und prüft sie gegen lokale Konten oder Active Director Konten

The local KDC for Kerberos is built on top of the local machine’s Security Account Manager so remote authentication of local user accounts can be done using Kerberos. This leverages IAKerb to allow Windows to pass Kerberos messages between remote local machines without having to add support for other enterprise services like DNS, netlogon, or DCLocator. IAKerb also does not require us to open new ports on the remote machine to accept Kerberos messages. Authentication through the local KDC uses AES out of the box improving the security of local authentication.
https://techcommunity.microsoft.com/blog/windows-itpro-blog/the-evolution-of-windows-authentication/3926848  

Offen ist hierbei natürlich, wie schnell und ob auch andere Gegenstellen eine Authentifizierung über IAKerb unterstützen. Die wenigsten Windows Server werden direkt aus dem Internet erreichbar sein und wenn ein Loadbalancer oder Reverse Proxy davor steht, dann ist zu prüfen, wie hier die Anmeldung über diesen Weg weiter möglich sein wird.

Die Authentifizierung durch IAKerb und LocalKdc eröffnet auch den Weg, lokale Konten über Kerberos nutzbar zu machen. Damit eröffnet sich auch ein Weg, sich an Servern ganz ohne Domain-Mitgliedschaft über Kerberos anzumelden.

Interessant finde ich, dass schon auf einem Windows 2022 Server der Dienst "LocalKdc" vorhanden ist.

Allerdings wird der Dienst nur "Manuell" gestartet und zumindest auf meinen Server konnte der Dienst bislang nicht erfolgreich gestartet werden (Feb 2026). Hier wird Microsoft wohl noch ein paar Einstellungen oder Updates benötigen.

For Windows 11, we are introducing two major features to Kerberos to expand when it can be used—addressing two of the biggest reasons why Kerberos falls back to NTLM today. The first, IAKerb, allows clients to authenticate with Kerberos in more diverse network topologies. The second, a local KDC for Kerberos, adds Kerberos support to local accounts.
IAKerb is a public extension to the industry standard Kerberos protocol that allows a client without line-of-sight to a Domain Controller to authenticate through a server that does have line-of-sight. This works through the Negotiate authentication extension and allows the Windows authentication stack to proxy Kerberos messages through the server on behalf of the client. IAKerb relies on the cryptographic security guarantees of Kerberos to protect the messages in transit through the server to prevent replay or relay attacks. This type of proxy is useful in firewall segmented environments or remote access scenarios.
The local KDC for Kerberos is built on top of the local machine’s Security Account Manager so remote authentication of local user accounts can be done using Kerberos. This leverages IAKerb to allow Windows to pass Kerberos messages between remote local machines without having to add support for other enterprise services like DNS, netlogon, or DCLocator. IAKerb also does not require us to open new ports on the remote machine to accept Kerberos messages.
Quelle: https://techcommunity.microsoft.com/blog/windows-itpro-blog/the-evolution-of-windows-authentication/3926848

Currently KDC Proxy is the only native solution to help with such line of sight issues but it’s list of supported applications is pretty limited.  A similar feature named IAKerb is currently in development which will allow the resource server to act as a proxy and enable the client to acquire service tickets without direct connectivity to the resource domain controller.  Unlike KDC Proxy, IAKerb will not be application dependent
Active Directory Hardening Series - Part 8 – Disabling NTLM
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-8-%E2%80%93-disabling-ntlm/4485782

Konfiguration von IAKerb und LocalKdc

Aktuell gibt es noch keine Umsetzung. Die Funktion ist noch nicht vorhanden 

Logging und DoS-Schutz

Wenn ich z.B. einen Webserver so aus dem Internet erreichbar mache, dann können Sie davon ausgehen, dass auch die Angreifer sehr schnell mit IAKerb austesten. Wer heute einen HTTP-Proxy mit Preauthentication und MFA nutzt, öffnet mit IAKerb und LocalKdc wieder einen direkten Weg die Gültigkeit von Anmeldedaten zu überprüfen.

IAKerb und LocalKdc Debugging

Sobald ich einen Client habe, der sich an einem Server mitteIs IAKerb und LocalKdc auf dem Server

Eventlog Wireshark und Fiddler-Traces stehen noch aus

Weitere Links