Kerberos Einstellung SpnCacheTimeout für UNIX Kompatibilität

Hallo, nach langer Abstinenz hier mal wieder Andy mit einem Erfahrungsbericht, wie schnell man in scheinbar unerklärliche Probleme laufen kann. Meine Geschichte handelt von den kleinen aber feinen Unterschied bei der Interpretation von Standards.

Ein Kunde hat folgendes Szenario. Ein Active Directory mit Windows Server 2008 (Windows Server 2003/2008 spielt hier keine Rolle) Weiterhin hat er eine Kerberos Realm Trust mit einem UNIX Systemen und einer Web Applikation die Single-Sign-On unterstützt. Will ein Benutzer diese Web Applikation nutzen lief die Authentifizierung folgender maßen ab:

1. Der Windows User kontaktiert den Windows Domain Controller um ein Ticket für die Web Applikation zu erhalten.
2. Der Domain Controller ist jedoch nicht autoritativ für den Kerberos Realm dieser Applikation, da die Applikation im UNIX REALM liegt. Aber der DC gibt ein Referral Ticket zurück.
3. Durch das Referral Ticket wendet sich nun der Anwender von seinem Windows XP Client zu dem UNIX KDC und fordert ein TGS Ticket für diesen Service an.
4. Der UNIX KDC stellt ein Ticket aus, mit dem der Anwender sich an der Applikation authentifizieren kann.

Dieses Konstrukt lief problemlos. Im Rahmen der Konsolidierung kam jedoch die Entscheidung die Applikation über einen Terminal Server zu nutzen und im Jahr 2011 ist die Wahl auf einen Windows Server 2008 R2 gefallen.

Ein erster Versuch zeigte das dies auch mit Windows Server 2008R2 funktioniert. Jedoch ist nun folgendes aufgefallen: Hat ein Anwender die Applikation gestartet, konnte kein weiterer Anwender die Applikation starten. Nach einer Wartezeit von 15 Minuten konnte wieder ein Anwender die Applikation starten, alle anderen blieben außen vor. Was natürlich zu einer gewissen Unzufriedenheit bei den Anwendern sorgte. Da die Anwender die Applikation nur im 15 Minuten Abstand starten konnten.

Nach einigen Analysen und dem Durchforsten von Network und ETL Traces sind wir zu folgenden Auffälligkeit gekommen (leider steht die Auswertung des ETL Loggings nur Microsoft intern zur Verfügung).
Fordert der Anwender sein Ticket frisch an, wird der REALM des SPNs im Referral Tickt in Großbuchstaben angegeben.  Im schlechten Fall wurde der SPN in Kleinbuchstaben angegeben. Für Windows macht dies keinen Unterschied, weil wir Groß/Kleinschreibung ignorieren.
Viele UNIX System sind da etwas zickiger und erwarten den REALM in Großbuchstaben. Somit war klar:
Ist der KDC ein Windows System entsteht kein Problem mit UNIX Systemen schon.

Aber wieso hat es immer einmal funktioniert und beim nachfolgenden Versuch nicht? Wieso funktioniert die Anmeldung nach 15 Minuten genau einmal? Und wieso tritt das Problem mit Windows Server 2008 auf und nicht mit XP?

Die Lösung:  SPN Cache und dessen Timeout

Um den Netzwerkverkehr damit die Authentifizierungslast zu reduzieren gibt es den SPN Cache. Wird der SPN aus dem Cache gelesen, wird der REALM Name in Kleinbuchstaben angegeben. Ist der SPN jedoch im Cache nicht vorhanden, wird der REALM in Großbuchstaben angegeben.
Also war die Lösung des Problems: Deaktivieren des SPN Cache was mit folgendem Registry Parameter erfolgt:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
SpnCacheTimeout=0x0

Somit wird jedes mal der KDC für den angegeben REALM neu abgefragt. Was aber nur eine minimal Belastung oder Erhöhung des Netzwerk Verkehr nach sich zieht.

Die Referenz zu der Einstellung finden wir im Artikel 837361 “ Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003”; https://support.microsoft.com/default.aspx?scid=kb;EN-US;837361
(Das ist natürlich keine Aufforderung, jetzt bei Kerberos Problemen einfach drauf los zu konfigurieren.)

Dass das Problem unter Windows XP nicht aufgetreten ist sondern erst mit Windows Server 2008R2 hing damit zusammen, dass die Applikation von einem Terminal Server aufgerufen wurde. Auf den Windows XP Clients wurde die Applikation nur einmal gestartet. Hier brachte der Cache nichts, wenn die Applikation nicht innerhalb von 15 Minuten neu gestartet wurde. Auf dem Terminal Server war die Situation natürlich eine ganz andere hier wurde die Applikation innerhalb von wenigen Minuten x-fach gestartet was zu diesem Problem führte. Obwohl sich Windows XP und Windows Server 2008 gleich verhalten haben, war die Auswirkung eine ganz andere. Als Software Problem wollte der Kunde das Thema nicht weiter verfolgen.

Als Fazit lässt sich sagen: Wenn ihr einen UNIX KDC einsetzt, schaltet den SPN Cache auf den Clients ab, gerade wenn es sich hierbei um Terminal Server handelt. Das hilft ganz besonders bei Fehlern die nur Zeitweise auftreten.

Euer Andy