Kerberos hinter Load Balancer und Reverse Proxy: warum die Anmeldung im Cluster scheitert

Es gibt Anrufe, die klingen am Telefon wie ein Erfolg und stellen sich beim zweiten Satz als Schadensmeldung heraus. „Wir haben die Anwendung jetzt auf drei Knoten gelegt, wegen der Verfügbarkeit. Läuft prima. Nur die Anmeldung fragt seitdem nach dem Kennwort.“ Die Verfügbarkeit ist damit tatsächlich gestiegen: Die Anwendung ist nun hochverfügbar unbequem.

Das Muster wiederholt sich mit einer Verlässlichkeit, die man sich für Sicherungsläufe wünschen würde. Ruft man einen einzelnen Knoten direkt über seinen Servernamen auf, läuft Single Sign-on lautlos durch. Ruft man dieselbe Anwendung über die gemeinsame Cluster-Adresse auf, erscheint entweder ein Anmeldedialog — oder es funktioniert scheinbar, aber im Mitschnitt steht plötzlich NTLM statt Kerberos. Und weil NTLM in den meisten Umgebungen noch klaglos arbeitet, merkt es monatelang niemand. Bis eine Delegierung ins Backend gebraucht wird, ein Audit danach fragt oder NTLM stufenweise abgeschaltet wird. Dann kippt alles gleichzeitig um, und zwar in der Woche, in der die halbe Mannschaft im Urlaub ist.

Die gute Nachricht: Die Ursache ist in den allermeisten Fällen dieselbe, und sie lässt sich in zwanzig Minuten belegen. Die schlechte: Sie liegt nicht dort, wo alle zuerst suchen. Der Load Balancer ist in dieser Geschichte selten der Täter. Er ist der Zeuge, der die Leiche gefunden hat — und dafür erst einmal verhört wird.

Dieser Beitrag zerlegt die Ursachenkette Station für Station, benennt die drei Stellen, an denen sie regelmäßig reißt, und beschreibt die Kontoführung, die den Fall dauerhaft schließt. Anschließend geht es um den Balancer selbst: durchreichen, TLS terminieren oder sich gleich selbst anmelden — drei Betriebsarten mit drei sehr unterschiedlichen Rechnungen.

Zur Einordnung: Dieser Beitrag ist ein Spoke der Serie rund um Microsoft Kerberos. Den Überblick über alle Bausteine — Tickets, Dienstnamen, Verschlüsselungstypen, Delegierung — gibt die Pillar-Seite /microsoft-kerberos. Die Grundlagen setze ich hier voraus: Wie ein Dienstname sauber gesetzt und wieder abgeräumt wird, steht in /spns-richtig-setzen-setspn. Was ein TGT von einem Service-Ticket unterscheidet und warum der Unterschied hier den Ausschlag gibt, erklärt /kerberos-tickets-tgt-und-service-ticket. Und wer den Reverse-Proxy-Teil vertiefen möchte, findet die Modelle dahinter im Delegierungs-Spoke dieser Welle: /kerberos-delegierung-unconstrained-bis-rbcd.

Das Symptom: einzeln lautlos, im Verbund laut

Bevor irgendjemand eine Konfigurationsdatei öffnet, lohnt sich ein sauberer Befund. Er kostet zwei Minuten und entscheidet, ob wir überhaupt über das Thema dieses Beitrags sprechen oder über etwas völlig anderes. Erstaunlich viele Eskalationen mit vier beteiligten Abteilungen wären an dieser Stelle beendet gewesen — hätte sie jemand gemacht.

Der Zwei-Minuten-Test, der zwei Tage spart

Man ruft dieselbe Anwendung zweimal auf: einmal über den Namen eines einzelnen Knotens, einmal über die gemeinsame Cluster-Adresse. Derselbe Arbeitsplatz, dasselbe Konto, derselbe Browser, unmittelbar nacheinander. Verhält sich der erste Aufruf still und fragt der zweite nach Anmeldedaten, ist die Sache eingegrenzt: Es liegt nicht an der Anwendung, nicht an den Berechtigungen und nicht am Anwenderkonto. Es liegt am Namen.

Der Test trennt zwei Fehlerklassen, die man sonst wochenlang miteinander verwechselt. Scheitert auch der Direktaufruf, hat man ein Kerberos-Problem ohne jeden Cluster-Bezug: Zeitversatz, abgeschaltete Verschlüsselungstypen, falsche Browserzone, defekte Vertrauensstellung. Scheitert nur der Aufruf über die Cluster-Adresse, ist es mit sehr hoher Wahrscheinlichkeit die Zuordnung von Dienstname zu Konto — und nichts sonst.

Fünf Meldungen, die alle dieselbe Ursache haben können

