Exporter (0) Imprimer
Développer tout
2 sur 2 ont trouvé cela utile - Évaluez ce sujet

Services de domaine Active Directory : Contrôleurs de domaine en lecture seule

Mis à jour: janvier 2011

S'applique à: Windows Server 2008

Un contrôleur de domaine en lecture seule (RODC) est un nouveau type de contrôleur de domaine du système d’exploitation Windows Server® 2008. Il permet aux organisations de déployer facilement un contrôleur de domaine à des emplacements où la sécurité physique ne peut être garantie. Il héberge des partitions en lecture seule de la base de données des services de domaine Active Directory® (AD DS).

Avant Windows Server 2008, si les utilisateurs devaient s’authentifier auprès d’un contrôleur de domaine sur un réseau étendu (WAN), il n’existait pas de véritable alternative. Dans de nombreux cas, ce n’était pas une solution efficace. Les succursales ne peuvent souvent pas fournir la sécurité physique adéquate qui est requise pour un contrôleur de domaine accessible en écriture. De plus, elles disposent souvent d’une bande passante réseau plutôt limitée lorsqu’elles sont connectées à un site concentrateur. Ces limitations peuvent entraîner l’augmentation de la durée requise pour ouvrir une session. Elles peuvent également gêner l’accès aux ressources réseau.

À compter de Windows Server 2008, une organisation peut déployer un contrôleur de domaine en lecture seule pour résoudre ces problèmes. De ce fait, les utilisateurs se trouvant dans cette situation peuvent profiter des avantages suivants :

  • Sécurité renforcée

  • Ouvertures de session plus rapides

  • Accès plus efficace aux ressources du réseau

Pour plus d’informations sur les contrôleurs de domaine en lecture seule, voir le guide de planification et de déploiement RODC sur le site http://go.microsoft.com/fwlink/?LinkID=135993 (éventuellement en anglais).

À quoi sert un contrôleur de domaine en lecture seule ?

Une sécurité physique inadéquate est la raison la plus courante pour envisager le déploiement d’un contrôleur de domaine en lecture seule. Un contrôleur de domaine en lecture seule permet de déployer de manière plus sécurisée un contrôleur de domaine à des emplacements qui nécessitent des services d’authentification rapides et fiables, mais qui ne peuvent pas assurer la sécurité physique d’un contrôleur de domaine accessible en écriture.

Cependant, votre organisation peut aussi décider de déployer un contrôleur de domaine en lecture seule pour répondre à des besoins administratifs particuliers. Par exemple, une application métier peut devoir être installée sur un contrôleur de domaine pour s’exécuter correctement. Il peut aussi arriver que le contrôleur de domaine soit le seul serveur de la succursale et qu’il doive héberger des applications serveur.

Dans ce cas, le propriétaire de l’application métier doit souvent se connecter au contrôleur de domaine de manière interactive ou utiliser les services Terminal Server pour configurer et gérer l’application. Cette situation crée un risque de sécurité qui peut être inacceptable pour un contrôleur de domaine accessible en écriture.

Un contrôleur de domaine en lecture seule fournit un mécanisme plus sécurisé pour déployer un contrôleur de domaine dans ce scénario. Vous pouvez accorder à un utilisateur du domaine n’ayant pas le statut d’administrateur le droit de se connecter à un contrôleur de domaine en lecture seule tout en minimisant le risque de sécurité par rapport à la forêt Active Directory.

Vous pouvez également déployer un contrôleur de domaine en lecture seule dans d’autres situations où le stockage local de tous les mots de passe de domaine est une menace capitale, par exemple dans un extranet ou dans un rôle lié aux applications.

Qui cette fonctionnalité peut-elle intéresser ?

Les contrôleurs de domaine en lecture seule sont conçus principalement pour être déployés dans un environnement distant ou de succursale. Les succursales présentent généralement les caractéristiques suivantes :

  • Nombre d’utilisateurs relativement réduit

  • Sécurité physique insuffisante

  • Bande passante réseau plutôt limitée vers un site concentrateur

  • Peu de connaissances en informatique

