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

21

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 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 à l' exception de l' 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 - les navigateurs eux-mêmes ne semblent donc pas se soucier de savoir 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 401.2 immédiate : 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 à l' exception de l' 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 un 401. légèrement différent. Aucun sous-code, avec le texte: l' accès est refusé en raison d'informations d'identification non valides.
  • La fonction de rôle IIS d' authentification Windows 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 ne charge si j'éteins l' authentification Windows et activer 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é la solution de contournement indiqué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
HttpSubStatus 2 non autorisé 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 y a une NOTIFY_MODULE_STARTligne 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é
Cache-Control: privé
Type de contenu: texte / html; charset = utf-8
Serveur: Microsoft-IIS / 7.5
WWW-Authenticate: Négocier
Authentification WWW: NTLM
X-Powered-By: ASP.NET
Date: sam.17 déc.2011 23:42:34 GMT
Longueur du contenu: 6399
Prise en charge du proxy: authentification basée sur la session

Éloigné:

HTTP / 1.1 401 non autorisé
Type de contenu: texte / 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 importance 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-t-il pas d'en-têtes WWW-Authenticate lorsque l'authentification Windows semble être installée, chargée et activée exclusivement?

security iis authentication iis-7.5 http-authentication Aaronaught
la source
Voulez-vous capturer un wirehark en texte brut de la tentative d'authentification (changez d'abord votre mot de passe en quelque chose de jetable - nous ne voulons pas que votre vrai mot de passe soit haché sur le net)? Il y a environ 18 mois, un correctif Windows a apporté des modifications à la négociation HTTP NTLM (au fait, les systèmes sont-ils corrigés à fond?), Ce qui a fait exploser l'application d'un fournisseur et m'a donné beaucoup plus d'expérience que je ne l'admets avec l'analyse conversations de négociation.
Shane Madden
@ShaneMadden: Je me dérange un peu à cause de toutes les différentes informations que j'exposerais, mais je peux faire une session Fiddler qui devrait être presque la même, puis je peux au moins anonymiser les IP et ainsi de suite - et en fait, je l'ai déjà fait, les résultats devraient être assez explicites (le client n'affiche pas l'invite d'informations d'identification car le serveur n'en demande pas).
Aaronaught
Oh, intéressant, quelqu'un semble avoir également signalé ce problème sur Stack Overflow - malheureusement pas de réponse.
Aaronaught
@Aaronaught Comment avez-vous obtenu ici un nom d'utilisateur différent de celui de Cooking? Quand j'ai vu cette question pour la première fois, je pensais que c'était quelqu'un qui vous usurpait.
Ward - Rétablir Monica
@Ward: N'importe qui peut modifier son nom d'utilisateur, cela fait partie du profil. C'était mon original, n'utilisez que d'autres sur les sites non techniques.
Aaronaught

Réponses:

14

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

Liste des modules

Sur le serveur, le WindowsAuthenticationmodule géré était là, mais pas le natif WindowsAuthenticationModulemis en évidence ci-dessus. La raison pour laquelle il a été configuré de cette façon est évidente, 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 rencontreront ce problème, assurez-vous que les deux modules sont chargés , car IIS ne vous avertira pas si l'un d'entre eux est manquant.

Aaronaught
la source
Le module managé WindowsAuthentication n'est pas ce à quoi il ressemble. C'est la prise en charge des identités Windows dans ASP.Net, et il est toujours installé (lorsque ASP.Net est installé). Mais le module natif d' authentification Windows est ce qui est installé lorsque vous cochez le composant Windows Auth dans le Gestionnaire de serveur, et c'est ce dont vous avez besoin pour que cette option d'authentification devienne visible dans l'interface graphique d'authentification.
TristanK
@TristanK: Dans ce cas, ce composant a été coché, mais le module n'a pas été installé. (L'option était cependant visible dans l'interface graphique d'authentification - je suis donc presque sûr que l'écran dépend du module géré, pas du module natif.)
Aaronaught
Je pense que cela peut être arrivé de cette façon en raison d'une falsification des fichiers de configuration (probablement ApplicationHost.config). Mais je suppose que peu importe comment tout cela est sorti de la détresse; ça faisait.
Aaronaught
Eh bien, clairement. Windows Auth ne fonctionne pas sauf si quelque chose arrive à le casser; dans ce cas, alors que la question indique que la configuration est identique, cela s'avère faux; donc ça n'a pas fonctionné de la même façon. QED.
TristanK
1
Ce problème de module manquant vient de me mordre dans Windows Server 2012 R2. C'est incroyable qu'il n'y ait aucune indication lorsque cette condition se produit. Quoi qu'il en soit, merci beaucoup pour cette réponse; J'arrachais littéralement mes cheveux!
Rob Davis
4

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

sh1rts
la source
J'ai trouvé que je pouvais basculer entre DisableLoopbackCheck étant 1 et 0 et le changement prendrait effet immédiatement. De plus, vous pouvez voir l'ID d'événement 4625 dans le journal des événements Journal de sécurité avec le message "Le compte n'a pas pu se connecter".
alastairtree
Je vous remercie! 2 jours de dérangement avec l'authentification IIS et les versions .Net seulement pour découvrir que c'est parce que j'utilisais mon fichier hosts pour créer une entrée DNS factice pendant le test d'une migration de site.
JohnLBevan