web-dev-qa-db-fra.com

Dépannage des problèmes d'authentification Windows (pas de défi) dans IIS 7.5?

Je sais qu'il y a des milliers de rapports de personnes ayant du mal à faire fonctionner l'authentification Windows intégrée avec IIS, mais ils semblent tous conduire à des pages Web qui ne s'appliquent pas ou à des solutions que j'ai déjà essayées. J'ai déjà déployé des dizaines de sites comme celui-ci auparavant, donc soit il se passe quelque chose de bizarre avec le serveur/la configuration, soit je regarde cela depuis trop longtemps et je ne vois pas l'évidence.

Autrement dit, tout fonctionne parfaitement sur ma machine locale, mais tombe en panne sur le serveur de production, qui pour autant que je sache a la exactement la même configuration.

Sur la machine locale:

  • La machine exécute Windows 7 Ultimate, Service Pack 1, IIS 7.5.
  • Le site a été testé avec succès, en utilisant à la fois IIS et VS Web Development Server.
  • La configuration du site IIS a toutes les méthodes d'authentification désactivées sauf Authentification Windows.
  • La machine locale n'est sur aucun domaine.
  • Les fournisseurs configurés sont Negotiate et NTLM (et non Negotiate: Kerberos).
  • La protection étendue est désactivée.
  • Tous les navigateurs testés (IE, Firefox, Chrome) affichent l'invite de défi et me permettent de me connecter au domaine localhost avec mon compte Windows (local).
  • Tous les navigateurs testés fonctionnent également en utilisant une adresse IP locale opaque - donc les navigateurs eux-mêmes ne semblent pas se soucier si le site apparaît "local" ou "distant".
  • J'ai ajouté une ligne d'affichage à la page Web qui montre l'utilisateur actuellement connecté et montre exactement ce à quoi je m'attendais (quel que soit l'utilisateur local avec lequel je me suis connecté).

Sur la machine distante:

  • Le serveur exécute Windows Server 2008 R2, IIS 7.5.
  • Le chargement de la page Web entraîne une erreur immédiate 401.2: Vous n'êtes pas autorisé à afficher cette page en raison d'en-têtes d'authentification non valides. Aucune invite de défi n'apparaît jamais.
  • La configuration du site IIS a toutes les méthodes d'authentification désactivées sauf Authentification Windows.
  • La machine distante n'est sur aucun domaine.
  • Les fournisseurs configurés sont Negotiate et NTLM (et non Negotiate: Kerberos).
  • La protection étendue est désactivée.
  • Sur la machine distante (session de bureau à distance), la même erreur apparaît dans Internet Explorer, que le domaine soit localhost ou l'adresse IP externe.
  • Si j'essaie d'afficher le site Web distant à partir de ma machine locale, l'erreur est toujours 401, mais 401 légèrement différent. Pas de sous-code, avec le texte : L'accès est refusé en raison d'informations d'identification non valides.
  • Le Authentification Windows IIS est installée.
  • Le module WindowsAuthentication est ajouté (au niveau du serveur).
  • La même erreur exacte se produit si je désactive l'authentification Windows et active l'authentification de base.
  • Le site le fait se charge si je désactive l'authentification Windows et active Anonymous (évidemment).
  • J'ai déjà suivi toutes les étapes de dépannage du support Microsoft: Dépannage des erreurs HTTP 401 dans IIS
  • J'ai déjà essayé le solution de contournement montrée sur une autre page de support Microsoft (censé forcer NTLM comme seule méthode).

Enfin, j'ai essayé d'activer FREB pour les erreurs 401.2 et les résultats ne semblent rien me dire d'utile, je ne vois que l'avertissement suivant:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName IIS Web Core
Notification 2
HttpStatus 401
HttpReason non autorisé
HttpSubStatus 2
ErrorCode 2147942405
ConfigExceptionInfo
Notification AUTHENTICATE_REQUEST
ErrorCode L'accès est refusé. (0x80070005)

... cela semble simplement me dire ce que je sais déjà (que c'est simplement rejeter la demande au lieu de négocier les informations d'identification).

La trace indique que le module WindowsAuthentication est correctement chargé car il existe un NOTIFY_MODULE_START ligne avec ModuleName = WindowsAuthentication (et divers autres événements de suivi ASP.NET - [un] heureusement, aucune erreur ou avertissement intéressant ici).

Quelqu'un peut-il me dire ce qui pourrait me manquer ici?

Mise à jour rapide:

Je suis un peu mal à l'aise d'envoyer un vidage Wireshark complet car cela révélerait des adresses IP, des URL et d'autres choses, mais j'ai fait une comparaison côte à côte des réponses HTTP de localhost et du serveur distant dans Fiddler, et cela semble assez auto - quel que soit le problème:

Localhost: 

 HTTP/1.1 401 Non autorisé 
 Contrôle du cache: privé 
 Type de contenu: texte/html; charset = utf-8 
 Serveur: Microsoft-IIS/7.5 
 WWW-Authenticate: Négocier 
 WWW-Authenticate: NTLM 
 X-Powered-By: ASP. NET 
 Date: sam. 17 déc. 2011 23:42:34 GMT 
 Contenu-Longueur: 6399 
 Proxy-Support: Session-Based-Authentication

Télécommande: 

 HTTP/1.1 401 Non autorisé 
 Type de contenu: text/html 
 Serveur: Microsoft-IIS/7.5 
 X-Powered-By: ASP.NET 
 Date: sam., 17 déc. 2011 23:43:13 GMT 
 Longueur du contenu: 1293

Mis à part quelques différences apparemment sans conséquence comme le contrôle du cache, la principale différence est que le serveur distant n'envoie pas les en-têtes WWW-Authenticate au client.

Donc, je suppose que cela réduit la question à: Pourquoi IIS n'envoie pas les en-têtes WWW-Authenticate lorsque l'authentification Windows semble être installée, chargée et exclusivement activée?

securityiisauthenticationiis-7.5http-authentication
21
Aaronaught

Problème résolu. J'ai finalement décidé de comparer côte à côte la liste des modules et il en manquait un. Il s'avère qu'il existe deux modules d'authentification Windows:

Module List

Sur le serveur, le module managé WindowsAuthentication était là, mais pas le WindowsAuthenticationModule natif mis en évidence ci-dessus. La raison pour laquelle il a été configuré de cette façon est une supposition, mais apparemment, si le module natif n'est pas chargé, le module géré se chargera joyeusement et échouera silencieusement.

Donc, pour tous les futurs lecteurs qui rencontrent ce problème, assurez-vous d'avoir les deux modules chargés , car IIS ( ne vous avertira pas si l'un d'eux est manquant.

14
Aaronaught

Nous avons constaté que cela ne résolvait pas nécessairement le problème pour les développeurs travaillant localement sur des sites ASP.NET fonctionnant sous l'authentification Windows. Nous avons trouvé un hack de registre qui désactive la vérification de bouclage; cela l'a corrigé: -

clé de Registre - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Créez un DWORD avec la valeur 1 appelée "DisableLoopbackCheck"

Vous devrez redémarrer la machine pour que le paramètre prenne effet

4
sh1rts