Présentation des comptes d’utilisateur et de groupe intégrés dans IIS 7

par Saad Ladki

Introduction

Dans les versions antérieures d’IIS, un compte local appelé IUSR_MachineName est créé lors de l’installation. IIS utilise le compte IUSR_MachineName par défaut chaque fois que l’authentification anonyme a été activée. Cela a été utilisé par les services FTP et HTTP.

Il y avait également un groupe appelé IIS_WPG, qui était utilisé comme conteneur pour toutes les identités du pool d’applications. Lors de l’installation d’IIS, toutes les ressources appropriées sur le système ont reçu les droits d’utilisateur appropriés pour le groupe IIS_WPG afin qu’un administrateur ait uniquement besoin d’ajouter son identité à ce groupe lorsqu’il a créé un compte de pool d’applications.

Ce modèle fonctionnait bien, mais avait ses inconvénients : le compte IUSR_MachineName et le groupe IIS_WPG étaient tous deux locaux sur le système sur lequel ils ont été créés. Chaque compte et groupe dans Windows reçoit un numéro unique appelé identificateur de sécurité (SID) qui le distingue d’autres comptes. Lorsqu’une liste de contrôle d’accès est créée, seul le SID est utilisé. Dans le cadre de la conception dans les versions antérieures d’IIS, IUSR_MachineName a été inclus dans le fichier metabase.xml afin que si vous essayiez de copier le metabase.xml d’un ordinateur à un autre, cela ne fonctionnerait pas. Le compte sur l’autre ordinateur aurait un nom différent.

En outre, vous ne seriez pas en mesure de « xcopy /o » ACL d’un ordinateur à un autre, car les SID étaient différents de l’ordinateur à l’ordinateur. Une solution de contournement était d’utiliser des comptes de domaine, mais cela nécessitait l’ajout d’un annuaire Active Directory à l’infrastructure. Le groupe IIS_WPG avait des problèmes similaires avec les droits des utilisateurs. Si vous définissez des listes de contrôle d’accès sur le système de fichiers d’un ordinateur pour IIS_WPG et que vous avez essayé de « xcopy /o » sur un autre ordinateur, cela échouerait. Cette expérience a été améliorée dans IIS 7 et versions ultérieures à l’aide d’un compte et d’un groupe intégrés.

Un compte et un groupe intégrés sont garantis par le système d’exploitation comme ayant toujours un SID unique. IIS 7 et versions ultérieures ont effectué cette opération et vérifié que les noms réels utilisés par le nouveau compte et le nouveau groupe ne seront jamais localisés. Par exemple, quelle que soit la langue de Windows que vous installez, le nom du compte IIS sera toujours IUSR et le nom du groupe sera IIS_IUSRS.

En résumé, IIS 7 et versions ultérieures offrent les éléments suivants :

• Le compte intégré IUSR remplace le compte IUSR_MachineName.
• Le groupe intégré IIS_IUSRS remplace le groupe IIS_WPG.

Le compte IUSR n’a plus besoin d’un mot de passe, car il s’agit d’un compte intégré. Logiquement, vous pouvez le considérer comme étant le même que les comptes NETWORKSERVICE ou LOCALSERVICE. Le nouveau compte IUSR et le groupe IIS_IUSRS sont abordés plus en détail dans les sections ci-dessous.

Présentation du nouveau compte IUSR

Le compte IUSR remplace le compte IUSR_MachineName dans IIS 7 et versions ultérieures. Le compte IUSR_MachineName sera toujours créé et utilisé si vous installez le serveur compatible FTP 6 inclus dans Windows Server 2008. Si vous n’installez pas le serveur FTP inclus dans Windows Server 2008, ce compte n’est pas créé.

Ce compte intégré n’a pas besoin d’un mot de passe et sera l’identité par défaut utilisée lorsque l’authentification anonyme est activée. Si vous recherchez dans le fichier applicationHost.config, vous verrez la définition suivante :

<anonymousAuthentication enabled="true" userName="IUSR" defaultLogonDomain="" />

Cela indique à IIS d’utiliser le nouveau compte intégré pour toutes les demandes d’authentification anonyme. Les avantages les plus importants sont que vous pouvez :

