Impossible d’obtenir l’authentification Windows pour fonctionner via local IIS
J'ai donc créé un nouveau projet ASP.NET MVC à l'aide du modèle intranet. web.config contient les valeurs appropriées (par exemple, <authentication mode="windows"/>).
Si je lance l'application Web à l'aide du serveur Web VS, tout se passe bien - la page affiche mon domaine et mon nom d'utilisateur Windows, etc. Cependant, cela fonctionne dans Opera et Safari ainsi que IE et FF, ce qui me dit qu’il n’utilise pas l’autorisation Windows du tout (depuis le meilleur À ma connaissance, cela ne fonctionne dans aucun navigateur, sauf IE/FF).
La prochaine étape consiste à le faire fonctionner via IIS local. Je crée une entrée de fichier hosts pointant vers www.mysite.mydomain vers 127.0.0.1. Donc, dans IIS je crée un site Web avec une liaison vers www.monsite.mydomain, j'active l'authentification Windows et désactive l'authentification anonyme.
J'ai configuré IE et FF pour activer l'authentification Windows comme suit:
C'EST-À-DIRE
- Ajouter une URL au groupe intranet
- S'assurer que l'authentification Windows est activée dans les paramètres avancés
FF
Mettez "www.monsite.mydomain" dans le paramètre de configuration network.automatic-ntlm-auth.trusted-uris.
Mais lorsque je compose mon site www.mysite.mydomain dans IE/FF, je reçois une invite de connexion. Fait intéressant, même lorsque je tape mon identifiant Windows ici, il échoue toujours et me montre l'invite de connexion. encore.
Nous n'avons pas Active Directory ici, mais d'après ce que j'ai compris, cela devrait fonctionner correctement avec un compte local.
Je ne peux penser à rien d'autre que je dois faire. Aucune suggestion?
Edit: nous avons récemment utilisé Active Directory et le problème persiste.
Modifier: lorsque j'annule l'invite de connexion, je suis redirigé vers une page "Erreur détaillée IIS 7.5" avec les informations suivantes:
Erreur HTTP 401.2 - Non autorisé Vous n'êtes pas autorisé à afficher cette page en raison d'en-têtes d'authentification non valides. **
Pour que l'authentification Windows fonctionne, vous devez liste blanche un domaine spécifié dans le fichier hosts.
Copié à partir du lien ci-dessus pour un accès rapide:
- Définissez l'entrée de Registre DisableStrictNameChecking sur 1. Pour plus d'informations sur la procédure à suivre, consultez l'article 281308 dans la Base de connaissances Microsoft.
- Cliquez sur Démarrer, sur Exécuter, tapez regedit, puis cliquez sur OK.
- Dans l'Éditeur du Registre, recherchez et cliquez sur la clé de Registre suivante: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
- Cliquez avec le bouton droit sur MSV1_0, pointez sur Nouveau, puis cliquez sur Valeur multi-chaînes.
- Tapez BackConnectionHostNames, puis appuyez sur Entrée.
- Cliquez avec le bouton droit sur BackConnectionHostNames, puis cliquez sur Modifier.
- Dans la zone Données de la valeur, tapez le nom d'hôte ou les noms d'hôte des sites situés sur l'ordinateur local, puis cliquez sur OK.
- Quittez l'Éditeur du Registre, puis redémarrez le service IISAdmin.
Avez-vous essayé de mettre le domaine devant le nom d'utilisateur?
DOMAIN\username
Si vous ne possédez pas de compte de domaine, essayez de préfixer votre nom d'utilisateur avec le nom de l'ordinateur:
MYCOMPUTER\myusername
J'ai récemment passé trois jours à essayer de résoudre le même problème et cela m'a rendu fou. Cela se produisait sur une configuration à charge équilibrée où l'un des serveurs s'authentifiait correctement tandis que l'autre échouait. L'examen du problème - et éventuellement sa résolution - s'est avéré ne pas être lié à l'environnement à charge équilibrée, cela peut arriver avec n'importe quel serveur lors de l'authentification à l'aide de l'authentification Windows et le serveur est appelé avec un nom différent de celui reconnu par Active Directory.
1. Activer la journalisation Kerberos
Pour diagnostiquer correctement votre problème, vous devez activer la journalisation Kerberos sur la machine hébergeant votre site IIS. Pour ce faire, ajoutez l'entrée de registre suivante:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Ajouter une valeur de Registre LogLevel avec ValueType REG_DWORD et une valeur x1.
Une fois que vous avez activé la journalisation, puis que vous avez essayé de vous authentifier, des erreurs seront consignées dans votre journal des applications Windows. Vous pouvez ignorer l'erreur KDC_ERR_PREAUTH_REQUIRED (cela fait simplement partie de la poignée de main) mais si vous obtenez l'erreur KDC_ERR_C_PRINCIPAL_UNKNOWN cela signifie que votre contrôleur AD ne reconnaît pas votre serveur, par conséquent vous avez besoin suivre les étapes ci-dessous.
2. KDC_ERR_C_PRINCIPAL_UNKNOWN
si vous obtenez KDC_ERR_C_PRINCIPAL_UNKNOWN, cela signifie que le nom "mysite.mydomain.com" est différent de la façon dont l'AD reconnaît votre machine, de sorte qu'il est impossible de fournir un ticket Kerberos valide. Dans ce cas, vous devez enregistrer un nom de principal de service (SPN) pour "'www.mysite.mydomain" sur l'AD.
Exécutez cette commande sur votre contrôleur AD. Vous aurez besoin du privilège d’administrateur de domaine:
Setspn -A HTTP/mysite.mydomain YOUR_MACHINE_HOSTNAME
. Utilisez une identité personnalisée pour votre pool d'applications
Enfin, faites en sorte que le pool d'applications utilise un compte personnalisé appartenant à Active Directory au lieu d'utiliser NetworkService. Cela peut être fait dans les paramètres avancés de votre pool d'applications.
et .. voila.
Remarques: Le problème pourrait (peu probablement) être lié au fait que plusieurs SPN soient enregistrés sur le même ordinateur. Dans ce cas, vous devrez exécuter une commande pour supprimer les SPN en double, mais je doute que ce soit le cas. Essayez également d’ajouter une liaison différente à votre site (qui n’utilise pas de nom personnalisé) comme htttp: // localhost: custom_port_number et voyez si l’authentification fonctionne. Si cela fonctionne, c'est une indication supplémentaire que vous souffrez du même problème que moi.
Vous devriez vérifier si l'authentification Windows est installée/activée. Cela peut paraître bizarre, mais IIS 7, vous devez installer et activer les différentes méthodes d’authentification. Check out http://support.Microsoft.com/kb/942043/ = pour plus d'informations, voir la section citée ci-dessous.
Cause 1
L'application Web est configurée pour utiliser l'authentification Windows intégrée. Cependant, la fonctionnalité d'authentification Windows n'est pas activée. Ou bien, la section de module natif d'authentification Windows intégrée du fichier ApplicationHost.config ou du fichier Web.config n'est pas valide. Pour résoudre ce problème, voir Résolution 1.
Original
Habituellement, lorsque vous essayez d'afficher une page Web asp.net hébergée sur IIS et que vous recevez une invite de connexion, cela ne signifie pas que vos informations d'identification n'ont pas été reçues ou que vous ne l'êtes pas ". t authentifié. Cela signifie que le compte sous lequel votre site Web est exécuté ne dispose pas des autorisations nécessaires pour utiliser les fichiers.
Dans IIS 6 et 7, vous pouvez facilement changer le compte d'utilisateur sous lequel votre pool d'applications s'exécute. Essayez de modifier l'identité du pool d'applications pour un compte avec un accès plus spécifiquement conçu à cet effet. Ou si vous le souhaitez Si vous vous en tenez au compte existant (IUSR_? Service réseau?), vous pouvez accorder à ce compte plus d'autorisations sur le répertoire dans lequel votre site Web est stocké.
Cet article est spécifiquement destiné à BizTalk mais ne contient pratiquement aucune référence et se concentre sur le dépannage des problèmes d'autorisations avec IIS et les pools d'applications: http://msdn.Microsoft.com/en -us/library/aa954062.aspx
Pourquoi IIS local? Pouvez-vous utiliser local IIS Express?
Si oui, essayez ceci. Il semble que IIS Express ait l'authentification Windows définie sur false.
Changement
<windowsAuthentication enabled="false">
sur "true" dans le fichier applicationhost.config (sous le dossier 'C:\Utilisateurs [Profil]\Documents\IISExpress\config'). Cela fonctionne pour moi.
Pour garantir que IIS utilise l'authentification Windows, je pense que vous devriez essayer de désactiver les autres méthodes d'authentification. Si l'authentification anonyme est activée, l'authentification Windows ne fonctionnera pas. Vous pouvez également lire ceci Article de support Microsoft qui décrit IE et IIS en détail).
Après avoir lu la réponse d'Espen Burud, j'ai résolu mon problème en modifiant le fichier web.config de la racine:
<allow users="*" />
à
<deny users="?" />
La page nécessitant une authentification Windows ne se trouve pas à la racine, mais dans un sous-répertoire avec son propre web.config avec deny users ? mais cela n’a pas permis à l’authentification Windows de fonctionner. Apparemment, pour que cela fonctionne, vous devez empêcher les utilisateurs à la racine.
L'authentification anonyme est activée dans le IIS config; cela n'a pas d'importance. Après le changement de web.config ci-dessus, l'authentification Windows a fonctionné.
J'ai eu cette erreur quand j'ai activé l'authentification Windows. Je voulais autoriser l'utilisateur en fonction de la connexion Windows et il n'y a pas de page de connexion dans mon application.
J'ai eu l'erreur corrigée en ajoutant ce qui suit dans mon Web config fichier. Sous la balise system.web, J'ai changé authentication mode="None" à authentication mode="Forms".
Sous la balise appSettings, j'ai ajouté add key="owin:AutomaticAppStartup" value="false"