Certains posts dans les newsgroups ainsi qu’un de mes clients m’ont remémoré ce message d’erreur rencontré lorsqu’un utilisateur visite un site web ou tente d’utiliser une application web hostée sur IIS.
Les requêtes/réponses HTTP contiennent deux parties: l’en-tête (header) et le corps (body). L’en-tête contient la plupart du temps des informations techniques échangées entre le client et le serveur; le corps contient des informations orientées utilisateur telles que le contenu d’une page web ou d’un fichier à télécharger par exemple. Le message d’erreur ci-dessus est en fait généré par le serveur parce que la requête envoyée par le client contient un en-tête qui est simplement trop large par rapport à ce que le serveur s’attend à recevoir. Mais qu’est-ce qui peut faire qu’un en-tête devienne si large? Tout dépend de la manière dont le navigateur (browser) est configuré (et parfois même le système d’exploitation sous-jacent dans certains cas), mais la plupart du temps les responsables sont les cookies (header: Cookie) et les informations d’authentification (Header: Autorization).
Lorsqu’on rencontre cette erreur sur un site Internet, il n’y a pas grand ’chose à faire si ce n’est nettoyer ses cookies et espérer que cela fonctionnera après.
Lorsque cette erreur survient dans un environnement intranet où les serveurs web tournent sous IIS et évezntuellement Sharepoint, SQL server reporting services ou Exchange avec OWA, elle est certainement causée par une combinaison des différents facteurs suivants:
- le serveur (ou site) web est configuré pour utiliser l’authentification Windows intégrée et Kerberos en particulier
- le client est capable de s’authentifier en utilisant Kerberos (le poste client et l’utilisateur sont membres d’une forêt Active Directory (AD))
- la taille du jeton de sécurité (security token) est large. Cela peut être causé par le fait que l’utilisateur soit membre de beaucoup de groupes AD (des centaines), que l’objet utilisateur dans AD contienne des informations dans son SID history relatives à des migrations/consolidations de domaines, que les groupes dont l’utilisateur est membre sont aussi affecés par le SID history tout comme l’utilisateur
- Le client envoie des informations d’authentification ET d’autorisation basées sur Kerberos. Contrairement aux méthodes NTLM et Basique qui n’envoient que des informations d’authentification et donc plus petites en taille, Kerberos inclut des informations telles que les groupes dont l’utilisateur est membre (group membership) ainsi que le SID history dans l’entête de la requête.
-> Suivant leur appartenance aux groupes et les informations contenues dans le SID History, certains utilisateurs peuvent être affectés alors que d'autres pas...
Heureusement, il existe plusieurs manières de contourner ce problème, bien que chacune d’entre-elles a ses inconvénients:
Utiliser l’adresse IP dans l’adresse URL au lieu des noms d’hôtes
Puisque Kerberos ne fonctionne qu’avec des noms d’hôtes, l’utilisation d’adresses IP forcera automatiquement la négociation NTLM. Bien sûr, cela ne dégrade pas que la sécurité, mais cela implique également de coder les adresses IP en dur, ce qui est rarement pratique et surtout signifie qu’un et un seul site web est hosté sur votre IIS. De plus, si votre application utilise la “délégation” de credentiels, qui est une caractéristique de Kerberos, cela ne fonctionnera plus (Je pense particulièrement à SQL SRS dans ce cas ou même Exchange OWA lorsqu’utilisé dans un scénario Front End-Back End)
Configurer IIS pour n’utiliser qu’NTLM
Dans le cadre de la configuration de l’authentification intégrée à Windows, vous pouvez simplement configurer IIS afin de n’utiliser que NTLM. Pour ce faire, il suffit de suivre l’article de la base de connaissances de Microsoft (MS KB) suivant: http://support.microsoft.com/kb/215383/fr
Bien que l’impact de cette configuration soit moins importante que celui de la première, il subsiste des problèmes de sécurité et de compatibilité avec Kerberos s’il est requis par votre application.
Configurer IIS pour accepter des en-têtes plus larges
Cela peut se faire en configurant IIS via la base de registres. Il est important de noter que cette configuration s’appliquera à tous les sites web tournant sur le même système qui tourne IIS parce ce paramètre est utilisé au niveau du composant kernel (http.sys). De ce fait, il impactera tous les applications sur ce server.
L’article MS KB suivant explique tous ces settings: http://support.microsoft.com/kb/820129/fr; celui à changer est MaxFieldLength. Cette opération doit se faire avec précautions car cela augmentera la taille de la mémoire utilisée par le système pour prendre en charge les requêtes. Sur un système 32 bits “assez chargé” (entendez: qui reçoit de nombreuses requêtes, non pas quelques requêtes larges), cela peut épuiser les resources allouées au kernel. Si boot.ini est configuré avec le paramètre /3G (éventuellement combiné au paramètre /USERVA), la situation peut empirer puisque moins de mémoire sera disponible pour le kernel. Sur un système 64bits, cette configuration sera sans danger, même si l’application tourne en mode 32 bits puisque c’est maintenu en mode kernel. Bien entendu, faites attention à ce que l’application fait avec ces en-têtes...
Prévoir une cure amaigrissante de vos utilisateurs AD
En réduisant (comprendre optimisant) l’appartenance aux groupes et en retirant les informations contenues dans le SID History des objets AD des utilisateurs et des groupes. Bien que cette solution soit profitable dans tous les scénarios et non pas uniquement ceux concernant l’authentification web (logon plus rapide, utilisation de mémoire réduite sur les serveurs, serveurs de boîte de mail Exchange, ...), cette solution ne doit jamais être implémentée sans une évaluation prudente de l’impact. L’article MS KB suivant explique comment automatiser cette tâche: http://support.microsoft.com/kb/295758/fr
Et maintenant quelques éléments d’information:
- Puisque cette erreur est générée par le driver HTTP.SYS, elle sera enregistrée dans HTTPERR.LOG et non pas dans un autre fichier de W3C. Afin de tracer qui est affecté, il suffit simplement de regarder l'adresse IP mentionnée dans le fichier log. Bien sûr, puisque l'information d'authentification ne peut pas être prise en charge, l’identité de l’utilisateur reste inconnue.
- Afin d’estimer la taille du jeton pour tous type d’utilisations, et non dans ce cas précis, Microsoft met à disposition l’outil suivant : http://www.microsoft.com/downloads/details.aspx?FamilyID=4A303FA5-CF20-43FB-9483-0F0B0DAE265C&displaylang=en
- La manière dont IIS traite les en-têtes et donc l’information relative à l’autorisation est une chose; la manière dont Windows, en général, traite les jetons de large taille en est une autre. Assurez-vous d’être consistant dans la manière dont l’authentification est traitée de bout en bout. Pour plus d’information, référez-vous à l’article MS suivant: http://www.microsoft.com/downloads/details.aspx?familyid=22DD9251-0781-42E6-9346-89D577A3E74A&displaylang=en (en anglais)
- un bon outil de surveillance du réseau (j’aime l’appeler http://www.wireshark.org/) ainsi qu’un bon outil de troubleshooting tel que MS WFetch (http://www.microsoft.com/downloads/details.aspx?FamilyID=b134a806-d50e-4664-8348-da5c17129210&DisplayLang=en) seront de grand aide pour le troubleshooting. Comme d’habitude, MS Logparser sera votre meilleur ami lorsqu’il s’agira d’analyser des log IIS. Jetez un coup d’oeil à ce forum pour vous aider à parser et comprendre HTTPERR.LOG: http://forums.iis.net/1141.aspx ou continuez de lire ce blog pour d’autres scripts LogParser
- Par facilité, j’utilise le terme “Kerberos” pour parler du protocole d’authentification entre un client et le serveur web. Le protocole réellement impliqué est SPNEGO ou “Négociation”, qui comporte plusieurs protocoles d’authentifications. Référez-vous à wikipedia pour plus de détails: http://en.wikipedia.org/wiki/SPNEGO
Marc
(traduit de l’anglais par Anthony)
Contact
Souscrire
Filter by APML