Je ne m’attendais pas à recevoir un tel retour par mail à ce sujet (si peu passionnant), et je ne parle pas que des sites de référencement. Cela me motiva donc à boucler la boucle en exécutant de nouveaux tests intensifs avec Windows 2008 (SP2) ainsi que Windows 2008 R2 afin de couvrir tous les cas de figure.

En résumé, quand la vérification de la signature PAC va-t ’elle se réaliser ?

Le tableau ci-dessous nous montre les différents scénarios possibles :

OS Serveur / Application ou Service Cible	2003 Serveur pre-SP2	2003 Serveur SP2 et supérieur, avec configuration additionnelle de la base de registre	2008 Serveur, 2008 Serveur R2
File & Print Sharing	PAS de Validation	PAS de Validation	PAS de Validation
Exchange Server	Validation	PAS de Validation	PAS de Validation
SQL Server	Validation	PAS de Validation	PAS de Validation
IIS dont le pool d’application tourne dans le contexte Local System ou Network Service	Validation	PAS de Validation	PAS de Validation
IIS dont le pool d’application tourne dans le contexte d’un utilisateur du domaine	Validation	Validation	Validation

En bref, la seule différence entre Windows Serveur 2003 et 2008/2008R2 est que la base de registre n’a plus à être modifiée puisque la valeur par défaut est inversée depuis 2008.

Une fois de plus, le point important ici est: si vous configurez Kerberos sur une ferme IIS (Sharepoint ou “simple” ASP.Net), la validation PAC sera TOUJOURS effectuée, quoique vous fassiez pour l’en empêcher A MOINS que l’application ne se voit accorder le droit « Autorisation d'agir dans le cadre du système d'exploitation », et en fasse usage.

Si l’application cible s’est vue accorder le privilège seTcb et en fait usage :

Accorder le privilège seTcb n’est pas suffisant parce qu’il sera désactivé par défaut jusqu’à ce que l’application le requière. Mais pourquoi en aurait-elle besoin ? Pour différentes raisons ce privilège peut être nécessaire par l’application du serveur. Deux usages courants sont expliqués dans les sections ci-dessous.

Transition de protocole

La transition de protocole est l’habilité pour une application serveur de déléguer les crédentiels d’un utilisateur vers un service back-end utilisant Kerberos, bien que non soumis de cette manière par le client.

En clair, cela signifie qu’un utilisateur peut être authentifié par un service utilisant des protocoles autres que Kerberos, tels que Basic, NTLM ou digest et que ce service, en utilisant cette particularité, transformera les crédentiels afin de les présenter à un autre serveur.

Exemple : un utilisateur qui s’authentifie à SharePoint en utilisant NTLM, désire utiliser le service de reporting qui tourne sur un second serveur. Le serveur SharePoint fera la transition nécessaire afin de transférer (appelé « déléguer ») les crédentiels de l’utilisateur au serveur SRS en utilisant Kerberos.

Ken Schaefer, MVP IIS, nous en donne un excellent aperçu sur son blog (en anglais) : IIS and Kerberos Part 5 - Protocol Transition, Constrained Delegation, S4U2S and S4U2P.

Services pour l’utilisateur (S4U – Services for user)

Les extensions S4U sont étroitement liées à la transition de protocole. Pour faire très court, elles permettent, sous certaines conditions, à une application d’effectuer un logon pour le compte de l’utilisateur sans connaître son mot de passe.

Cette caractéristique est, par exemple, utilisée dans le produits IAM (Identity Access Management) ou SSO (Single Sign-On) tels que IBM TAM/WebSEAL ou CA SiteMinder.

Pour chacune des technologies, puisque l’utilisateur ne s’authentifie pas à l’origine en utilisant Kerberos, il n’y a pas de PAC à valider.

OK. Mais finalement, pourquoi désactiver la validation PAC est si importante ?