• Définissez les autorisations du système de fichiers pour le compte IUSR à l’aide de l’Explorateur Windows ou de l’un des nombreux outils de ligne de commande.
• Vous n’avez plus besoin de vous soucier des mots de passe arrivant à expiration pour ce compte.
• Utilisez xcopy /o pour copier des fichiers avec leurs informations de propriété et de liste de contrôle d’accès sur différents ordinateurs en toute transparence.

Remarque

Le compte IUSR est similaire à LOCALSERVICE de la manière dont il agit anonymement sur le réseau. Les comptes NETWORKSERVICE et LOCALSYSTEM peuvent agir en tant qu’identité de machine, mais pas le compte IUSR, car cela nécessiterait une élévation des droits utilisateur. Si vous avez besoin que le compte anonyme dispose de droits sur le réseau, vous devez créer un compte d’utilisateur et définir manuellement le nom d’utilisateur et le mot de passe, comme vous l’avez fait par le passé pour l’authentification anonyme.

Pour accorder des droits de compte anonyme sur le réseau à l’aide du Gestionnaire IIS :

1. Cliquez sur Démarrer, tapez INetMgr.exe, puis cliquez sur Entrée. Si vous y êtes invité, cliquez sur Continuer pour élever vos autorisations.
2. Dans la section Connexions, cliquez sur le bouton + à côte du nom de votre ordinateur.
3. Dans le Gestionnaire des services Internet, double-cliquez sur le site que vous souhaitez administrer.
4. Dans Affichage des fonctionnalités, double-cliquez sur Authentification.
5. Sélectionnez Authentification anonyme, puis cliquez sur Modifier dans le volet Actions.
6. Dans la boîte de dialogue Modifier les informations d’identification d’authentification anonyme, cliquez sur l’option Utilisateur spécifique, puis sur Définir.
7. Dans la boîte de dialogue Définir les informations d’identification, entrez le nom d’utilisateur et le mot de passe souhaités, puis cliquez sur OK.

Présentation du nouveau groupe IIS_IUSRS

Le groupe IIS_IUSRS remplace le groupe IIS_WPG. Ce groupe intégré a accès à toutes les ressources système et fichiers nécessaires afin qu’un compte, lorsqu’il est ajouté à ce groupe, puisse agir en toute transparence en tant qu’identité de pool d’applications.

Comme avec le compte intégré, ce groupe intégré résout plusieurs obstacles de déploiement xcopy. Si vous définissez des autorisations sur vos fichiers pour le groupe IIS_WPG (disponible sur les systèmes IIS 6.0) et que vous avez essayé de copier ces fichiers sur un autre ordinateur Windows, le SID du groupe serait différent entre les ordinateurs et les configurations de votre site serait rompu.

Étant donné que le SID de groupe dans IIS 7 et versions ultérieures est le même sur tous les systèmes qui exécutent Windows Server 2008, vous pouvez utiliser « xcopy /o » pour conserver les informations de propriété et de la liste de contrôle d’accès à mesure que vous déplacez des fichiers de l’ordinateur vers l’ordinateur. Cela facilite les déploiements xcopy.

Les versions 7 et supérieures d'IIS facilitent également le processus de configuration de l'identité d'un pool d'applications et la réalisation de toutes les modifications nécessaires. Lorsque IIS démarre un processus de travail, il doit créer un jeton que le processus utilisera. Lorsque ce jeton est créé, IIS ajoute automatiquement l’appartenance IIS_IUSRS au jeton de processus de travail lors de l’exécution. Les comptes qui s’exécutent en tant qu'« identités de pool d’applications » n’ont plus besoin d’être une partie explicite du groupe IIS_IUSRS. Ce changement vous aide à configurer vos systèmes avec moins d’obstacles et à rendre votre expérience globale plus favorable.

Si vous souhaitez désactiver cette fonctionnalité et ajouter manuellement des comptes au groupe IIS_IUSRS, désactivez cette nouvelle fonctionnalité en définissant la valeur manualGroupMembership sur « true ». L’exemple suivant montre comment procéder pour defaultAppPool :

<applicationPools>
    <add name="DefaultAppPool">
        <processModel manualGroupMembership="true" />
    </add>
</applicationPools >