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


18

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.

Réponses:


10

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.


1
Vous avez dit que personne ne pouvait s'y connecter; mais personne ne pourrait également se connecter à un contrôleur de domaine standard s'il n'avait pas les informations d'identification de domaine appropriées. Alors, où est la sécurité améliorée? À propos du vol: en quoi un DC inscriptible volé serait-il plus dangereux qu'un vol en lecture seule?
Massimo

2
@Massimo - se référant à la connexion, ce n'est un problème que si la personne a des droits de connexion locale, vous avez raison. Cependant, nous les accordons à quelques comptes afin qu'ils puissent vérifier les sauvegardes / échanges de bandes de sauvegarde. Pour la sécurité physique, un DC inscriptible volé vous donne la possibilité de comprendre leurs informations d'identification et leurs mots de passe et de revenir plus tard sur le réseau pour des données supplémentaires ... le RODC ne le fait pas.
TheCleaner

@Massimo - J'ai remarqué dans votre OP que vous avez dit "réplique complète" ... c'est vrai SAUF pour les mots de passe. Il ne reproduit pas les mots de passe, ce qui finit par être la plus grande fonctionnalité de sécurité pour le vol.
TheCleaner

D'accord pour les mots de passe. Mais ne sont-ils pas stockés à l'aide d'un cryptage unidirectionnel, de toute façon? Il est certainement préférable que quelqu'un ne s'en empare pas du tout, mais je ne pense pas que le craquage des mots de passe AD soit si facile.
Massimo

3
Le RODC ne stocke pas les hachages de mot de passe si vous désactivez la mise en cache ... Je crois qu'il stocke le "jeton de connexion". Oui, le client s'authentifie initialement avec le vrai DC dans un emplacement différent. Voir ici: devendrathatte.blogspot.com/2009/04/… et ici: milesconsultingcorp.com/…
TheCleaner

10

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


Brian, merci pour la réponse détaillée, mais je suis toujours aussi curieux qu'auparavant à propos de certaines choses: 1) Si quelqu'un peut mettre la main sur un DC, comment peut-il apporter des modifications au domaine, s'il n'a pas d'administration Compte? Il ne serait même pas en mesure de se connecter. 2) Si quelqu'un vole un DC, comment peut-il obtenir des mots de passe de la base de données AD? Ils sont stockés dans une base de données propriétaire, utilisant un cryptage unidirectionnel (et assez fort, IIRC). 3) Si votre DC est volé et qui l'a volé peut accéder à votre réseau et le reconnecter, quelque chose est définitivement brisé dans votre sécurité ... et aucun RODC ne va le réparer.
Massimo

1
En ce qui concerne 1 et 2, il existe des outils disponibles sur Internet qui prendront volontiers une base de données AD et y lire / écrire directement. Tout ce que vous devez faire est d'insérer le ou les disques durs dans un endroit qui les contient et de les ouvrir à partir d'une autre machine. Convenu de 3 dans une certaine mesure. De nombreuses organisations ont des centaines de DC dans leurs succursales partout dans le monde. Je peux vous dire de première main que l'application de la sécurité physique dans un placard à 10 000 miles de votre bureau est presque impossible.
Brian Desmond

Si un méchant a accès à votre matériel - ce n'est plus votre matériel. Utilisez-vous Bitlocker pour vos DC actuels pour commencer? Sinon, envisagez de faire cela pour commencer ou un autre chiffrement complet du disque ... si les méchants ont vos données - vous êtes SOL ^^
Oskar Duveborn

1

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é.


1

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.


0

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

Voir le court article ici


2
Je ne suis pas d'accord avec la "vitesse". Si les utilisateurs ont besoin de s'authentifier auprès d'un "vrai" contrôleur de domaine, le RODC n'accélère en fait rien: disposer d'un contrôleur de domaine accessible en écriture sur le site au lieu du RODC serait en fait plus rapide .
Massimo

0

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.


Qu'entendez-vous par "aucune modification apportée ne sera reproduite"? Si je peux obtenir un accès administratif à AD, qui est nécessaire pour tout changement de tout, alors je peux me connecter ADUC à un « réel » DC (ou RDP dedans) et faire mes changements directement là - bas . Et si je ne peux pas accéder à l'administration, je ne peux rien faire même si j'ai un DC assis sur ma table.
Massimo

2
@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é.
TheCleaner du

@Massimo Vous n'avez pas besoin d'un accès administratif à AD pour changer quoi que ce soit - démarrez à partir d'un DVD et vous pouvez directement écrire dans les bases de données AD.
Richard Gadsden

0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.