Adresse originale : http://www.iis.net/1026/SinglePageArticle.ashx
Traduit par : Tony Qu (de l'équipe de traduction BluePrint)
Auteur : Vikas Malhotra
Dernière mise à jour : mardi 12 septembre 2006 à 11h48
Introduction Dans les versions précédentes d'IIS, un compte local était créé lors de l'installation appelé IUSR_MachineName. Une fois l'authentification anonyme activée, ce compte IUSR_MachineName est l'identité utilisée par IIS par défaut et il est utilisé dans les services FTP et HTTP. Il existe également un groupe appelé IIS_WPG, qui est le conteneur de tous les comptes du pool d'applications. Lors de l'installation d'IIS, vous devez vous assurer que toutes les ressources système disponibles ont été définies avec les autorisations appropriées pour IIS_WPG. Lorsque l'administrateur crée un nouveau compte de pool d'applications, il vous suffit d'ajouter le nouveau compte (identité) à ce groupe.
Ce modèle fonctionne très bien, mais comme toute autre conception, il a ses inconvénients, le principal étant que le compte IUSR_MachineName et le groupe IIS_WPG sont locaux sur le système sur lequel ils sont créés. Chaque compte ou groupe dans Windows possède un numéro unique appelé SID (Security Identification Number), afin de pouvoir le distinguer des autres comptes ou groupes. Nous utilisons uniquement le SID pour créer l'ACL. Dans le cadre de la conception des versions précédentes d'IIS, nous avons inclus IUSR_MachineName dans le fichier metabase.xml. Si vous essayez de copier metabase.xml d'une machine à une autre, cela ne fonctionnera pas immédiatement car les autres comptes d'une machine utilisent des comptes différents. noms. De plus, vous ne pouvez pas simplement utiliser xcopy /o pour copier l'ACL, car les SID sont différents sur différentes machines. Une solution de contournement consiste à utiliser un compte de domaine, mais vous devrez ajouter un Active Directory à votre schéma. Le groupe IIS_WPG a également le même problème d'autorisations. Si vous définissez une ACL pour le groupe IIS_WPG sur le système de fichiers d'une machine, l'utilisation de xcopy /o pour copier l'ACL sur une autre machine ne réussira pas. IIS comprend ce problème et l'a amélioré en utilisant des comptes et des groupes intégrés dans IIS 7.0.
Les comptes et groupes intégrés sont garantis par le système d'exploitation, ce qui garantit un SID unique et garantit que les nouveaux noms de comptes et de groupes ne sont jamais localisés. Par exemple, quelle que soit la version linguistique de Windows que vous installez, le nom du compte IIS sera toujours IUSR et le nom du groupe sera toujours IIS_IUSRS.
En résumé, dans IIS 7.0 :
le compte intégré IUSR remplace le compte IUSR_MachineName
Le groupe intégré IIS_IUSRS remplace le groupe IIS_WPG
Étant donné que IUSR est un compte intégré, il ne nécessite plus de mot de passe. Logiquement, vous pouvez le considérer comme le compte NETWORKSERVICE ou LOCALSERVICE. Le compte IUSR et le groupe IIS_IUSRS seront présentés plus en détail dans les chapitres suivants.
Comprendre le nouveau compte IUSR Comme mentionné ci-dessus, le compte IUSR remplacera le compte IUSR_MachineName dans IIS 7.0. Le compte IUSR_MachineName sera créé et utilisé uniquement lors de l'installation du serveur FTP. Si FTP n'est pas installé, le compte ne sera jamais créé.
Ce compte intégré ne nécessite pas de mot de passe et sera utilisé comme identité utilisateur par défaut lorsque l'authentification anonyme est activée. Si vous jetez un œil au fichier applicationHost.config, vous trouverez la définition suivante :
Cela indique à IIS d'utiliser le nouveau compte intégré pour toutes les demandes d'authentification anonymes. Le gros avantage de cette procédure est que nous pouvons désormais :
* Définir les autorisations du système de fichiers pour IUSR à l'aide de l'Explorateur Windows ou de nombreux autres outils de ligne de commande.
* Pas besoin de vous soucier de l'expiration du mot de passe de ce compte
* Utilisez xcopy /o pour copier de manière transparente les fichiers, leur propriété et les informations ACL sur différentes machines.
Il est important de mentionner que le compte IUSR est très similaire au compte LOCALSERVICE dans la mesure où il fonctionne de manière anonyme sur le réseau. NETWORKSERVICE et LOCALSYSTEM peuvent fonctionner comme des machines, mais pas IUSR car il s'agit d'une promotion privilégiée. Si vous souhaitez disposer d'un compte anonyme avec accès au réseau, vous devrez créer un nouveau compte utilisateur et définir manuellement le nom d'utilisateur et le mot de passe, tout comme vous avez précédemment configuré l'authentification anonyme. Pour y parvenir dans IIS Manager, vous pouvez :
* Cliquez sur le bouton Démarrer, tapez "INetMgr.exe" et appuyez sur Entrée (si une boîte de dialogue apparaît, appuyez sur Continuer pour augmenter les autorisations).
* Cliquez sur le bouton "+" à côté du nom de la machine dans Connexion
* Double-cliquez sur le site que vous souhaitez gérer dans IIS Manager
* Double-cliquez sur l'élément Authentification sous l'en-tête Nom de la fonctionnalité
* Sélectionnez Authentification anonyme, cliquez sur Modifier sous le titre de la tâche à droite et la boîte de dialogue Spécifier les informations d'identification apparaîtra.
* Cliquez sur l'option Utilisateur spécifique puis appuyez sur le bouton "Définir".
* Entrez le nom d'utilisateur et le mot de passe souhaités, puis appuyez sur OK
pour comprendre le nouveau groupe IIS_IUSRS. Comme mentionné précédemment, le groupe IIS_IUSRS est utilisé pour remplacer le groupe IIS_WPG. Il dispose déjà de droits d'accès à tous les fichiers et ressources système. Le compte est ajouté au groupe et il fonctionnera de manière transparente comme une identité de pool d'applications.
Parce qu'il fonctionne avec des comptes intégrés, ce groupe intégré peut résoudre plusieurs problèmes de déploiement de xcopy. Si vous définissez des autorisations pour IIS_WPG sur les fichiers (cela est possible dans IIS6) et essayez de copier ces fichiers sur un autre système Windows, les paramètres du site peuvent être corrompus car le SID du groupe est différent sur les différentes machines.
Dans IIS7, puisque le groupe SID est le même dans tous les systèmes Longhorn. L'utilisation de « xcopy /o » préserve l'ACL et les informations de propriété lorsque vous déplacez des fichiers d'une machine à une autre, ce qui simplifie grandement les déploiements xcopy !
La deuxième demande des clients est « Une fois que nous avons configuré l'identité du pool d'applications, nous avons besoin d'IIS pour apporter toutes les modifications nécessaires à notre place. » Nous avons accepté ce commentaire et rendu ce processus encore plus simple dans IIS7.0. Lorsque IIS démarre un processus de travail, il doit créer un jeton à utiliser par le processus. Désormais, lorsque nous créons ce jeton, IIS ajoutera automatiquement l'appartenance à IIS_IUSRS au jeton de processus de travail au moment de l'exécution. Cela permettra au compte de s'exécuter en tant que pool d'applications sans faire explicitement partie du groupe IIS_IUSRS. Nous pensons que ce changement vous aidera à configurer votre système plus facilement et à améliorer votre expérience globale.
Si vous souhaitez désactiver cette fonctionnalité et ajouter manuellement des comptes au groupe IIS_IUSRS, vous ne pouvez utiliser cette fonctionnalité qu'en définissant la valeur manualGroupMembership sur true. Voici un exemple de la façon de configurer defaultAppPool pour désactiver cette fonctionnalité :