Nous vous recommandons de lire cette section et la documentation connexe sur les contrôleurs de domaine en lecture seule si vous faites partie de l’un des groupes suivants :

  • Planificateurs et analystes informatiques qui procèdent à une évaluation technique du produit

  • Planificateurs et concepteurs informatiques d’entreprise pour une organisation

  • Responsables de la sécurité informatique

  • Administrateurs des services de domaine Active Directory qui s’occupent de succursales de petite taille

Existe-t-il des considérations particulières ?

Pour déployer un contrôleur de domaine en lecture seule, il est nécessaire qu’au moins un contrôleur de domaine accessible en écriture exécute Windows Server 2008 dans le domaine. En outre, le niveau fonctionnel du domaine et de la forêt doit correspondre à Windows Server 2003 ou version ultérieure.

Pour plus d’informations sur les conditions préalables au déploiement d’un contrôleur de domaine en lecture seule, voir Comment préparer le déploiement de cette fonctionnalité ?

Quelles sont les nouvelles fonctionnalités offertes ?

Les contrôleurs de domaine en lecture seule résolvent certains des problèmes qui sont fréquemment rencontrés dans les succursales. Ces emplacements peuvent être dépourvus de contrôleur de domaine. Sinon, ils peuvent avoir un contrôleur de domaine accessible en écriture, mais sans la sécurité physique, la bande passante réseau ou les compétences locales nécessaires à sa prise en charge. Les fonctionnalités suivantes des contrôleurs de domaine en lecture seule atténuent ces problèmes :

  • Base de données AD DS en lecture seule

  • Réplication unidirectionnelle

  • Mise en cache des informations d’identification

  • Séparation des rôles d’administrateur

  • Serveur DNS (Domain Name System) en lecture seule

Base de données AD DS en lecture seule

À l’exception des mots de passe de compte, un contrôleur de domaine en lecture seule contient tous les objets et attributs Active Directory contenus par un contrôleur de domaine accessible en écriture. Par contre, aucune modification ne peut être apportée à la base de données qui est stockée sur le contrôleur de domaine en lecture seule. Les modifications doivent être effectuées sur un contrôleur de domaine accessible en écriture, puis répliquées sur le contrôleur de domaine en lecture seule.

Les applications locales qui demandent un accès en lecture à l’annuaire peuvent l’obtenir. Les applications LDAP (Lightweight Directory Access Protocol) qui demandent un accès en écriture reçoivent une réponse de référence LDAP. Cette réponse les renvoie vers un contrôleur de domaine accessible en écriture, normalement sur un site concentrateur.

Jeu d’attributs filtré pour contrôleur de domaine en lecture seule

Certaines applications qui utilisent les services de domaine Active Directory (AD DS) en tant que magasin de données peuvent contenir des données assimilables à des informations d’identification (telles que des mots de passe, des informations d’identification ou des clés de chiffrement) qu’il est déconseillé de stocker sur un contrôleur de domaine en lecture seule en cas de compromission de ce dernier.

Pour les applications de ce type, vous pouvez configurer dynamiquement un jeu d’attributs dans le schéma pour les objets de domaine qui ne seront pas répliqués sur un contrôleur de domaine en lecture seule. Ce jeu d’attributs est appelé le jeu d’attributs filtré pour contrôleur de domaine en lecture seule. Les attributs qui sont définis dans le jeu d’attributs filtré pour contrôleur de domaine en lecture seule ne peuvent être répliqués sur aucun contrôleur de domaine en lecture seule de la forêt.

