3.3.1. Contrôleur de domaine en lecture seul
Actuellement, s’il n’est pas possible de garantir la sécurité physique des serveurs dans une succursale, deux solutions sont envisageables :
• Les utilisateurs s’identifient via un réseau longue distance (WAN) avec comme inconvénients des temps d’authentification relativement longs.
• Implémenter
3.3. Active Directory sur vos sites distants
un contrôleur de domaine malgré le risque qu’une personne dérobant ce serveur puisse récupérer la base de compte (mot de passe). Avec Windows Serveur "Longhorn" une troisième solution est envisageable :
Placer une copie en lecture seule de la base de données d’annuaire Active Directory à proximité des utilisateurs situés sur les sites non sécurisés. Ainsi, ils profitent d’un temps de connexion accéléré et d’un accès plus efficace aux ressources d’authentification du réseau. Ce nouveau type de contrôleur de domaine introduit par "Longhorn" est nommé Domain contrôleur en lecture seul ou RODC (Read-Only Domain Controller). Attention : ce modèle n’est pas à confondre avec le modèle introduit par NT4 : PDC et BDC (maitre//esclave) et l’infrastructure Active Directory reste bien multi-maître, cependant il sera désormais possible d’assurer son intégrité en limitant son contenu. Voici les caractéristiques des RODC (Longhorn Beta 2)
• Il ne peut pas être Catalogue global
• Pas de communication possible entre deux RODC, donc un seul par site
• Par défaut, sa base ne possède pas de mot de passe "utilisateurs". Ce qui nécessite une utilisation du réseau pour s’identifier. Il est possible à l’aide de la stratégie de réplication des mots de passe de définir ceux qui seront répliqués.
• Réplication unidirectionnelle, c’est un comportement normal puisque la base d’un RODC n’est pas modifiable. Ainsi, le RODC se mettra à jour grâce au contrôleur de domaine "classique" défini lors de son installation.
• Mise en cache des groupes universels activés par défaut.
• Les applications suivantes seront supportées : Applications LDAP, ADFS, DNS, DHCP, FRS V1, DFSR (FRS V2), Group Policy, NAP, PKI, CA, IAS/VPN, DFS, SMS, ADSI queries, MOM Caractéristiques des RODC prévu dans la Beta3 :
• Le support du catalogue global mais uniquement pour l’utilisation des clients Outlook. En effet pour le moment sur un site distant disposant d’un RODC (beta2) vos clients Outlook sont dans l’incapacité de communiquer ! • La possibilité de mettre deux RODC par site. Limitations finales pour le RODC
• Pas de version d’ADAM en lecture seule
• Pas de support d’Exchange Server
• Il ne sera pas possible de répliquer entre eux deux RODC
Téléchargez cette ressource
Mac en entreprise : le levier d’un poste de travail moderne
Ce livre blanc répond aux 9 questions clés des entreprises sur l’intégration du Mac : sécurité, compatibilité, gestion, productivité, coûts, attractivité talents, RSE et IA, et l’accompagnement sur mesure proposé par inmac wstore.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Pourquoi les outils de sécurité ne suffisent plus face aux angles morts de la détection
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- L’analytique prédictive au service de la décarbonation en France
- Ofelia, ex-Bonitasoft, lance une solution d’orchestration IA agentique
Articles les + lus
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
À la une de la chaîne Tech
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