En fait, je ne dirais pas que c’est « si important ». Cela peut permettre d’améliorer les performances sous certaines circonstances. Puisque, pour faire bref, le PAC est vérifié par l’application serveur avant d’accorder un Ticket-Granting-Service (TGS) au client, cela n’est pas effectué à chaque requête tant que le TGS reste valide (note : il existe certaines exceptions à cette règle). MAIS dans certains cas, la vérification initiale peut prendre un certain temps car 1) l’AD du client est distant (en termes de réseau, nombre de sauts, latence, bande passante, …) de l’AD du serveur ou 2) l’AS du client est trop chargé. Cela donne donc la fausse impression que l’authentification du client au serveur est ralentie alors qu’on s’attend à une nette amélioration en passant à Kerberos.

Ressources additionnelles (en anglais)

· MSDN Patterns & Practices - Protocol Transition with Constrained Delegation Technical Supplement

· MSDN Magazine April 2003 - Exploring S4U Kerberos Extensions in Windows Server 2003

· MSDN - [MS-APDS]: Authentication Protocol Domain Support Specification

Marc

(traduit de l’anglais par Anthony)

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)

La sortie de Windows Seven ne tarit pas vraiment le flot de questions sur le répertoire WinSxs, son utilitié et surtout sa taille…

Qu’est-ce que WinSxS?

WinSxS (SxS pour Side-By-Side soit côte-à-côte) est une technologie intégrée à Windows ainsi un emplacement de stockage centralisé pour les fichiers d’installation de Windows, des mises à jours et des application à conditions que celles-ci soient compatibles avec cette technologie.

Les buts de cette technologie sont les suivants:

• Améliorer voire garantir (grâce notamment à d’autres technologie connexe) l’intégrité du système, de ses dépendances et composants additionnels/optionnels
• Palier aux problèmes récurrents de conflits de DLL qui affectent Windows depuis des années.

Un garant de l’intégrité du système?

Windows Vista et à fortiori Seven sont des systèmes modulables, en tous cas, beaucoup plus modulables que XP et ses prédécesseurs. Lors de l’installation, tous les fichiers sont copiés sur le disque dur même si certains sont liés à des fonctionnalités non-activées. Cela évite que par après, à l’activation de celles-ci, on ne se retrouve avec des conflit de version si par exemple, un service pack a été installé entretemps.

Afin d’éviter les manipulations manuelles hasardeuses, les emplacements habituels du systèmes et des applications tels que “C:\Windows” ou “C:\Program Files” sont protégés par des permissions assez strictes qui empêche même l’administrateur ou le compte “SYSTEM” d’y effectuer des modifications de fichiers. Cela évite également toute modification par des processus malveillants même ci ceux-ci exploitent le contexte de sécurité d’un administrateur. Cette protection se voit renforcée grâce à l’UAC (User Account Control), encensé ou décrié, c’est selon…

Seul le compte “TrustedInstaller” (Installateur approuvé) possède les permissions suffisantes pour modifier les fichiers et répertoires stockés dans ces emplacements.. Ce compte est en fait un compte de service, principalement responsable de toutes les installations de mises à jour, service pack, fonctionnalités etc… Il est d’ailleurs propriétaire de la plupart de ces fichiers. Donc, à moins de modifier ces permissions (opération non supportée), aucun moyen modifier le contenu de ces répertoires, WinSxS inclus.

WinSxS, par la même occasion, permet également la désinstallation de Service Pack de manière propre et sans danger pour le système, pour peu que les fichiers originaux soient préservés (voir section “Et peut-on le nettoyer pour faire de la place?”)

La solution aux problèmes de conflits de DLL?

