Empfangen der Anmeldeaufforderung mithilfe der integrierten Windows-Authentifizierung

Ich habe eine .NET 3.5-Anwendung, die unter IIS 7 auf einem Windows 2003-Server ausgeführt wird, und kann die integrierte Windows-Authentifizierung nicht ordnungsgemäß ausführen, da ich weiterhin zur Anmeldung aufgefordert werde. Ich habe die Windows-Authentifizierung in IIS aktiviert und alle anderen Sicherheitstypen deaktiviert. Die Authentifizierung / Autorisierung der Datei web.config meiner Anwendung ist wie folgt eingerichtet:

<system.web>
    <compilation debug="true" strict="false" explicit="true" targetFramework="3.5" />
    <authenticationmode="Windows"/>
    <authorization>
    <deny users = "?" />
    </authorization>
</system.web>

Mit diesem Setup erwarte ich, dass der Windows-Benutzer hinter den Kulissen überprüft, um den Zugriff zu ermöglichen und anonyme Benutzer zu verweigern. Ich erhalte jedoch ein Windows-Anmelde-Popup, wenn ich versuche, auf die Site zuzugreifen.

Ich behebe dieses Problem seit einigen Tagen und kann das Problem nicht herausfinden. Basierend auf Posts mit ähnlichen Problemen habe ich bestätigt, dass meine URL keine Punkte enthält, doppelt überprüft, ob meine IE-Einstellungen auf Integrierte Windows-Authentifizierung aktivieren eingestellt sind, und meine URL zu meinen Intranetsites hinzugefügt, aber weiterhin das Popup angezeigt.

Zur weiteren Fehlerbehebung habe ich die anonyme Authentifizierung in IIS aktiviert und meine Datei web.config geändert, in die ich direkt zugreifen kann, und dann Response.Write (System.Security.Principal.WindowsIdentifity.getcurrent (). User.name.toString () hinzugefügt. ), um zu sehen, welcher Benutzer bei der Authentifizierung verwendet wird. Das Ergebnis ist IIS APPPOOL \ myapp, das offensichtlich der IIS-Anwendungspool für meine Anwendung ist.

Ich freue mich über jede Hilfe, die jemand leisten kann, damit ich immer noch nur die Windows-Authentifizierung verwende, aber kein Popup erhalte und die Windows-Authentifizierung für den tatsächlichen Windows-Benutzer durchgeführt wird.

Vielen Dank.

Zusätzlicher Hinweis nach weiterer Fehlerbehebung:

Ich habe gerade bemerkt, dass, wenn die Anmeldung fehlschlägt und die Windows-Anmeldeaufforderung erneut angezeigt wird, der Benutzername angezeigt wird, der versucht hat, sich als "SERVERNAME" \ "USERNAME" anzumelden Domain. Um dies zu bestätigen, habe ich direkt auf dem App-Server ein lokales Benutzerkonto mit demselben Benutzernamen und Kennwort wie der Benutzer der Netzwerkdomäne erstellt und versucht, mich erneut anzumelden. Das Ergebnis war, dass ich erneut die Anmeldeaufforderung erhielt, aber als ich diesmal den Benutzernamen und das Passwort eingab, konnte ich mich erfolgreich anmelden. Der Netzwerkbenutzer und der App-Server befinden sich in derselben Domäne. Sie sind sich also nicht sicher, warum die IIS-Authentifizierung auf die lokalen App-Server-Konten und nicht auf die Domänenkonten verweist. Mir ist klar, dass dies zu diesem Zeitpunkt eine IIS-Frage ist, also poste auf forums.iis.

Ich habe einen Windows 2008-Server, an dem ich arbeite, daher ist meine Antwort nicht ganz dieselbe wie die des OP auf einem Windows 2003-Server.

Hier ist, was ich getan habe (dies hier aufnehmen, damit ich es später finden kann).

Ich hatte das gleiche Problem:

In meiner Web.config- Datei hatte ich diesen Abschnitt:

<system.web>
    <authentication mode="Windows" />
    <authorization>
        <allow users="*" />
        <deny users="?" />
    </authorization>
</system.web>

Unter IIS scheinen alle diese Probleme unter dem Authentifizierungssymbol gelöst zu sein .

