ASP.NET les Problèmes d'Authentification sur IIS7 de l'Utilisateur.L'identité.Le nom est vide pour l'authentification Windows

Nous avons une ASP.NET application sur ASP.NET 4.0 en utilisant MVC 3, qui utilise l'authentification Windows.

Lorsqu'il est exécuté à partir de Visual Studio 2010, tout fonctionne comme prévu, mais pendant la phase de déploiement de IIS7 le Windows de l'utilisateur connecté n'est jamais rempli (vérification de l'Utilisateur.L'identité.Nom). Aucune boîte de dialogue d'invite pour l'identification de l'utilisateur se présente.

Le web.paramètre de configuration:

<authentication mode="Windows" />

Dans IIS, je peux voir que l'authentification Windows est activé, comme l'est Anonyme (désactivation Anonyme résultats dans un 403 Forbidden et aucun contenu montré).

J'ai essayé les deux, l'activation et la désactivation de "l'authentification en mode Noyau" (useKernelMode="true"), mais cela ne semble pas faire de différence. Bien que je me souviens que nous avons eu pour désactiver ce paramètre sur un autre site sur un autre serveur pour obtenir l'authentification fonctionne correctement (peut-être un problème potentiel plus bas dans la pile?).

Dans le cas où il est utile, à partir de IIS est applicationHost.config:

<security>
  <authentication>
    <anonymousAuthentication enabled="true" />
    <digestAuthentication enabled="false" />
    <basicAuthentication enabled="false" />
    <windowsAuthentication enabled="true" useKernelMode="false">
      <providers>
        <clear />
        <add value="NTLM" />
      </providers>
    </windowsAuthentication>
  </authentication>
</security>

Les idées de ce que peut être le problème?

Merci d'avance pour toutes les suggestions.

Mise à jour de 1

J'ai réussi à trouver un autre serveur IIS7 pour tester et j'ai découvert que si j'ai désactivé l'accès Anonyme, tout a fonctionné comme souhaité. Cependant j'ai encore des questions sur l'origine IIS7 serveur, même si j'ai désactiver l'accès Anonyme (je vais garder Anonyme désactivé maintenant). Donc il y a un problème plus bas dans la pile, je suppose. Des idées? Quelque chose que j'ai besoin de fixer comme il va garder popping up et à mordre pour nous j'imagine.

Mise à jour 2

Si je activer l'Authentification Digest sur le problème IIS7 boîte, puis je suis contestées avec l'invite de connexion dialogue et tout fonctionne comme prévu si je fournir les informations d'identification appropriées. Mais le fait d'être interne d'une application web avec des utilisateurs déjà enregistrés dans le domaine nous n'avons pas vraiment envie de le défi de cette façon. Les informations d'identification devrait être passé au travers de la manière la plus transparente qu'il travaille sur la deuxième IIS7 boîte.

Mise à jour 3

Quelques progrès... j'ai trouvé que si l'application web est à la racine et non pas un sous-site, puis de modifier directement le applicationHost.fichier de configuration pour IIS7 pour donner à la suite des paramètres d'authentification permet au site de fonctionner comme prévu:

<authentication>
  <anonymousAuthentication enabled="false" />
  <windowsAuthentication enabled="true">
    <providers>
      <clear />
      <add value="NTLM" />
    </providers>
  </windowsAuthentication>
  <digestAuthentication enabled="false" />
</authentication>

