Was ist an meiner Kerberoskonfiguration falsch?

Tobias Wolter Als Antwort am 26 Feb. 2011 02:15

Hallo Hannes,

es scheint so zu sein, dass die Kerb Auth. von WFE zu SQL funktioniert - aber nicht von Client zu WFE.

Ich würde fogendes durchspielen:

1. ApplicationHost.config: Sicherstellen, dass mit dem AppPool User authentifiziert wird:
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true"> http://blogs.blackmarble.co.uk/blogs/rhepworth/archive/2009/07/06/kerberos-for-sharepoint-on-server-2008-with-iis-7.aspx

2. setspn: SPN auf AppPool User setzen

3. klist: Überprüfen ob ein Service-Ticket auf Client vorhanden ist. Es müsste ein Eintrag mit Server: HTTP/<DEINSPN> geben

4. II7.5 (nur mit R2): Kerberos Auth. im IIS erzwingen. (http://tobiaswolter.wordpress.com/2010/12/06/sharepoint-2010-kerberos-authentifizierung-erzwingen/). Nach dem Trobleshooting wieder wegnehmen, Crawler kann nur NTLM.
Alternativ: Überprüfen mit Fiddler2 oder MS Netzwerkmonitor;

5. Im User Objekt sicherstellen, dass Delegation auf das Zielsystem erlaubt ist.

Neustart hilft bei der Kerberos Konfiguration oft!

Es könnte sein, dass IE Einstellungen Kerberos verhindern oder deine Webseite nicht auf Port 80 läuft - auch damit hat der IE ein Problem.

Grüße, Tobias

hannes 86 Als Antwort am 28 Feb. 2011 13:51

Hey Tobias,

danke für deine Hilfsbereitschaft. Zu deinen Vorschlägen:

[quote user="Tobias Wolter"]

1. ApplicationHost.config: Sicherstellen, dass mit dem AppPool User authentifiziert wird:
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true"> http://blogs.blackmarble.co.uk/blogs/rhepworth/archive/2009/07/06/kerberos-for-sharepoint-on-server-2008-with-iis-7.aspx

[/quote]

Ich habe die Einträge platziert, hat nichts geändert, ich habe sie auch momentan noch drinn gelassen auch wenn der offiziele microsoft Guide explitzit davon abrät den KernelMode zu verwänden.

[quote user="Tobias Wolter"]

2. setspn: SPN auf AppPool User setzen

Ok, hatte ich auch schon habe es aber nochmal mit "setspn -L" kontrolliert. An dieser Stelle sind mir aber zweifel aufgekommen, ob ich vielleicht bei der Sharepoint Installation nicht einen Fehler begonnen haben könnte. Im Log des SQL Servers sind nicht nur Einträge des AppPool Users vorhanden sind, sondern auch viele des Farmadmins. Die Installation ist schon länger her, hatte dann keine Zeit mehr etwas in Richtung SP zu machen, deshalb erinnere ich mich nicht mehr genau was ich damals alles eingestellt hatte. Ist folgende Zuordnung der Dienstkonten richtig?

Farmkonto...       sp_farm
Windows Dienst- MS SP Foundation Sandkastendienst Codedienst... sp_farm
Webanwendunspools...      sp_service
Dienstanwendungspool- SecurityTokenServiceApplicationPool... sp_farm
Dienstanwendungspool- SP Web Service Default...   sp_service
Dienstanwendungspool- SP Web Service System...   sp_farm

[quote user="Tobias Wolter"]

3. klist: Überprüfen ob ein Service-Ticket auf Client vorhanden ist. Es müsste ein Eintrag mit Server: HTTP/<DEINSPN> geben

Hab ich gemacht, kein Service-Ticket. Mir ist leider erst jetzt aufgefallen, dass wenn man am Client den Benutzer wechselt, scheint im Log des WFE die Anmeldung mit NTLM auf. Also funktioniert definitiv kein Kerberos zwischen Client und WFE.

[quote user="Tobias Wolter"]

4. II7.5 (nur mit R2): Kerberos Auth. im IIS erzwingen. (http://tobiaswolter.wordpress.com/2010/12/06/sharepoint-2010-kerberos-authentifizierung-erzwingen/). Nach dem Trobleshooting wieder wegnehmen, Crawler kann nur NTLM.
Alternativ: Überprüfen mit Fiddler2 oder MS Netzwerkmonitor;

Habe das NTLM herausgenommen, keine Änderung. Habe diese Einstellung auch momentan noch drinnen gelassen.

[quote user="Tobias Wolter"]

5. Im User Objekt sicherstellen, dass Delegation auf das Zielsystem erlaubt ist.

[/quote]

Ist auch ok. Habe es beim sp_service eingestellt.

Mittlerweile habe ich sicher die Server 10x neugestartet. Die IE Einstellungen habe ich so gemacht wie sie im Guide standen. In der Intranet Zone "Automatisches Anmelden nur in der Intranet Zone" und im Register Erweitert unter Sicherheit die nötigen Punkte.

 Wie kann ich sicher gehen, dass die zwischen SQL und WFE Kerberos auch wirklich funktioniert. Im Log ist kein einziger NTLM eintrag, immer nur Kerberos, aber reicht das schon als Nachweis??

Grüße

hannes 86 Als Antwort am 28 Feb. 2011 14:14

Hah... weiß jetzt nicht ob das auf irgend einer weiße direkt mit meinem Problem zu tun hat aber, wenn ich nun die Zentraladministration öffne, kommt immer eine Fehlermeldung "Das Ressourcenobjekt mit dem Schlüssel "PageDirection" wurde nicht gefunden."

Die URL endet mit msswecom.aspx anstelle des default.aspx. Wenn ich es händisch korrigiere, komme ich ganz normal in die Zentraladministration.

Ich seh schon, mit dem herumprobieren habe ich die Testumgebung schon etwas zerschossen. Wenn mir keiner helfen kann, werde ich den SP bei Gelegenheit auch neu Aufsetzen.

Grüße

Tobias Wolter Als Antwort am 28 Feb. 2011 23:09

Zwischen SQL und WFE indem du im SQL Activity Monitor die Sessions ermittelst und dann mit:

select * from sys.dm_exec_connections;

schaust ob NTLM oder Kerberos in der auth_scheme Spalte steht.

Zwischen WFE und Client wie beschrieben über IIS Setting, GPO oder eben mit Fiddler2, MS Netzwerkmonitor.

Zeichne doch mal mit dem MS Netzwerkmonitor vom Client aus den Authentication Traific auf(Filter setzen). Ansonsten sollte natürlich die Verbindung zur Domain vorhanden sein und die Uhrzeit von Client und DC nicht abweichen. Aber ich vermute es existieren bereits andere SV-Tickets z.B. LDAP, CIFS etc.

Grüße, Tobias

hannes 86 Als Antwort am 1 März 2011 20:05

Hallo Tobias,

also ersteres hat geklappt, ich habe gesehen das die entsprechenden Sessions den eintrag Kerberos haben. Soweit alles OK.

Dann habe ich beim MS Netzwerkmonitor den Authentication Filter gesetzt und zum testen die Funktion "Als anderer Benutzer anmelden" benützt. Zuersts habe ich im SP die Webanwendungsauthentifizierung wieder auf NTLM gesetzt und beim Benutzerwechsel im SP am Client mitgesnifft.

Dabei wurden nur 3 Frames übertragen:

1. Client zu WFE, HTTP:Request,GET; Authorization: NTLM

2. WFE zu Client, HTTP:Response,HTTP; wwwAuthenticate: NTLM

3. Client zu WFE, HTTP:Request,GET; Authentication: NTLM

Danach habe ich wieder auf Kerberos umgestellt und es wurden tatsächlich Kerberos Frames zwischen Client und Domain Controller ausgetauscht:

1. Client zu DC, KerberosV5:AS Request

2. DC zu Client, KerberosV5:KRB_ERROR- KRB_ERR_RESSPONSE_TOO_BIG(52)

3. Client zu DC, KerberosV5:AS Request

4. DC zu Client, KerberosV5:AS Response Ticket

5. Client zu WFE, HTTP:Request,GET; Authorization: Negotiate --> NegotiateAuthorization: --> Scheme: Negotiate --> GssApi --> Token:NTLM Negotiate Message

6. WFE zu Client, HTTP:Response,HTTP; wwwAuthenticate: Negotiate --> NegotiateAuthorization: --> Scheme: Negotiate --> GssApi --> Token:NTLM Challange Message

7. Client zu WFE, HTTP:Request,GET; Authentication: Negotiate --> NegotiateAuthorization: --> Scheme: Negotiate --> GssApi --> Token:NTLM Negotiate Message

Wegen der Übersict wollte ich oben nicht hinschreiben, dass bei Frame 6 noch StatusCode:401,Unauthorized steht.

Ich habe keine Ahnung wie das normalerweise ablaufen sollte. Generell ist jaWas bedeutet der komische Fehler bei dem zweiten Kerberos Frame? Bei Frame 4 wird doch das Ticket gesendet, wieso scheint es dann nicht mit klist auf? Fordert der Client bei Frame 5 bereitz über NTLM die Seite an?

Tobias Wolter Als Antwort am 3 März 2011 00:06

Hallo Hannes,

den Fehler KRB_ERROR- KRB_ERR_RESSPONSE_TOO_BIG(52) kenne ich nicht. Vielleicht ist das Kerberos Ticket zu groß wegen zu vielen Gruppenmitgliedschaft. Je mehr Gruppen desto länger der String. Das sollte bei einem AppPool User aber kein Problem sein.
http://kb4sp.wordpress.com/2009/10/07/krb_err_response_too_big-forcing-tcpip-over-udp/

Ist die IIS Konfiguration bei den Providern auf Negotiate:Kerberos ? oder steht sie noch auf Negotiate?

Wenn hier Negotiate:Kerberos steht, dann wird auch Kerberos verwendet. Man kann es auch an der länge des Auth Header erkennen der ist bei NTLM ca. 300 Zeichen:

Authorization Header is present: NTLM

4E 54 4C 4D 53 53 50 00 03 00 00 00 00 00 00 00 NTLMSSP.........

58 00 00 00 00 00 00 00 demo 00 00 00 X.......X.......

58 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 X.......X.......

58 00 00 00 00 00 00 00 58 00 00 00 05 C2 88 A2 X.......X....ˆ¢

06 01 B1 1D 00 00 00 0F E4 93 82 8C 06 BB E5 58 ..±.....ä“‚Œ.»åX

3E 3F 58 96 15 76 F0 C6 >?X–.vðÆ

Ich verwende hierfür Fiddler2, gibt aber auch andere Tools wie z.B.  WFETCH.

Beste Grüße, Tobias

hannes 86 Als Antwort am 4 März 2011 14:37

Hallo Tobias,

leider hatte ich gestern keine Zeit um weiter daran zu arbeiten. Zunächst mal möchte ich dir für deine Geduld mit mir bedanken.

Den TOO_BIG Fehler hatte ich schnell behoben, er war eigentlich kein Problem da der Client automatisch die MaxSegmentSize auf1460 gestellt hatte. Ich habe den Parameter in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters händisch hinzugefügt und jetzt scheint die Meldung gar nicht mehr auf.

Ich hatte die IIS Einstellung immer noch auf Negotiate, habe es dann auf Negotiate: Kerberos umgestellt.

Effekt war einmal, dass ich mit dem Client nicht mehr den die SharePoint Seite öffnen konnte, es blieb immer das Fenster offen das die Kredenzialien abfragt. Im Network Monitor schien ein neuer Kerberosfehler auf: KDC_ERR_S_PRINCIPAL_UNKNOWN(7) und HTTP Response Unauthorized.

Eindeutig, es stimmt etwas mit meinen SPN Einträgen oder Delegierungen nicht. Ich habe dann eine neue Variante der Delegierungseinstellung in der AD versucht und jetzt ist der Fehler weg.

Hier nochmal meine Einstellungen:

Sql_service = Dienstaccount unter dem der SQL Server läuft

MSSQLSvc/SERVER:1433

MSSQLSvc/SERVER.DOMAIN.LOCAL:1433

Sp_service = Dienstaccount unter dem die Webapplication läuft.

HTTP/WEBAPPLICATION.DOMAIN.LOCAL

HTTP/WEBAPPLICATION

In der AD am Dienstaccount sp_service habe ich unter Delegierung (Belibiges Authentifizierungsprotokoll verwänden) den sql_service Account hinzugefügt.

Vorher hatte ich die Delegierung in der AD genau umgekehrt eingestellt. In meiner Paranoia habe ich auch nochmal HTTP groß geschriebn, vorher hatte ich es klein.

Mit den obigen Einstellungen ist auch der Fehler nicht mehr aufgetaucht. Ich mich immer noch nicht anmelden. Im Network Monitor stand folgendes:

Kerberos: AS Request Cname: BENUTZER  Realm: DOMAIN Sname: krbtgt/DOMAIN

Kerberos: AS Response Ticket[Realm: DOMAIN.LOCAL, Sname: krbtgt/DOMAIN.LOCAL]

Dann werden noch 4 TCP Frames über den Kerberosport ausgetauscht und anschließend versucht der Client sich am WFE anzumelden.

Http: Request, GET /test/Teamwebsite/ , Using GSS-API Authorization

Http: Response, HTTP/1.1, Status: Unauthorized, URL: /test/Teamwebsite/ , Using Negotiate Authentication

Da aber nun kein Kerberosfehler mehr kam, wollte ich die Einstellung im IIS nochmal auf nur Negotiate gesetzt, habe mich mit dem Client angemeldet und sieh da es hat geklappt die Externe Liste hat die Daten abgerufen.

Interessant ist aber, dass wenn ich mir das Ganze mit WFetch anschaue immer noch ein verdächtig Kurzer String ist.

WWW-Authenticate: Negotiate TlRMTVNTUAACAAAACgAKADgAAAAVgoniN39cAY5BAnkAAAAAAAAAAIYAhgBCAAAABgGwHQAAAA9LAEEAUwBFAFIAAgAKAEsAQQBTAEUAUgABAAoAUwBSAFYAMAA

1AAQAFgBLAEEAUwBFAFIALgBMAE8AQwBBAEwAAwAiAFMAUgBWADAANQAuAEsAQQBTAEUAUgAuAEwATwBDAEEATAAFABYASwBBAFMARQBSAC4ATABPAEMAQQBMAAcACAC5sXAmbtrLAQAAAAA=\r\n

Habe alles nochmal gepostet, vielleicht macht auch noch jemand so einen Noob- Fehler wie ich, ist aber eher unwahrscheinlich :)

Danke Tobias für deine Hilfe, jetzt kann ich endlich mit meinen externen Listen spielen.

LG

Hannes