Problembehandlung bei der Windows-Authentifizierung (keine Herausforderung) in IIS 7.5?

Ich weiß, dass es Tausende von Berichten gibt, denen zufolge Menschen Probleme haben, die integrierte Windows-Authentifizierung für die Arbeit mit IIS zu erhalten, aber alle scheinen zu Webseiten zu führen, die nicht zutreffen, oder zu Lösungen, die ich bereits ausprobiert habe. Ich habe schon Dutzende solcher Sites bereitgestellt, also ist entweder etwas Bizarres mit dem Server / der Konfiguration los, oder ich habe mir das zu lange angesehen und nicht das Offensichtliche gesehen.

Einfach gesagt, alles funktioniert perfekt auf meinem lokalen Computer, fällt aber auf dem Produktionsserver auseinander, der, soweit ich das beurteilen kann, genau die gleiche Konfiguration hat .

Auf dem lokalen Computer:

Auf dem Computer wird Windows 7 Ultimate, Service Pack 1, IIS 7.5 ausgeführt.
Die Site wurde erfolgreich mit IIS und dem VS Web Development Server getestet.
In der IIS-Standortkonfiguration sind alle Authentifizierungsmethoden mit Ausnahme der Windows-Authentifizierung deaktiviert .
Der lokale Computer befindet sich in keiner Domäne.
Die eingerichteten Provider sind Negotiate und NTLM (nicht Negotiate: Kerberos).
Der erweiterte Schutz ist deaktiviert.
Alle getesteten Browser (IE, Firefox, Chrome) zeigen die Sicherheitsabfrage an und ermöglichen mir, mich mit meinem (lokalen) Windows-Konto bei der localhost- Domäne anzumelden .
Alle getesteten Browser funktionieren auch mit einer undurchsichtigen lokalen IP-Adresse - daher scheint es den Browsern selbst egal zu sein, ob die Site "lokal" oder "remote" angezeigt wird.
Ich habe der Webseite eine Anzeigezeile hinzugefügt, die den aktuell angemeldeten Benutzer und genau das anzeigt, was ich erwarten würde (mit welchem lokalen Benutzer ich mich auch immer angemeldet habe).

Auf dem Remote-Computer:

Auf dem Server wird Windows Server 2008 R2, IIS 7.5 ausgeführt.
Das Laden der Webseite führt zu einem sofortigen 401.2-Fehler: Sie sind aufgrund ungültiger Authentifizierungsheader nicht berechtigt, diese Seite anzuzeigen. Es wird nie eine Sicherheitsabfrage angezeigt.
In der IIS-Standortkonfiguration sind alle Authentifizierungsmethoden mit Ausnahme der Windows-Authentifizierung deaktiviert .
Der Remotecomputer befindet sich in keiner Domäne.
Die eingerichteten Provider sind Negotiate und NTLM (nicht Negotiate: Kerberos).
Der erweiterte Schutz ist deaktiviert.
Auf dem Remotecomputer (Remotedesktopsitzung) wird im Internet Explorer derselbe Fehler angezeigt, unabhängig davon, ob es sich bei der Domäne um den lokalen Host oder um die externe IP-Adresse handelt.
Wenn ich versuche, die Remotewebsite von meinem lokalen Computer aus anzuzeigen , ist der Fehler weiterhin 401, jedoch ein geringfügig anderer 401. Kein Subcode mit dem Text: Der Zugriff wird aufgrund ungültiger Anmeldeinformationen verweigert.
Die Windows-Authentifizierungs- IIS-Rollenfunktion ist installiert.
Das WindowsAuthentication- Modul wird hinzugefügt (auf Serverebene ).
Der exakt gleiche Fehler tritt auf, wenn ich die Windows-Authentifizierung deaktiviere und die Standardauthentifizierung aktiviere.
Die Site wird geladen, wenn ich die Windows-Authentifizierung deaktiviere und Anonym (offensichtlich) aktiviere.
Ich habe bereits alle Schritte zur Fehlerbehebung beim Microsoft-Support ausgeführt: Fehlerbehebung bei HTTP 401-Fehlern in IIS
Ich habe bereits die auf einer anderen Microsoft-Support-Seite gezeigte Problemumgehung ausprobiert (angeblich, um NTLM als einzige Methode zu erzwingen).