Was im Ticket steht	Was tatsächlich passiert	Wo der Beleg liegt
Über die Cluster-Adresse kommt eine Kennwortabfrage	Kerberos scheitert, der Server bietet ersatzweise NTLM an; ohne passende Zonenzuordnung landet das als Dialog beim Anwender	Mitschnitt: WWW-Authenticate: Negotiate, danach NTLMSSP
Es funktioniert, aber die Weitergabe ins Backend nicht mehr	Die Anmeldung läuft in Wahrheit über NTLM; NTLM kann nicht delegieren	Backend protokolliert einen anonymen oder falschen Aufrufer
Nur ein Teil der Belegschaft ist betroffen	Der SPN hängt an genau einem Knoten; betroffen ist, wen der Balancer auf die anderen verteilt	Systemprotokoll der übrigen Knoten: Ereignis-ID 4, KRB_AP_ERR_MODIFIED
Der Fehler tritt nur „manchmal“ auf	Zwei Konten tragen denselben SPN; welcher gewinnt, entscheidet der Zufall der Verzeichnissuche	setspn -X` meldet den doppelten Eintrag
Nach einem Neustart eines Knotens ist es wieder gut	Sitzungsbindung schiebt Anwender auf den einen funktionierenden Knoten	Verteilungsstatistik des Balancers

 

FAKTEN Warum der Client den falschen Namen gar nicht bemerken kann Ein Kerberos-Client fragt beim Domänencontroller nach einem Ticket für einen Dienstnamen, den er selbst aus der aufgerufenen Adresse bildet. Er kennt weder die IP-Adresse des antwortenden Knotens noch dessen Computernamen — er kennt nur den Host-Teil der URL beziehungsweise den Verbindungsnamen, den die Anwendung ihm nennt. Damit ist die zentrale Regel dieses Beitrags gesetzt: Der SPN muss auf die gemeinsame Adresse zeigen, nicht auf den realen Zielserver. Und er darf nur an einem einzigen Konto hängen, das alle Knoten teilen.

 

Warum NTLM den Schaden monatelang verdeckt

Der Aushandlungsmechanismus hinter der HTTP-Kopfzeile „Negotiate“ ist höflich. Findet der Domänencontroller keinen passenden Dienstnamen, wird nicht etwa abgebrochen; der Client versucht es mit NTLM. In einer Domäne mit Standardeinstellungen gelingt das meistens. Aus Sicht der Anwender ist damit alles in Ordnung, aus Sicht des Betriebs auch — schließlich meldet das Überwachungssystem keinen Fehler. Es gibt keinen. Es gibt nur ein schwächeres Protokoll.

Der Ärger kommt später und in drei Wellen. Erstens, wenn die Anwendung Daten aus einem Backend braucht und dafür die Identität des Anwenders weiterreichen soll: NTLM kann das nicht, Punkt. Zweitens, wenn eine Prüfung feststellt, dass die vermeintlich moderne Anmeldung an der zentralen Anwendung seit Jahren auf einem Protokoll läuft, das man eigentlich abschalten wollte. Und drittens, wenn NTLM tatsächlich eingeschränkt wird — dann fällt nicht ein Dienst aus, sondern alle gleichzeitig, die dieselbe Schwäche teilen.

WARNUNG Der teuerste Satz in diesem Themenfeld „Es funktioniert doch.“ — Diese Aussage ist der Grund, warum Kerberos-Probleme hinter Load Balancern typischerweise nicht bei der Inbetriebnahme gefunden werden, sondern zwei Jahre später, in einem völlig anderen Projekt, unter Zeitdruck und mit Beteiligung von Personen, die den Aufbau nie gesehen haben. Wer eine Anwendung hinter einen Balancer stellt, sollte einmalig aktiv nachweisen, dass die Anmeldung über Kerberos läuft — nicht, dass sie „geht“. Der Nachweis dauert keine fünf Minuten und ist die billigste Versicherung im ganzen Vorhaben.

 

Die Ursachenkette: der Client baut den SPN aus der URL

Die eigentliche Erkenntnis dieses Beitrags passt in einen Satz, und trotzdem braucht sie eine Skizze, weil sie so oft an der falschen Stelle vermutet wird: Der Client bildet den Dienstnamen aus dem Host-Teil der aufgerufenen Adresse — nicht aus dem realen Zielserver. Alles Weitere ist Konsequenz.

Von der Adresszeile bis zum entschlüsselten Ticket: sechs Stationen, an denen jeweils etwas anderes schiefgehen kann. Der Balancer ist nur eine davon — und meistens die unschuldigste.

Sechs Stationen bis zum Ticket

Station eins ist der Client. Er nimmt den Host-Teil der Adresse, hängt die Dienstklasse davor und hat damit seinen Dienstnamen: aus einem Aufruf von https://portal.example.internal/ wird HTTP/portal.example.internal. Diese Dienstklasse ist übrigens sprechend, aber nicht wörtlich zu nehmen: Sie lautet HTTP, auch wenn die Verbindung über TLS läuft.

Station zwei ist die Namensauflösung. Zeigt der eingegebene Name auf einen Alias, folgen die gängigen Browser der Kette und verwenden den kanonischen Zielnamen für den SPN. Das ist der Punkt, an dem eine gut gemeinte DNS-Vereinfachung die ganze Konstruktion umwirft — dazu gleich mehr.

Station drei ist der Domänencontroller. Er sucht den Dienstnamen im Verzeichnis. Findet er ihn nicht, antwortet er mit KDC_ERR_S_PRINCIPAL_UNKNOWN, und der Client geht auf NTLM zurück. Findet er ihn, verschlüsselt er in Station vier das Service-Ticket mit dem Langzeitschlüssel des Kontos, an dem der SPN hängt. Nicht mit dem Schlüssel des Servers, der antworten wird — dieser Unterschied ist der Kern des gesamten Problems.

Station fünf ist der Balancer. Auf Ebene 4 reicht er das Ticket unverändert durch und ist an der Anmeldung überhaupt nicht beteiligt. Station sechs ist der Knoten, der die Anfrage annimmt. Er kann das Ticket genau dann entschlüsseln, wenn der annehmende Prozess unter demselben Konto läuft, an dem der SPN registriert ist. Tut er das nicht, protokolliert er KRB_AP_ERR_MODIFIED — eine Meldung, die klingt, als hätte jemand am Ticket manipuliert, und in Wirklichkeit nur bedeutet: falscher Schlüssel.

Die Kette im Überblick — und wo sie erfahrungsgemäß reißt

Station	Was dort geschieht	Typischer Bruch	Erkennbar an
1 — Client	SPN wird aus dem Host-Teil der URL gebildet	SPN existiert nirgends	klist` zeigt kein Ticket für den Namen
2 — DNS	Aliaskette wird aufgelöst und kanonisiert	Alias zeigt auf einen einzelnen Knoten	klist` zeigt den Knotennamen
3 — KDC	Suche nach dem servicePrincipalName	kein Treffer	KDC_ERR_S_PRINCIPAL_UNKNOWN, danach NTLM
4 — KDC	Ticket wird mit dem Kontoschlüssel verschlüsselt	SPN an zwei Konten	setspn -X` meldet ein Duplikat
5 — Balancer	Verteilung auf einen Knoten	TLS wird aufgebrochen, Kanalbindung entfällt	Fehler nur bei erzwungenem erweitertem Schutz
6 — Knoten	Ticket wird entschlüsselt und geprüft	Prozess läuft unter dem falschen Konto	Systemprotokoll, Ereignis-ID 4

 

Die CNAME-Falle

Die Namensauflösung verdient einen eigenen Abschnitt, weil sie den perfiden Fall produziert: Alles ist richtig konfiguriert, und es funktioniert trotzdem nicht. Legt jemand die Cluster-Adresse als Alias auf einen Knotennamen oder auf den Herstellernamen des Balancers, dann fragt der Browser nicht nach dem Namen, den der Anwender eingegeben hat, sondern nach dem Namen, auf den der Alias zeigt.

