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übersicht gegen Webserver

Es wäre Wunschdenken, wenn alle Firmen immer nur den Internet Explorer auf Windows einsetzen würden. Die Welt kennt durchaus weitere Browser und Betriebssysteme, die sich für den Zugriff auf Webseiten eignen. Auch Clientprogramme wie Outlook, SMB-Zugriffe etc. können Kerberos nutzen.

Mit Office 365 ist diese Funktion für die Anmeldung am ADFS-Server besonders wichtig um dem Anwender die mehrfache Eingaben der Anmeldedaten zu ersparen. Beachten Sie dazu aber die Seite ADFS Authentication.

Ich habe einen IIS unter Windows 2012 installiert, auf dem mehrere Testdateien (ntlm.htm, basic.htm, anon.htm, kerb.htm) angelegt mit mit der entsprechenden Authentifizierung versehen wurden. Dann habe ich den Browser auf den Clients gestartet und die Dateien abgerufen. Die Clients sind alle in die Domäne eingebunden und der Anwender als Domänenbenutzer angemeldet.

Browser Windows MacOS 10.8+ Linux
Internet Explorer

Ja, Hinweis 1

entfällt

entfällt
Chrome

Ja

Ja, Hinweis 3

noch nicht getestet
FireFox

Ja, Hinweis 2

Ja, Hinweis 2

noch nicht getestet
Safari

Ja

Ja

noch nicht getestet
Opera

noch nicht getestet

noch nicht getestet

noch nicht getestet

Interessant ist, dass sehr viele Browser mit wenigen Konfigurationseinstellungen auf verschiedenen Betriebssystemen direkt mit einem Windows KDC zusammen arbeiten können.

Die Hinweise bedeuten:

  1. Die URL des Servers muss in der Intranet-Zone sein. Siehe auch IE Zonen
  2. Die Domains bzw. Hosts müssen in about:config network.negotiate-auth.trusted-uris eingetragen werden.
  3. Auf dem Mac muss die Domain oder der Host erst zugelassen werden.

Erinnern Sie sich aber daran, dass der angesprochene Hostname in der URL natürlich im Active Directory als ServicePrincipalName an einen Computer oder Dienstkonto gebunden wurde. Ansonsten kann der Client zwar den KDC fragen aber bekommt keine Antwort. Dazu gehört natürlich, dass der angesprochene Dienste Kerberos-Tickets verarbeiten kann und dem Client auch "Negotiate" anbietet. So können Sie sehr viele Dienste auch für "Nicht IE-Browser" im Intranet mit einem Single-SignOn versehen.

Anpassungen je Browser

Passend zu den den Anmerkungen bei der Tabelle der Browser hier die entsprechenden Fenster:

Browser Einstellung  

IE

NTLM eingeschaltet und richtige Zone aktiv

Im Internet Explorer muss global eingeschaltet sein, dass WIA genutzt wird und die Zielseite muss natürlich in einer Zone sein, für die die automatische Anmeldung aktiv ist.

Firefox

Windows

Anmeldung geht nicht da Firefox per Default keinen Reals traut. Dies kann über die „about.config“ eingestellt werden

network.negotiate-auth.trusted-uris = Liste der Domains (Kommagetrennt)
network.auth.use-sspi = true  (default)

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

Safari

Mac

Wenn der Mac mit dem AD gekoppelt ist, kann kann der Safari auch Kerberos-Tickets nachfragen und senden. Er nimmt dabei auch keine Rücksicht auf "Zonen" etc. Solange im AD ein passender SPN gefunden wird, ist das alles in bereit.

Chrome

Mac

Die Zielhosts oder Domains müssen eingetragen werden,

defaults write com.google.Chrome AuthServerAllowlist *.msxfaq.net

Mehrere Einträge können durch komme getrennt werden. Es sind aber keine Anführungsstriche erforderlich, wie dies in einigen Blogs aufgeführt wird.

Andere Browser haben ich noch nicht getestet.

  • Authentication uses NTLM instead of Kerberos
    http://technet.microsoft.com/en-us/library/cc779070.aspx
  • 299838 unable to negotiate Kerberos authentication after upgrading to Internet Explorer 6
  • 299270 Kerberos Does Not Negotiate using Internet Explorer 5.5 If an FQDN Is used to Connect
  • 908209 Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003

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 HKeyCurrentUser, 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:

  • A-Record
    d.h. der Hostname wird direkt auf eine IP-Adresse aufgelöst wie im folgenden Beispiel:
msxfaq.de    SOA
webserver    A    10.10.10.10
msxfaq.de    SOA
  • CNAME
    Viele Administratoren nutzen aber als A-Record den echten Servernamen und tragen einfach einen Alias für den Hostnamen der URL ein wie im folgenden Beispiel:
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.

Mein Rat: Verzichten Sie auf CNAME in Verbindung mit Kerberos, wenn mehrere Server z.B. durch einen Loadbalancer unter einem Namen erreichbar sind und nutzen Sie einen A-Record, der auch so im SPN erscheint.
Ein CNAME ist dann besser, wenn ein Server unter einem anderen (virtuellen) Namen erreicht werden soll und Kerberos erwünscht ist.

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