Un utilisateur malveillant qui compromet un contrôleur de domaine en lecture seule peut tenter de le configurer de manière à ce qu’il essaie de répliquer les attributs définis dans le jeu d’attributs filtré pour contrôleur de domaine en lecture seule. Si le contrôleur de domaine en lecture seule essaie de répliquer ces attributs à partir d’un contrôleur de domaine exécutant Windows Server 2008, la demande de réplication est refusée. Par contre, si le contrôleur de domaine en lecture seule essaie de répliquer ces attributs à partir d’un contrôleur de domaine exécutant Windows Server 2003, la demande de réplication peut aboutir.

Par conséquent, par mesure de précaution, veillez à ce que le niveau fonctionnel de la forêt corresponde à Windows Server 2008 si vous prévoyez de configurer le jeu d’attributs filtré pour contrôleur de domaine en lecture seule. Lorsque le niveau fonctionnel de la forêt est Windows Server 2008, un contrôleur de domaine en lecture seule compromis ne peut pas être exploité de la sorte car les contrôleurs de domaine exécutant Windows Server 2003 ne sont pas autorisés dans la forêt.

Il est impossible d’ajouter des attributs indispensables au système au jeu d’attributs filtré pour contrôleur de domaine en lecture seule. Un attribut est indispensable au système s’il est nécessaire au bon fonctionnement des services de domaine Active Directory (AD DS), de l’autorité de sécurité locale (LSA), du Gestionnaire des comptes de sécurité (SAM) et des interfaces SSPI spécifiques à Microsoft, telles que le protocole Kerberos. Un attribut indispensable au système a une valeur d’attribut schemaFlagsEx égale à 1 (valeur d’attribut schemaFlagsEx & 0x1 = TRUE).

Le jeu d’attributs filtré pour contrôleur de domaine en lecture seule est configuré sur le serveur qui détient le rôle de maître d’opérations du schéma. Si vous tentez d’ajouter un attribut indispensable au système au jeu d’attributs filtré pour contrôleur de domaine en lecture seule lorsque le contrôleur de schéma exécute Windows Server 2008, le serveur renvoie une erreur LDAP « Active Directory n’a pas pu effectuer l’opération ». Si vous tentez d’ajouter un attribut indispensable au système au jeu d’attributs filtré pour contrôleur de domaine en lecture seule sur un contrôleur de schéma Windows Server 2003, l’opération semble réussir, mais en réalité l’attribut n’est pas ajouté. Par conséquent, il est recommandé que le contrôleur de schéma soit un contrôleur de domaine Windows Server 2008 lorsque vous ajoutez des attributs au jeu d’attributs filtré pour contrôleur de domaine en lecture seule. Cela garantit que les attributs indispensables au système ne sont pas inclus dans le jeu d’attributs filtré pour contrôleur de domaine en lecture seule.

Réplication unidirectionnelle

Comme aucune modification n’est écrite directement sur le contrôleur de domaine en lecture seule, aucune modification ne provient de ce dernier. En conséquence, les contrôleurs de domaine accessibles en écriture qui font office de partenaires de réplication n’ont pas à récupérer de modifications auprès du contrôleur de domaine en lecture seule. Autrement dit, aucune donnée modifiée ou endommagée par un utilisateur malveillant au niveau d’une succursale ne peut être répliquée sur le reste de la forêt à partir du contrôleur de domaine en lecture seule. Cette fonctionnalité permet également de réduire la charge de travail des serveurs tête de pont dans le concentrateur et les efforts nécessaires pour surveiller la réplication.

La réplication unidirectionnelle du contrôleur de domaine en lecture seule s’applique aussi bien à la réplication des services de domaine Active Directory (AD DS) qu’à la réplication DFS (Distributed File System) de SYSVOL. Le contrôleur de domaine en lecture seule procède à la réplication entrante normale des modifications AD DS et SYSVOL.

noteRemarque
Tout autre partage sur un contrôleur de domaine en lecture seule que vous configurez pour répliquer à l’aide de la Réplication DFS serait bidirectionnel.

Mise en cache des informations d’identification