Die Browser der Chromium-Familie und der Internet-Explorer-Unterbau verhalten sich hier gleich: Standardmäßig wird der kanonische Name verwendet. Steuern lässt sich das über eine Richtlinie, aber das ist die zweitbeste Lösung. Die beste ist ein schlichter A-Eintrag auf die virtuelle Adresse des Balancers. Microsoft gibt dieselbe Empfehlung übrigens auch für die Anbindung interner Anwendungen über den Anwendungsproxy: im internen DNS einen A-Eintrag verwenden, keinen CNAME.

DNS: der Unterschied, der über Kerberos entscheidet # Falsch gedacht, richtig gebaut – und trotzdem kaputt: portal.example.internal. CNAME knoten1.example.internal.   # Der Client fragt dann nach: HTTP/knoten1.example.internal <- nicht das, was registriert ist   # Richtig: A-Eintrag direkt auf die virtuelle Adresse portal.example.internal. A 10.20.30.40

 

TIPP Wenn der Alias politisch nicht verhandelbar ist Manchmal ist der CNAME gesetzt, dokumentiert, in dreißig Skripten verdrahtet und damit faktisch unantastbar. Dann gibt es zwei gangbare Wege. Erstens: den SPN zusätzlich für den kanonischen Zielnamen am selben Konto registrieren — solange dieser Zielname nicht der Computername eines Knotens ist, ist das sauber. Zweitens: per Richtlinie die Kanonisierung im Browser abschalten (bei Edge und Chrome heißt sie DisableAuthNegotiateCnameLookup). Der zweite Weg wirkt nur dort, wo die Richtlinie greift — er hilft also nicht bei Nicht-Windows-Clients, mobilen Geräten oder Anwendungen, die keinen Browser benutzen. Der erste Weg wirkt überall. Nehmen Sie den ersten.

 

Port, Schreibweise und andere Kleinigkeiten

Zwei Detailfragen kommen in jeder Diskussion auf, und beide lassen sich kurz beantworten. Die Schreibweise ist gleichgültig: Die Suche im Verzeichnis unterscheidet nicht zwischen Groß- und Kleinbuchstaben, HTTP/Portal und http/portal führen zum selben Ergebnis. Der Port dagegen ist eine Falle mit doppeltem Boden.

Windows-Browser hängen den Port standardmäßig nicht an den Dienstnamen an — auch dann nicht, wenn die Anwendung auf 8443 läuft. Ein SPN mit Portangabe wird deshalb in aller Regel schlicht nie gefragt. Wer trotzdem Ports im SPN führen möchte, muss das Verhalten der Clients explizit umstellen; in der Chromium-Familie über die Richtlinie EnableAuthNegotiatePort. Die pragmatische Empfehlung lautet: SPN ohne Port registrieren, und den Sonderfall nur dann bauen, wenn zwei verschiedene Dienste unter demselben Hostnamen auf verschiedenen Ports wirklich getrennte Identitäten brauchen.

FAKTEN Was in den SPN gehört und was nicht Registriert wird der Name, der in der Adresszeile steht — in der Regel gleich zweimal: als vollqualifizierter Name und als Kurzform, weil manche Anwendungen und viele Anwender nur die Kurzform benutzen. Nicht in den SPN gehören: IP-Adressen (Kerberos arbeitet mit Namen, nicht mit Adressen), Portangaben ohne zwingenden Grund, und vor allem nicht der Name eines einzelnen Knotens, wenn der Dienst über eine gemeinsame Adresse erreichbar sein soll.

 

Ein Name, ein Konto: Dienstkonto oder gMSA

Damit ist die Diagnose abgeschlossen und die Therapie bereits vorgezeichnet. Wenn der Client nach einem Namen fragt, den es nur einmal gibt, und das Ticket mit dem Schlüssel genau eines Kontos verschlüsselt wird, dann müssen alle Knoten diesen einen Schlüssel besitzen. Es gibt exakt einen Weg dorthin: Sie laufen alle unter demselben Konto.

Das Zielbild: Der Client fragt nach der Cluster-Adresse, der Domänencontroller findet genau ein Konto mit diesem SPN, und jeder Knoten hält denselben Langzeitschlüssel. Welchen Knoten der Balancer wählt, ist für Kerberos ab hier belanglos.

Warum das Computerkonto im Verbund ausscheidet

Auf einem Einzelserver ist die Welt bequem: Der Dienstname HTTP/servername hängt automatisch am Computerkonto, der Dienst läuft unter Netzwerkdienst oder Lokales System und benutzt damit ebenfalls den Schlüssel des Computerkontos. Niemand muss etwas tun, und genau deshalb weiß in vielen Häusern niemand, dass überhaupt etwas geschieht.

Im Verbund bricht dieser Automatismus zusammen, denn jeder Knoten hat sein eigenes Computerkonto mit eigenem Schlüssel. Der gemeinsame Name gehört aber nur einem davon — oder, noch schlimmer, allen. Die vier denkbaren Kontomodelle stehen in der folgenden Skizze nebeneinander; drei davon enden im Anmeldedialog.

Vier Wege, denselben Namen zu registrieren. Nur der vierte überlebt die Verteilung auf mehrere Knoten — und er ist zugleich der mit dem geringsten Betriebsaufwand.

Kontomodelle für eine Anwendung hinter einer gemeinsamen Adresse

Kontomodell	Kennwortpflege	Verhalten im Verbund	Empfehlung
Computerkonten der einzelnen Knoten	entfällt	Der Cluster-Name ist nirgends registriert; nur Direktaufrufe funktionieren	ungeeignet
Cluster-SPN an einem Computerkonto	entfällt	Funktioniert für die Anfragen, die zufällig auf diesem Knoten landen	ungeeignet
Cluster-SPN an mehreren Computerkonten	entfällt	Doppelter SPN; der Domänencontroller wählt eines der Konten aus	gefährlich
Klassisches Dienstkonto für alle Knoten	manuell, mit Wechselprozess und Neustartfenster	Funktioniert zuverlässig, solange das Kennwort gepflegt wird	brauchbar
Gruppenverwaltetes Dienstkonto (gMSA)	automatisch durch das Verzeichnis	Funktioniert zuverlässig; neue Knoten brauchen nur die Gruppenmitgliedschaft	erste Wahl

 