À l'aide de IIS7 de l'INTERFACE utilisateur de configurer l'authentification ne donne pas tout à fait le droit de résultats. l'authentification des éléments sont manquants après pupilles (que je suppose que IIS7 suppose qu'ils sont hérités) ou qu'ils ont le mauvais paramètres (windowsAuthentication semble avoir besoin les fournisseurs de configuration ci-dessus présentent de fonctionner correctement).

Malheureusement, l'application web en question est en fait une sous application, car il y a une version interne (à l'aide de l'authentification windows > www.site.com/internal) et une version externe (à l'aide de l'authentification par formulaires > www.site.com/external). Je ne peux toujours pas l'authentification de travailler comme sous demande encore. Je viens d'obtenir un "Code d'Erreur: 403 Forbidden".

vérifier celui-ci: stackoverflow.com/questions/1067591/...
quel navigateur êtes-vous tester? Si c'est Firefox, vous pourriez vouloir vérifier: addons.mozilla.org/en-US/firefox/addon/... Firefox n'a pas l'authentification windows "activé" correctement hors de la boîte.
Cheers Davide, mais rien n'y fit. Ce gars semblait avoir des problèmes à obtenir l'authentification Windows pour le travail parce qu'il avait raté le web.paramètres de configuration (et ne pouvais donc pas en de VS ou IIS). Tout fonctionne bien pour moi de VS, c'est juste IIS que les choses ne sont pas se comporter comme prévu.
Merci À Chris. J'ai essayé sous IE, Firefox et Chrome. Tous fonctionne bien lorsqu'il est exécuté à partir de VS, mais pas quand sur IIS. Je pense que je suis absent quelque chose sur IIS, ou il y a un problème, il y plus bas dans la pile comme il devrait être assez simple à installer dans la théorie.
avez-vous jamais trouver le problème?

OriginalL'auteur Gavin | 2011-09-28

3

Dans ce cas, c'était un Microsoft ISA Server question. Semble que la demande a été acheminée à l'interne par le biais d'ISA pour le Windows site Authentifié, une fois que ISA a été enlevé le problème a disparu.

Je ne sais pas beaucoup sur les ISA et comment il achemine les requêtes, mais je suppose qu'il doit avoir été le décapage des informations importantes à partir de la demande en raison d'une règle quelqu'un aura configuré.

Comme une note de côté dans le cas où il permet de diagnostiquer similaire configurations: j'ai été informé par l'administrateur réseau personnel que le trafic interne n'a pas été acheminé par ISA, mais d'interroger le site web à l'interne ont montré que ISA était réellement en jeu.

Alors, c'est comment vous avez obtenu les choses de travail? Je suis confus sur exactement ce que cela signifie.
Désolé, ma mémoire n'est pas extensible très bien à 6 ans 😉
Pas de problème. Merci, de toute façon. Je suis en utilisant .Net Core, mais encore assez similaire. Mon problème a été l'ajout d' forwardWindowsAuthToken="true" qui est quelque chose que Microsoft affirme que ce qui est vrai par défaut, mais sans cette propriété, à l'identité de l'utilisateur propriétés sont nulles.

OriginalL'auteur Gavin
0

Vous avez mentionné que le fait de désactiver l'accès anonyme a travaillé sur un autre serveur, mais sur votre serveur principal vous rencontrez des erreurs 403. Donc, je voudrais vérifier le fichier en fonction des autorisations sur le dossier où votre site est en cours d'exécution. Dans le passé, j'ai besoin d'accorder l' \Network Service contrôle total du compte sur le site un dossier et tous les sous-dossiers, ou je dirais expérience erreurs 403. Vérifiez les autorisations de fichier sur le serveur de travail et voir si il y a des différences avec le serveur qui ne fonctionne pas.

Aussi, si ce n'est pas la question, je vous recommande de comparer tous les autres paramètres IIS entre les deux serveurs, puisque vous savez qu'il fonctionne sur l'un et pas l'autre. Trouver la différence.

Merci Paige, mais toujours pas de joie. Service réseau dispose de toutes les autorisations pour les dossiers et est également utilisé par l'Application de la Piscine. Je suis en comparant les serveurs, mais il n'y a pas de différences évidentes jusqu'à présent. Je me demande si c'est quelque chose à voir avec l'ANNONCE de configuration étant différente pour les différentes cases. Va traquer un membre de l'équipe des opérations pour tenter et de poursuivre l'enquête.
vous avez besoin de vérifier les permissions pour le pool d'applications de l'identité qui n'a pas besoin d'être de service réseau.
des acclamations. Dans ce cas, le Service Réseau est en cours d'utilisation par application poolNetwork Service a aussi de l'ensemble des autorisations à des emplacements de fichiers.

OriginalL'auteur Paige Cook

Vous devez vous connecter pour publier un commentaire.