„Ich glaub ich steh im Wald“ – Kerberos hilf mir suchen!

Hier ist wieder einmal der Herbert. Heute möchte ich die Aufmerksamkeit auf ein bisher wenig beachtetes Feature in Windows Server 2008 R2 und Windows 7 lenken. Es ermöglicht, einen Service Principal Name (SPN) in mehreren Forests zu finden.

Es kann nämlich Situationen geben, wo man nicht immer einen Server FQDN hat, oder man hat einen, den man keinem Forest eineindeutig zuweisen kann. Das kann der Fall sein, wenn gerade Dienste zwischen zwei Forests umgezogen werden und die Suffixes zu keinem der beiden Forests passen. Dazu braucht man dann die „Kerberos Forest Search Order“ (KFSO).

Das Feature wird per Group Policy aktiviert, man kann es für Domain Controller (KDC) und Domainmitglieder (Kerberos) aktivieren. Der Name ist “Use forest search order” in:

KDC: Computer Configuration\Administrative Templates\System\KDC
Kerberos: Computer Configuration\Administrative Templates\System\Kerberos

Der Wert sind Namen von weiteren Forests, die durchsucht werden sollen.

Wie funktioniert das?

Die Forest Search wird nur für “zweiteilige“ Namen gemacht. Ein Kerberos SPN kann bis zu drei Teile haben:

1111/222222@33333

Beispiele:
Cifs/server1@contoso.com
Cifs/server1.contoso.com@contoso.com

Syntax:

1. Servicetyp
2. Server Netzwerkname
3. Realmname

Die meisten Client Applikationen verwenden zweiteilige Namen ohne „ @ “, also sind sie für Forest Search geeignet. Soweit es den KDC betrifft, ist die Realm unbekannt und muss gesucht werden (Suffix Mapping). Wenn der Client die Realm angeben würde, wäre die Forest Search nicht erlaubt.

Übrigens: Dreiteilige SPNs erlauben es auch Kerberos Tickets über externe Trusts zu bekommen. Forest Search ist auch für Trusting Domains über externe Trusts möglich. Update: Es gibt eine wichtige Einschränkung: Wir können nicht garantieren, dass eine solche Weiterleitung in allen Fällen funktioniert. Supportbar ist das KFSO nur über einen Forest Trust. Referenz:

2977475 Kerberos Forest Search Order may not work in an external trust and event ID 17 is returned

Wenn also der SPN nicht in der lokalen Datenbank und im GC gefunden werden kann (weder Cifs/server1 noch Cifs/server1.contoso.com) und der DNS Host Suffix (contoso.com) nicht einem anderen Forest zugewiesen ist, kann der KDC Forest Search nutzen. Der Client macht das gleiche, wenn er KDC_ERR_S_PRINCIPAL_UNKNOWN vom KDC zurückbekommt. Man kann also sowohl KDC als auch Kerberos suchen lassen, auch in unterschiedlichen Forests.
Gesucht werden die SPNs auf GCs der Forests. Die Komponente hat einen “forest reference cache” mit dem sie sich merkt, für welchen Forest welcher GC verwendet wurde. Sie merkt sich in dem Cache auch Fehler, so dass nicht innerhalb kurzer Zeit oft nicht erreichbare Forests versucht werden. Damit wird vermieden, dass aggressive Clients einen DC über Gebühr beanspruchen, oder das Netz, wenn der Client sucht.
Das Konto der GC-Suche ist die Computer-Identität, also entweder der DC oder das Mitglied. Auch dafür braucht es also eine Anmeldung und eventuell gibt es dabei auch Fehler (wie bei one-way Trusts, Selective Authentication).

KFSO Algorithmus

1. Führe die Schleife aus über die Namen in der Liste.

2. Für jeden Forest:

a) Finde einen GC des Forests über DNS Namensauflösung und DC Locator Ping UDP/389.
b) Melde Dich am GC an im Forest per AD Replikations-RPC Interface. Das benötigt die RPC Server Port auf der Firewall wie in KB 224196 beschrieben.
c) Rufe DsCrackNames mit Namensformat DS_SERVICE_PRINCIPAL_NAME für den SPN auf.
d) Wenn der SPN gefunden wurde, merke Dir den Treffer und höre auf.

3. Die Suche kehrt in die normale Ausführung im KDC oder Kerberos Client zurück und:

a) KDC erstellt Referral Ticket für die Rootdomain des Zielforests und gibt diesen an den Client.
b) Kerberos fragt nach Ticket für die Rootdomain des Zielforests vom eigenen DC.
c) Mit dem Ticket geht es dann weiter zur richtigen Domain im Zielforest.

Highlight
Diese Suche ist recht effizient und vermeidet hohen Overhead, auch wenn viele nicht existierende SPNs gesucht werden.

Hinweis
Trotzdem sollte die Forestliste so kurz wie möglich gehalten werden um eine “Distributed Denial of Service” Attacke zu erschweren. Streng genommen ist ein Domain Controller von vorne herein ein DDoS Angriffsziel.

Weitere Themen:

Functional Levels
Das Feature ist nicht von einem Functional Level abhängig, sondern nur vom Betriebssystem. Es funktioniert also auch in gemischten Umgebungen. Damit sich das System konsistent verhält, sollten alle oder zumindest die große Mehrzahl der Domainmitglieder oder Domain Controller die neueste Version des OS haben, damit die Suche konsistent funktioniert.