1. Berechtigungen bearbeiten: Stellen Sie sicher, dass Ihr ASP.NET-Konto über Berechtigungen verfügt. Meins wurde ursprünglich nicht hinzugefügt.

Gehen Sie nun zu den Funktionen der Authentifizierung :

Aktivieren Sie die anonyme Authentifizierung mit IUSR:

Aktivieren Sie die Windows-Authentifizierung und klicken Sie mit der rechten Maustaste, um die Anbieter festzulegen .

NTLM muss an erster Stelle stehen!

Als nächstes prüfen, ob unter Erweiterte Einstellungen ... die erweiterte Schutz ist Akzeptieren und Kernel-Mode - Authentifizierung aktiviert aktiviert ist:

Nachdem ich dies getan hatte, kehrte ich zu meiner Webanwendung zurück, klickte auf den Link Durchsuchen und loggte mich ein, ohne meine Anmeldeinformationen erneut eingeben zu müssen.

Ich hoffe, dass dies für viele von Ihnen von Vorteil ist, und ich hoffe, dass es später auch für mich nützlich ist.

Nur zum Nutzen anderer. Wenn der Fehler a ist 401.1 Unauthorizedund Ihr Fehlercode übereinstimmt 0xc000006d, stoßen Sie tatsächlich auf eine Sicherheitsfunktion, die Anforderungen an den vollqualifizierten Domänennamen oder benutzerdefinierte Host-Header blockiert, die nicht mit Ihrem lokalen Computernamen übereinstimmen:

Befolgen Sie diesen Support-Artikel, um das Problem zu beheben:

https://webconnection.west-wind.com/docs/_4gi0ql5jb.htm (Original, jetzt nicht mehr verfügbar: http://support.microsoft.com/kb/896861 )

Um sicherzustellen, dass der Support-Artikel nicht verloren geht:

Die Problemumgehung ist ein Registrierungs-Hack, der diese Richtlinie explizit deaktiviert.

Um diese Konfiguration manuell durchzuführen, suchen Sie diesen Schlüssel in der Registrierung auf dem Server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

und bearbeiten oder fügen Sie einen neuen Schlüssel hinzu:

DisableLoopbackCheck (DWORD)

Senden Sie dann den Wert an 1, um die Loopback-Prüfung zu deaktivieren (lokale Authentifizierung funktioniert) oder an 0 (lokale Authentifizierung ist nicht zulässig).

Oder einfacher können Sie Powershell verwenden:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword

Es sieht so aus, als ob neuere Versionen von Windows 10 (1803 und höher?) Diese Konfigurationseinstellung ebenfalls benötigen, um sich lokal zu authentifizieren.

Dieser hat eine Weile gedauert, weil mir die Kommentare aller anderen hier nicht geholfen haben. Ich habe diesen Artikel gefunden und er hat ihn behoben!

Ich hatte ein ähnliches Problem, bei dem ich nur einen bestimmten Teil meiner Website schützen wollte. Alles hat gut funktioniert, außer im IE. Ich habe sowohl die anonyme als auch die Windows-Authentifizierung aktiviert. Für Anonym wird die Identität auf die Identität des Anwendungspools festgelegt. Das Problem war mit der Windows-Authentifizierung. Nach einigem Stöbern habe ich Fiddler gestartet und festgestellt, dass Kerberos als Provider verwendet wird (eigentlich ist es standardmäßig auf Negotiate eingestellt). Ich habe es auf NTLM umgestellt und das hat es behoben. HTH

Daudi

Fügen Sie Ihrer Websicherheit die Berechtigung [Domänenbenutzer] hinzu.

• Klicken Sie mit der rechten Maustaste auf Ihre Site in IIS im Ordner Sites
• Klicken Sie auf Berechtigungen bearbeiten ...
• Wählen Sie die Registerkarte Sicherheit
• Klicken Sie im Abschnitt Gruppen- oder Benutzernamen auf die Schaltfläche Bearbeiten ....
• Klicken Sie im Popup "Berechtigungen" unter den Gruppen- oder Benutzernamen auf Hinzufügen ...
• Geben Sie [Domänenbenutzer] in die Objektnamen ein, um den Textbereich auszuwählen, und klicken Sie auf OK, um die Änderung zu übernehmen
• Klicken Sie auf OK, um das Popup "Berechtigungen" zu schließen
• Klicken Sie auf OK, um das Popup "Eigenschaften" zu schließen und Ihre neuen Einstellungen zu übernehmen

