MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Kerberos Cross Forest

Ich bin ein Fan von Kerberos und ziehe es NTLM auf jeden Fall vor. Das funktioniert in einer Domäne und auch noch im gleichen Forest sehr gut. Aber wir sieht es aus, wenn die Server in einem anderen vertrauten Forest oder sogar im Internet stehen?

Kerberos vs Basic, NTLM, OAUTH

Ich hoffe, sie reduzieren den Einsatz von "Basic Auth" auf ein Minimum, denn es ist unbequem, (Eingabe durch User), Unsicher (Verschlüsselung hofft einen sicheren Übertragungsweg) und der Server muss prüfen. Eine NTLM-Anmeldung ist zumindest bei Verzicht auf MD5 und möglichst auch RC4 und Nutzung von IIS Extended Protection sicherer aber belastet den DC durch häufige Abfragen. SMAL/OAUTH ist sicher die Zukunft im Internet aber für Intern wird man keinen OAUTH-Service betreiben und SAML-Tickets ausstellen, wenn der DC dies nicht von alleine macht. Jeder Windows Domain Controller ist aber zugleich Kerberos Server und stellt Kerberos Tickets aus. Für den Zugriff auf einen Service, durchläuft der Client im Grunde folgende Schritte:

  1. Vorarbeit: Anmeldung mit TGT
    Der Anwender muss sich natürlich zuerst einmal auf dem Client an der Domäne anmelden. Für lokale Benutzer gibt es erst einmal kein Kerberos. Der Client nutzt seine "Domainmitgliedschaft", um für den Anwender eine Domainanmeldung durchzuführen und bekommt in dem Zuge vom Kerberos Distribution Center ein "Ticket Granting Ticket (TGT"=. mit sich der Client dann weitere Servicetickets anfordern kann. Details dazu finden Sie auf Kerberos Grundlagen
  2. DNS zu Ermittlung der IP-Adresse
    Wenn der DNS-Server für den Namen über einen A-Record eine IP-Adresse liefert, ist der Name für die weitere Suche wichtig. Wenn ein CNAME geliefert kommt, folgt der Client der Alias bis er den realen Namen über einen A-Record findet und diesen Namen für die weitere Suche nutzt.
  3. Client verbindet sich anonym zum Server
    Am Anfang weiß der Client ja gar nicht, welche Dialekte und Authentifizierungsverfahren der Server anbietet. Der Client starte mit einem Negotiate und der Server meldet dann z.B. NTLM und Kerberos.
    Der Server sollte nun natürlich die Verbindung annehmen aber eine Anmeldung anfordern. Er teilt dem Client mit, dass er z.B. "Negotiate" versteht.
  4. Der Client fragt seinen KDC nach einem Ticket
    Das macht er natürlich nur, wenn er dem "REALM" vertraut, also der Name muss in einer Domain sein, für die der Client ein Ticket anfordern kann. Der KDC der eigenen Domain kann natürlich nur Tickets für seine Domain ausstellen. Wenn der Zugriff auf Server in einem anderen Namensraum erfolgt, dann muss der Client weitere Kerberos-Anfragen starten.

Gerade diese weitere Anfragen interessieren mich auf dieser Seite.

Testumgebung

Daher haben ich mir für die folgenden Tests eine Umgebung mit drei Domains und vier Systemen zusammengestellt. Ich habe dazu bestehende Domains genutzt.

  • Client  (in der Root-Domain)
    Ich habe einen gesonderten Client in "carius.de" zum Mitschnitt der Pakete mit Wireshark platziert. Nur so kann ich auch alle Pakete des Clients sehen, denn ein Test auf einem DC Selbst funktioniert wegen "Localhost"-Abfragen nicht.
  • DC01.carius.de
    Der DomainController der "Root-Domain", in der auch mein Client ist. Er ist der KDC für die Domain und stelle ein NETLOGN-Share bereit
  • subdc.sub.carius.de
    Ein Domain Controller der Subdomain, der ebenfalls ein "Dateiserver" unter "\\subdc1.sub.carius.de\NETLOGON" bereitstellt.
  • msxfaq.de 
    Eine komplett getrennter Forest mit eigenem DC mit SMB-Freigabe unter \\dc.msxfaq.de\netlogon" auf dem Domain Controller.

