warum funktioniert die windows-Authentifizierung / Identitätswechsel nicht auf asp.net Anwendung mit iis 7.5 / windows 7 /

Ich bin Fehlerbehebung warum kann ich nicht vorbei an den login-dialog auf einem ASP.Net Website konfiguriert, die Windows-Authentifizierung und den Identitätswechsel.

Habe ich eine ASP.Net 2.0-Anwendung, und ich versuche, installieren Sie es auf Windows 7 mit IIS 7.5. Ich habe eine neue Website, und Band es auf "localhost" und den voll qualifizierten domain-Namen. der FQDN ist in meiner hosts-Datei, und umgeleitet wird zu 127.0.0.1

Die site ist auch mit einer AppDomain ich erstellt, mit integrierter pipeline-Modus, und das Prozess-Modell der Identität gesetzt ist ApplicationPoolIdentity.

Web.config enthält die folgenden:

<trust level="High" />
<authentication mode="Windows" />
<authorization>
  <deny users="?"/>
</authorization>
<identity impersonate="true"/>`

ACL für das Verzeichnis für die Website festgelegt ist, Jeder (Vollzugriff - Für die Prüfung).
Der Application-Pool der virtuellen-Konto (Windows 7 Sache) eingestellt ist, um die volle Kontrolle über das physikalische Verzeichnis für die Website.

IIS-Authentifizierung hat ASP.Net Identitätswechsel aktiviert und die Windows-Authentifizierung aktiviert.

Wenn ich eine Website als "localhost" erlaubt es mir in der Vergangenheit in der login-prompt und lädt die Anwendung ohne Zwischenfälle.

Wenn ich eine Verbindung zu der Website, wie der FQDN gesetzt, in der die host-Header-Bindungen für diese Website/ip/port, ich kann nicht vorbei an den login-prompt. Klick auf Abbrechen erzeugt einen http-Fehler 401.1-Seite.

Warum?

InformationsquelleAutor unknown | 2010-06-10
  1. 7

    und die Antwort für diesen einen wird ein Sicherheits-feature, bekannt als Authentifizierungs-loopback, eingeführt Weg zurück in Windows 2003 SP1 als pro: http://support.microsoft.com/kb/926642

    ich versuche eine Verbindung zu meinem iis host-Header-Instanz, die mit einem host-header, definiert in meine /etc/hosts-Datei als Hinweis auf 127.0.0.1, während Sie eingeloggt sind, auf dem Computer mit iis - das ist die loopback-Szenario.

    beißt es Sie in verschiedenen Kontexten, wie dies (http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx) oder diese Welt der verletzt in google (http://www.google.ca/search?q=authentication+loopback+check&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a)

    DAS UPDATE umfasst einige einfache regedit Arbeit: http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx

    ich auch nicht brauchen, um zu aktivieren den Identitätswechsel für meine situation, und so habe ich deaktiviert, und jetzt kann ich verbinden mit meinem gefälscht fqdn sowohl lokal als auch Remote

    InformationsquelleAutor unknown
  2. 7

    Die URL Samt down ist. Ich fand eine Cache-version auf archive.org:

    "
    401.1 Fehlermeldung Beim Zugriff Auf SharePoint Server

    Ich lief in dieses Problem mehrere Male in der Vergangenheit bei der Einrichtung von SharePoint-Umgebungen (sowohl für die interne Entwicklung nutzen und Kunden), so dass ich dachte, es war Zeit, um zu schreiben einen blog-Beitrag darüber. Wenn Sie mit SharePoint Server 2007 oder WSS 3.0 auf Windows Server 2003 SP1 oder später läuft man in Authentifizierungsprobleme auf, wenn Sie versuchen, Zugriff auf eine SharePoint-Website über die host-Header vom server selbst (z.B. host-Datei hat portal.mydomain.com wies auf 127.0.0.1). Dieses Problem manifestiert sich als das Ergebnis eines loop-back-Sicherheits-check, dass Microsoft in Windows Server 2003 SP1 und höher. Der Zweck des loopback ist zu beseitigen, denial-of-service-Angriffe, aber es führt zu Problemen mit Zugriff auf SharePoint-sites lokal vom server. In einer typischen Produktionsumgebung, ist dies normalerweise kein problem, da man nur selten den Zugriff auf SharePoint-Websites (neben zuv) aus einem front-end-web-server selbst. Was ich allerdings habe, physischen und virtuellen Entwicklungsumgebungen, wo alle Aktivitäten stattfinden, die vom server, so kann dies dazu führen, dass einige Sodbrennen wenn Sie gearbeitet haben, durch die Ausgabe vor. Sie können Lesen Sie die ausführlichen KB-Artikel bei KB926642 & KB896861. Hier ist eine kurze Zusammenfassung, wie das problem zu lösen. Ich in der Regel deaktivieren Sie die loopback-dies ist jedoch nicht empfohlen für die Produktion server-Umgebungen.

    Methode 1: Deaktivieren der loopback-Authentifizierung
    Re-aktivieren Sie die Verhalten, die es in Windows Server 2003 festlegen der "DisableLoopbackCheck" registry-Eintrag in der HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa Unterschlüssel der Registrierung auf 1. Um die DisableLoopbackCheck Registrierungseintrag auf 1, gehen Sie folgendermaßen vor um auf dem Clientcomputer:

    1. Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sie regedit ein, und klicken Sie dann auf OK.
    2. Suchen Sie, und klicken Sie dann auf den folgenden Registrierungsunterschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    3. Der rechten Maustaste auf Lsa, zeigen Sie auf Neu, und klicken Sie dann auf DWORD-Wert.
    4. Typ DisableLoopbackCheck, und drücken Sie dann die EINGABETASTE.
    5. Der rechten Maustaste auf DisableLoopbackCheck, und klicken Sie dann auf Ändern.
    6. In das Feld Wert, geben Sie 1 ein, und klicken Sie dann auf OK.
    7. Beenden Sie Den Registrierungs-Editor.
    8. Starten Sie den computer neu.
      Hinweis: Sie müssen den server neu starten, damit diese änderung wirksam wird. Standardmäßig wird die loopback-Funktionalität ist eingeschaltet in Windows Server 2003 SP1, und der "DisableLoopbackCheck" registry-Eintrag auf 0 gesetzt ist (null). Die Sicherheit wird reduziert, wenn Sie deaktivieren Sie die Authentifizierung loopback, und öffnen Sie die Windows Server 2003-server für man-in-the-middle-Angriffe (MITM) auf NTLM.

    Methode 2: Erstellen Sie die Local Security Authority host-Namen, auf die verwiesen werden kann, in eine NTLM-Authentifizierung anfordern
    Um dies zu tun, befolgen Sie diese Schritte für alle Knoten, die auf dem client-computer:

    1. Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sie regedit ein, und klicken Sie dann auf OK.
    2. Suchen Sie, und klicken Sie dann auf den folgenden Registrierungsunterschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
    3. Der rechten Maustaste auf MSV1_0, zeigen Sie auf Neu, und klicken Sie dann auf Wert der mehrteiligen Zeichenfolge.
    4. In der Spalte Name, geben Sie BackConnectionHostNames, und drücken Sie dann die EINGABETASTE.
    5. Der rechten Maustaste auf BackConnectionHostNames, und klicken Sie dann auf Ändern.
    6. In der Wert Daten im Feld, geben Sie den CNAME-oder den DNS-alias, der für die lokalen Freigaben auf dem computer, und klicken Sie dann auf OK.

    Hinweis: Geben Sie jeden Namen host in einer separaten Zeile.

    Hinweis: Wenn die BackConnectionHostNames registry-Eintrag existiert als Typ REG_DWORD, löschen Sie die BackConnectionHostNames registry-Eintrag.
    7. Beenden Sie den Registrierungs-Editor, und starten Sie den computer neu.

    "

    Aus: http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx am Juni 05 2009

    InformationsquelleAutor jpknoll
Schreibe einen Kommentar