Wir haben mehrere von IIS gehostete Sites, die Windows-Authentifizierung verwenden. Einige unserer Benutzer können sich bei einer der Sites anmelden, erhalten aber bei einer anderen eine nicht enden wollende Authentifizierungsaufforderung (die zweite wird in einem Iframe der ersten verwendet). Wir haben herausgefunden, dass Benutzer, die sich nicht anmelden können, Kerberos-Authentifizierung verwenden (andere NTLM). Alle Sites verwenden dieselben Autorisierungseinstellungen (useAppPoolCredentials auf „true“ gesetzt). Daher können Benutzer auf eine Site zugreifen, aber nicht auf die zweite mit denselben Einstellungen. Der App-Pool-Identitätsbenutzer befindet sich in der Administratorgruppe und in der Gruppe IIS_IUSRS. Ich habe auch versucht, mich mit dem Domänenbenutzerkonto von einer VM aus bei der Site anzumelden und erhielt wegen Kerberos dieselbe nicht enden wollende Authentifizierungsaufforderung. Ich habe Chiranth Ramaswamys Artikel über IIS-Authentifizierung gelesen, konnte aber leider keine Lösung für das Problem finden. Gibt es eine Möglichkeit, das Problem zu lösen?
BEARBEITEN: Wir haben auch einen zweiten Server mit denselben Sites und Einstellungen.
EDIT2: Ich habe herausgefunden, dass ich mich anmelden kann, wenn ich dasselbe Domänenbenutzerkonto verwende, wenn ichnichtDomäne in Login schreiben. Somit funktioniert "Benutzername" und "Domänenname\Benutzername" nicht
Antwort1
Hier gibt es einiges zu beheben und mehr Details wären hilfreich, einschließlich der Information, wie Sie Kerb eingerichtet haben, welche anderen Sites vorhanden sind und welche URLs verwendet werden.
Kurz gesagt: Ich glaube, Kerb ist kaputt. Und damit es funktioniert, könnten Sie möglicherweise eine IP-Adresse anstelle des Namens verwenden. (Kerb funktioniert nur, wenn Sie einen Namen verwenden, keine IP-Adresse).
Ich vermute, Sie dekodieren die Tickets nicht im Kontext des App Pool-Kontos (das übrigens fast nie ein Administrator sein sollte).
Die Ursache hierfür kann ein doppelter SPN oder ein anderer defekter Aspekt von Kerb sein.
Es ist auch möglich, dass es sich um eine clientseitige Browsereinstellung wie „Integrierte Windows-Authentifizierung aktivieren“ und nicht um ein PAC-Skript und/oder Zoneneinstellungen handelt.
So! Einkaufsliste:
Überprüfen Sie die Zone(n), in die die Site geladen wird, wenn Sie IE verwenden.
Aktivieren Sie die Einstellung „Integrierte Windows aktivieren“, wenn Sie IE verwenden.
Starten Sie einen defekten Client neu (oder zumindest
klist purge) und erhalten Sie dann eine Netmon- oder Wireshark-Ablaufverfolgung einer fehlgeschlagenen Verbindung von der Clientseite. Dies könnte einige KDC-Antwortprobleme identifizieren, d. h. zurückgegebene Kerberos-Fehler, die einen Hinweis darauf geben, was Kerb beschädigen könnte.Wenn Sie useAppPoolCredentials verwenden, haben Sie wahrscheinlich SetSPN verwendet. Suchen Sie nach Duplikaten aller SPNs, die die Site-Namen betreffen.
Wenn Sie keine Delegierung verwenden, sollten Sie in Erwägung ziehen, „useAppPoolCredentials“ trotzdem zu entfernen, da das Systemkonto standardmäßig die Tickets für alle App-Pools dekodiert, wenn keine SPN-Überschreibung vorhanden ist.
Antwort2
Nach dem Neustart des Servers habe ich festgestellt, dass useApplicationCredentials wieder auf „false“ zurückgesetzt wurde. Ich habe es auf „true“ geändert und IIS neu gestartet. Danach tritt das Problem nicht mehr auf. Aber ich bin mir nicht sicher, ob das kein Zufall ist. Wir haben das gleiche Problem auf dem anderen Server. 4 Maschinen mit den gleichen IIS-Einstellungen. 2 funktionieren nicht richtig über Kerberos, zwei schon. Für keine von ihnen wurde SPN konfiguriert. Außerdem haben die beiden, die funktionieren, „false“ in useApplicationCredentials.
Ich werde die gleiche Methode ausprobieren: reboot-set useApplicationCredentials auf true, wenn es nicht so ist, und dann iisreset. Aber ich bin ziemlich sicher, dass das kein Problem ist. Ich kann nicht verstehen, warum Kerberos funktioniert, wenn SPN nicht gesetzt ist