Der Weg zum gruppenverwalteten Dienstkonto

Ein gruppenverwaltetes Dienstkonto ist für genau diesen Fall gebaut: Mehrere Rechner dürfen dasselbe Konto benutzen, das Kennwort verwaltet das Verzeichnis selbst und wechselt es turnusmäßig, ohne dass jemand einen Wartungstermin dafür braucht. Voraussetzung ist ein Stammschlüssel im Verzeichnis; er wird einmal pro Gesamtstruktur angelegt und ist nach der Replikationswartezeit nutzbar.

Der Ablauf ist überschaubar. Eine Sicherheitsgruppe für die Knoten, das Konto selbst, die Zuordnung der SPNs, die Installation auf jedem Knoten und zum Schluss die Umstellung des Anwendungsprozesses. Wichtig ist nur die Reihenfolge: Erst wenn der Knoten Mitglied der Gruppe ist und diese Mitgliedschaft in seinem Kerberos-Ticket steht — was in der Praxis einen Neustart bedeutet —, kann er das Kennwort abrufen.

Einrichtung des gemeinsamen Kontos, PowerShell auf dem Verwaltungsrechner # 1) Stammschlüssel (einmalig je Gesamtstruktur) Add-KdsRootKey -EffectiveImmediately   # 2) Gruppe der Knoten, die das Konto benutzen dürfen New-ADGroup -Name 'GG-Portal-Knoten' -GroupScope Global Add-ADGroupMember -Identity 'GG-Portal-Knoten' -Members 'KNOTEN1$','KNOTEN2$','KNOTEN3$'   # 3) Das gMSA mit den SPNs der GEMEINSAMEN Adresse New-ADServiceAccount -Name 'svc-portal' ` -DNSHostName 'portal.example.internal' ` -PrincipalsAllowedToRetrieveManagedPassword 'GG-Portal-Knoten' ` -ServicePrincipalNames 'HTTP/portal.example.internal','HTTP/portal'   # 4) Auf JEDEM Knoten (nach Neustart, damit die Gruppe im Ticket steht) Install-ADServiceAccount -Identity 'svc-portal' Test-ADServiceAccount -Identity 'svc-portal'

 

Der vierte Schritt ist der, der am häufigsten vergessen wird — und zwar auf dem Knoten, der drei Monate später nachgerüstet wird. Dann funktioniert die Anwendung auf zwei von drei Knoten, und die Fehlersuche beginnt von vorn, diesmal mit der Zusatzhypothese, dass „der Balancer wohl kaputt“ sei.

WARNUNG Doppelte Dienstnamen sind kein Schönheitsfehler Ein SPN darf in der Gesamtstruktur nur einmal vorkommen. Existiert er zweimal, entscheidet die Reihenfolge der Verzeichnissuche, welches Konto den Zuschlag bekommt — und diese Reihenfolge ist weder dokumentiert noch stabil. Das Ergebnis ist ein Fehler, der wandert: heute auf Knoten zwei, morgen auf Knoten drei, nächste Woche nirgends. Vor jeder Registrierung prüfen und nach jeder Änderung nachsehen: setspn -X listet sämtliche Duplikate der Gesamtstruktur auf. Alte Einträge auf Computerkonten müssen dabei aktiv entfernt werden; sie verschwinden nicht von selbst, wenn man den neuen Eintrag am Dienstkonto anlegt.

 

Die vier setspn-Aufrufe, die man wirklich braucht setspn -X # alle Duplikate der Gesamtstruktur setspn -Q HTTP/portal.example.internal # wem gehört dieser Name? setspn -L svc-portal # was hängt an diesem Konto? setspn -D HTTP/portal.example.internal KNOTEN1$ # Altlast entfernen

 

Die IIS-Besonderheit: Kernelmodus und Anwendungspool-Anmeldedaten

Wer die Anwendung unter IIS betreibt, stolpert an dieser Stelle über eine Voreinstellung, die auf Einzelservern hilfreich und im Verbund tückisch ist. Die Windows-Authentifizierung läuft standardmäßig im Kernelmodus, und der Kernelmodus entschlüsselt das Ticket mit dem Schlüssel des Computerkontos — unabhängig davon, unter welchem Konto der Anwendungspool läuft.

Auf einem Einzelserver ist das genau richtig und sogar schneller. In unserem Aufbau ist es der Grund, warum die Umstellung des Anwendungspools auf das Dienstkonto scheinbar wirkungslos bleibt. Die Lösung heißt useAppPoolCredentials: Damit bleibt der Kernelmodus aktiv, aber die Entschlüsselung benutzt die Anmeldedaten des Anwendungspools. Microsoft rät ausdrücklich davon ab, den Kernelmodus stattdessen abzuschalten, wenn Kerberos mit einer eigenen Poolidentität im Spiel ist.

IIS: Kernelmodus behalten, aber die Poolidentität benutzen appcmd.exe set config "Portal" ^ -section:system.webServer/security/authentication/windowsAuthentication ^ /useKernelMode:"True" /commit:apphost   appcmd.exe set config "Portal" ^ -section:system.webServer/security/authentication/windowsAuthentication ^ /useAppPoolCredentials:"True" /commit:apphost   # Anwendungspool auf das gMSA umstellen (Kennwortfeld bleibt leer) Set-ItemProperty 'IIS:\AppPools\Portal' -Name processModel.identityType -Value 3 Set-ItemProperty 'IIS:\AppPools\Portal' -Name processModel.userName ` -Value 'EXAMPLE\svc-portal$'

 

WICHTIG Auf allen Knoten identisch — ohne Ausnahme Die Einstellungen aus diesem Abschnitt müssen auf jedem Knoten gleich sein. Ein einziger Knoten mit abweichender Poolidentität oder fehlendem useAppPoolCredentials erzeugt exakt das Fehlerbild, das am schwersten zu greifen ist: Es funktioniert für die meisten, aber nicht für alle, und niemand kann sagen, warum. Wer die Konfiguration über eine gemeinsame Konfigurationsfreigabe oder ein Automatisierungswerkzeug ausrollt, hat dieses Problem nicht. Wer sie von Hand pflegt, braucht eine Abnahmeliste — die steht weiter unten in diesem Beitrag.

 