Last but not least habe ich versucht, FREB für 401.2-Fehler einzuschalten, und die Ergebnisse scheinen mir nichts Nützliches zu verraten. Ich sehe nur die folgende Warnung:

MODULE_SET_RESPONSE_ERROR_STATUS

Modulname IIS Web Core-
Benachrichtigung 2
HttpStatus 401
HttpReason Nicht autorisiert
HttpSubStatus 2
ErrorCode 2147942405
ConfigExceptionInfo-
Benachrichtigung AUTHENTICATE_REQUEST
ErrorCode-Zugriff verweigert. (0x80070005)

... das scheint mir nur zu sagen, was ich bereits weiß (dass es einfach die Anfrage ablehnt, anstatt die Anmeldeinformationen zu verhandeln).

Die Ablaufverfolgung zeigt an, dass das WindowsAuthentication-Modul korrekt geladen ist, da eine NOTIFY_MODULE_STARTZeile mit ModuleName= WindowsAuthentication(und verschiedenen anderen ASP.NET- Folgeereignissen - zum Glück keine interessanten Fehler oder Warnungen) vorhanden ist.

Kann mir jemand sagen, was ich hier vermissen könnte?

Schnelles Update:

Es ist mir ein wenig unangenehm, einen ganzen Wireshark-Dump zu senden, da er IPs, URLs und andere Informationen enthüllt, aber ich habe die HTTP-Antworten von localhost und dem Remote-Server in Fiddler nebeneinander verglichen, und es scheint ziemlich selbstständig zu sein -evident, was das Problem ist:

Localhost:

HTTP / 1.1 401 Nicht autorisiert
Cache-Kontrolle: privat
Inhaltstyp: Text / HTML; Zeichensatz = utf-8
Server: Microsoft-IIS / 7.5
WWW-Authentifizierung: Verhandeln
WWW-Authentifizierung: NTLM
X-Powered-By: ASP.NET
Datum: Sa, 17. Dezember 2011, 23:42:34 GMT
Inhaltslänge: 6399
Proxy-Support: Sitzungsbasierte Authentifizierung

Fernbedienung:

HTTP / 1.1 401 Nicht autorisiert
Inhaltstyp: Text / HTML
Server: Microsoft-IIS / 7.5
X-Powered-By: ASP.NET
Datum: Samstag, 17. Dezember 2011, 23:43:13 Uhr GMT
Inhaltslänge: 1293

Abgesehen von ein paar scheinbar unwichtigen Unterschieden wie der Cache-Steuerung besteht der Hauptunterschied darin, dass der Remote-Server die WWW-Authenticate-Header nicht an den Client zurücksendet.

Ich vermute also, dass dies die Frage einschränkt auf: Warum sendet IIS keine WWW-Authentifizierungsheader, wenn die Windows-Authentifizierung installiert, geladen und exklusiv aktiviert zu sein scheint?

security iis authentication iis-7.5 http-authentication Aaronaught
quelle

Denken Sie daran, einen Klartext-Wireshark des Authentifizierungsversuchs zu erfassen (ändern Sie zuerst Ihr Passwort in etwas Wegwerfbares - wir möchten nicht, dass Ihre echten Passwort-Hashes im Netz sind)? Ungefähr vor 18 Monaten hat ein Windows-Patch einige Änderungen an der HTTP-NTLM-Aushandlung vorgenommen (sind die Systeme übrigens vollständig gepatcht?), Die die App eines Anbieters in die Luft gesprengt haben und mir mehr Erfahrung gaben, als ich zugeben möchte Verhandlungsgespräche.

