Contrôleurs de domaine Windows Server 2008 R2 : Planification soigneuse des contrôleurs de domaine en lecture seule
Paul Yu
Lorsque la sécurité physique fait défaut, il devient essentiel de se focaliser sur la sécurité des données. Windows Server 2008 et Windows Server 2008 R2 offrent pour cela de nouveaux moyens qui semblent adaptés tout particulièrement aux environnements comme les bureaux distants, dans lesquels la sécurité physique peut ne pas être très rigoureuse. Les contrôleurs de domaine en lecture seule (RODC, Read-Only Domain Controllers) sont une nouvelle fonctionnalité des services de domaine Active Directory (AD DS, Active Directory Domain Services) dans les systèmes Windows Server. Ils constituent un changement fondamental dans la manière dont on utilise généralement les contrôleurs de domaine.
Une grande partie des nouvelles fonctionnalités des contrôleurs de domaine en lecture seule ayant un impact sur les aspects clés du processus de conception et de déploiement, il est important de bien comprendre comment en tirer profit dans l'entreprise. Des facteurs critiques en matière de conception et de planification doivent également être pris en compte avant de les introduire dans votre environnement. Les contrôleurs de domaine en lecture seule sont des contrôleurs de domaine qui hébergent des copies complètes en lecture seule de partitions de bases de données Active Directory, une copie en lecture seule de SYSVOL et un jeu d'attributs filtré qui restreint la réplication entrante de certaines données d'applications à partir des contrôleurs de domaine accessibles en écriture.
Par défaut, les contrôleurs de domaine en lecture seule ne stockent pas de manière sélective d'informations d'identification de comptes d'utilisateurs et d'ordinateurs, mais vous pouvez les configurer pour qu'il le fasse. Cet aspect justifie à lui seul l'utilisation de contrôleurs de domaine en lecture seule dans des succursales distantes ou des réseaux de périmètre ne disposant pas de la sécurité physique couramment offerte par les intranets de centre de données. Les contrôleurs de domaine en lecture seule procurent également des fonctionnalités de sécurité moins connues, telles qu'un compte d'accord de ticket Kerberos spécial qui gère les attaques basées sur tickets associées à la compromission des contrôleurs de domaine en lecture seule proprement dits.
Bien que les soucis en matière de sécurité constituent la principale raison de déployer des contrôleurs de domaine en lecture seule, ils procurent également d'autres avantages comme l'évolutivité et la facilité de gestion d'entreprise. En règle générale, les contrôleurs de domaine en lecture seule sont destinés aux environnements qui requièrent une authentification et une autorisation locales mais ne disposent pas de la sécurité physique adéquate pour utiliser sans risque des contrôleurs de domaine accessibles en écriture. Par conséquent, on les rencontre le plus souvent dans des réseaux de périmètre de centre de données ou à des emplacements de succursales.
Une utilisation appropriée des contrôleurs de domaine en lecture seule serait par exemple le cas d'un centre de données qui requiert les services AD DS mais qui, à cause de contraintes de sécurité, ne peut tirer profit de la forêt AD DS d'entreprise dans le réseau de périmètre. Dans ce cas, les contrôleurs de domaine en lecture seule répondent aux conditions de sécurité pertinentes et modifient en conséquence la portée d'infrastructure de l'implémentation AD DS d'entreprise. Il est probable que ce scénario type deviendra de plus en plus fréquent. Il reflète également les modèles AD DS recommandés actuellement pour les réseaux de périmètre, tels que le modèle de forêt d'entreprise étendue.
Contrôleurs de domaine en lecture seule dans les environnements de succursales
Les environnements les plus courants pour les contrôleurs de domaine en lecture seule avec services AD DS sont encore les succursales. Ces types d'environnements sont généralement des points de terminaison dans une topologie réseau Hub and Spoke. Ils sont répartis sur une large étendue géographique, sont en grand nombre, hébergent individuellement de petites populations d'utilisateurs, se connectent aux sites concentrateurs par le biais de liaisons réseaux lentes et non fiables et ne disposent généralement pas d'administrateurs locaux et expérimentés.
Pour les succursales qui hébergent déjà des contrôleurs de domaine accessibles en écriture, il est probablement inutile de déployer des contrôleurs de domaine en lecture seule. Dans ce scénario, en revanche, les contrôleurs de domaine en lecture seule peuvent non seulement répondre aux conditions requises existantes liées aux services AD DS, mais également les dépasser en termes de renforcement de la sécurité, d'amélioration de la gestion, de simplification de l'architecture et de réduction du coût total de possession. Pour les emplacements où les exigences de sécurité ou de gestion empêchent le recours à des contrôleurs de domaine, les contrôleurs de domaine en lecture seule peuvent vous aider à introduire des contrôleurs de domaine dans l'environnement et à fournir un certain nombre de services localisés et bénéfiques.
Même si les nouvelles fonctionnalités et avantages rendent incontournable l'évaluation des contrôleurs de domaine en lecture seule, d'autres facteurs doivent également être pris en compte, tels que la compatibilité des applications et les conditions d'impact sur les services. Ces facteurs sont susceptibles de rendre les déploiements de contrôleurs de domaine en lecture seule inacceptables pour certains environnements.
Par exemple, étant donné que de nombreux services et applications compatibles avec l'annuaire lisent des données à partir des services AD DS, elles devraient continuer de fonctionner avec un contrôleur de domaine en lecture seule. En revanche, si certaines applications requièrent un accès en écriture à tout moment, un contrôleur de domaine en lecture seule peut ne pas être acceptable. Les contrôleurs de domaine en lecture seule dépendent également de la connectivité réseau à un contrôleur de domaine accessible en écriture pour les opérations d'écriture. Bien que les échecs d'opérations d'écriture peuvent être la cause de la plupart des problèmes d'applications bien connus, il existe d'autres problèmes à prendre en compte, tels que les insuffisances ou les échecs d'opérations de lecture, les échecs d'opérations d'écriture-relecture et les échecs d'applications généraux associés au contrôleur de domaine en lecture seule proprement dit.
Au-delà des problèmes d'applications, des opérations utilisateur et de traitement fondamentales peuvent être affectées lorsque la connectivité à un contrôleur de domaine accessible en écriture est perturbée ou perdue. Les services d'authentification de base peuvent par exemple échouer si les mots de passe de comptes ne peuvent pas être mis en cache et ne sont pas mis en cache localement sur le contrôleur de domaine en lecture seule. Il est facile d'atténuer ce problème en faisant en sorte que les comptes puissent être mis en cache par le biais de la stratégie de réplication de mot de passe du contrôleur de domaine en lecture seule, puis en mettant en cache les mots de passe grâce au préremplissage. Ces étapes requièrent également une connectivité à un contrôleur de domaine accessible en écriture.
Outre les autres problèmes d'authentification, les expirations de mots de passe et les verrouillages de comptes sont également touchés de manière significative en cas d'indisponibilité de la connectivité à un contrôleur de domaine accessible en écriture. Les demandes de modification de mot de passe et toute tentative de déverrouillage manuel d'un compte verrouillé continueront d'échouer jusqu'à ce que la connectivité à un contrôleur de domaine accessible en écriture ait été restaurée. La compréhension de ces dépendances et des modifications ultérieures du comportement opérationnel est essentielle afin de garantir le respect des exigences et de tout contrat de niveau de service (SLA).
Il existe plusieurs scénarios généraux dans lesquels vous pouvez déployer des contrôleurs de domaine en lecture seule. Ils sont utiles aux emplacements où il n'existe aucun contrôleur de domaine ou aux emplacements qui hébergent actuellement des contrôleurs de domaine qui vont être remplacés ou mis à niveau vers une nouvelle version de Windows. Bien qu'il existe des considérations de planification spécifiques à chaque scénario, nous allons examiner ici les approches non spécifiques. Elles sont néanmoins propres aux contrôleurs de domaine en lecture seule, plutôt qu'aux contrôleurs de domaine accessibles en écriture traditionnels.
Préplanification
Avant de commencer toute planification RODC formelle, vous devez procéder à une préplanification AD DS soigneuse et fondamentale. Cette phase de préplanification doit inclure des tâches essentielles telles que la validation de la structure logique AD DS existante et la vérification de la prise en charge des exigences techniques et professionnelles existantes par le modèle d'administration et la structure physique AD DS. Il vous faudra également examiner les exigences matérielles, les stratégies de mise à niveau logicielle et les problèmes connus applicables liés au système d'exploitation, ainsi qu'évaluer les conditions préalables pour les services AD DS RODC. Ces informations seront essentielles aux processus de planification et de déploiement. Vous constaterez qu'elles sont bien documentées dans les listes de vérification de déploiement détaillées.
Installation et gestion
Les contrôleurs de domaine en lecture seule proposent une fonctionnalité de gestion substantielle nommée « séparation des rôles d'administrateur ». Celle-ci délègue aux administrateurs autres que les administrateurs de service la capacité à installer et administrer des serveurs RODC sans accorder de droits Active Directory. Il s'agit d'un changement radical par rapport aux considérations traditionnelles liées à la conception des serveurs contrôleurs de domaine, à la délégation de l'administration et aux procédures de déploiement. Cette séparation des rôles prend une importance cruciale avec les applications critiques qui requièrent une installation directe sur un contrôleur de domaine ou pour les emplacements qui hébergent des serveurs uniques à usages multiples.
Rôles de serveurs supplémentaires
En règle générale, il convient de supprimer du serveur tous les rôles qui ne sont pas nécessaires au fonctionnement du contrôleur de domaine en lecture seule. Par conséquent, les seuls rôles que vous devez ajouter aux contrôleurs de domaine en lecture seule sont les rôles de serveurs de catalogue global et DNS. Vous devez installer le rôle de serveur DNS sur chaque contrôleur de domaine en lecture seule de sorte que les clients DNS locaux puissent effectuer la résolution DNS lorsque la connectivité réseau à un contrôleur de domaine accessible en écriture est indisponible. Toutefois, si le rôle de serveur DNS n'est pas installé par le biais de Dcpromo.exe, vous devrez l'installer ultérieurement. Vous devez utiliser Dnscmd.exe pour enrôler le contrôleur de domaine en lecture seule dans les partitions d'annuaires d'applications DNS qui hébergent les zones intégrées à Active Directory. Vous devez également configurer les contrôleurs de domaine en lecture seule comme serveurs de catalogue global de sorte qu'ils puissent effectuer des requêtes de catalogue global et d'authentification simplement à l'aide du contrôleur de domaine en lecture seule. Du point de vue de l'authentification, si le rôle de catalogue global n'est pas une option, vous pouvez recourir à la mise en cache de groupe universel. La réussite de l'authentification sur un contrôleur de domaine en lecture seule peut finalement dépendre de la configuration de la stratégie de réplication de mot de passe du contrôleur de domaine en lecture seule.
Positionnement des contrôleurs de domaine en lecture seule
Le positionnement des contrôleurs de domaine a changé considérablement depuis l'introduction de la stratégie de réplication de mot de passe des contrôleurs de domaine en lecture seule. Ceux-ci doivent être en mesure de répliquer la partition de domaine depuis un contrôleur de domaine accessible en écriture exécutant Windows Server 2008 ou Windows Server 2008 R2 dans le même domaine, car seuls ces contrôleurs de domaine peuvent appliquer les stratégies de réplication de mot de passe pour les contrôleurs de domaine en lecture seule. Pour garantir une réplication correcte, le contrôleur de domaine accessible en écriture doit être placé dans le site AD DS qui possède le lien de sites au coût le plus faible vers le site contenant le contrôleur de domaine en lecture seule.
Si vous ne pouvez pas établir cette configuration, la réplication RODC devra dépendre de l'option Relier tous les liens de sites (synonyme de transitivité de liens de sites) ou de ponts entre les liens de sites qui contiennent le site RODC et le site du contrôleur de domaine accessible en écriture. Si la transitivité des sites ou les ponts entre liens de sites ne sont pas une option envisageable, vous pouvez créer des liens de sites afin de connecter directement le site RODC et le site du contrôleur de domaine accessible en écriture.
Il est conseillé de ne pas placer d'autres contrôleurs de domaine dans le même site AD DS que le contrôleur de domaine en lecture seule, car les opérations clientes peuvent devenir incohérentes et rendre le comportement des clients imprévisible. Des opérations de base telles que l'authentification, les écritures et lectures LDAP et les modifications de mots de passe peuvent toutes se comporter différemment selon les configurations RODC, la version de Windows d'un contrôleur de domaine accessible en écriture et selon que la connectivité à d'autres contrôleurs de domaine accessibles en écriture est disponible ou non. Il convient également de laisser tous les utilisateurs et toutes les ressources d'un même domaine dans un site RODC. Les contrôleurs de domaine en lecture seule ne stockent pas les mots de passe d'approbation et requièrent l'autorisation entre domaines pour transférer les demandes d'authentification vers différents contrôleurs de domaine accessibles en écriture dans chaque domaine. En supposant que les contrôleurs de domaine accessibles en écriture résident dans des sites distincts, toutes les demandes d'authentification entre domaines dépendraient de la connectivité réseau et échoueraient en cas de défaillance de celle-ci.
Évolutivité et réplication
Les contrôleurs de domaine en lecture seule procurent également des avantages en termes d'évolutivité qui sont utiles pour les implémentations AD DS complexes ou à grande échelle. Ils fournissent par exemple une réplication unidirectionnelle. Ainsi, le déploiement de contrôleurs de domaine en lecture seule dans des succursales réduit la charge de performance sur les serveurs tête de pont de site concentrateur qui traitent normalement la réplication entrante pour les contrôleurs de domaine de succursales. Du point de vue du coût total de possession, cela réduit le nombre d'objets de connexion à créer et à gérer. Cela peut également réduire le nombre de contrôleurs de domaine de site concentrateur requis.
Les contrôleurs de domaine en lecture seule apportent également des améliorations en termes d'équilibrage de la charge qui aident à distribuer de manière automatique et homogène des objets de connexion entrants parmi les serveurs tête de pont du site concentrateur. Dans les versions précédentes de Windows, cela nécessitait une intervention manuelle de routine. Désormais, lorsque le vérificateur de cohérence des données sur un contrôleur de domaine en lecture seule détecte qu'un serveur tête de pont est ajouté ou supprimé dans un site concentrateur, il détermine s'il faut faire basculer les partenaires de réplication vers une nouvelle tête de pont. Il exécute pour cela un algorithme et un équilibrage de la charge probabiliste. Si des contrôleurs de domaine en lecture seule sont ajoutés à des emplacements de succursales, le vérificateur de cohérence des données équilibre également les connexions entrantes parmi les serveurs tête de pont du site concentrateur existants.
Mise en cache des informations d'identification
La stratégie de réplication de mot de passe d'un contrôleur de domaine en lecture seule détermine si les comptes peuvent être mis en cache sur ce contrôleur de domaine en lecture seule spécifique. Par défaut, la liste « autoriser » dans la stratégie de réplication de mot de passe indique que vous ne pouvez mettre en cache aucun mot de passe de compte. Elle interdit également de manière explicite la mise en cache de certains comptes. Ce paramètre est prioritaire par rapport aux configurations « autoriser » effectuées manuellement. Comme mentionné plus haut, vous devrez peut-être configurer les stratégies de réplication de mot de passe sur chaque contrôleur de domaine en lecture seule de sorte que les mots de passe des comptes puissent être mis en cache.
Cette étape doit être menée à précaution, car les modifications de stratégie de réplication de mot de passe ont un impact sur la sécurité et sur la disponibilité des services. Par exemple, le scénario par défaut dans lequel aucun compte ne peut être mis en cache procure une sécurité élevée, mais aucun accès hors connexion en cas d'indisponibilité de la connectivité réseau à un contrôleur de domaine accessible en écriture. Inversement, lorsqu'un fort pourcentage des comptes peut être mis en cache (par exemple le groupe d'utilisateurs de domaine), la sécurité est moindre en cas de compromission du contrôleur de domaine en lecture seule, mais le niveau de disponibilité de service est supérieur pour les comptes qui peuvent être mis en cache. Étant donné les exigences techniques et professionnelles uniques parmi différents environnements d'infrastructure, les conceptions de stratégies de réplication de mot de passe varient d'une organisation à l'autre.
Dès que vous aurez établi un modèle de stratégie de réplication de mot de passe, vous devrez configurer la stratégie sur chaque contrôleur de domaine en lecture seule afin de pouvoir mettre en cache les comptes appropriés. En guise de méthode conseillé, vous devez configurer les stratégies de réplication de mot de passe avec des autorisations explicites et ne pas modifier la liste d'exclusion. Celle-ci est essentielle car elle empêche la mise en cache des informations d'identification de comptes critiques (tels que les administrateurs des services AD DS) sur les contrôleurs de domaine en lecture seule.
L'un des autres aspects clés de la conception des stratégies de réplication de mot de passe consiste à déterminer si les comptes qui peuvent être mis en cache seront préremplis avec des mots de passe. Par défaut, les informations d'identification des comptes qui peuvent être mis en cache ne sont réellement mises en cache qu'après l'ouverture de session initiale sur un contrôleur de domaine en lecture seule, lorsque la demande d'authentification est transférée à un contrôleur de domaine Windows Server 2008 ou Windows Server 2008 R2 accessible en écriture et que les informations d'identification sont répliquées sur le contrôleur de domaine en lecture seule. Cela signifie que si la connectivité réseau à un contrôleur de domaine accessible en écriture devient indisponible avant que les comptes qui peuvent être mis en cache ne soient authentifiés auprès d'un contrôleur de domaine en lecture seule, l'ouverture de session échouera bien que les comptes aient été configurés comme pouvant être mis en cache.
Pour résoudre ce problème, vous pouvez préremplir manuellement le cache de mots de passe dès que la stratégie de réplication de mot de passe est configurée et que les comptes sont marqués comment pouvant être mis en cache. Cette opération requiert également une connectivité réseau entre un contrôleur de domaine Windows Server 2008 ou Windows Server 2008 R2 accessible en écriture et le contrôleur de domaine en lecture seule. Vous pouvez effectuer cette opération au préalable lors du processus de déploiement, bien avant que les utilisateurs pouvant être mis en cache ne se connectent pour la première fois.
Vous pouvez utiliser ces conseils fondamentaux en matière de conception architecturale comme base pour votre planification de contrôleurs de domaine en lecture seule. Traitant des principaux aspects liés à la conception, cet article constitue un point de départ idéal pour la conception d'une solution RODC complète et détaillée. Ce processus complexe requiert un effort de temps en vue de réconcilier les nouvelles fonctionnalités et considérations de planification avec les exigences et l'environnement uniques à votre organisation.
Paul Yu* (Paul.Yu@microsoft.com) est Conseiller en chef au sein de Microsoft Consulting Services. Il travaille pour Microsoft depuis 10 ans et propose des solutions d'infrastructure d'entreprise destinées aux grandes sociétés commerciales et aux organisations du secteur public.*