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 |
![]() |
![]() |
![]() |
---|---|---|---|
![]() |
|
|
|
![]() |
|
|
|
![]() |
|
|
|
![]() |
|
|
|
![]() |
|
|
|
Interessant ist, dass sehr viele Browser mit wenigen Konfigurationseinstellungen auf verschiedenen Betriebssystemen direkt mit einem Windows KDC zusammen arbeiten können.
Die Hinweise bedeuten:
- Die URL des Servers muss in der Intranet-Zone sein. Siehe auch IE Zonen
- Die Domains bzw. Hosts müssen in about:config network.negotiate-auth.trusted-uris eingetragen werden.
- 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
- 281660 Behavior of stored User names and passwords
- 306992 How to manage stored User names and passwords on a computer in a domain in Windows XP
- CmdkeyCreates - , lists, and deletes stored User
names and passwords or credentials.
http://technet.microsoft.com/de-de/library/cc754243(WS.10).aspx - Manipulate stored credentials
http://blogs.msdn.com/spatdsg/archive/2006/07/19/manipulate-stored-credentials.aspx
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 und ServicePrincipalName
-
CNAME vs A-Record
Die richtige Art einen Alias auf echte Server zu verweisen - 911149 Error message in Internet Explorer when you
try to access a Web site that requires Kerberos
authentication on a Windows XP-based computer: "HTTP
Error 401 - unauthorized: Access is denied due to
invalid credentials"
Windows XP SP2 hat einen Bug, der in SP1 nicht da war und SP3 gefixt wurde: IE nutzt dann den Hostnamen anstelle des CNAME - Kerberos fails when using CNAME records
http://www.marcvalk.net/2009/06/kerberos-fails-when-using-cname-records/ - Kerberos für MOSS
http://jakeswebpad.blogspot.com/2007/09/kerberos-for-moss.html - 870911 How to consolidate print servers by using DNS alias (CNAME) records in Windows Server 2003 and in Windows 2000 Server
-
Fix: Access CNAME based URL from same server
(SharePoint, CRM etc)
http://techontip.wordpress.com/2011/03/22/fix-access-cname-based-URL-from-same-server-sharepoint-crm-etc/
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
- DNS - _kerberos-Einträge im DNS
- ADFS Kerberos
- IE Zonen
-
CNAME vs A-Record
Die richtige Art einen Alias auf echte Server zu verweisen - Troubleshooting Kerberos Errors
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx - 264921 How IIS authenticates browser clients
- Kerberos in einer SharePoint Farm einrichten
http://weblogs.mysharepoint.de/fabianm/archive/2007/10/28/kerberos-in-einer-sharepoint-farm-einrichten.aspx - 269643 Internet Explorer Kerberos authentication does not work because of an insufficient buffer connecting to IIS
- 927265 Authentication fails when client computers use Internet Explorer 7 to authenticate with an upstream ISA Server computer through a downstream ISA Server computer that does not require authentication
- 152526 Changing the Default Interval für User Tokens in IIS
Per Default 15 Min werden Tokens von angemeldeten Usern gecached. Ein User kann also so lange auch nach einer KennwortÄnderung weiter mit dem alten Kennwort arbeiten. - ExBPA Der Parameter „IIS 6.0 MaxFieldLength“ wurde nicht
ordnungsgemäß festgelegt
http://technet.microsoft.com/de-de/library/aa996475(EXCHG.80).aspx - 820129 INF: Http.sys Registry Settings für IIS
- 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
- Fun with the Kerberos Delegation Web Site
http://blogs.technet.com/askds/archive/2008/11/25/fun-with-the-kerberos-delegation-web-site.aspx - Ask the Directory Services Team - Keyword Kerberos
http://blogs.technet.com/askds/archive/tags/Kerberos/default.aspx