La mise en cache des informations d’identification correspond au stockage des informations d’identification de l’utilisateur ou de l’ordinateur. Les informations d’identification sont constituées d’un petit ensemble d’environ 10 mots de passe qui sont associés aux entités de sécurité. Par défaut, un contrôleur de domaine en lecture seule ne stocke pas les informations d’identification des utilisateurs ou des ordinateurs. Il existe deux exceptions à cette règle, à savoir le compte d’ordinateur du contrôleur de domaine en lecture seule et un compte krbtgt spécial dont dispose chaque contrôleur de domaine en lecture seule. Vous devez explicitement autoriser la mise en cache des autres informations d’identification sur un contrôleur de domaine en lecture seule.

Le contrôleur de domaine en lecture seule est publié en tant que centre de distribution de clés de la succursale. Il n’utilise pas le même compte krbtgt et le même mot de passe que ceux utilisés par le centre de distribution de clés d’un contrôleur de domaine accessible en écriture lorsqu’il signe ou chiffre des demandes de tickets d’accord de tickets (TGT).

Une fois qu’un compte est correctement authentifié, le contrôleur de domaine en lecture seule tente de contacter un contrôleur de domaine accessible en écriture sur le site concentrateur et demande une copie des informations d’identification appropriées. Le contrôleur de domaine accessible en écriture reconnaît que la demande provient d’un contrôleur de domaine en lecture seule et consulte la stratégie de réplication de mot de passe en vigueur pour ce contrôleur de domaine en lecture seule.

La stratégie de réplication de mot de passe détermine si les informations d’identification d’un utilisateur ou d’un ordinateur peuvent être répliquées à partir du contrôleur de domaine accessible en écriture sur le contrôleur de domaine en lecture seule. Si la stratégie de réplication de mot de passe le permet, le contrôleur de domaine accessible en écriture réplique les informations d’identification sur le contrôleur de domaine en lecture seule et ce dernier les met en cache.

Une fois que les informations d’identification sont mises en cache sur le contrôleur de domaine en lecture seule, celui-ci peut traiter directement les demandes d’ouverture de session de cet utilisateur jusqu’à ce que les informations d’identification changent. (Lorsqu’un ticket TGT est signé avec le compte krbtgt du contrôleur de domaine en lecture seule, celui-ci reconnaît qu’il dispose d’une copie mise en cache des informations d’identification. Si un autre contrôleur de domaine signe le ticket TGT, le contrôleur de domaine en lecture seule transfère les demandes à un contrôleur de domaine accessible en écriture.)

En limitant la mise en cache des informations d’identification aux seuls utilisateurs qui se sont authentifiés auprès du contrôleur de domaine en lecture seule, le risque d’exposition des informations d’identification est lui aussi limité en cas de compromission du contrôleur de domaine en lecture seule. En règle générale, seul un petit sous-ensemble d’utilisateurs du domaine dispose d’informations d’identification mises en cache sur un contrôleur de domaine en lecture seule donné. Par conséquent, en cas de vol d’un contrôleur de domaine en lecture seule, seules les informations d’identification mises en cache courent le risque d’être piratées.

Vous pouvez limiter encore plus les risques en laissant la mise en cache des informations d’identification désactivée, mais toutes les demandes d’authentification seront alors transférées à un contrôleur de domaine accessible en écriture. Un administrateur peut modifier la stratégie de réplication de mot de passe par défaut pour permettre la mise en cache des informations d’identification des utilisateurs sur le contrôleur de domaine en lecture seule.

Séparation des rôles d’administrateur

Vous pouvez déléguer des autorisations d’administration locales sur un contrôleur de domaine en lecture seule à n’importe quel utilisateur du domaine sans accorder à cet utilisateur aucun droit sur les contrôleurs du domaine ou d’autres domaines. Cela permet à un utilisateur local d’une succursale d’ouvrir une session sur un contrôleur de domaine en lecture seule et d’effectuer des tâches de maintenance sur le serveur, par exemple en mettant à niveau un pilote. Par contre, cet utilisateur ne peut pas ouvrir de session sur un autre contrôleur de domaine ou exécuter d’autres tâches d’administration dans le domaine. De cette manière, l’utilisateur de la succursale peut disposer par délégation de la capacité à gérer efficacement le contrôleur de domaine en lecture seule dans la succursale, sans pour autant compromettre la sécurité du reste du domaine.

