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
  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 abgeschaltet

Im Internet Explorer muss global iengeschaltet sein, dass WIA genutzt wird

IE

Zonen

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 AuthServerWhitelist *.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

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:

  • Internet Zone
    Hier landen eigentlich alle URL, wenn sie einen "Punkt" im Namen haben oder über einen Proxy gehen. An diese Hosts sendet der IE per Default nie ein Ticket oder Kennwort. Das macht so auch absolut Sinn.
  • Intranet Zone
    Hier landen alle URLs, die als "intern" gelten, d.h. kurze Hostnamen ohne Punkt oder Systeme, die nicht über den Proxy erreicht werden.

    Allerdings muss natürlich die Proxy-Konfiguration entsprechend eingestellt sein, z.B. dass "*.internedomain.tld" eben nicht über den Proxy geht. Ansonsten landen auch interne voll qualifizierte Namen auf der Internet Liste. Die Pflege von manuellen Listen ist möglich, aber kann letztlich dazu führen, dass ein Anwender auch von zu Hause dann die Firmen-URLs als "trusted" ansieht, obwohl er gar nicht auf dem Server landet. Insofern ist der SSL-Zwang hier eigentlich ratsam.
    An Hosts dieser Zone sendet der IE per Default auch ein Kerberos Ticket
  • "Vertrauenswürdige Hosts"
    Für diese Zone erlaubt der Browser eine niedrigere Sicherheit aber per Default keine automatische Anmeldung. Dies kann aber in den Zoneneinstellungen angepasst werden.
  • Eingeschränkte Sites
    Eigentlich klar, dass hier keine automatische Anmeldung unterstützt wird.

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:

  • 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