Der Balancer selbst: durchreichen, terminieren oder anmelden

Bis hierher war der Balancer ein unbeteiligter Zuschauer. Das bleibt er, solange er sich auf das Verteilen von Verbindungen beschränkt. Sobald er TLS aufbricht oder gar selbst anmeldet, wird er zur Partei — und dann muss man ihn auch so konfigurieren.

Drei Betriebsarten mit drei sehr unterschiedlichen Rechnungen. Von oben nach unten steigt der Konfigurationsaufwand, und mit ihm die Zahl der Stellen, an denen die Anmeldung scheitern kann.

Ebene 4: der Balancer bleibt unsichtbar

Die einfachste und robusteste Variante: Der Balancer verteilt TCP-Verbindungen und sieht von der Anmeldung nichts. Das Ticket wandert unverändert bis zum Knoten, die TLS-Verbindung endet dort, und sämtliche Sicherheitsmerkmale bleiben intakt. Für Kerberos ist in dieser Betriebsart am Balancer nichts einzurichten — buchstäblich nichts. Die gesamte Arbeit steckt in der Kontoführung aus dem vorigen Abschnitt.

Wenn Sie die Wahl haben und keine zwingenden Gründe für Ebene 7 vorliegen — Inhaltsprüfung, Umschreiben von Adressen, zentrale Zertifikatsverwaltung —, nehmen Sie diese Variante. Sie hat den angenehmen Nebeneffekt, dass Kerberos-Fehler danach eindeutig im Verzeichnis oder auf den Knoten liegen und nicht mehr diskutiert werden muss, ob „vielleicht der Balancer etwas kaputt macht“.

Ebene 7 mit TLS-Terminierung: Host-Header und Kanalbindung

Terminiert der Balancer die TLS-Verbindung, entstehen zwei neue Fehlerquellen. Die erste ist der Host-Header. Ersetzt der Balancer beim Weiterleiten den Namen der Cluster-Adresse durch den Namen des Zielknotens — manche Produkte tun das in der Voreinstellung —, dann bekommt die Anwendung eine Anfrage, die aus ihrer Sicht an einen anderen Dienst gerichtet ist. Der Host-Header muss unverändert durchgereicht werden.

Die zweite ist der erweiterte Schutz der Authentifizierung. Er bindet die Anmeldung an den TLS-Kanal, über den sie läuft. Bricht der Balancer diesen Kanal auf und baut einen neuen zum Knoten, passt die Bindung nicht mehr, und die Anmeldung wird abgewiesen. Microsoft formuliert das für die eigenen Produkte unmissverständlich: Wer TLS am Balancer terminiert und nicht mit demselben Zertifikat zum Server neu verschlüsselt, kann den erweiterten Schutz nicht erzwingen.

Was jede Betriebsart für Kerberos bedeutet

Betriebsart	Was mit dem Ticket geschieht	Am Balancer einzurichten	Erweiterter Schutz
Ebene 4, reines Durchreichen	unverändert bis zum Knoten	nichts Kerberos-Spezifisches	uneingeschränkt möglich
Ebene 7, TLS beenden und neu verschlüsseln	unverändert, aber in neuem Kanal	Host-Header erhalten, gleiches Zertifikat verwenden	nur mit identischem Zertifikat, sonst abschalten
Ebene 7, TLS beenden, unverschlüsselt weiter	unverändert, aber im Klartext im Rechenzentrumsnetz	Host-Header erhalten; Weiterleitungsadressen prüfen	nicht möglich
Ebene 7 mit Vorab-Anmeldung	Der Proxy erzeugt ein neues Ticket im Namen des Anwenders	eigener SPN, eingeschränkte Delegierung auf das Zielkonto	am Proxy möglich, zum Knoten hin gesondert zu betrachten

 

WARNUNG Die Reihenfolge der Fehlersuche bei Ebene 7 Wenn eine Anwendung hinter einem terminierenden Balancer nicht anmeldet, prüfen Sie in dieser Reihenfolge: erstens den Host-Header, den der Knoten tatsächlich sieht; zweitens, ob der erweiterte Schutz auf dem Knoten erzwungen wird; drittens die Kontoführung. Der Grund für diese Reihenfolge ist unangenehm praktisch: Die ersten beiden Punkte sind in Minuten geprüft, der dritte zieht ein Änderungsverfahren im Verzeichnis nach sich. Man beantragt keine Verzeichnisänderung, solange eine Kopfzeile die Ursache sein kann.

 

Der Reverse Proxy als eigene Kerberos-Partei

Die dritte Betriebsart ist eine andere Welt. Hier meldet sich der Anwender nicht mehr bei der Anwendung an, sondern beim Proxy — über ein Formular, ein Zertifikat, einen Token aus der Cloud oder was auch immer vorne steht. Der Proxy besorgt sich anschließend im Namen des Anwenders ein Kerberos-Ticket für die interne Anwendung. Das ist eingeschränkte Delegierung, und damit sind wir beim Nachbarthema dieser Welle.

Die Modelle dahinter — von der uneingeschränkten Delegierung über die klassische eingeschränkte Variante bis zur ressourcenbasierten Delegierung — sind im Delegierungs-Spoke ausführlich beschrieben: /kerberos-delegierung-unconstrained-bis-rbcd. Hier nur die drei Punkte, die im Zusammenspiel mit einem Proxy regelmäßig schiefgehen.

Erstens braucht der Proxy ein eigenes Dienstkonto mit eigenem SPN — er ist ja selbst ein Dienst, bei dem sich jemand anmeldet. Zweitens muss die Delegierung auf das Konto zeigen, unter dem die Zielanwendung läuft, also auf unser gemeinsames Dienstkonto und nicht auf die Computerkonten der Knoten. Drittens gilt auch hier die Namensregel: Der Proxy fragt nach dem SPN der internen Adresse, und diese Adresse sollte im internen Verzeichnisdienst als A-Eintrag geführt sein.