Zwischen dem Forest "carius.de" und dem Forest "msxfaq.de" gibt es einen Forest-Trust. 

Aus Vereinfachungsgründen habe ich in den folgenden Mitschnitten die DNS-Abfragen der Clients, den TGT-Request bei der Anmeldung etc. ausgeblendet. Die Systeme haben ja durchaus noch andere Workloads. Zudem habe ich IPv6 abgeschaltet und statische IPv4-vergeben  abgeschaltet. Wer

SMB Handshake

Ehe überhaupt der Client sich  um Kerberos Gedanken machen kann, muss er erst einmal den gewünschten Service per DNS auflösen und erreichen können. Aber auch dann weiß der Client noch nicht, was die entfernte Seite überhaupt unterstützt. Daher greifen die meisten Protokolle erst einmal anonym auf den Service zu, um dann die Fehlermeldung zu interpretieren. Bei HTTP habe ich das auf der Seite HTTP Authentication und Kerberos mit Browsern beschrieben. Denn Kerberos benötigt nicht nur das Angebot des Servers, sondern der Client muss es dann auch annehmen.

Meine folgenden Beispiele habe ich einen Zugriff per SMB als Beispiel genutzt. In den folgenden Mitschnitten habe ich diese vier Pakete nicht mehr weiter analysiert und teils nicht mal mitgeschnitten.

Der Client verbindet sich nach einer Namensauflösung mit dem Server per SMBv1 und der Server antwortet damit, dass er nur SMB2+ spricht und zudem nicht nur "Signing enabled" sondern sogar "Signing required" ist. Im Bereich GSS-API wirwd SPNETGo, drei Kerberos-Dialekte und noch NTLM angeboten. Die Information wiederholt bei den zwei nächsten Paketen, die ein SMB2-Handshake sind. Damit weiß der Client, dass der Server eine Anmeldung per NEGO/KERBEROS annehmen würde. Jetzt ist es am Client sich die passenden Zugangsdaten zu besorgen.

Ticket Granting Ticket-Trace

Damit ein Client ein Kerberos-Ticket für die Gegenstelle erhält, muss er sich beim "Kerberos Distribution Center (KDC) erst ein Ticket Granting Ticket (TGT). Diese Pakete sind auf dem Client selbst nicht ohne Vorbereitungen zu erwischen, denn bei der Anmeldung am Client erfolgt schon die Anmeldung am DC und das entsprechende TGT hat ihr Client schon im Speicher und es gilt einige Stunden. Mit KLIST können Sie die Tickets dem Cache des Benutzers sehen. mit KLIST PURGE können Sie aber auch alle Tickets löschen, so dass beim nächsten Zugriff dann wieder die Anmeldung mitgeschnitten werden kann.

IP, NTP und DNS Abfragen

WINS war gestern und Broadcasts funktioniere auch nicht mit Kerberos. Stellen Sie vorher sicher, dass ihr Fundament korrekt gelegt ist. Dazu gehört, dass alle Server und Clients die gleiche Uhrzeit verwenden. Die Zeitzone selbst ist nicht wichtig, da intern alles auf UTC umrechnet wird aber wenn Server mehrere Minuten abweichen, weil Sie als VM ohne Echtzeituhr driften oder der Hypervisor selbst eine falsche Zeit hat und diese den Gäste immer wieder aufdrückt, dann wird Kerberos nicht zuverlässig sein.

Werfen Sie hier auch noch mal einen Blick auf DNS, denn auch der KDC wird mit den entsprechenden Ressource-Records gesucht. Wenn Sie später zwei Forests mit einem Trust betreiben wollen, dann sollten Sie die DNS-Welten sauber verbinden. Es gibt drei Optionen:

  • selektive Weiterleitungen
    Ihr Client fragt ihren DNS-Server, der dann die gewünschten Informationen für den Client besorgt und dem Client antwortet. Das ist einfach und schnell aufgesetzt und die Clients bleiben lokal. Der DNS-Server hat natürlich etwas mehr zu tun
  • "REFERER"
    Sie können bei sich auch einen STUB-Zone einrichten, die einfache nur auf die eigentlichen DNS-Server verweist. Die Clients fragen dann ihren lokalen DNS-Server, der dem Client die "richtigen Server" liefert. Der Client baut dann eine Verbindung zu den DNS-Servern des anderen Forest auf und umgeht damit ihre eigenen DNS-Server. So funktioniert z.B. das Internet, wenn Sie einen Root-Server fragen. Für Firmen ist dies weniger interessant, da damit alle Clients eines Forests auch die DNS-Server des anderen Forests nutzen müssen.
  • Replikation der Zonen
    Der ADmin eines Forest kann natürlich auch die DNS-Zonen der anderen Forest als "sekundäre Zone" bei sich vorhalten. Allerdings kann man sekundäre Zonen nicht per AD-Replikation auf eigene DNS-Server verteilen. Man müsste dann zumindest die sekundäre Zone auf alle eigenen DNS-Stammserver replizieren lassen und bei Änderungen in der Quelle auch wieder anpassen.