“Avant”, les applications ayant besoin d’un DLL donnée la recherche tout d’abord dans leur propre répertoire d’installation et faute de la trouver, cherchaient ensuite dans divers répertoires (les emplacements et ordre de priorité diffèrent selon la version de Windows et le paramétrage, voir MSDN - Dynamic-Link Library Search Order.

Des DLL bien connus et très utilisées comme comdlg32 ou le runtime C++ par exemple, se retrouvaient à divers endroits à divers niveaux de versions

Actuellement, et pour autant que l’application soit conforme à la technologie SxS, elle expose ses besoin en terme de DLL (et version) sous la forme d’un manifeste (fichier XML de configuration), contenant une liste de “dépendances”.

Pourquoi ce répertoire utilise-t-il autant d’espace disque?

Regardé par le biais d’un explorateur Windows, il semble en effet être un gouffre à Giga et c’est en grande partie le cas car il contient, en gros presque tous les fichiers nécessaires pour installer et maintenir Windows ainsi que les applications installées, à l’exception de celles antérieures à cette technologie bien entendu.

En réalité, beaucoup de fichiers présents dans les sous-répertoires de WinSxS sont des “hardlinks”: un lien de très bas niveau qui pointe vers le fichier réel et se comporte exactement comme lui. Impossible de reconnaitre un hardlink en utilisant la commande DIR ou l’explorateur. L’outil en ligne de commande “FSUTIL hardlink list” permet d’afficher ces hardlink pour un fichier donné mais pas de lister tous ceux présdent dans un répertoire donné. A ma connaissance, seul l’outil non MS “FINDDUPE” permet de lister ceux-ci, via l’option “-hardlink”, voir http://www.sentex.net/~mwandel/finddupe/.

Donc en résumé, l’espace disque utilisé en réalité en moindre que ce que représente le total de WinSxS et des autres répertoires car nombre de “doublons” donnent l’impression contraire. Note: la taille réelle d’un hardlink est en fait négligeable.

Et peut-on le “nettoyer” pour faire de la place?

Malgré ce que certains clament haut et fort dans les forums, il n’existe aucun moyen pour réduire de manière drastique la taille de ce répertoire, qui rappelons-le est moins volumineux que ce que l’Explorateur Windows ou la command DIR pourrait indiquer. Il faut égalemnt garder à l’esprit qu’il ne fera que grandir étant donné les MAJ du système et des applications. En attendant, on peut réduire sa taille de manière modérée par les méthodes suivantes:

• Désinstaller proprement les applications inutiles. Note: retirer des fonctionnalités Windows de réduira en rien sa taille
• Si la désinstallation “propre” s’avère impossible, tenez à l’aides des utilitaires MS suivants: Windows Installer CleanUp et l’Outil de nettoyage d'inscription de correctifs
• Retirer les fichiers liés au Service Pack, au risque toutefois de ne plus pouvour désinstaller ledit service pack. Cela se fait à l’aide des commandes VSP1CLN.exe (Service Pack 1, voir http://technet.microsoft.com/en-us/library/cc709655%28WS.10%29.aspx) et COMPCLN.exe (à partir su service pack 2)

Question subsidiaire: peut-on déplacer ce répertoire?

Pas à ma connaissance!

Est-il nécessaire d’en prendre un backup

Non, ce répertoire est lié au système et applications installées, pas au données des utilisateurs.

Par contre, il rend également le système quasi parfaitement compatible au backup de type “Image”: Winimage, Acronis… Parce que, notamment, il prévient les dépendant sur les sources d’installation externes…

Infos Complémentaires

• MSDN - Windows Resource Protection
• MSDN - Application Installing and Servicing

Marc

Une petite surprise de fin d’année 2009 repointe le bout de son nez début 2010: Sur IIS6, si un site est paramétré pour utiliser l’authentification Windows Intégrée (IWA), le processus W3WP.exe servant ce site est susceptible de planter avec le code de retour 0xffffffff si Windows Server 2003 est en service pack 2 et que la mise à jour KB973917 est installée.

Ce problème est en fait causé par un certain nombre de fichiers d’IIS qui ne sont pas au niveau requis malgré la présence du service pack 2.

Petite procédure pour remettre IIS en ordre de marche et si nécessaire réinstaller cette MAJ

1. Effectuer un inventaire des MAJ actuellement installées, afin de pouvoir les réinstaller si nécessaire par après. Personnellement j’utilise PsInfo pour ce faire (option –h). Mais il existe évidemment d’autres méthodes
2. Ré-appliquer le Service Pack 2
3. Si nécessaire, réinstaller les MAJ en fonction de l’inventaire effectué à l’étape 1
4. Vérifier les niveaux de version des fichiers d’IIS. Voir “Complément d’information”
5. Si nécessaire, réinstaller la MAJ KB973917

Complément d’information

• MS KB: Il est possible qu'Internet Information Services 6.0 ne fonctionne pas correctement après l'installation de KB973917
• MS KB: Description de la mise à jour qui implémente la protection étendue pour l'authentification dans les Services IIS
• MS Security Research & Defense Blog: Extended Protection for Authentication
• MS TechNet: Microsoft Security Advisory (974926) Credential Relaying Attacks on Integrated Windows Authentication
• Blog du Team Support IIS US: VBScript permettant de vérifier les niveau de version de fichiers d’IIS
• Version PowerShell du VBScript mentionné ci-dessus que j’ai adapté librement. Attention: les deux scripts semblent de pas récupérer les niveaux de version correctement sur les plateformes 64-bit, à investiguer donc!

Evidemment, il se peut que IIS plante pour d’autres raisons. Le code de retour devrait dans ce cas vous mettre sur la piste du coupable.

Marc

A plusieurs reprises, il m'a été donné d'aider des administrateurs ou développeurs SharePoint aux prises avec ce comportement pour le moins déconcertant: alors que les utilisateurs peuvent se connecter et s'authentifier au serveur SharePoint sans le moindre problème, les administrateurs ayant ouvert une session localement sur le serveur se voient refusés l'accès à SharePoint tout en recevant l'erreur HTTP 401.1 (Unauthorized: Access is denied).

Ce comportement est, comme souvent avec Microsoft "By Design" depuis le service pack 1 de Windows Server 2003: il a pour but d'augmenter le niveau de sécurité sur un serveur lorsque les conditions suivantes sont d'application:

• La version de l'OS est au moins Windows Server 2003 SP1
• Un utilisateur ou administrateur est loggé localement sur la console du serveur ou via RDP
• Il (ou elle, ne soyons pas macho, le système ne l’étant pas), tente d’accéder à une ressource ou un service utilisant l’authentification NTLM en passant un nom d’hôte pointant vers l’adresse de loopback (127.0.0.1) alors que ce nom d’hôte n’est pas “localhost”

Le résultat étant un “Access Denied” ou en langage HTTP, un 401.1. il est à noter que ce problème pourrait tout aussi bien se produire en accédant à un répertoire partagé, par ex.

Bien mais pourquoi est-ce alors si flagrant dans le cas  de SharePoint? Il existe deux grands cas de figure dans lesquels il est fréquent de recourir à la modification du fichier HOSTS afin de faire pointer une ou plusieurs application web vers l’adresse 127.0.0.1:

• L'indexeur paramétré pour se viser lui-même, et non un autre serveur frontal. Cela se faisant soit manuellement par l’édition du fichier HOSTS, soit en laissant SharePoint s’en charger
• Les machines de développement, afin d’éviter de devoir enregistrer des noms dans le serveur DNS

Il n’est pas rare que des scripts de “warm-up” de SharePoint provoque également le problème.

Plusieurs solutions existent:

• Désactiver complètement cette fonctionnalité, voir l’article de KB suivant: Message d'erreur en utilisant le nom de domaine complet ou l'alias CNAME d'un serveur pour y accéder localement après l'installation de Windows Server 2003 Service Pack 1 : « Accès refusé » ou « Aucun logiciel réseau n'a accepté le chemin réseau fourni »
• Déclarer les noms par lesquels le service sera accédé, voir le même article de KB ci-dessus
• Utiliser Kerberos plutôt que NTLM. Kerberos inclut son propre système de vérification des noms par lequel le service est accédé (Service Principal Name)

Marc