Delegierung auf das gemeinsame Zielkonto, nicht auf die Knoten # Ressourcenbasierte Delegierung: die Zielseite entscheidet, wer delegieren darf Set-ADServiceAccount -Identity 'svc-portal' ` -PrincipalsAllowedToDelegateToAccount (Get-ADUser 'svc-proxy')   # Kontrolle – was steht jetzt am Zielkonto? Get-ADServiceAccount 'svc-portal' -Properties PrincipalsAllowedToDelegateToAccount | Select-Object -ExpandProperty PrincipalsAllowedToDelegateToAccount   # Klassische Variante am Proxy-Konto (msDS-AllowedToDelegateTo) Set-ADUser 'svc-proxy' -Add @{'msDS-AllowedToDelegateTo' = 'HTTP/portal.example.internal'}

 

TIPP Der Proxy verdeckt die Kontofrage nicht — er verdoppelt sie Ein verbreiteter Irrtum lautet: Wenn vorne ein Proxy mit Vorab-Anmeldung steht, braucht man sich um SPNs nicht mehr zu kümmern. Das Gegenteil ist der Fall. Der Anmeldevorgang wird zweigeteilt, und jede Hälfte hat ihre eigene Namens- und Kontofrage: der Proxy nach außen, die Anwendung nach innen. Der praktische Vorteil bleibt trotzdem beträchtlich: Nach außen ist keine Kerberos-Fähigkeit mehr nötig. Damit funktionieren auch Zugriffe von Geräten, die nicht in der Domäne sind — und das ist meist der eigentliche Grund, warum der Proxy überhaupt angeschafft wurde.

 

Sitzungsbindung: notwendig oder Aberglaube?

In jeder zweiten Diskussion taucht die Behauptung auf, Kerberos brauche Sitzungsbindung am Balancer. Das ist falsch, und der Irrtum hat eine erkennbare Quelle: Sitzungsbindung repariert das Symptom. Wenn der SPN nur an einem Knoten hängt und alle Anwender fest auf diesem Knoten landen, funktioniert die Anmeldung — bis dieser Knoten in Wartung geht.

Sauber konfiguriert ist jede Anfrage eigenständig authentifizierbar, und jeder Knoten kann jedes Ticket entschlüsseln. Sitzungsbindung kann aus Anwendungsgründen sinnvoll sein — Sitzungszustand im Arbeitsspeicher, Warenkörbe, Assistenten über mehrere Schritte. Für Kerberos ist sie es nicht. Wer sie als Kerberos-Maßnahme einführt, hat den Fehler nicht behoben, sondern nur verschoben, und zwar in das nächste Wartungsfenster.

Diagnose und Umsetzung in der Praxis

Die Theorie ist damit vollständig. Was fehlt, ist ein Ablauf, den man auch dann durchhält, wenn drei Personen gleichzeitig fragen, wann es wieder läuft. Die folgenden fünf Schritte sind in dieser Reihenfolge zu gehen — die Reihenfolge ist nicht dekorativ, sie sortiert nach Aufwand und nach Wahrscheinlichkeit.

Der Ablauf, der in der Praxis fast jeden Cluster-Fall auflöst. Vier von fünf Schritten laufen ohne Änderung an der Umgebung — man kann sie also auch im laufenden Betrieb gehen.

Vom Client aus

Der Ticket-Cache ist die ehrlichste Auskunftsstelle im ganzen Aufbau. Er zeigt, wonach der Client tatsächlich gefragt hat — nicht, was jemand vermutet. Wichtig ist das Leeren vor dem Test, sonst betrachtet man ein Ticket von gestern und wundert sich über widersprüchliche Ergebnisse.

Schritt 1 und 2: der Ticket-Cache des Clients klist purge # Cache leeren # jetzt die Anwendung im Browser aufrufen klist tickets # was wurde geholt?   # Erwartet: # Server: HTTP/portal.example.internal @ EXAMPLE.INTERNAL # Verdächtig: # Server: HTTP/knoten1.example.internal -> DNS hat kanonisiert # gar kein Eintrag -> KDC hat nichts gefunden

 

Im Verzeichnis

Zwei Fragen sind zu beantworten: Existiert der Name überhaupt, und existiert er genau einmal? Beide Antworten liefert setspn in Sekunden. Das Ergebnis „kein Treffer“ ist genauso ein Befund wie „zwei Treffer“ — nur die Therapie unterscheidet sich.

Schritt 3: Bestandsaufnahme im Verzeichnis setspn -Q HTTP/portal.example.internal setspn -Q HTTP/portal setspn -X | Select-String -Pattern 'portal'   # Und die Gegenprobe am Konto: setspn -L svc-portal

 

Auf dem Knoten

Bleibt die Frage, unter welchem Konto der annehmende Prozess wirklich läuft — und zwar auf jedem einzelnen Knoten, nicht auf dem, den man zufällig gerade offen hat. Das Systemprotokoll ist dabei überraschend gesprächig: Ereignis-ID 4 der Quelle Kerberos benennt den Konflikt beinahe im Klartext.

Schritt 4 und 5: Kontokontext und Protokoll # Kontokontext des Anwendungspools Import-Module WebAdministration Get-ChildItem IIS:\AppPools | Select-Object name, @{n='Identität';e={$_.processModel.userName}}   # Kerberos-Meldungen der letzten Tage Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kerberos-Key-Distribution-Center','Kerberos'} ` -MaxEvents 50 | Format-List TimeCreated, Id, Message

 

FAKTEN KRB_AP_ERR_MODIFIED übersetzt Die Meldung klingt nach Manipulation und bedeutet in neunundneunzig von hundert Fällen etwas viel Banaleres: Der Dienst konnte das Ticket nicht entschlüsseln, weil es mit dem Schlüssel eines anderen Kontos verschlüsselt wurde. Der Name war also richtig, das Konto war falsch. Häufigste Auslöser sind ein SPN am Computerkonto statt am Dienstkonto, ein Duplikat in der Gesamtstruktur oder ein Kennwortwechsel des Dienstkontos, der auf einem Knoten nicht angekommen ist. Der dritte Auslöser entfällt vollständig, wenn Sie ein gruppenverwaltetes Dienstkonto einsetzen.

 

Ein anonymisiertes Beispiel aus der Praxis

Ein mittelständisches Fertigungsunternehmen, rund viertausend Arbeitsplätze, betreibt ein internes Bestellportal. Ursprünglich ein Server, seit einer Erweiterung drei Knoten hinter einer virtuellen Adresse. Nach der Erweiterung meldeten etwa zwei Drittel der Belegschaft eine Kennwortabfrage. Der Betrieb vermutete den Balancer, der Hersteller vermutete das Verzeichnis, und nach zwei Wochen vermuteten alle einander.