Von den drei Optionen ist mit die selektive Weiterleitung am sympathischsten, denn Sie ist schnell eingerichtet und recht aktuell ohne viele Firewall-Ports öffnen zu müssen. Aber alle drei Optionen haben ihre Freunde und Je nach Einsatzzweck auch Vorteile.

Kerberos Same Domain

Wir fangen erst einmal einfach an und nutzen den Client in der gleichen Domain, um einfach eine SMB-Freigabe aufzulisten:

C:> dir \\dc01\netlogon

Das Verzeichnis wird aufgelistet und in Wireshark habe ich folgende Pakete gesehen.

Da ich schon angemeldet war, sehen Sie den ersten roten TGT-Request und Antwort nicht, da ich schon ein Ticket Granting Ticket habe. Auch den SMB-Handshake am Anfang  habe ich weggelassen.

Der ausführliche Ablauf ist:

 

Paket-Nr. Gegenstelle Beschreibung

90 und 93

KDC der UserDomain

Der Client nutzt sein bestehendes TGT-Ticket, um vom KDC ein TGS für das Ziel "cifs:/dc01" anzufordern.
 
Er bekommt das Ticket in Paket 93 zurück

109,111 

SMB Verbindung zum Server

 Hier sehen wir dann den SMB Handshake zum Dateiserver. Der Client sendet das vorher erhaltene Ticket mit.

Die weiteren SMB-Pakete analysiere ich nicht weiter.

Bis hier war es noch einfach.

Kerberos Cross Domain

Im nächsten Schritt greife ich vom gleichen Client auf die NETLOGON-Freigabe des Domaincontrollers in einer SUB-Domäne des gleichen Forest zu.

C:> dir \\subdc.sub.carius.de\netlogon

Auch hier habe ich die Initiale Anmeldung mit dem Erhalt eines TGT, die davor stattfindenden DNS-Abfragen zur Namensauflösung und den SMB-Check ausgeblendet.

Wir sehen in Wireshark auf dem Client aber schön, dass der Client zuerst eine Verbindung zum KDC seiner Anmeldedomain aufbaut, um ein Ticket zu erhalten um dann aber noch eine zweite Verbindung zum KDC der SUB-Domain zu nutzen.

Insgesamt können Sie folgende Pakete finden

 

Ein paar Pakete schauen wir uns genauer an.

Paket-Nr. Gegenstelle Beschreibung

207,210

KDC der UserDomain

Mein Client geht zuerst zum DC meiner Userdomain um sich ein KRBTGT für die Subdomain zu holen.

Das Ticket ist im Paket 210 enthalten. Ich habe hier nicht zwischen den DCs mitgeschnitten, ob es eine Kommunikation gibt.

218,221 

KDC der Sub-Domain

Im Paket 218 sehen wir dann die Anforderung (Request) zum KDC der Subdomain für ein CIFS-Ticket.


Das Ticket kommt im Paket 221 vom KDC

224,228

SMB-Server der Sub-Domain

 Der nächste Zugriff erfolgt auf den SMB-Server mit dem Kerberosticket des Sub-Domain-KDC

Der Zugriff auf einen Service innerhalb des Forest ist auch über mehrere Domains hinweg möglich. Der Client fordert ein TGC-Ticket von seinem "Heimat-KDC" an, mit dem er sich dann vom KDC der Service Domain ein TGS-Ticket für die Authentifizierung am Ziel besorgen kann.

Kerberos über zwei Forests

