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
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les défaillances des pipelines de données pèsent lourdement sur la performance des grandes entreprises
- Les nouvelles menaces liées à l’IA obligent les entreprises à dépasser la seule stratégie de sauvegarde
- Gestion des vulnérabilités : pourquoi seulement 7,6 % des entreprises corrigent les failles critiques en moins de 24 heures
- SMS et e-mails : la notification, un enjeu économique stratégique
Articles les + lus
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
À la une de la chaîne Tech
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