Erstellen Sie keine Fehler auf Ihrem Server, indem Sie alles ändern. Wenn Windows bei Verwendung der Windows-Authentifizierung unter 2008 R2 aufgefordert wird, sich anzumelden, gehen Sie für jede Ihrer Anwendungen zu ProvidersUP NTLM. Wenn Negotiatees das erste in der Liste ist, kann die Windows-Authentifizierung die Arbeitseigenschaft für eine bestimmte Anwendung unter 2008 R2 beenden und Sie können aufgefordert werden, Benutzername und Kennwort einzugeben, da dies niemals funktioniert. Das passiert manchmal, wenn Sie Ihre Anwendung aktualisiert haben. Stellen Sie nur sicher, dass NTLMes auf der Liste an erster Stelle steht, und Sie werden dieses Problem nie wieder sehen.

Wenn Ihre URL Punkte im Domainnamen enthält, wird sie vom IE wie eine Internetadresse und nicht lokal behandelt. Sie haben mindestens zwei Möglichkeiten:

1. Holen Sie sich einen Alias, der in der URL verwendet wird, um server.domain zu ersetzen. Zum Beispiel myapp.
2. Führen Sie die folgenden Schritte auf Ihrem Computer aus.

Gehen Sie zur Site und brechen Sie den Anmeldedialog ab. Lass das geschehen:

In den IE-Einstellungen:

WindowsIdentity.GetCurrentist richtig: Sie sollten den APPPOOL-Benutzer erhalten. Dies liegt daran, dass der ASP.NET-Prozess, der Ihren Code ausführt, die aktuelle Identität ist. Wenn Sie möchten, dass der Benutzer die Identität der Site erreicht, müssen Sie die folgende Zeile in Ihre web.config einfügen:

<identity impersonate="true" />

Dies führt dazu, dass der Prozess die Identität des Benutzers annimmt, der die Seite anfordert. Alle Aktionen werden in ihrem Namen ausgeführt. Wenn Sie also versuchen, Ordner im Netzwerk zu lesen oder auf Datenbankressourcen und dergleichen zuzugreifen, benötigt der aktuelle Benutzer Berechtigungen für diese Dinge. Weitere Informationen zum Identitätswechsel finden Sie hier . Beachten Sie, dass je nach Einrichtung Ihrer Web- / Datenbankservertopologie möglicherweise Delegierungsprobleme auftreten, wenn der Identitätswechsel aktiviert ist.

Ihr ursprüngliches Problem ist jedoch, dass die Identität anscheinend nicht ermittelt werden kann und Sie ein Anmelde-Popup erhalten. Ich werde darauf hinweisen, dass Sie den <deny>Block nicht benötigen , wenn Sie die anonyme Authentifizierung in IIS deaktiviert haben. Wir nehmen es nie auf (außer in speziellen <location>Blöcken und dergleichen), daher würde ich sagen, dass Sie versuchen könnten, es zu entfernen und es erneut zu versuchen. Alles andere klingt jedoch richtig.

Sie haben nicht angegeben, welcher Benutzer den Anwendungspool in IIS ausführt. Ist es ein benutzerdefiniertes Konto oder ist es das Standardkonto? Wenn es benutzerdefiniert ist, handelt es sich um ein Domänenkonto oder ein lokales Konto auf dem Webserver? Benutzerdefinierte Konten können manchmal einige weitere Schritte erfordern, z. B. das Registrieren eines SPN. Möglicherweise liegt auch ein Problem damit vor, dass das benutzerdefinierte Konto in AD keine Berechtigung zum Auflösen des Kontos des eingehenden Benutzers hat.

Sie können auch die IIS-Protokolle überprüfen, um festzustellen, welche Antwort zurückgegeben wird. Es wird höchstwahrscheinlich ein 401 sein, aber es sollte eine Subnummer wie 401.2 oder so haben. Diese Subnummer kann manchmal helfen, das Grundproblem zu bestimmen. Dieser KB-Artikel listet fünf auf.

Das hat es für mich behoben.

Mein Server- und Client-PC ist Windows 7 und befindet sich in derselben Domäne

1. Aktivieren Sie in iis7.5 die Windows-Authentifizierung für Ihr Intranet (deaktivieren Sie alle anderen Authentifizierungen. Auch die Windows-Authentifizierung muss in der Datei web.config nicht erwähnt werden

2. Gehen Sie dann zum Client-PC. IE8 oder 9- Tools-Internetoptionen-Sicherheit-Lokales Intranet-Sites-Erweitert-Fügen Sie Ihre Site hinzu (entfernen Sie das Ticketmark "Server erforderlich veri ...")

3. IE8 oder 9- Tools-Internetoptionen-Sicherheit-Lokales Intranet-Benutzerdefinierte Ebene-Benutzerauthentifizierung-Anmeldung-Automatische Anmeldung mit aktuellem Benutzernamen und Passwort auswählen

4. Speichern Sie diese Einstellungen. Sie sind fertig. Keine Aufforderung mehr zur Eingabe von Benutzername und Passwort.

5. Stellen Sie sicher, dass Sie für diese Einstellungen ein Gruppenrichtlinienobjekt haben müssen, da Ihr Client-PC Teil der Domäne ist. Andernfalls wird diese Einstellung beim nächsten Anmelden des Benutzers bei Windows zurückgesetzt

Kann browserbezogen sein. Wenn Sie den Internet Explorer verwenden, können Sie unter Erweiterte Einstellungen das Kontrollkästchen "Integrierte Windows-Authentifizierung aktivieren" aktivieren.

In meinem Fall wurden die Autorisierungseinstellungen nicht richtig eingerichtet.

Ich musste

1. Öffnen Sie die .NET-Autorisierungsregeln in IIS Manager

   

2. und entfernen Sie die Verweigerungsregel

   

In unserem Intranet wurde das Problem auf der Clientseite behoben, indem die Sicherheitseinstellungen wie hier gezeigt angepasst wurden. Jedes der Kontrollkästchen rechts hat bei uns funktioniert.

Ich habe gerade ein ähnliches Problem mit einer ASP.Net-Anwendung gelöst.

Symptome: Ich konnte mich mit einem lokalen Benutzer, aber nicht mit einem Domänenbenutzer bei meiner App anmelden, selbst wenn der Computer ordnungsgemäß der Domäne beigetreten war (wie Sie in Ihrem zusätzlichen Hinweis angeben). In der Sicherheitsereignisanzeige gab es ein Ereignis mit der ID = 4625 "Domain sid inkonsistent".

Lösung: Ich habe hier die Lösung gefunden . Das Problem war, dass auf meinen Testmaschinen virtuelle Maschinen geklont wurden (Windows Server 2008 R2; ein Domänencontroller und ein Webserver). Beide hatten dieselbe Maschinen-SID, was anscheinend Probleme verursachte. Folgendes habe ich getan:

1. Entfernen Sie den Webserver aus der Domäne.
2. Führen Sie c: \ Windows \ System32 \ Sysprep \ Sysprep.exe in der VM aus.
3. Starten Sie die VM neu.
4. Verbinden Sie den Webserver mit der Domäne.

Sie verlieren dabei einige Einstellungen (Benutzereinstellungen, statische IP, neu erstelltes selbstsigniertes Zertifikat), aber jetzt, da ich sie neu erstellt habe, funktioniert alles korrekt.

Ich hatte auch das gleiche Problem. Versuchte die meisten Dinge in diesem und anderen Foren.

Endlich war es erfolgreich, nachdem ich ein wenig eigenes RnD gemacht hatte.

Ich ging in die IIS-Einstellungen und fügte dann in den Berechtigungsoptionen meiner Website meine Organisationsdomänen-Benutzergruppe hinzu.

Da nun allen meinen Domainbenutzern der Zugriff auf diese Website gewährt wurde, ist dieses Problem nicht aufgetreten.

Hoffe das hilft

Haben Sie versucht, sich mit Ihrem Domain-Präfix anzumelden, z. B. DOMAIN \ Benutzername? In IIS 6 wird standardmäßig der Host-Computer als Standarddomäne verwendet. Wenn Sie also die Domäne bei der Anmeldung angeben, kann das Problem möglicherweise behoben werden.

Ich habe die oben genannten IIS-Konfigurationstricks und den Loopback-Registrierungs-Hack ausprobiert und die Berechtigungen für den App-Pool und ein Dutzend anderer Dinge überprüft und neu erstellt. Trotzdem konnte ich die auf meiner Entwicklungsarbeitsstation mit IIS Express oder IIS 7.5 ausgeführte Authentifizierungsschleife nicht entfernen. von einer lokalen oder Remote-Browsing-Sitzung. Ich habe vier 401.2-Statusantworten und eine leere Seite erhalten. Die exakt gleiche Site, die auf meinem IIS 8.5-Staging-Server bereitgestellt wird, funktioniert einwandfrei.

Schließlich bemerkte ich, dass das vom Browser leer gemachte Markup im Antworttext die Standardseite für eine erfolgreiche Anmeldung enthielt. Ich stellte fest, dass die benutzerdefinierte Fehlerbehandlung für ASP.NET und HTTP für den 401-Fehler die Windows-Authentifizierung meiner Workstation verhinderte / störte aber nicht der Staging-Server. Ich habe mehrere Stunden damit verbracht, mich damit zu beschäftigen, aber sobald ich die benutzerdefinierte Behandlung nur für den 401-Fehler entfernt hatte, war die Workstation wieder normal. Ich präsentiere dies als eine andere Möglichkeit, Ihren eigenen Fuß zu schießen.

Die Windows-Authentifizierung in IIS7.0 oder IIS7.5 funktioniert nicht mit Kerberos (Anbieter = Aushandeln), wenn die Identität des Anwendungspools ApplicationPoolIdentity lautet. Sie müssen den Netzwerkdienst oder ein anderes integriertes Konto verwenden. Eine andere Möglichkeit besteht darin, NTLM zu verwenden, um die Windows-Authentifizierung zum Laufen zu bringen (in Windows-Authentifizierung, Anbieter, setzen Sie NTLM an die Spitze oder entfernen Sie das Aushandeln).

chris van de vijver

Ich hatte das gleiche Problem, weil der Benutzer (Identität), den ich im Anwendungspool verwendet habe, nicht unter der Gruppe IIS_IUSRS lag. Der Benutzer wurde der Gruppe hinzugefügt und alles funktioniert

In meinem Fall bestand die Lösung (zusätzlich zu den oben vorgeschlagenen Anpassungen) darin , den lokalen Entwicklungscomputer / IIS (Hosting-Server) meines / meiner Benutzer neu zu starten . Mein Benutzer wurde gerade zur neu erstellten AD-Sicherheitsgruppe hinzugefügt. Die Richtlinie galt erst für das AD-Benutzerkonto, als ich mich abgemeldet / meinen Computer neu gestartet habe.

Hoffe das wird jemandem helfen.

Ich bin auf dasselbe Problem mit der Eingabeaufforderung für Anmeldeinformationen gestoßen und habe eine schnelle Suche durchgeführt, und nichts im Internet würde das Problem beheben. Es dauerte einige Zeit, um das dumme Problem zu finden.

In IIS -> Erweiterte Einstellungen -> Berechtigungsnachweis für physischen Pfad (ist leer)

Sobald ich eine Computer-ID (Domäne / Benutzer) hinzugefügt habe, die Zugriff auf die VM / den Server hat, wird die Kennwortabfrage beendet.

Hoffe das hilft

Ich hatte dieses Problem auf .net Core 2 und nachdem ich die meisten Vorschläge von hier durchgesehen habe, scheint es, dass wir eine Einstellung auf web.config verpasst haben

<aspNetCore processPath="dotnet" arguments=".\app.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Die richtige Einstellung war forwardWindowsAuthToken = "true" , was jetzt offensichtlich erscheint, aber wenn es so viele Situationen für dasselbe Problem gibt, ist es schwieriger, genau zu bestimmen

Bearbeiten: Ich fand auch den folgenden Msdn-Artikel hilfreich, der die Fehlerbehebung durchführt.

Ich habe das gleiche Problem und es wurde behoben, indem die Anwendungspoolidentität des Anwendungspools, unter dem die Webanwendung ausgeführt wird, in NetworkService geändert wurde