Pourquoi l'authentification/l'emprunt d'identité de Windows échoue-t-il sur l'application asp.net avec iis 7.5/windows 7/

Question

Je ne parviens pas à résoudre le problème de la boîte de dialogue de connexion sur un site ASP.Net configuré pour l'authentification et l'emprunt d'identité Windows.

J'ai une application ASP.Net 2.0 et j'essaye de la déployer sur Windows 7 avec IIS 7.5. J'ai créé un nouveau site et je l'ai lié à localhost et à un nom de domaine complet. le nom de domaine complet est dans mon fichier hosts et est redirigé vers 127.0.0.1

Le site fonctionne également avec un AppDomain que j'ai créé, avec le mode pipeline intégré, et l'identité du modèle de processus est définie sur ApplicationPoolIdentity.

Web.config comprend les éléments suivants:

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

ACL sur le répertoire du site est mis à tout le monde (Contrôle total - Pour les tests). Le compte virtuel Pool d'applications (Windows 7 thing) est également configuré pour un contrôle total sur le répertoire physique du site.

L'authentification IIS a l'emprunt d'identité ASP.Net activé et l'authentification Windows activée. Lorsque je me connecte au site en tant qu'hôte local, cela me permet de dépasser l'invite de connexion et l'application se charge sans incident. Lorsque je me connecte au site en tant que nom de domaine complet défini dans les liaisons d'en-têtes d'hôte pour ce site/ip/port, je ne peux pas dépasser l'invite de connexion. Cliquer sur annuler génère une page d'erreur http 401.1.

Pourquoi?

Answer 1

et la réponse à celle-ci va être une caractéristique de sécurité connue sous le nom contrôle de bouclage d'authentification, a présenté le chemin du retour dans Windows 2003 SP1, selon: http://support.microsoft.com/kb/926642

je tente de se connecter à mes iis têtes d'hôte instance utilisant un en-tête d'hôte défini dans mon fichier/etc/hosts comme pointant vers 127.0.0.1, alors qu'il est connecté sur la machine qui exécute iis - ceci est le scénario de bouclage.

il vous mord dans divers contextes, comme celui-ci (http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx) ou ce monde de mal dans 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)

CORRECTIF implique un travail regedit simple: http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx

i aussi ne pas besoin de permettre l'usurpation d'identité pour ma situation, et donc je l'ai désactivé, et maintenant je peux me connecter en utilisant mon faqed fqdn à la fois localement et à distance

Answer 2

L'URL fournie par Velvet est en panne. J'ai trouvé une version en cache sur archive.org:

" 401,1 Erreur lors de l'accès SharePoint à partir du serveur

je suis tombé sur cette question à plusieurs reprises dans le passé dans la mise en place des environnements SharePoint (pour une utilisation interne de développement et les clients Si vous exécutez SharePoint Server 2007 ou WSS 3.0 sous Windows Server 2003 SP1 ou version ultérieure, vous rencontrerez des problèmes d'authentification si vous tentez d'accéder à un site SharePoint à l'aide d'en-têtes d'hôte à partir du serveur lui-même (par exemple, le fichier hôte porte la référence 127.0.0.1 à portal.mydomain.com.) Ce problème est le résultat d'une vérification de sécurité de bouclage effectuée par Microsoft dans Windows Server 2003 SP1 et versions ultérieures.Le but de la vérification de bouclage est d'éliminer les attaques par déni de service, mais cela provoque des problèmes d'accès local aux sites SharePoint depuis le serveur. Dans un environnement de production typique, ce n'est généralement pas un problème car vous accédez rarement aux sites SharePoint (en plus de l'administration centrale) à partir d'un serveur Web frontal lui-même. Cependant, j'ai des environnements de développement physiques et virtuels où toutes les activités ont lieu à partir du serveur, donc cela peut causer des brûlures d'estomac, sauf si vous avez déjà travaillé sur le problème. Vous pouvez lire l'article détaillé de la base de connaissances au KB926642 & KB896861. Voici un aperçu de la façon de résoudre le problème. Je désactive généralement le contrôle de bouclage, mais ce n'est pas recommandé pour les environnements de serveur de production.

Méthode 1: Désactiver la vérification de réalimentation d'authentification réactivez le comportement qui existe dans Windows Server 2003 en définissant l'entrée de Registre DisableLoopbackCheck dans la sous-clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa à 1. Pour définir l'entrée de Registre DisableLoopbackCheck-1, procédez comme suit sur l'ordinateur client:

1. Cliquez sur Démarrer, sur Exécuter, tapez regedit, puis cliquez sur OK.
2. Recherchez et cliquez sur la sous-clé de Registre suivante: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Cliquez avec le bouton droit sur Lsa, pointez sur Nouveau et puis cliquez sur Valeur DWORD.
4. Tapez DisableLoopbackCheck, puis appuyez sur ENTRÉE.
5. Cliquez avec le bouton droit sur DisableLoopbackCheck, puis cliquez sur Modifier.
6. Dans la zone Données de la valeur, tapez 1 et puis cliquez sur OK.
7. Quittez l'Éditeur du Registre.
8. Redémarrez l'ordinateur. Remarque Vous devez redémarrer le serveur pour que cette modification prenne effet. Par défaut, la fonctionnalité de vérification de bouclage est activée dans Windows Server 2003 SP1 et l'entrée de Registre DisableLoopbackCheck est définie sur 0 (zéro). La sécurité est réduite lorsque vous désactivez la vérification de bouclage d'authentification et que vous ouvrez le serveur Windows Server 2003 pour les attaques MITM (Man-in-the-middle) sur NTLM.

Méthode 2: Créer les noms d'hôte de l'Autorité de sécurité locale qui peut être référencée dans une demande d'authentification NTLM Pour ce faire, procédez comme suit pour tous les noeuds sur l'ordinateur client:

1. Cliquez sur Démarrer Cliquez sur Exécuter, tapez regedit, puis cliquez sur OK.
2. Recherchez et cliquez sur la sous-clé de Registre suivante: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Cliquez avec le bouton droit sur MSV1_0, pointez sur Nouveau, puis cliquez sur Valeur de chaîne multiple.
4. Dans la colonne Nom, tapez BackConnectionHostNames et appuyez sur ENTRÉE.
5. Cliquez avec le bouton droit sur BackConnectionHostNames, puis cliquez sur Modifier.
6. Dans la zone Données de la valeur, tapez CNAME ou l'alias DNS utilisé pour les partages locaux sur l'ordinateur, puis cliquez sur OK.

Note Type chaque nom d'hôte sur une ligne distincte.

Remarque Si l'entrée de registre BackConnectionHostNames existe en tant que type REG_DWORD, vous devez supprimer l'entrée de registre BackConnectionHostNames. 7. Quittez l'Éditeur du Registre, puis redémarrez l'ordinateur.
"

De:. http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx sur Merci pour ce 05 Juin 2009