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

Windows Server 2008 a introduit des contrôleurs de domaine en lecture seule, qui reçoivent une réplique complète de la base de données de domaine mais ne peuvent pas la modifier, tout comme un bon vieux BDC Windows NT.

Je connais tous les tenants et aboutissants techniques de la façon de faire fonctionner ces semi-DC (je viens de passer 70-646 et 70-647), mais je n'ai toujours pas de réponse claire à la question la plus importante de toutes: pourquoi devriez-vous les utiliser ?

Ce commentaire de TheCleaner le résume vraiment pour moi:

@Massimo - oui, vous avez raison. Vous cherchez une raison impérieuse pour un RODC et il n'y en a pas. Il a quelques fonctionnalités de sécurité supplémentaires pour aider à atténuer la sécurité des succursales et n'a vraiment besoin d'être déployé là-bas que si vous n'avez pas déjà de contrôleur de domaine là-bas et que vous êtes anxieux quant à sa sécurité.

C'était la même chose que je pensais ... une petite augmentation de la sécurité, oui, bien sûr, mais certainement pas trop pour en valoir la peine.

Je vais vous donner un scénario réel:

• nous en avons un dans notre succursale en Chine

Nous l'utilisons car il n'y a pas de département informatique là-bas, nous traitons toutes les demandes de comptes AD, etc. ici aux États-Unis. En ayant un RODC là, nous savons:

1. Personne ne peut s'y connecter et essayer de "pirater" AD.
2. Personne ne peut le voler et obtenir quelque chose de valable pour ensuite revenir et "pirater" le réseau plus tard.

En ayant AD / DNS en lecture seule, nous n'avons pas à nous soucier des tentatives de manipulation des données sur le contrôleur de domaine là-bas.

Cela est dû aux fonctionnalités trouvées ici: http://technet.microsoft.com/en-us/library/cc732801%28WS.10%29.aspx

C'est plus de "tranquillité d'esprit" qu'autre chose pour nous ... en plus, cela a permis une installation de serveur très minimale car il s'agissait simplement d'un cœur de serveur avec le rôle RODC installé. Nous l'avons installé sur un ancien serveur 1U avec 2 disques Raid-1 de 18 Go. Nous avons en fait mis 2 d'entre eux dans ... la même configuration exacte en utilisant du matériel non garanti plus ancien que nous avions dans les racks.

Simple, fait ce qu'il doit faire et nous n'avons pas à nous en soucier. Si l'une des boîtes tombe en panne, nous la remplacerons simplement.

J'ai un chapitre entier sur cette fonctionnalité dans mon livre (www.briandesmond.com/ad4/). Le long et le court, c'est que c'est une fonctionnalité de sécurité et pour les organisations distribuées, c'est une affaire énorme.

Il y a deux très gros scénarios ici:

-> Les RODC ne stockent aucun mot de passe par défaut. Cela signifie que si quelqu'un obtient physiquement les disques du serveur, il n'obtient pas tous vos mots de passe utilisateur (et ordinateur).

La réponse correcte si quelqu'un vole un RWDC est de réinitialiser TOUS les mots de passe du domaine, car vous pouvez les considérer comme tous compromis. Il s'agit d'une entreprise majeure.

Avec un RODC, vous ne pouvez dire que mettre en cache les mots de passe du sous-ensemble X des utilisateurs et des ordinateurs. Lorsque le contrôleur de domaine en lecture seule met en cache le mot de passe, il stocke ces informations dans AD. Si le RODC est volé, vous avez maintenant une petite liste de mots de passe qui doivent être réinitialisés.

-> Les RODC se répliquent à sens unique. Si quelqu'un vous volait RWDC, y apportait des modifications et le rebranchait, ces modifications se répliquaient dans l'environnement. Par exemple, ils peuvent s'ajouter au groupe d'administrateurs de domaine ou réinitialiser tous les mots de passe administrateur ou quelque chose. Avec un RODC, ce n'est tout simplement pas possible.

Il n'y a pas d'amélioration de la vitesse, sauf si vous placez un RODC dans un endroit qui n'avait pas de DC auparavant, et il y aura probablement une amélioration de la vitesse dans certains scénarios.

La réponse de TheCleaner est vraiment incorrecte. Il existe BEAUCOUP de scénarios convaincants pour les contrôleurs de domaine en lecture seule et je peux penser à plusieurs déploiements d'entre eux à grande échelle. Ce sont des trucs de sécurité simples, pas des trucs "anaux sur la sécurité".

Merci,

Brian Desmond

MVP Active Directory

Vous avez besoin de RODC lorsque vous avez beaucoup de succursales avec une mauvaise sécurité physique et / ou une connectivité réseau lente ou peu fiable. Exemples:

• Fournisseur médical avec un bureau central et des cliniques vitrines qui se déplacent fréquemment et utilisent DSL / câble pour la connectivité
• Une entreprise avec des installations dans des régions éloignées où l'infrastructure de télécommunications n'est pas fiable ou où vous êtes obligé d'utiliser des réseaux cellulaires ou par satellite.

La plupart des organisations ont des normes de sécurité physique pour les équipements distants. Si vous ne pouvez pas répondre à ces exigences, les contrôleurs de domaine en lecture seule vous permettent de fournir une authentification à haute vitesse pour l'accès aux applications locales et aux partages de fichiers. Ils vous permettent également de limiter le nombre d'informations d'identification stockées sur le serveur. Un serveur compromis ne compromet que les utilisateurs de l'emplacement distant. Un contrôleur de domaine complet avec 75 000 utilisateurs expose tous ces utilisateurs en cas de compromis local.

Si vous travaillez dans une petite entreprise, ce n'est pas grave du tout. Je suis motivé pour les déployer avec BitLocker car les RODC réduisent considérablement les risques de sécurité.

Nous allons utiliser RODC dans une DMZ basée sur cet article TechNet . Configuration d'une nouvelle forêt pour les services Web avec un contrôleur de domaine en lecture seule dans DMZ.

Principalement pour la sécurité, mais aussi pour la vitesse.

Voir le court article ici

Un contrôleur de domaine en lecture seule contient une copie en lecture seule de votre AD et vous en utilisez une dans une succursale où vous n'avez pas de personnel informatique présent et ne pouvez donc pas garantir la sécurité ou l'intégrité de votre salle de serveurs. Dans le cas où le contrôleur de domaine en lecture seule est compromis, vous êtes sûr que quiconque le compromettra n'aura accès à votre AD que dans l'état où il se trouvait au moment de la découverte. Aucune modification apportée ne sera répliquée sur vos principaux contrôleurs de domaine. Cela signifie que quiconque le compromet ne peut pas faire des choses désagréables comme s'élever au niveau de l'administrateur du domaine, verrouiller vos propres administrateurs et avoir leur chemin méchant avec l'ensemble de votre réseau.

Les contrôleurs de domaine en lecture seule sont utiles pour les grandes entreprises, les services d'annuaire d'entreprise concurrents comme Novell eDirectory ont des répliques en lecture seule depuis des années.

Un autre avantage des contrôleurs de domaine en lecture seule est qu'ils vous permettront d'avoir des contrôleurs de domaine fonctionnels pendant que vous effectuez une récupération après sinistre, ce qui implique de supprimer tous les contrôleurs de domaine normaux pour reconstruire Active Directory. Vous n'avez pas à désactiver les contrôleurs de domaine en lecture seule dans ces situations.