Les RODC pour les agences ou succursales

d’elles héberge un petit nombre d’utilisateurs et se connecte via des liaisons réseau lentes et peu fiables aux sites centraux. Par ailleurs, ces agences manquent souvent d’administrateurs chevronnés sur place.

Pour les agences comportant déjà des DC en écriture, le déploiement de RODC est probablement inutile. Toutefois, dans ce type de scénario, les RODC peuvent non seulement répondre aux exigences AD DS existantes, mais aussi aller au-delà par une sécurité renforcée, une gestion améliorée, une architecture simplifiée et un coût total de possession (TCO) plus faible.

Pour les sites dont les exigences de sécurité ou de gestion proscrivent le recours à des DC, les RODC peuvent vous aider à mettre en place des contrôleurs de domaine dans l’environnement et à fournir un certain nombre de services localisés avantageux.

Même si les nouvelles fonctionnalités et les avantages peuvent inciter à évaluer les RODC, d’autres facteurs doivent être pris en compte, notamment les problèmes de compatibilité des applications et les conditions d’impact sur les services. Ces facteurs pourraient rendre inacceptables un déploiement de RODC pour certains environnements.

Par exemple, comme nombre d’applications et de services compatibles avec les annuaires lisent des données à partir d’AD DS, elles doivent rester opérationnelles avec un RODC. Toutefois, si certaines applications nécessitent constamment des accès en écriture, un RODC peut ne pas convenir. Les RODC dépendent aussi de la connectivité réseau vers un DC autorisant les opérations d’écriture.

Même si des échecs d’opérations d’écriture peuvent être la cause de la majorité des problèmes d’applications bien connus, d’autres problèmes doivent être pris en compte, notamment des opérations de lecture médiocre ou en échec, des opérations d’écriture-relecture (write-read-back) en échec, ou encore les défaillances d’application générales associées au RODC proprement dit.

Outre les problèmes d’applications, des opérations fondamentales effectuées par les utilisateurs et les systèmes peuvent être perturbées en cas de coupure de la connectivité vers un DC en écriture. Par exemple, des services d’authentification de base peuvent être défaillants si les mots de passe de comptes n’autorisent pas la mise en cache et ne sont pas placés en cache localement sur le RODC. Il est facile d’atténuer ce problème en autorisant la mise en cache des comptes via une stratégie de réplication des mots de passe (PRP, Password Replication Policy) du RODC, puis en plaçant les mots de passe en mémoire cache via un préremplissage. La réalisation de ces étapes nécessite aussi une connectivité vers un DC en écriture.

En marge d’autres problèmes d’authentification, l’impact sur les expirations de mots de passe et les verrouillages de comptes est considérable si la connexion vers un DC en écriture est indisponible. Les demandes de changement de mots de passe et les tentatives de déverrouillage manuel d’un compte verrouillé échoueront jusqu’au rétablissement de la connectivité vers un DC en écriture. La compréhension de ces dépendances et les changements consécutifs de comportement opérationnel sont critiques pour préserver vos exigences et le respect de contrats de niveau de service (SLA).

Plusieurs scénarios généraux sont disponibles pour le déploiement de RODC. Ils sont utiles sur des sites dépourvus de DC ou hébergeant des DC sur le point d’être remplacés ou mis à niveau vers une version plus récente de Windows. Bien que chaque scénario soit assorti de considérations de planification qui lui sont propres, nous allons mettre l’accent sur des approches non spécifiques. Toutefois, celles-ci sont propres aux RODC et ne s’appliquent pas à des DC en écriture classiques.