Recevoir une invite de connexion à l'aide de l'authentification Windows intégrée
J'ai une application .NET 3.5 s'exécutant sous IIS 7 sur le serveur Windows 2003 et je ne parviens pas à obtenir l'authentification intégrée Windows fonctionnant correctement car je continue à être invité à ouvrir une session. J'ai défini l'authentification Windows sur Activé dans IIS avec tous les autres types de sécurité désactivés et l'authentification/autorisation de mon fichier web.config d'application est configurée comme suit:
<system.web>
<compilation debug="true" strict="false" explicit="true" targetFramework="3.5" />
<authenticationmode="Windows"/>
<authorization>
<deny users = "?" />
</authorization>
</system.web>
Avec cette configuration, je m'attends à ce que la vérification en arrière-plan de l'utilisateur Windows permette l'accès et refuse les utilisateurs anonymes. Cependant, ce que je reçois est une fenêtre de connexion Windows lorsque j'essaie d'accéder au site.
Je résous ce problème depuis quelques jours et je n'arrive pas à comprendre le problème. Sur la base de publications avec des problèmes similaires, j'ai confirmé que mon adresse URL n'incluait pas de points, j'ai vérifié deux fois que mes paramètres IE étaient définis sur Activer l'authentification intégrée de Windows et ajouté mon adresse URL à mes sites intranet, -up.
Pour résoudre ce problème plus en profondeur, j'ai activé l'authentification anonyme dans IIS et modifié mon fichier web.config, ce qui me permet de l'afficher directement puis d'ajouter Response.Write (System.Security.Principal.WindowsIdentifity.getcurrent (). User.name .toString ()) pour essayer de voir quel utilisateur est utilisé dans l'authentification. Le résultat obtenu est IIS APPPOOL\myapp, qui est évidemment le pool d'applications IIS de mon application.
J'apprécie vraiment toute aide que quiconque peut fournir pour que je n'utilise toujours que l'authentification Windows, mais ne reçois pas la fenêtre contextuelle et l'authentification Windows est effectuée sur l'utilisateur Windows réel.
Merci.
Note supplémentaire après le dépannage supplémentaire:
Je viens de remarquer que lorsque la connexion échoue et que l'invite de connexion Windows s'affiche à nouveau, le nom d'utilisateur qui a tenté de se connecter sous le nom "SERVERNAME"\"USERNAME" s'affiche, ce qui m'a amené à penser qu'il tentait de valider l'utilisateur contre le serveur. domaine. Pour le confirmer, j'ai créé un compte d'utilisateur local directement sur le serveur d'applications avec les mêmes nom d'utilisateur et mot de passe que l'utilisateur du domaine réseau et j'ai essayé de me connecter à nouveau. Le résultat est que j'ai reçu à nouveau l'invite de connexion, mais lorsque j'ai entré le nom d'utilisateur et le mot de passe cette fois, j'ai pu me connecter avec succès. L'utilisateur réseau et le serveur d'applications se trouvent sur le même domaine; vous ne savez donc pas vraiment pourquoi l'authentification IIS pointe vers les comptes du serveur d'applications local et non vers les comptes du domaine. Je me rends compte que c’est une question IIS à ce stade-ci, alors publiez-le également sur forums.iis.net, mais appréciez les conseils que tout le monde peut avoir depuis le dépannage depuis des jours.
Je travaille sur un serveur Windows 2008, ma réponse n'est donc pas tout à fait la même que celle de l'OP sur un serveur Windows 2003.
Voici ce que j'ai fait (enregistrer ici pour pouvoir le retrouver plus tard).
J'avais ce même problème:
Dans mon fichier Web.config , j'avais cette section:
<system.web>
<authentication mode="Windows" />
<authorization>
<allow users="*" />
<deny users="?" />
</authorization>
</system.web>
Sous IIS, tout cela semble être résolu sous l'icône Authentification .
- Modifier les autorisations: assurez-vous que votre compte ASP.NET est autorisé. Le mien n'a pas été ajouté à l'origine.
Entrez maintenant dans les fonctionnalités de Authentification :
Activer Authentification anonyme avec la IUSR:
Activez Authentification Windows , puis cliquez avec le bouton droit de la souris pour définir les Fournisseurs .
NTLM doit être PREMIER!
Ensuite, vérifiez que sous Paramètres avancés ... le Protection étendue est acceptez et activez l'authentification en mode noyau est cochée:
Une fois cela fait, je suis retourné à mon application Web, j'ai cliqué sur le lien Parcourir et je me suis connecté sans avoir à fournir à nouveau mes informations d'identification.
J'espère que cela s'avérera bénéfique pour beaucoup d'entre vous et j'espère que cela me sera utile ultérieurement.
Juste pour le bénéfice des autres. Si l'erreur est un 401.1 Unauthorized et que votre code d'erreur correspond à 0xc000006d, vous vous retrouvez face à une "fonctionnalité" de sécurité qui bloque les requêtes vers un nom de domaine complet ou des en-têtes d'hôte personnalisés qui ne correspondent pas à votre nom d'ordinateur local:
Suivez cet article de support pour résoudre le problème:
http://support.Microsoft.com/kb/896861
Celui-ci m'a pris un certain temps parce que les commentaires de tous les autres ici ne m'ont pas aidé. J'ai trouvé cet article et il l'a corrigé!
J'ai eu un problème similaire dans lequel je voulais protéger seulement une certaine partie de mon site Web. Tout a bien fonctionné sauf dans IE. L’authentification anonyme et l’authentification Windows sont activées . Pour Anonymous, l’identité est définie sur l’identité du pool d’applications. Le problème était avec l'authentification Windows. Après quelques recherches, j'ai lancé le violoniste et découvert qu'il utilisait Kerberos en tant que fournisseur (en réalité, il est défini sur Négocier par défaut). Je suis passé à NTLM et ça a été corrigé . HTH
Daudi
Ajoutez l'autorisation [Utilisateurs du domaine] à votre sécurité Web.
- Faites un clic droit sur votre site dans IIS sous le dossier Sites
- Cliquez sur Modifier les autorisations ...
- Sélectionnez l'onglet Sécurité
- Sous la section Groupe ou noms d'utilisateur, cliquez sur le bouton Modifier ....
- Dans la fenêtre Autorisations, sous le nom du groupe ou de l'utilisateur, cliquez sur Ajouter ...
- Entrez [Utilisateurs du domaine] dans les noms d'objet pour sélectionner la zone de texte et cliquez sur OK pour appliquer le changement
- Cliquez sur OK pour fermer la fenêtre des autorisations.
- Cliquez sur OK pour fermer la fenêtre Propriétés et appliquer vos nouveaux paramètres.
Ne créez pas d'erreurs sur votre serveur en changeant tout. Si vous avez une invite Windows pour vous connecter lors de l’utilisation de l’authentification Windows sur 2008 R2, il suffit d’aller dans Providers et de déplacer UP NTLM pour chaque application . Lorsque Negotiate est le premier liste, l'authentification Windows peut cesser de fonctionner pour une propriété spécifique à une application sur 2008 R2 et vous pouvez être invité à entrer votre nom d'utilisateur et votre mot de passe plus que jamais. Cela se produit parfois lorsque vous avez mis à jour votre application. Soyez juste sûr que NTLM est le premier sur la liste et vous ne verrez plus jamais ce problème.
Cela a résolu le problème pour moi.
Mon serveur et mon ordinateur client sont sous Windows 7 et appartiennent au même domaine.
dans iis7.5-enable l'authentification Windows pour votre Intranet (désactivez toutes les autres authentifications .. également pas besoin de mentionner l'authentification Windows dans le fichier web.config
ensuite, allez sur le PC client .. IE8 ou 9 - Outils - Options Internet - Sécurité - Intranet local - Sites - Avancé - Ajoutez votre site (enlevez le code "Requiert verfi ..."
Internet Explorer 8 ou 9 - Outils - Options Internet - Sécurité - Intranet local - Niveau personnalisé - Authentification - Connexion - Sélectionnez une connexion avec le nom d'utilisateur et le mot de passe actuels
enregistrer ces paramètres .. vous avez terminé .. Plus besoin de demander un nom d’utilisateur et un mot de passe.
Assurez-vous que, puisque votre ordinateur client fait partie du domaine, vous devez disposer d'un GPO pour ces paramètres, .. ou bien ce paramètre sera rétabli lors de la prochaine connexion de l'utilisateur à Windows
Si votre URL contient des points dans le nom de domaine, IE la traitera comme s'il s'agissait d'une adresse Internet et non locale. Vous avez au moins deux options:
- Obtenez un alias à utiliser dans l'URL pour remplacer server.domain. Par exemple, myapp.
- Suivez les étapes ci-dessous sur votre ordinateur.
Allez sur le site et annulez la boîte de dialogue de connexion. Laissez cela arriver:
Dans les paramètres d’IE:
Peut être lié au navigateur. Si vous utilisez Internet Explorer, vous pouvez accéder aux Paramètres avancés et cocher la case "Activer l'authentification intégrée de Windows".
WindowsIdentity.GetCurrent est correct: vous devriez obtenir l'utilisateur APPPOOL. Cela est dû au fait que le processus ASP.NET, qui exécute votre code, est l'identité actuelle. Si vous souhaitez que l'utilisateur renvoyant l'identité du site soit renvoyé, vous devez ajouter la ligne suivante dans votre fichier web.config:
<identity impersonate="true" />
Cela fait en sorte que le processus assume l'identité de l'utilisateur qui demande la page. Toutes les actions étant effectuées en leur nom, toute tentative de lecture de dossiers sur le réseau ou d'accès à des ressources de base de données, etc., signifiera que l'utilisateur actuel aura besoin d'autorisations sur ces éléments. Vous pouvez en savoir plus sur l'emprunt d'identité ici . Notez que, selon la configuration de la topologie de votre serveur Web/base de données, vous pouvez rencontrer des problèmes de délégation avec l'emprunt d'identité activé.
Mais votre problème initial est qu'il semble que l'identité ne peut pas être déterminée et que vous obtenez une fenêtre de connexion. Je noterai que vous n'avez pas besoin du bloc <deny> si vous avez désactivé l'authentification anonyme dans IIS. Nous ne l'incluons jamais (sauf dans les blocs spéciaux <location> et autres), je dirais donc que vous pourriez essayer de l'enlever et d'essayer à nouveau. Tout le reste sonne bien, cependant.
Vous n'avez pas spécifié quel utilisateur exécute le pool d'applications dans IIS. Est-ce un compte personnalisé ou est-ce le compte par défaut? S'il s'agit d'une personnalisation, s'agit-il d'un compte de domaine ou d'un compte local sur le serveur Web? Les comptes personnalisés peuvent parfois nécessiter quelques étapes supplémentaires, telles que l'enregistrement d'un SPN. En outre, il se peut que le compte personnalisé ne détienne pas l'autorisation nécessaire pour résoudre le compte de l'utilisateur entrant.
Vous pouvez également consulter les journaux IIS pour voir quelle réponse est renvoyée. Ce sera probablement un 401, mais il devrait y avoir un sous-numéro après 401.2 ou quelque chose du genre. Ce sous-numéro peut parfois aider à déterminer le problème racine. Cet article KB en énumère cinq.
Dans notre intranet, le problème a été résolu côté client en modifiant les paramètres de sécurité comme indiqué ci-dessous. L'une ou l'autre des cases à cocher à droite a fonctionné pour nous.
Dans mon cas, les paramètres d'autorisation n'étaient pas configurés correctement.
J'ai dû
ouvrir le Règles d'autorisation .NET dans IIS Manager
![open the .NET Authorization Rules in IIS Manager]()
et retirer la Refuser la règle
![remove the Deny Rule]()
J'ai aussi eu le même problème. J'ai essayé la plupart des choses trouvées sur ce forum et d'autres.
Enfin réussi après avoir fait un peu de propre RnD.
Je suis entré dans IIS Paramètres puis dans mon site Web permission options ajouté à mon groupe d'utilisateurs du domaine d'organisations.
Maintenant, comme tous les utilisateurs de mon domaine ont obtenu l'accès à ce site Web, je n'ai pas rencontré ce problème.
J'espère que cela t'aides
Je viens de résoudre un problème similaire avec une application ASP.Net.
Symptômes: Je pouvais me connecter à mon application en utilisant un utilisateur local, mais pas un utilisateur de domaine, même si la machine était correctement jointe au domaine (comme vous le dites dans votre note complémentaire). Dans l'observateur d'événements de sécurité, il y avait un événement avec ID = 4625 "Domain s inconsistent".
Solution: J'ai trouvé la solution ici . Le problème était que mes machines de test étaient des machines virtuelles clonées (Windows Server 2008 R2; un contrôleur de domaine et un serveur Web). Les deux avaient le même SID de la machine, ce qui a apparemment posé des problèmes. Voici ce que j'ai fait:
- Supprimez le serveur Web du domaine.
- Exécutez c:\Windows\System32\Sysprep\Sysprep.exe dans la machine virtuelle.
- Redémarrez la VM.
- Rejoignez le serveur Web au domaine.
Vous perdez certains paramètres dans le processus (préférences utilisateur, adresse IP statique, recréation du certificat auto-signé), mais maintenant que je les ai recréés, tout fonctionne correctement.
J'ai essayé les astuces de configuration IIS ci-dessus et le piratage du registre en boucle, et j'ai revu et recréé les autorisations du pool d'applications et une douzaine d'autres choses sans parvenir à supprimer la boucle d'authentification exécutée sur mon poste de travail de développement avec IIS Express ou IIS 7.5, depuis une session de navigation locale ou distante. J'ai reçu quatre réponses d'état 401.2 et une page vierge. Le même site déployé sur mon IIS 8.5 serveur de transfert fonctionne parfaitement.
Enfin, dans le corps de réponse, le balisage contenant la page par défaut indiquant la réussite de la connexion était la page par défaut. J'ai déterminé que la gestion des erreurs personnalisées pour ASP.NET et HTTP pour l'erreur 401 empêchait/interférait avec l'authentification Windows de mon poste de travail. mais pas le serveur de transfert. J'ai passé plusieurs heures à bidouiller cela, mais dès que j'ai supprimé le traitement personnalisé de l'erreur 401, le poste de travail était revenu à la normale. Je présente cela encore une autre façon de tirer votre propre pied.
Avez-vous essayé de vous connecter avec votre préfixe de domaine, par exemple. Domaine\Nom d'utilisateur? IIS 6 utilise par défaut l'ordinateur hôte comme domaine par défaut. Par conséquent, spécifier le domaine à la connexion peut résoudre le problème.
Dans mon cas, la solution était (en plus des ajustements suggérés ci-dessus) de redémarrer mon ordinateur de développement local/utilisateurs/IIS (serveur d’hébergement) . ajouté au groupe de sécurité AD nouvellement créé - et la stratégie ne s'appliquait pas au compte utilisateur de l'utilisateur jusqu'à ce que je me déconnecte/redémarre mon ordinateur.
J'espère que cela aidera quelqu'un.
L'authentification Windows dans IIS7.0 ou IIS7.5 ne fonctionne pas avec kerberos (fournisseur = Négocier) Lorsque l'identité du pool d'applications est ApplicationPoolIdentityOne doit utiliser le service réseau ou un autre compte intégré . Un autre. La possibilité est d'utiliser NTLM pour que Windows Authenticatio fonctionne (dans l'authentification Windows, les fournisseurs, placez NTLM au premier plan ou supprimez la négociation)
chris van de vijver
J'ai rencontré le même problème avec les informations d'identification, et j'ai fait une recherche rapide et rien sur Internet ne résoudrait le problème. Il a fallu du temps pour trouver le problème, un idiot.
Dans IIS -> Paramètres avancés -> Informations d'identification du chemin physique (est vide)
Dès que j'ai ajouté un ID d'ordinateur (domaine/utilisateur) ayant accès à la machine virtuelle/serveur, l'invite de mot de passe s'arrête.
J'espère que cela t'aides
J'avais ce problème sur .net core 2 et après avoir examiné la plupart des suggestions d'ici, il semble que nous ayons raté un paramètre sur web.config.
<aspNetCore processPath="dotnet" arguments=".\app.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
Le paramètre correct était forwardWindowsAuthToken = "true", cela semble évident maintenant, mais lorsqu'il y a tant de situations pour le même problème, il est plus difficile de déterminer avec précision
Edit: j’ai également trouvé utile l’article Msdn suivant qui passe en revue le problème.
J'ai eu le même problème car l'utilisateur (Identity) que j'avais utilisé dans le pool d'applications n'était pas lié au groupe IIS_IUSRS Ajout de l'utilisateur au groupe et tout fonctionne