Serveur DNS en lecture seule

Vous pouvez installer le service Serveur DNS sur un contrôleur de domaine en lecture seule. Un contrôleur de domaine en lecture seule peut répliquer toutes les partitions de l’annuaire d’applications utilisées par le serveur DNS, y compris ForestDNSZones et DomainDNSZones. Si le serveur DNS est installé sur un contrôleur de domaine en lecture seule, les clients peuvent l’interroger pour la résolution des noms de la même manière qu’ils interrogent n’importe quel autre serveur DNS.

Néanmoins, le serveur sur un contrôleur de domaine en lecture seule est en lecture seule et, en conséquence, il ne prend pas en charge les mises à jour de client directement. Pour plus d’informations sur les mises à jour de client DNS traitées par un serveur DNS sur un contrôleur de domaine en lecture seule, voir Mises à jour DNS pour les clients situés sur un site de contrôleur de domaine en lecture seule.

Quels paramètres ont été ajoutés ou modifiés ?

Pour prendre en charge la stratégie de réplication de mot de passe des contrôleurs de domaine en lecture seule, les services AD DS de Windows Server 2008 incluent de nouveaux attributs. La stratégie de réplication de mot de passe désigne le mécanisme qui permet de déterminer si la réplication des informations d’identification d’un utilisateur ou d’un ordinateur est autorisée à partir d’un contrôleur de domaine accessible en écriture vers un contrôleur de domaine en lecture seule. La stratégie de réplication de mot de passe est toujours définie sur un contrôleur de domaine accessible en écriture qui exécute Windows Server 2008.

Parmi les attributs AD DS qui ont été ajoutés au schéma Active Directory de Windows Server 2008 pour prendre en charge les contrôleurs de domaine en lecture seule, figurent les suivants :

  • msDS-Reveal-OnDemandGroup

  • msDS-NeverRevealGroup

  • msDS-RevealedList

  • msDS-AuthenticatedToAccountList

Pour plus d’informations sur ces attributs, voir le guide de planification et de déploiement RODC sur le site http://go.microsoft.com/fwlink/?LinkID=135993 (éventuellement en anglais).

Comment préparer le déploiement de cette fonctionnalité ?

Les conditions préalables au déploiement d’un contrôleur de domaine en lecture seule sont les suivantes :

  • Le contrôleur de domaine en lecture seule doit transférer les demandes d’authentification à un contrôleur de domaine accessible en écriture exécutant Windows Server 2008. La stratégie de réplication de mot de passe est définie sur ce dernier pour déterminer si les informations d’identification sont répliquées dans la succursale pour une demande transférée à partir du contrôleur de domaine en lecture seule.

  • Le niveau fonctionnel du domaine doit correspondre à Windows Server 2003 ou version ultérieure afin de prendre en charge la délégation Kerberos contrainte. La délégation contrainte est utilisée pour les appels de sécurité qui doivent être représentés sous le contexte de l’appelant.

  • Le niveau fonctionnel de la forêt doit correspondre à Windows Server 2003 ou version ultérieure afin de prendre en charge la réplication de valeurs liées. Cette configuration augmente le niveau de cohérence de la réplication.

  • Vous devez exécuter une fois adprep /rodcprep dans la forêt pour mettre à jour les autorisations sur toutes les partitions de l’annuaire d’applications DNS de la forêt. De cette manière, tous les contrôleurs de domaine en lecture seule qui sont aussi des serveurs DNS peuvent répliquer les autorisations.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft. Tous droits réservés.