Endlosschleifen
Bevor ein Request in einen entfernten Forest geschickt wird, muss er erst einmal im lokalen Forest fehlen, und er wird nur hingeschickt, wenn es den SPN im untersuchten Forest auch gibt. Eine Schleife scheint nur möglich, wenn in jedem Forest der SPN auf dem GC vorhanden ist, aber nicht auf dem erwarteten DC („lingering“ Objekt oder SPN).
Der Test per DsCrackNames sollte in den allermeisten Fällen solche Schleifen vermeiden. Damit kann aus einem Forest ohne Probleme in anderen Forests gesucht werden und umgekehrt. Wichtig ist wie immer, dass die SPNs eineindeutig zugeordnet sind.
Die DsCrackNames-Anfrage ermöglicht es auch, dass ohne Schleifen sowohl der KDC als auch der Client die Suche durchführt, auch in den gleichen Forests. Die Last wird halt höher, darauf muss man aufpassen.

Monitoring und Leistungsfähigkeit
Der KDC bearbeitet die Anfragen in einem ATQ worker thread, diese werden “LDAP worker threads” in den Performance-Objekten “NTDS” oder “Directory Services” (je nach OS Version). Der Grund dafür ist, dass dieser Pool sowohl LDAP als auch Kerberos-Anfragen bearbeitet.

Hinweis
Die Gesamtlast auf dem Pool sollte überwacht werden mit diesen Countern. Zu LDAP gehören auch LDAP über UDP, also die DC Locator Pings. Seit Windows Server 2008 R2 könnte es bei diesen Requests zu Engpässen kommen, da die Pings für IPv4/IPv6 Dual Stack Support Namensauflösung machen.
Eventuell müssen wir die “MaxPoolThreads” LDAP Policy erhöhen, damit es mehr Worker Threads gibt: "315071 How to view and set LDAP policy in Active Directory by using Ntdsutil.exe"; https://support.microsoft.com/default.aspx?scid=kb;EN-US;315071

Tipp
Man sollte die Frequenz von DsCrackNames überwachen, mit dem die SPNs für dieses Feature geprüft werden. Im Objekt “NTDS” bzw. “Directory Services” gibt es einen Zähler “DS Client Name Translations/sec”, der das auf dem DC mitzählt.
Die Aufrufe selbst kann man nur mit “NTDS diagnostics” Logging der Kategorie “23 DS RPC Server” auf Level 5 sehen. Dieses Level ist SEHR geschwätzig, und loggt leider nicht den angefragten SPN.
Als Semi-Überwachung bieten sich noch die “Data Collector Sets” für Active Directory and. Dort werden fehlgeschlagene Kerberos Anfragen (Fehler 7, KDC_ERR_S_PRINCIPAL_UNKNOWN , Kandidaten für Forest Search) und DsCrackNames Aufrufe mitverfolgt.

Skalierungslimits
Es gibt wenig Erfahrungen mit dem Feature. Unsere Einschätzung ist, dass die Suche vom Client insgesamt besser skaliert da keine Server-Seitigen Resourcen für die zusätzliche Arbeit belegt werden. Aber wie beim Thema DDoS schon erwähnt können viele Clients alle Forests in der Suchliste mit vielen Anfragen lahm legen.

Es gibt folgende Warnungen:
· Viele ungültige SPNs sorgen dafür, dass der KDC eine potentiell lange Liste von Forests abklappert und der Serverthread lange in Beschlag genommen wird. Hier ist eine kurze Liste nützlich.
· Jede Anfrage bindet einen Server Thread, davon gibt es vier pro Server Core (LDAP policy MaxPoolThreads). Man kann das Limit nicht ins Unendliche erhöhen, da der Server viel Zeit mit dem Verschieben von Threads verbringt.

Empfehlung
· Die Anzahl der Zielforests so klein wie möglich machen.
· Die Liste so sortieren, dass die Forests mit den wahrscheinlich meisten Treffern vorne sind, das sind auch die größten Forests mit den meisten und leistungsfähigen DCs.
· Auf die Verteilung der Clients achten (Subnet/Site-Mapping über Forests bzw. Besetzung der Site-Less Namen, siehe KB 306602).
· Eine Client-seitige Suche kann am besten skalieren. Die Domain Controller einer Domain sind aber am einfachsten auf eine konsistente Version zu bekommen.

Namensfindung
Wenn der blanke Hostname von der Applikation (z.B. „Server1“) kommt, dann kann nur der im Forest gefunden werden. Windows kann nicht wissen in welchem Forest er sonst sein könnte und braucht KFSO. Wenn FQDNs von der Applikation verwendet werden (z.B. „Server1.constoso.com“), dann ist die Findung per Suffix-Mapping schon einfacher. Aber auch hier kann KFSO nötig werden, wenn constoso.com über den GC oder Trust-Referenzen zunächst nicht gefunden wird.
Wir werden für beide Themen Applikationen finden. Es gibt durchaus noch Applikationen, die „NETBIOS“-Namen verhaftet sind. Bislang sind diese Apps auf NTLM zurück gefallen, nun gibt es die Chance dafür Kerberos zu bekommen.
Applikationen sollten sich an die korrekte Namensverwaltung halten, sonst gibt es Probleme. Problematisch ist zum Beispiel, mit einem blanken Hostnamen anzufangen und dem im DNS gefundenen Suffix einen FQDN-SPN zu erstellen.
Probleme damit gibt’s auch ohne KFSO, zum Beispiel hatte Internet Explorer hier einen Fehler, das wurde mit KB 911149 behoben.

Dann hoffen wir mal, daß der ein oder andere damit den richtigen Wald "vor lauter Bäumen" findet :)
Herbert