Shane Madden

@ShaneMadden: Ich habe etwas dagegen wegen all der verschiedenen Informationen, die ich enthüllen würde, aber ich kann eine Fiddler-Sitzung durchführen, die fast gleich sein sollte, und dann kann ich zumindest IPs anonymisieren und so weiter - und Das Ergebnis sollte eigentlich selbsterklärend sein (der Client zeigt die Eingabeaufforderung für Anmeldeinformationen nicht an, da der Server keine Informationen anfordert).

Aaronaught

Oh, interessant, jemand scheint dieses Problem auch bei Stack Overflow gemeldet zu haben - leider gibt es dort keine Antworten.

Aaronaught

@Aaronaught Wie haben Sie hier einen anderen Benutzernamen als beim Kochen erhalten? Als ich diese Frage zum ersten Mal sah, dachte ich, es wäre jemand, der dich fälscht.

Ward - Reinstate Monica

@Ward: Jeder kann seinen Benutzernamen bearbeiten, er ist Teil des Profils. Dies war mein Original, verwende nur andere auf den Non-Tech-Sites.

Aaronaught

Problem gelöst. Schließlich habe ich beschlossen, die Modulliste nebeneinander zu vergleichen, und es fehlte tatsächlich eine. Es stellt sich heraus, dass es zwei Windows-Authentifizierungsmodule gibt:

Modulliste

Auf dem Server war das verwaltete WindowsAuthenticationModul vorhanden, jedoch nicht das WindowsAuthenticationModuleoben hervorgehobene native . Warum es so konfiguriert wurde, ist unklar. Wenn das native Modul jedoch nicht geladen wird, wird das verwaltete Modul munter geladen und schlägt im Hintergrund fehl.

Stellen Sie daher für zukünftige Leser, die auf dieses Problem stoßen, sicher, dass beide Module geladen sind , da IIS Sie nicht warnt, wenn eines von ihnen fehlt.

Aaronaught
quelle

Das verwaltete WindowsAuthentication-Modul ist nicht das, wonach es sich anhört. Es unterstützt Windows-Identitäten in ASP.Net und ist immer installiert (wenn ASP.Net installiert ist). Das native Windows-Authentifizierungsmodul wird jedoch installiert, wenn Sie die Windows-Auth-Komponente im Server-Manager ankreuzen. Dies ist erforderlich, damit diese Authentifizierungsoption in der Authentifizierungs-GUI angezeigt wird.

TristanK

@TristanK: In diesem Fall wurde diese Komponente angekreuzt, aber das Modul wurde nicht installiert. (Die Option war jedoch in der Authentifizierungs-GUI sichtbar - ich bin mir also ziemlich sicher, dass der Bildschirm vom verwalteten Modul abhängt, nicht vom nativen.)

Aaronaught,

Ich denke, dass es auf Grund von Manipulationen an den Konfigurationsdateien (wahrscheinlich ApplicationHost.config) auf diese Weise gekommen sein könnte. Aber ich denke, es spielt keine Rolle, wie alles aus dem Ruder gelaufen ist. es tat.

Aaronaught

Na klar. Windows Auth funktioniert nicht, es sei denn, es ist ein Fehler aufgetreten. In diesem Fall stellt sich heraus, dass die Konfiguration zwar identisch ist, sich jedoch als unwahr herausstellt. also hat es nicht gleich geklappt. QED.

TristanK

Dieses fehlende Modulproblem hat mich in Windows Server 2012 R2 nur gebissen. Es ist unglaublich, dass es keinen Hinweis darauf gibt, wann dieser Zustand eintritt. Trotzdem vielen Dank für diese Antwort. Ich riss mir buchstäblich die Haare aus!

Rob Davis

Problembehandlung bei der Windows-Authentifizierung (keine Herausforderung) in IIS 7.5?

Antworten: