Kerberos mit Browsern

Wenn nun ein Webserver für Kerberos eingerichtet ist, dann wird er eine anonyme Anfrage eines Browsers erst einmal mit einem 401-Fehler quittieren und als Authentication "Negotiate" anbieten. Der Client muss sich dann ein passendes Ticket besorgen und die Anfrage erneut stellen. Auch hier kann einiges "schief" gehen.

Browser Einstellung Verhalten  
IE NTLM abgeschaltet Mit Kerbtray und Netmon kann man sehen, dass der Client kein Ticket anfordert oder bekommt.
IE Zonen "401 Fehlemeldung" im Browser, dass die Anmeldung nicht erfolgreich war.
Wenn der Browser auch noch Basic oder NTLM anbietet, dann kommt alternativ ein Anmeldefenster.
Firefox Windows Anmeldung geht nicht da Firefox per Default keinen Reals traut. Firefox  über „about.config“ einstellen:
network.negotiate-auth.trusted-uris = Liste der Domains
network.auth.use-sspi = true  (default)

Die Einstellungen stehen auch in den PREFS-Dateien und können per Skript geändert werden.

Andere Browser haben ich noch nicht getestet

Internet Explorer und Zoneneinstellungen

Im vorherigen Abschnitt haben Sie ja schon gesehen, dass der IE einige Überraschungen in der Konfiguration bereit halten kann. Aber selbst wenn dort alles richtig eingestellt ist, kann es derart zu Problemen kommen, das der Browser die URL, bzw. den Hostnamen der URL, nicht in die richtige Zone einordnet. Da gibt es gleich mehrere:

Unangenehm ist teilweise, dass die Einstufung in die Zone in der Fußleister erst aktualisiert wird, wenn Sie die Anfrage (auch fehlerhaft) abgeschlossen haben. Wenn ihr Browser also ein Fallback auf NTLM/Basic macht und einen Kennwortdialog anzeigt, dann ist die Anzeige der Fußzeile meist noch falsch.

Kerberos und gespeicherte Kennworte

Bei einem Supporteinsatzes bin ich auf ein seltsames Kerberos-Problem gestoßen. Nachdem Alles auf dem Webserver und Clients korrekt eingerichtet wurde, konnte ein Anwender von seinem PC trotzdem nicht per Kerberos sich am Webserver anmelden. Mit NetMon3 haben wir nachgewiesen, das der Client sich weiterhin per NTLM anmeldet und nicht mal versucht, sich ein Kerberos Ticket zu besorgen. Kerbtray hat kein Ticket angezeigt. Aufgefallen ist dies wieder nur mal aufgrund des "Double Hop"-Problems. Ein anderer Benutzer auf dem gleichen Computer konnte allerdinge arbeiten und der Benutzer selbst konnte auf einem zweiten Computer auch arbeiten. Es musste also etwas im "Profil" des Benutzers sein.

Alle Suche in HKeyCurrent_User, Internet Explorer Einstellungen etc. waren nicht von erfolg gekrönt. Wurde das Benutzerprofil aber neu angelegt, dann funktionierte die Anmeldung per Kerberos. Erst als wir dann Verzeichnis für Verzeichnis aus dem alten Profil kopiert haben, und es plötzlich nicht mehr ging, sind wie dem Problem auf die Schliche gekommen:

In der Vergangenheit muss es einen Zeitpunkt gegeben haben, an der Kerberos noch nicht funktioniert hat, (z.B. weil der SPN nicht auf das Dienstkonto der Application zugewiesen war). Der Anwender wurde dann vom Browser nach Benutzername/Kennwort gefragt und hier hat der Anwender seine Daten eingegeben UND "Kennwort speichern" gesagt. Und seit dem hat der IE immer nur noch dieses Kennwort per NTLM übermittelt. Die Lösung war dann einfach: Über die Systemsteuerung - Benutzerkonten wurde das gespeicherte Kennwort wieder entfernt.

Danach forderte der IE auch wieder ein Kerberos Token für diese Ressource beim KDC an, übergab sie an den Webserver und die Applikation konnte mit den Berechtigungen des Benutzers auf einen nachgelagerten SQL-Server zugreifen.

Mit dem Programm CMDKEY (Windows 2003 Server, Vista und höher) können Sie per Kommandozeile diese Kennworte pflegen. Die Version aus Windows 2003 funktioniert auch mit Windows XP !

C:>cmdkey

Erstellt, löscht und zeigt gespeicherte Benutzernamen und Kennwörter an.

Die Syntax des Befehls lautet:

CMDKEY [{/add | /generic}:Zielname
        {/smartcard | /user:Benutzername
       {/pass{:Kennwort}}} |
       /delete{:Zielname | /ras /list{:Zielname}]

Beispiele:

  Auflisten verfügbarer Anmeldeinformationen:
     cmdkey /list
     cmdkey /list:Zielname

  Erstellen von Domänenanmeldeinformationen:
     cmdkey /add:Zielname /user:Benutzername /pass:Kennwort
     cmdkey /add:Zielname /user:Benutzername /pass
     cmdkey /add:Zielname /user:Benutzername
     cmdkey /add:Zielname /smartcard

  Erstellen generischer Anmeldeinformationen:
     Der Schalter /add kann durch /generic ersetzt werden, um generische
     Anmeldeinformationen zu erstellen.

  Löschen vorhandener Anmeldeinformationen:
     cmdkey /delete:Zielname

  Löschen von RAS-Anmeldeinformationen:
     cmdkey /delete /ras

SPN und Kerberos und DNS mit CNAME

Ein weiteres Problem kann sich in der Namensauflösung verbergen. Wenn Sie in ihrem Browser eine URL eingeben, und der Browser nicht über einen Proxy geht, dann versucht der Browser den Hostnamen der URL über DNS aufzulösen. Hierbei gibt es zwei Optionen, wie der Name per DNS zurück kommen kann:

msxfaq.de    SOA
webserver    A    10.10.10.10
msxfaq.de    SOA

msxfaq.de    SOA
webserver    CNAME server1.msxfaq.de
server1        A    10.10.10.10
msxfaq.de    SOA

Bei einigen Versionen von Browsern und Betriebssystemen kann dies aber dazu führen, dass der Browser zwar den Alias in der Adressleiste anzeigt aber intern auf den echten Hostnamen (Hier also server1.msxfaq.de) zugreift und natürlich auch ein Kerberos-Ticket für diesen Namen anfordert.

Sehr oft funktioniert das sogar, wenn die angesprochene Applikation dann auch als "Local System" läuft und Zugriff auf die Schlüssel hat. Wenn Sie aber mehrere Server hinter einem Namen betreiben (z.B. NLB) oder ein Dienstkonto mit einem eigenen Applikationpool einsetzen, dann funktioniert dies nicht mehr. Wenn der Host selbst z.B. kein Windows-Host ist, dann kann er seinen Host-SPN gar nicht selbst eintragen und der Client bekommt kein Ticket für diesen SPN. Als Workaround kann man auch den Host-SPN natürlich addieren.

Ich rate hier aber besser zu weiteren A-Records, die eben auf die gleiche IP-Adresse verweisen. Ein PTR-Eintrag verweist dann natürlich wieder auf den richtigen Host oder den Namen der virtuellen IP-Adresse.

Wenn der Webserver Kerberos nicht allein erzwingt, sondern auch noch andere Anmeldeverfahren anbietet, dann können Sie bei so einem Fehler oft im Anmeldefenster den REALM lesen, für den der Browser versucht hat ein Ticket zu bekommen.

Kerberos mit Proxy

Direkt in das Thema mit DNS fällt auch die Verbindung zu einem Webserver über einen HTTP-Proxy. Hier verbindet sich der Browser ja nicht direkt mit dem Webserver, sondern geht über einen Proxy-Server. Der Browser "weiss" also gar nicht, ob der angesprochene Name nun über einen CNAME oder A-Record aufgelöst wird. Insofern kann der Browser sich also nur ein Ticket für den Hostnamen besorgen, welches er dann über den Proxy weiter gibt. Die Problematik mit dem CNAME bei einer direkten Verbindung tritt hier also nicht auf. Allerdings kann hier dann wieder die Einstufung der "Zonen" im Internet Explorer stören, dass das Ziel als "Internet" angesehen wird und daher überhaupt keine integrierte Anmeldung versucht wird..

Kurze Hostnamen (Netbios-Name statt FQDN)

Ist es ein Unterschied zwischen http://hostname und http://hostname.domain.tld ? Ja, es ist ein großer Unterschied, da für kurze Namen anscheinend kein Kerberos Request generieren bzw. ein SPN in der Form "http/hostname" wird anscheinend nicht gefunden. Erst wenn ich einen "http/hostname.meinedomain.tld" als SPN addiert habe, hat der Client auch ein Ticket für diesen Host bekommen, nachdem er danach gefragt hat. Es scheint aber wirklich so zu sein, dass der Internet Explorer beim Zugriff auf "kurze Hostnamen" kein Kerberos Ticket nachfragt.

Eine Bestätigung habe ich dazu noch nicht, aber sie sollten parallel immer auch mal den Zugriff per FQDN versuchen.

Weitere Links

Keywords:Kerberos Browser