Interessant wird es nun, wenn der Service nicht im gleichen Forest steht, sondern  in einer ganz anderen Umgebung. Die meisten Firmen werden dies kaum benötigen, da Sie nur eine Domain mit einem Forest oder vielleicht mehrere Domains im gleichen Forest nutzen. Aber dann denken Sie mal an...

  • Firmengruppen
     ein Konstruktion mit mehreren Firmen, die für sich eigenständig sind aber dennoch zusammen arbeiten. Das müssen nicht einmal die ganz großen Firmen sein. Ich habe solche Umgebungen auch in kleinen Firmen gesehen
  • Merger&Aquisitions
    Eine Firma kauft eine andere, die dann zuerst angebunden und vielleicht letztlich migriert wird.
  • Firmenaufsplittung
    Firmen entwickeln sich kontinuierlich weiter und manchmal gibt ein eine Teileinheit, die später besser losgelöst weiter agiert. Dann bietet es sich an dieser Teilfirma einen eigenen Namen und einen eigenen Forest zu geben und deren Diensts dort hinzu migrieren, ehe Sie dann später geplant getrennt werden.
  • Interner AD-Umbau
    Einen zweiten Forest können Sie aber auch für eine interne Migration benötigen, Nicht wenige Firmen haben schon im Jahr 2000 mit dem AD angefangen und in den Jahren haben sich durchaus einige Altlasten der verschiedenen Administratoren versammelt, z.B. unsichere Einstellungen, unklare ACLs, nicht mehr passendes OU-Konzept, Zu viele Domains Administratoren, insbesondere für Dienstkonten oder auch einfach ein aus heutiger Sicht falsche DNS-Name. Ich kenne Firmen, die nutzen intern sogar einen externen DNS-Namen, der ihnen nicht gehört, was speziell für Homeoffice-User eine Sicherheitsgefahr darstellen kann.

Bei diesen und anderen Konstellationen ist ein zweiter Forest eine legitime Konfiguration. Aber auch hier möchte man nicht nur ein "Seamless-SignOn" sondern vor allem kein alten NTLM o.ä., haben. Für die Nutzung von Kerberos in solchen Umgebungen sind aber einige Voraussetzungen erforcherlich:

  • Eindeutige UPN und Namensraum 
    Es versteht sich von selbst, dass der neue Forest nicht den gleichen UPN-Namensraum und DNS-Namensraum nutzen kann.
  • IP-Verbindung und Namensauflösung
    Eigentlich selbstverständlich aber ich möchte es dennoch erwähnen, dass Sie für den Trust natürlich IP-Routing, Firewalls und Namensauflösung sicherstellen müssen, damit Clients und DCs sich entsprechend finden
  • Uhrzeit
    Eine synchrone Uhrzeit zwischen den Systemen ist wichtig. Kerberos erlaubt nur wenige Minuten Abweichungen. Aber das sollte heute kein Problem mehr sein. Eine kurze Kontrolle stellt sicher, dass die Authentifizierung nicht an dieser Kleinigkeit scheitert
  • SID-Filterung
    Als Schutzmaßnahme können Sie bei Trusts eine Filterfunktion einrichten, damit ein Benutzer einer andere Domain nicht z.B.: per SIDHistory o.ä. SIDs der Zieldomäne mit sendet.
  • Bidirektionaler Trust
    Nach meinem Kenntnisstand geht es mit einem Bidirektionalen Forest-Trust am besten, damit Kerberos‑Tickets über die Forest‑Grenze hinweg weitergereicht werden können. Kontrollieren Sie die auf beiden Seiten unter "AD Domain und Trusts" und prüfen Sie auch das "Name Suffix Routing" zu den jeweils anderen Domains des Forest.
  • Forest-Trust, kein Domaintrust
    Forest‑Trust, nicht nur Domain‑Trust, weil Kerberos auf Forest‑Ebene die globale KDC‑Vertrauensstruktur nutzt.

Kerberos requires exact suffix mapping. LSA uses one set of functions for routing domain searches and the Kerberos rules are used there for forest trusts.
Quelle: Overlapping Forest Names cause problems once Forest Trusts are established
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/overlapping-forest-names-problem-forest-trust-established

Ich starte auf meinem Client einen "dir \\msxfaq.net\netlogon" um den Zugriff zu erreichen:

 

Die interessanten Pakete sind hier

Paket-Nr. Gegenstelle Beschreibung

2064-2086 

Client <-> DC.carius.de 

Die initiale Anmeldung mit dem Abrufen des TGT