Der Befund war in zwanzig Minuten erhoben. Bei der Erweiterung war der SPN der Cluster-Adresse am Computerkonto des ersten Knotens registriert worden — dort, wo die Anwendung ursprünglich allein lief. Zwei Drittel der Anfragen landeten auf den beiden anderen Knoten und scheiterten. Die Sitzungsbindung, die man als Sofortmaßnahme eingeschaltet hatte, verbesserte die Lage genau so lange, bis der erste Knoten neu startete.

Die Bereinigung bestand aus vier Schritten: gruppenverwaltetes Dienstkonto anlegen, SPNs vom Computerkonto entfernen und am Dienstkonto registrieren, Anwendungspools auf allen drei Knoten umstellen und useAppPoolCredentials setzen. Umsetzungsdauer im Wartungsfenster: knapp eine Stunde, davon vierzig Minuten Wartezeit auf die Replikation. Nachgelagert wurde die Sitzungsbindung wieder entfernt, weil sie nie ein Kerberos-Thema war.

Die Abnahmeliste für jeden neuen Knoten

Der Fall aus dem vorigen Abschnitt ist deshalb so lehrreich, weil er nicht bei der Erstinstallation entstand, sondern bei einer Erweiterung. Genau dort entsteht er fast immer. Eine kurze Liste, die beim Hinzufügen eines Knotens abgehakt wird, verhindert die Wiederholung zuverlässiger als jede Dokumentation.

Der Knoten ist Mitglied der Gruppe, die das Dienstkonto abrufen darf — und er wurde danach neu gestartet.

Test-ADServiceAccount liefert auf diesem Knoten „Wahr“.

Der Anwendungsprozess läuft unter demselben Konto wie auf den anderen Knoten.

useAppPoolCredentials ist gesetzt, der Kernelmodus bleibt aktiv.

Am Computerkonto des neuen Knotens ist kein SPN der Cluster-Adresse registriert.

setspn -X meldet für die Cluster-Adresse kein Duplikat.

Testaufruf über die Cluster-Adresse; klist zeigt ein Ticket für den Cluster-SPN.

Der Balancer reicht den Host-Header unverändert weiter.

Wann diese Liste erneut abgearbeitet werden muss

Auslöser	Was danach zu prüfen ist	Aufwand
Neuer Knoten im Verbund	Gruppenmitgliedschaft, Kontokontext, kein SPN am Computerkonto	10 Minuten
Neue Cluster-Adresse oder neuer Alias	SPN am Dienstkonto ergänzen, DNS auf A-Eintrag prüfen	20 Minuten plus Replikation
Wechsel des Dienstkontos	SPNs umhängen, alte Registrierung entfernen, alle Knoten umstellen	Wartungsfenster
Balancer wird auf Terminierung umgestellt	Host-Header, Zertifikat, erweiterter Schutz	1 Stunde mit Test
Reverse Proxy wird vorgeschaltet	eigener SPN für den Proxy, Delegierung auf das Zielkonto	halber Tag

 

Häufige Fragen

Muss ich für jeden Knoten einen eigenen SPN setzen?

Nein — und genau dieser Reflex ist die häufigste Fehlerquelle. Der Client fragt nie nach dem Knotennamen, sondern nach dem Namen aus der Adresszeile. Für den Betrieb über die Cluster-Adresse braucht es einen einzigen SPN an einem einzigen Konto. SPNs für die Knotennamen sind höchstens für die Administration nützlich, und dafür bringt jedes Computerkonto seine eigenen bereits mit.

Kann ich denselben SPN nicht einfach an alle Computerkonten hängen?

Technisch lässt sich das eintragen, funktional ist es ein Duplikat, und Duplikate sind in Kerberos kein Kompromiss, sondern ein Defekt. Der Domänencontroller wählt eines der Konten aus, ohne dass Sie die Wahl beeinflussen können. Das Ergebnis ist ein Fehler, der zwischen den Knoten wandert — die unangenehmste aller Varianten, weil sie sich nicht reproduzieren lässt.

Brauche ich Sitzungsbindung am Balancer, damit Kerberos funktioniert?

Nein. Sauber konfiguriert ist jede Anfrage eigenständig authentifizierbar. Sitzungsbindung kann aus Anwendungsgründen nötig sein, etwa bei Sitzungszustand im Arbeitsspeicher. Als Kerberos-Maßnahme verdeckt sie nur, dass die Kontoführung nicht stimmt.

Muss der Port im SPN stehen?

In der Regel nicht. Windows-Browser hängen den Port standardmäßig nicht an den Dienstnamen an, auch bei abweichenden Ports nicht. Ein SPN mit Portangabe wird deshalb meist schlicht nie angefragt. Wer Ports wirklich braucht, muss zusätzlich das Clientverhalten umstellen — und sollte sich vorher fragen, ob der Aufwand den Nutzen trägt.

CNAME oder A-Eintrag für die Cluster-Adresse?

A-Eintrag. Ein Alias führt dazu, dass der Client den kanonischen Zielnamen für den SPN verwendet, und der zeigt typischerweise auf einen einzelnen Knoten oder auf das Gerät des Balancer-Herstellers. Wenn der Alias unvermeidbar ist, registrieren Sie den kanonischen Namen zusätzlich am selben Dienstkonto.

Wie merke ich, dass die Anmeldung in Wahrheit über NTLM läuft?

Am schnellsten über den Ticket-Cache: Kein Service-Ticket für den Namen der Anwendung, aber die Anwendung funktioniert — dann läuft es über NTLM. Der zweite Weg führt über die Anmeldeprotokolle des Servers, in denen das verwendete Authentifizierungspaket steht.

Reicht ein gruppenverwaltetes Dienstkonto, oder brauche ich ein klassisches?

Für diesen Anwendungsfall ist das gruppenverwaltete Konto die bessere Wahl: Es darf von mehreren Rechnern benutzt werden, das Verzeichnis wechselt das Kennwort selbstständig, und niemand muss ein Kennwort kennen. Ein klassisches Dienstkonto bleibt nur dann übrig, wenn eine Anwendung ausdrücklich keine verwalteten Konten unterstützt — das kommt vor, wird aber seltener.

Was ändert sich, wenn der Balancer TLS terminiert?

Zwei Dinge. Der Host-Header muss unverändert weitergereicht werden, sonst ändert sich der Dienstname, nach dem gefragt wird. Und der erweiterte Schutz der Authentifizierung lässt sich nicht mehr erzwingen, sofern nicht mit demselben Zertifikat zum Knoten neu verschlüsselt wird.

Wir haben einen Reverse Proxy mit Vorab-Anmeldung. Brauche ich dann noch SPNs?

Ja, sogar zwei Ebenen davon: einen für den Proxy selbst und einen für die interne Anwendung, auf den der Proxy delegiert. Der Vorteil liegt woanders — nach außen ist keine Kerberos-Fähigkeit des Clients mehr nötig, was Zugriffe von Geräten außerhalb der Domäne erst möglich macht.

Wie schnell wirkt eine SPN-Änderung?

Der Eintrag ist sofort geschrieben, muss aber repliziert werden, und die Clients halten ihre Tickets bis zum Ablauf. Für einen belastbaren Test also: Replikation abwarten, dann klist purge auf dem Testrechner, dann erneut aufrufen. Wer diesen Zwischenschritt überspringt, misst die Vergangenheit und zieht daraus falsche Schlüsse.

Gilt das alles auch für andere Dienste als Webanwendungen?

Im Kern ja. Ob Datenbank hinter einem Verfügbarkeitslistener, Dateidienst hinter einem Clusternamen oder Anwendungsserver hinter einer virtuellen Adresse — die Regel bleibt identisch: Der Name, unter dem der Dienst angesprochen wird, muss als SPN an genau dem Konto hängen, unter dem der Dienst auf allen Knoten läuft. Nur die Dienstklasse und die Werkzeuge zur Prüfung unterscheiden sich.

Fazit

Kerberos hinter einem Load Balancer ist kein schwieriges Thema. Es ist ein Thema, das an einer unerwarteten Stelle entschieden wird. Wer erwartet, dass die Anmeldung dort konfiguriert wird, wo der Verkehr verteilt wird, sucht tagelang am falschen Ort — und findet dabei erstaunlich viele Dinge, die zwar interessant, aber nicht ursächlich sind.

Drei Sätze tragen den ganzen Beitrag. Der Client bildet den Dienstnamen aus dem Namen in der Adresszeile, nicht aus dem realen Zielserver. Dieser Dienstname muss an genau einem Konto hängen. Und alle Knoten müssen unter diesem einen Konto laufen, damit jeder von ihnen das Ticket entschlüsseln kann. Alles Weitere — Betriebsart des Balancers, Kanalbindung, Delegierung an einem vorgeschalteten Proxy — ist Detailarbeit, die auf diesem Fundament aufsetzt.

Für die Umsetzung heißt das: ein gruppenverwaltetes Dienstkonto, ein A-Eintrag auf die virtuelle Adresse, die SPNs für den vollqualifizierten Namen und die Kurzform an diesem Konto, identische Konfiguration auf allen Knoten und eine Abnahmeliste für jeden weiteren Knoten. Das ist eine Stunde Arbeit bei der Einrichtung und zehn Minuten bei jeder Erweiterung.

Die Alternative kostet erfahrungsgemäß zwei Wochen — verteilt auf mehrere Abteilungen, mehrere Hersteller und mindestens ein Wochenende. Der Unterschied zwischen beiden Wegen ist nicht Fachwissen, sondern der Zeitpunkt, zu dem jemand die richtige Frage stellt: Nach welchem Namen fragt der Client eigentlich, und wem gehört dieser Name?

Weiterlesen in dieser Serie: /microsoft-kerberos als Überblick, /spns-richtig-setzen-setspn für die Arbeit mit Dienstnamen, /kerberos-tickets-tgt-und-service-ticket für die Ticketmechanik und /kerberos-delegierung-unconstrained-bis-rbcd für alles, was hinter einem vorgeschalteten Proxy passiert.

Quellen

Microsoft Community Hub (AskDS) — Kerberos and Load Balancing — https://techcommunity.microsoft.com/blog/askds/kerberos-and-load-balancing/399539

Microsoft Community Hub — Service Principal Name (SPN) checklist for Kerberos authentication with IIS — https://techcommunity.microsoft.com/blog/iis-support-blog/service-principal-name-spn-checklist-for-kerberos-authentication-with-iis-7-07-5/347639

Microsoft Learn — Windows Authentication <windowsAuthentication> (useKernelMode) — https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/windowsauthentication/

Microsoft Learn — Windows Extended Protection <extendedProtection> — https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/windowsauthentication/extendedprotection/

Microsoft Learn — Group Managed Service Accounts Overview — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/group-managed-service-accounts-overview

Microsoft Learn — Manage Group Managed Service Accounts — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/manage-group-managed-service-accounts

Microsoft Learn — Service Principal Names — https://learn.microsoft.com/en-us/windows/win32/ad/service-principal-names

Microsoft Learn — Troubleshoot Kerberos failures in Internet Information Services — https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/www-authentication-authorization/troubleshoot-kerberos-failures-ie

Microsoft Learn — Kerberos SPN is on wrong account (Ereignis 4, KRB_AP_ERR_MODIFIED) — https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-event-4-access-denied

Microsoft Learn — Kerberos Constrained Delegation for single sign-on with application proxy — https://learn.microsoft.com/en-us/entra/identity/app-proxy/how-to-configure-sso-with-kcd

Microsoft Learn — Troubleshoot Kerberos constrained delegation — https://learn.microsoft.com/en-us/entra/identity/app-proxy/application-proxy-back-end-kerberos-constrained-delegation-how-to

Microsoft Learn — Microsoft Edge Policy: DisableAuthNegotiateCnameLookup — https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/disableauthnegotiatecnamelookup

Microsoft Learn — Microsoft Edge Policy: EnableAuthNegotiatePort — https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/enableauthnegotiateport

The Chromium Projects — HTTP Authentication (Bildung des SPN) — https://www.chromium.org/developers/design-documents/http-authentication/

RFC 4559 — SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows — https://www.rfc-editor.org/rfc/rfc4559.html

RFC 4120 — The Kerberos Network Authentication Service (V5) — https://www.rfc-editor.org/rfc/rfc4120.html