2498-22501

Client zum Server

Die DNS-Anfrage wurde nicht mitgeschnitten. Der Client versucht einen Zugriff und erhält die Information, welche SMB-Dialekte und Authentifizierungen möglich sind.

2507

 Von: Client
Zu KDC carius.de 192.168.178.216

Zuerst geht mein Client wieder zum lokalen KDC, um ein Ticket für das Zielsystem zu erhalten.

2511

 Von KDC carius.de 192.168.178.216
Zu: Client
 Der KDC kann aber kein Ticket für den Server in dem anderen Forest ausstellen. Aber er kann mir ein Ticket geben, mit dem ich mir ein Ticket beim KDC im anderen Forest abrufen kann:

2520 

 Von Client:
Zum KDC msxfaq.net		 Mit dem erhaltenen "Kerberos Referral Ticket" kann der Client nun an den KDC im anderen Forest gehen.

2524  

 Vom KDC msxfaq.net 
Von Client:		 Der KDC/mxfaq.net akzeptiert meinen Request und liefert mir nun ein TGS für den CIFS-Zugriff.

4389

Client zum Dateiserver

 Erst jetzt kann der Client den anfänglichen SMB-Handshake mit einer Anmeldung fortsetzen.

Entsprechend finden wir mit KLIST die Tickets auf dem Client:

Die Reihenfolge ist hier etwas durcheinander aber wir haben folgende Tickets:

  • #1 TGT von Carius.de
    Das ist eigentlich das erste Ticket, welches ich schon bei der Anmeldung bekomme
  • #3 TGS für den DC01.carius.de
    Das fordere ich mir an, um auf den DC1 zugreifen zu können. Es hat mit der eigentlichen Verbindung nichts zu tun, sondern war der geöffneten MMC
  • 0# TGT von MSXFAQ.DE
    Mit dem Ticket #3 habe ich mich dann beim DC des anderen Forest authentifiziert und von dort ein TGT zu bekommen
  • #2 TGS zum CIFS/SMB-Server
    Mit dem TGT zur Domain "msxfaq.de" kann ich mich nicht am Share anmelden. Daher hat mein Client mit dem krbtgt/msxfaq.de ein TGS für den FQDN des Servers geholt, auf den er per DFS verwiesen wurde.

Auch ohne Wireshark oder Adminrechte können Sie alleine mit KLIST eine erster Fehlersuche betreiben.

Natürlich können Sie auch das Windows Eventlog auf Fehler und Erfolgsmeldungen auswerten. Es bietet sich sogar an, das Ausstellen von TGS-Tickets z.B. in einem SIEM zu loggen um Nutzung und Angriffe nachvollziehen zu können.

Edge Browser Client Allow

Kerberos über mehrere Forests funktioniert mit Windows-Komponenten. Allerdings ist dies nicht immer für alle Programme der Fall. Hier fallen die Browser auf, die natürlich sehr oft externe Adressen erreichen wollen. Wenn Sie dann für jede angesurfte Webseite erst den eigenen KDC nach einem Ticket und einem Referral fragen, dann hat ihr Domain Controller viel unnütze Arbeit. Daher pflegen Browser eine Liste von Domänen, für die Sie Kerberos überhaupt nur nutzen. Beim Edge-Browser ist das nur der eigene Forest, so dass Sie bei einer Nutzung von Kerberos auf andere Forests schon aktiv werden müssen.

HKLM\SOFTWARE\Policies\Microsoft\Edge\AuthNegotiateDelegateAllowlist:REG_SZ="*.msxfaq.net"
HKLM\SOFTWARE\Policies\Microsoft\Edge\AuthServerAllowlist:REG_SZ = "*.msxfaq.net"

Am besten verwalten Sie die Einträge per Gruppenrichtlinien. Sie müssen Sie dazu erst die ADMX-Templates für den Edge Browser von Microsoft herunterladen und einspielen, ehe Sie dann "Microsoft Edge" in den Richtlinien finden:

Ähnliche Einstellungen gibt es auch für Chrome, Firefox und andere Browser:

HKLM\SOFTWARE\Policies\Google\Chrome\AuthNegotiateDelegateAllowlist

Es liegt immer am Client, wie er auf das Angebot von NEGO/Kerberos reagiert und ein Ticket anfordert.

Weitere Links