Présentation, installation et configuration de RODC
Discussion générale
Toutes les réponses
-
RODC: partie 1 - Présentation
Mise à jour le Vendredi, 19 Novembre 2010 08:20Sommaire
RODC fait partie des grandes nouveautés qui sont apparues avec la version de Windows Server 2008 et a fait l’objet d’une grande curiosité. D’un premier abord, RODC est un sujet piège car relativement simple à maîtriser et sans réelle complexité. Nous avons donc décidé de traiter le sujet de manière exhaustive.
Nous allons voir en détail dans une série de quatres articles ce que peut nous apporter cette fonctionnalité et les étapes de réalisation. Les deux articles disponibles sur Technet AD DS: Read-Only Domain Controllers et Read-Only Domain Controllers Step-by-Step Guide en seront la pierre angulaire. Ce premier article est consacré à la présentation de la fonctionnalité.
Un contrôleur de domaine Active Directory travaille, et cela en tout logique, à partir d’une base de données qui est constituée de partitions d’annuaire. De façon simplifiée, chaque contrôleur dispose d’un accès en lecture/écriture leur permettant de lire, écrire ou modifier toute type d’information et de les répliquer sur leurs pairs. La particularité principale du contrôleur de domaine en lecture seule est, comme son nom l’indique, d’avoir simplement un accès en lecture seule à la quasi-totalité de la base (en quasi-totalité car nous verrons plus loin que certaines données sensibles ne sont pas répliquées sur le RODC). Si nous ouvrons par exemple la console « Utilisateurs et ordinateurs Active Directory » à partir d'un RODC et que nous accédons aux propriétés d’un utilisateur, nous n’avons pas la possibilité d’ajouter ou de modifier des données mais seulement de les visualiser.
Si la zone DNS est intégrée à Active Directory, elle est soumise aux mêmes contraintes que le reste des données de l’annuaire. Elle n’est accessible quand lecture seule depuis le RODC. Ci-dessous vous pouvez voir que toutes les fonctions de création ou de modification sont grisées depuis la console « gestionnaire DNS » à partir d’un RODC.
Ne pouvant ajouter ou modifier des données de l’annuaire depuis un RODC, la réplication se réalise uniquement d’un contrôleur de domaine accessible en écriture vers un RODC et est donc unidirectionnelle. Dans l’exemple suivant, nous voyons depuis la console « Sites et services Active Directory » que seul le contrôleur de domaine accessible en écriture (SRVAD) est défini comme partenaire de réplication pour le contrôleur de domaine en lecture seule (RODC) et pas l'inverse.
Les fonctionnalités spécifiques du RODC qui attirent notre attention sont :
- La stratégie de réplication de mot de passe: Appelé communément PRP pour Password Replication Policy, cette fonctionnalité vous permettra de définir les comptes dont les mots de passe seront mis en cache sur le RODC. Cela permettra dans un premier temps d’éviter de stocker sur le RODC les mots de passe des comptes sensibles. Dans un second temps, vous éviterez de faire transiter les requêtes d’authentification vers un contrôleur de domaine accessible en écriture pour les comptes où la mise en cache sera autorisée et de ce fait, le RODC assurera l’authentification des utilisateurs même en cas de rupture de vos liaisons WAN. Enfin si le RODC est volé il suffira simplement de réinitialiser les mots de passes des comptes utilisateurs concernés par cette stratégie.
- Filtrage des attributs: les FAS pour Filtered Attribute Set correspondent à des attributs définis par défaut qui ne sont pas répliqués sur le RODC pour des raisons de sécurité. Il est par la suite possible de rajouter des attributs en fonction des besoins et des contraintes de sécurité se posant dans votre architecture. A noter que si vous envisagez l’utilisation des FAS et même en allant plus loin si vous désirez que cette fonctionnalité soit pleinement opérationnelle, il sera nécessaire de passer le niveau fonctionnel de votre forêt en 2008 et s’assurer que le maître de schéma est hébergé sur un 2008.
- Délégation d’administration: L’ASR pour Adminitration Role Separation permet de déléguer l’administration du RODC à un utilisateur ou un groupe d’utilisateurs sans pour autant octroyer des droits sur le domaine. De façon simplifiée, cette délégation est assez similaire aux droits d’administrateur local que l’on peut trouver sur des ordinateurs ou serveurs membres du domaine.
Ces trois fonctionnalités sont vu en détail depuis les articles RODC: partie 3 - Configuration de PRP et RODC: partie 4 - Configuration de FAS et ARS.
- Un accès total en lecture seule à la base annuaire
- Un accès en lecture seule de la zone DNS intégrée à Active Directory
- Une mise en cache des informations d’authentification et filtrage des attributs
- Une réplication unidirectionnelle
- Une séparation des rôles administratifs
Dans un grand nombre de structures constituées de plusieurs sites, la question de mettre en place un contrôleur de domaine sur les sites annexes peut se poser. Entre l’authentification et l’application de stratégies, les ouvertures de sessions peuvent être souvent longues car la bande passante est souvent limitée et peu optimisée pour ce type d’opération sans la mise en place d’un contrôleur de domaine.
D’un autre côté, la mise en place d’un contrôleur de domaine sur un site distant n’ayant pas à disposition de technicien à-même de le gérer ni d’un endroit approprié pour le stocker de manière sécurisée représentaient un réel frein. Il faut, en général, soit attendre que le site annexe prennent de l’ampleur ou que les utilisateurs fassent tout simplement contre mauvaise fortune bon cœur. Dans d’autres cas, certaines applications exigent d’être hébergées sur des contrôleurs et dans ce cas-là, c’est le service informatique qui fait contre mauvaise fortune bon cœur car malheureusement les contraintes fonctionnelles priment sur les contraintes de sécurité.
Une prise de conscience chez Microsoft de ces différents points a donc amené à la création de cette nouvelle fonctionnalité à partir de la version 2008 pour répondre aux besoins suscités que nous récapitulons:
- Améliorer les performances sur les sites annexes (optimisation et limitation des flux inter-sites...)
- Adapter la sécurité à la configuration des lieux (risques de sécurité réduits au niveau physique et applicatif)
- Limiter les tâches de gestion et d’administration (intervention limitée de façon ponctuelle et délégation spécifique)
Vous avez l'article Technet Deciding Which Type of Domain Controller Meets the Needs of a Branch Office Location pour appuyer le choix d’un déploiement d'un RODC.
Nous avons donc défini dans cette première partie et dans les grandes lignes la fonctionnalité RODC sur Windows Server 2008 et ce qu'elle peut vous apporter au sein de votre infrastructure. Si vous êtes intéressé par RODC, vous pouvez maintenant aller plus loin dans sa découverte et consulter l'article suivant RODC: partie 2 - Préparatifs et installation.
-
RODC: partie 2 - Préparatifs et installation
Mise à jour le Vendredi, 19 Novembre 2010 08:28Sommaire
Après vous avoir présenté la fonctionnalité RODC depuis notre article RODC: partie 1 - Présentation nous allons maintenant passer à son installation en nous attardant premièrement sur les pré-requis à sa mise en place.
Pour assurer la pertinence de la mise en place d'un RODC au sein de votre infrastructure vous devez disposer d’un réseau WAN constitué d’au moins deux sites. Sauf dans le cas où vous voudriez profiter des avantages des rôles administratifs, mettre un RODC sur un site unique ne vous apportera que peu de choses. Il en va de même pour un site disposant déjà d’un contrôleur de domaine accessible en écriture.
Veuillez noter que votre premier contrôleur de domaine racine ou enfant ne peut être un RODC du fait qu’il ne gère pas les réplications sortantes, n’a pas d’accès en écriture sur la base d’annuaire et qu’il ne peut se voir attribuer le moindre maîtres d’opérations.
Techniquement, il est nécessaire de respecter ou de prendre en compte les points suivants:
- Les niveaux fonctionnels: Vous devez disposer d’un niveau fonctionnel de forêt et de domaine en 2003 ou supérieur.
- Les versions des schémas: Les versions du schéma de la forêt et du domaine doivent être au minimum en 2008. Il faudra également modifier le schéma pour accueillir la fonctionnalité RODC qui nécessite une mise à jour particulière.
- La version de vos contrôleurs de domaine: Pour chaque RODC en version 2008 ou 2008 R2 déployé sur un domaine, vous devez avoir au minimum un serveur en version 2008 à disposition sur chacun de ces domaines pour la réplication. Pour assurer la tolérance de panne, il est même conseillé de disposer d’au moins deux contrôleurs 2008 en écriture. Si le RODC est en 2008 R2 et que vous ne disposez que de contrôleurs 2008 en écriture alors certaines erreurs dans le journal d’évènements pourront apparaitre mais que vous pouvez totalement occulter (event id 1699).
- La version de vos postes clients: Côté client, les versions 2000 ne sont pas supportées. Des versions ultérieures jusqu’à Vista, il sera nécessaire d’appliquer un hotfix disponible ici. A partir de Vista SP1, la compatibilité est native avec RODC. Vous avez des informations exhaustives depuis l'article Technet Known Issues for Deploying RODCs.
- Prise en charge des FAS (Filtered Attribute Set): Pour gérer le filtrage des attributs, il sera impératif de placer le rôle maître de schéma sur un contrôleur en version 2008. Et il est fortement recommandé de passer le niveau fonctionnel de votre forêt en 2008.
- Placement du catalogue global: Il est fortement conseillé de mettre le RODC en catalogue global car la mise en cache de l’appartenance aux groupes universels peut provoquer des résultats inattendus (problème de rafraichissement entre la mise en cache des mots de passe et de l’appartenance aux groupes universels). L’activation de cette fonctionnalité sur le RODC permettra en plus de cantonner les requêtes clients sur leur site respectif. L’inconvénient principal sera une consommation relativement accrue de la bande passante donc l’activation de cette fonction dépendra toute fois de cette restriction.
Cet article s’appuie sur une maquette constituée d’un contrôleur de domaine accessible en écriture placé sur le site de Paris et de notre RODC sur le site de Marseille.
Site principal :
- Nom du site: PARIS
- Réseau IP du site: 192.168.0.0/24
- Domaine Active Directory: corpnet.net
- Nom du contrôleur: SRVAD
- Type de version: Windows 2008 R2 Edition Standard
- IP du contrôleur: 192.168.0.1
Site annexe:
- Nom du site: MARSEILLE
- Réseau IP du site: 192.168.1.0/24
- Domaine Active Directory: corpnet.net
- Nom du contrôleur: RODC
- Type de version: Windows 2008 R2 Edition Standard
- IP du contrôleur: 192.168.1.1
Vous devez obligatoirement avoir déjà à votre disposition un contrôleur de domaine en 2008 au sein de votre domaine afin de pouvoir accueillir le RODC. Vos schémas sont donc déjà à jour. Cependant il est probable que vous désiriez intégrer votre RODC sous une version 2008 R2 et dans ce cas-là il faudra mettre à jour de nouveau vos schémas.
Si vous disposez déjà d'un 2008 R2 en tant que contrôleur de domaine alors il faudra préparer nos partitions de schéma pour l’accueil du RODC qui nécessite une mise à jour. Placez donc le DVD d’installation de 2008 R2 sur votre maître de schéma et saisissez la commande « d:\support\adprep\adprep.exe /rodcprep » ou « d:\support\adprep\adprep32.exe /rodcprep » (D: est notre lecteur de DVD) selon qu'il soit en 64bits (adprep.exe) ou en 32bits (adprep32.exe).
Si vous ne disposiez que d'une version 2008 alors lancez depuis un invite de commandes « d:\support\adprep\adprep.exe /forestprep » ou« d:\support\adprep\adprep32.exe /forestprep » pour mettre à jour votre forêt.
Il faudra faire de même pour le schéma du domaine en lançant la commande « d:\support\adprep\adprep.exe /domainprep » ou « d:\support\adprep\adprep32.exe /domainprep ».
Remarque : les résultats fournis ci-dessus nous signale que nos schémas sont déjà à jour car en effet notre contrôleur de domaine est déjà en 2008 R2.
Une fois le schéma mis à jour, nous allons configurer le site Active Directory de Marseille pour l’accueil du RODC. Pour cela, ouvrez la mmc « Sites et services Active Directory » depuis « Démarrer » | « Outils d’administration ». Comme vous pouvez le voir ci-dessous, nous avons déjà créé le site PARIS contenant SRVAD et le subnet 192.168.0.0/24 qui lui est rattaché.
Nous allons faire de même pour le site de Marseille. Faites un clic droit sur « Sites » et sélectionnez « Nouveau site… ». Entrez le nom du site et sélectionnez le nom du lien DEFAULTIPSITELINK.
Le site de Marseille étant créé, nous allons ensuite pouvoir lui rattacher le sous réseau 192.168.1.0/24 en se plaçant sur « Subnets » et en sélectionnant « Nouveau sous-réseau… » à l’aide d’un clic droit. Entrez donc votre adresse et votre masque de sous-réseau 192.168.1.0/24 depuis le champs préfixe et associez-le au site MARSEILLE.
Pour plus de clarté, il vous sera possible de renommer votre lien de site créé par défaut et portant le nom DEFAULTIPSITELINK en vous rendant dans « Inter-Site Transports » | « IP ».
Si vous désirez une configuration mieux adaptée à votre structure, Technet propose l'article RODC Placement Considerations.
Pour finir au niveau de la préparation, il sera intéressant de créer un groupe Administrateurs Marseille qui se verra octroyer les droits d’administration sur le RODC.
Le domaine étant prêt à accueillir le RODC et notre nouveau site Active Directory étant créé, nous allons passer à l’installation du RODC. Premièrement réalisez une nouvelle installation d’un Windows 2008. Si vous avez besoin d’aide pour réaliser l’installation nous vous invitons à vous rendre sur l'article Installation de Windows 2008 R2.
Remarque: Il peut être également intéressant de déployer le RODC sur une installation Windows de type Core cependant nous traiterons de ce sujet dans un autre article très prochainement.
Nous allons maintenant promouvoir ce nouveau serveur en tant que RODC grâce à la commande « DCPROMO ». Pensez à cocher « Utiliser l’installation en mode avancé ».
Notre RODC sera bien entendu intégré dans une forêt existante en tant que contrôleur supplémentaire. Il faudra donc ensuite préciser le nom de domaine Active Directory et les informations d’authentification permettant l’ajout du contrôleur au domaine (un compte membre du groupe administrateurs du domaine).
Il faudra que vous sélectionniez le site correspondant au nouveau contrôleur. Si vous avez suivi correctement les étapes de préparation, l’assistant détectera automatiquement le site voulu.
Cette étape est la plus importante lors de l’installation d’un RODC. C’est justement lors de cette phase que vous définissez votre nouveau contrôleur en tant que RODC en cochant « Contrôleur de domaine en lecture seule (RODC) ».
L’assistant proposera ensuite de définir la stratégie de réplication de mots de passe que vous voulez mettre en place. Nous nous consacrerons à cette tâche ultérieurement donc laissez les paramètres par défaut pour le moment.
Nous passons à la configuration de la délégation d’administration qui permettra d’allouer les droits d’administration locale sur le RODC à un groupe ou à un utilisateur. Nous avons opté pour un groupe. Il nous suffira simplement de définir les membres de ce groupe selon les besoins.
Nous sortons du paramétrage propre au RODC pour reprendre l’assistant tel qu’il se présente pour une promotion traditionnelle. Dans cette partie, vous pouvez choisir de répliquer la base de votre annuaire via le réseau où à partir d’un support. Bien que la dernière solution peut s’avérer très utile surtout si la bande passante est limitée, nous ne la traitons pas dans cet article. Ayant donc choisi de répliquer via le réseau, nous avons la possibilité désormais de choisir notre partenaire de réplication durant l’installation.
Il ne reste plus qu’à définir le stockage des différentes données de votre RODC, de définir le mot de passe de restauration et de vérifier vos paramètres avant d’en finir avec l’assistant.
Une fois le serveur redémarré, il est désormais promu en tant que contrôleur de domaine en lecture seule. Vous pouvez le vérifier assez simplement à partir de la console « Utilisateurs et ordinateurs Active Directory ». Depuis le conteneur « Domain Controllers », vous avez la colonne « type de contrôleur de domaine » vous indiquant si un objet est en lecture seule.
Votre RODC est désormais installé et opérationnel. Maintenant, il ne vous reste plus qu'à configurer le PRP, les FAS et l'ASR afin de sécuriser et gérer au mieux votre nouvelle installation. Pour cela, nous vous proposons de consulter les articles RODC: partie 3 - Configuration de PRP et RODC: partie 4 - Configuration de FAS et ARS.
-
RODC: partie 3 - Configuration de PRP
Mise à jour le Vendredi, 19 Novembre 2010 08:44Sommaire
Cet article fait suite aux deux articles RODC: partie 1 - Présentation et RODC: partie 2 - Préparatifs et installation et va être consacré essentiellement à l'approfondissement de ce que nous considérons comme étant la fonctionnalité la plus complexe de RODC : la stratégie de réplication des mots de passe. Nous allons donc voir dans le détail son fonctionnement et sa configuration.
Pour ceux qui auront déjà consulté notre article de présentation, certains éléments pourront vous paraître répétitifs cependant nous avons jugé nécessaire de les réincorporer pour permettre une meilleure compréhension.
Par défaut un RODC transmet toutes les demandes d’authentification à un contrôleur de domaine accessible en écriture et donc en tout logique à travers un réseau WAN. Vos utilisateurs seront donc toujours assujettis à la lenteur d’une ouverture de session depuis un WAN (hormis l'application des stratégies) et même tributaires en cas de dysfonctionnement. Pour pallier à cela et en particulier pour des comptes utilisateurs considérés comme peu sensibles, Microsoft a mis en place le PRP (Password Replication Policy).
Le PRP va tout simplement vous permettre de définir quels sont les mots de passe des comptes à mettre en cache sur le RODC. Configurer le PRP vous apportera les avantages suivants :
- Il empêchera toujours la mise en cache des comptes sensibles pour une meilleure sécurité.
- Il permettra une authentification rapide à partir du RODC pour les comptes utilisateurs dont la mise en cache des mots de passesa été activée (il faut mettre également en cache les comptes ordinateurs et de services associés).
- Il offrira la possibilité aux utilisateurs de se connecter même en cas de ruptures de la liaison WAN ne nécessitant plus de faire appel à un contrôleur de domaine accessible en écriture.
ATTENTION !!! Pour que le PRP assure pleinement sa fonction, il faudra impérativement qu’il n’y ait plus de Windows Server 2000 et donc que le niveau fonctionnel de la forêt soit au minimum en 2003. Toutes données disponibles sur un 2000 sont accessibles par un RODC.
Gestion et fonctionnement du PRP
Dans un premier temps, nous allons voir comment accéder à la gestion de PRP. Pour cela, il suffit simplement d’ouvrir la mmc « Utilisateurs et ordinateurs Active Directory » depuis un contrôleur accessible en écriture. Ensuite vous devez vous rendre dans l’unité d’organisation « Domain Controllers » et sélectionner « Propriétés » à l’aide d’un clic droit sur le RODC concerné. Une fois que vous accédez aux propriétés du RODC, allez dans l’onglet dans « Stratégie de réplication de mot de passe ». Notez que chaque RODC présent dans votre infrastructure disposera de sa propre stratégie PRP.
Si vous cliquez sur le bouton « Avancé… », vous obtenez depuis l'onglet « Utilisation de la stratégie » la liste des comptes mis en cache et la liste des comptes authentifiés. A noter que la liste des comptes stockés contient par défaut deux comptes qui sont le compte ordinateur du RODC et son compte spécial krbtgt. Le deuxième onglet « Stratégie résultante » vous permettra de vérifier si un compte est paramétré pour être mis en cache ou non.
Si nous revenons dans la fenêtre « Propriétés de » de votre RODC, dans l’onglet « Stratégie de réplication de mot de passe » vous avez la colonne « Paramètre » qui vous permettra de définir si un groupe ou un compte sera mis en cache en les intégrant soit dans une liste d’autorisation soit dans une liste de refus. Elles sont tenues à disposition du RODC sous forme de deux attributs : msDS-RevealOnDemandGroup pour la liste d’autorisation et msDS-NeverRevealGroup pour la liste de refus.
Remarque: cette partie présente la gestion d'une partie de la stratégie de réplication de mot de passe au niveau du schéma Active Directory. Elle n'est pas une étape nécessaire à la configuration mais nous espérons qu'elle vous permettra de mieux appréhender le sujet.
Pour accéder à ces deux attributs, ouvrez la mmc adsiedit. Faites ensuite un clic droit sur la racine « Modification ADSI » pour choisir « Connexion... » et sélectionnez depuis la fenêtre « Paramètres de connexion le point de connexion » le point de connexion « Contexte d’attribution des noms par défaut ».
Naviguez ensuite dans l’arborescence jusqu'à « OU=Domain Controllers,DC=corpnet,DC=net » pour atteindre l’objet « CN=RODC » où RODC correspond au nom de votre contrôleur de domaine en lecture seule. Réalisez un clic droit sur cet objet et sélectionnez « Propriétés ». Vous accédez directement depuis l’onglet « Editeur d’attributs » aux deux attributs que vous pouvez modifier en conséquence à l’aide du bouton « Modifier ».
msDS-RevealOnDemandGroup permettra de définir quel compte sera mis en cache. Par défaut, il contient une seule valeur qui est tout simplement le groupe « Groupe de réplication dont le mot de passe RODC est autorisé » situé dans le répertoires « Users » accessible depuis la mmc « Utilisateurs et ordinateurs Active Directory ».
Le second attribut msDS-NeverRevealGroup quand à lui contiendra les comptes qui seront explicitement rejetés de cette mise en cache. Par défaut, il contient le groupe « Opérateurs de compte », « Opérateurs de serveur », « Opérateurs de sauvegarde », « Administrateurs » et « Groupe de réplication dont le mot de passe RODC est refusé ». Ce dernier est situé au même droit que « Groupe de réplication dont le mot de passe RODC est autorisé » mais par contre il n’est pas vide comme son homologue et contient les groupes visibles depuis l’imprime écran ci-dessous. Il englobe par défaut tous les comptes les plus sensibles de votre forêt.
Remarque: PRP utilise également d'autres attributs que nous ne verrons pas ici. Si vous voulez en savoir plus sur ce point, une liste de liens exhaustifs vous est fournie en conclusion.
Idéalement, il faudra donc créé un groupe de type sécurité avec une étendue de domaine qui contiendra l’ensemble des comptes utilisateurs et ordinateurs à mettre en cache pour chacun de vos RODC. Bien entendu, si vous n’avez qu’un seul RODC par domaine, vous pourrez vous contenter des groupes proposés de base lors de l’installation du RODC. Pour reprendre notre maquette de l’article précédent, nous allons donc créer un groupe « Utilisateurs et Ordinateurs Marseille » que nous mettrons en cache sur le RODC.
Depuis l’onglet « Stratégie de réplication de mot de passe » de votre RODC, cliquez sur « Ajouter », choisissez « Autoriser la réplication des mots de passe du compte sur ce contrôleur de domaine en lecture seule (RODC) » pour ensuite sélectionner votre groupe créé au préalable. Tous les membres de ce groupe sera donc mis en cache au fur et à mesure et lors de leur première authentification.
Remarque: si un compte fait partir d’une liste autorisée et conjointement d’une liste de refus, la plus restrictive prendra le pas (donc la liste de refus).
Il est aussi possible de pré-remplir les objets ayant l’autorisation d’être mis en cache plutôt que d’attendre leur première authentification. Toujours depuis l’onglet « Stratégie de réplication de mot de passe », cliquez sur « Avancé… ». A partir de l’onglet « Utilisation de la stratégie », cliquez « Préremplir les mots de passe… » et sélectionnez le compte ordinateur ou utilisateur qui sera pré-rempli. Il n’est pas possible de réaliser cette étape par lot en sélectionnant un groupe. Il faudra passer malheureusement par un script. Vous aurez enfin un message d’alerte pour vous prévenir du risque que peut entrainer le pré-remplissage et vous invitant à faire la manipulation pour le compte ordinateur de l’utilisateur sélectionné.
Nous avons fait le tour du PRP hormis peut-être un cas particulier qui concerne la gestion des comptes mis en cache lors du vol de votre RODC. Ca ne devrait pas vous arrivez tous les jours cependant prenez note qu’il faudra réinitialiser tous les mots de passe des comptes mis en cache afin d’en assurer l’intégrité. Pour cela il suffira simplement de supprimer l’objet ordinateur correspondant à votre RODC pour que vous ayez à l’écran la fenêtre « Suppression du contrôleur de domaine » avec la possibilité de réinitialiser les mots de passes utilisateurs et/ou ordinateurs.
Nous avons essayé de voir de manière exhaustive la fonctionnalité PRP et cet article devrait vous permettre de la gérer au mieux et d'en maitriser la majeure partie. Il peut être toutefois nécessaire d'approfondir le sujet et pour cela nous vous proposons de consulter les articles Technet suivants:
-
RODC: partie 4 - Configuration de FAS et ARS
Mise à jour le Vendredi, 19 Novembre 2010 09:00Sommaire
Nous clôturons le sujet RODC par ce dernier article qui se consacre exclusivement à la configuration des filtrages d'attribut et la mise en place des délégations d'administration.
Ayant pour anagramme FAS, cette seconde particularité de RODC permet à une liste d’attributs d’être filtrée pour ne pas être répliquée sur le RODC toujours pour des raisons de sécurité. FAS est assez proche de PRP à la différence qu’elle ne se cantonne pas exclusivement aux informations d’authentification mais à peu près tout type d’attribut que vous pourriez considérer comme sensible en cas de compromission de votre RODC. Veuillez simplement noter que certains attributs de base ne sont pas filtrables et en particulier ceux dont la valeur d’attribut pour systemsFlags est défini sur 0x10.
ATTENTION !!! Si vous voulez assurer pleinement le fonctionnement de FAS sur votre RODC, il faudra que le niveau fonctionnel de la forêt soit en 2008 car le RODC peut répliquer les attributs filtrés depuis un Windows Server 2003 ou antérieur. En clair, le FAS n’est pris en compte qu’à partir de 2008.
Remarque: Toutes les modifications d'attributs et spécialement pour le filtrage doivent être réalisées sur un serveur 2008 disposant du maître d'opération maître de schéma.
A partir de la console ADSIEDIT et en ouvrant la partition de schéma, si vous accédez aux propriétés de l’attribut « Computer » par exemple, nous pouvons voir que la valeur d’attribut systemFlags est défini sur 0x10 (16) et donc le filtrage ne sera pas possible.
Pour activer le FAS sur un attribut spécifique, il faut modifier le dixième bit de sa valeur d’attribut searchFlags. Par défaut cette valeur d’attribut est affichée en hexadécimal et les modifications passent par des valeurs décimales, donc pour plus de clarté, on considérera qu’il faudra ajouter la valeur décimale 512 à searchFlags.
- Valeur décimale : 512
- Valeur hexadécimal : 200
- Valeur binaire : 1000000000 (le dixième bit est passé à 1)
Il est également recommandé par Microsoft de rendre l’attribut confidentiel et de modifier également le septième bit de la valeur d’attribut searchFlags ce qui permettra entre autres de ne plus rendre lisible l’attribut par le groupe « utilisateurs authentifiés ». Il faudra donc ajouter la valeur décimale 128.
- Valeur décimale : 128
- Valeur hexadécimal : 80
- Valeur binaire : 1000000 (le septième bit est passé à 1)
En conclusion, pour activer le filtrage et la confidentialité sur un attribut, il faut configurer la valeur d’attribut searchFlags à 640 (512+128) qui correspond à la valeur binaire 1001000000. Attention toutefois que la valeur searchFlags n’a pas toujours par défaut une valeur nulle donc il faudra combiner les différentes valeurs. Si l’attribut est indexé alors la valeur d’attribut searchFlags sera de 1. Si vous voulez le rendre confidentiel et le filtrer tout en conservant l’indexation, il faudra donc lui rentrer comme nouvelle valeur 641. Vous avez la liste des différentes valeurs attribuables par défaut à searchFlags ici.
Nous ne l’avions pas cité précédemment mais 6 attributs sont filtrés et marqués comme confidentiels par défaut. Sachant qu’il faut que leur valeur searchFlags soit à 640, nous pouvons les localiser assez simplement. Pour cela ouvrez « ldp.exe » depuis « Exécuter ». Une fois ldp lancé, allez dans « Connexion » | « Se connecter… » et indiquez le FQDN du contrôleur de domaine où vous devez vous connecter. Si vous rencontrez des problèmes d’authentification, préciser les informations d’identification depuis « Connexion » | « Lier… ».
Une fois connecté, sélectionner à partir du menu « Parcourir » la fonction « Rechercher », placez-vous sur la partition de schéma et entrez comme filtre de recherche « (SearchFlags:1.2.840.113556.1.4.803:=640) » pour afficher les attributs filtrés et confidentiels (valeur 640). A noter que la valeur 1.2.840.113556.1.4.803 est décrite depuis le KB Microsoft Comment faire pour interroger Active Directory à l’aide d’un filtre au niveau du bit. Cette information et de manière globale cette section reprend l’article Enumerate The RODC FAS. Une fois que vous cliquez sur le bouton « Exécuter », vous obtiendrez le détail des attributs concernés.
Comme vous pouvez le constater, il y a 6 attributs qui sont configurés de base comme étant filtrés et confidentiels. Nous les détaillerons ici pas mais vous pouvez obtenir plus d’information depuis l’article Technet RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC.
Vous pouvez modifier les attributs à partir de divers outils tel que ADSIEDIT que nous avions utilisé précédemment. Il suffit simplement d’accéder aux propriétés de l’attribut et de modifier la valeur searchFlags.
Administrative Role Separation
La dernière fonctionnalité est ARS pour Administrative Role Separation. Grâce à ARS vous pourrez déléguer l’administration du RODC localement à un utilisateur ou un groupe d’utilisateurs sans droit supplémentaire au niveau de votre domaine. ARS est assez similaire au droit d’administrateur local que l’on peut retrouver sur un poste lambda.
Lors de l’installation du RODC, vous avez la possibilité de définir le groupe ou l’utilisateur ayant les droits d’administration sur le RODC. Par contre, si vous désirez modifier ces accès, il vous suffira simplement d’ouvrir la console « Utilisateurs et ordinateurs Active Directory », de vous rendre dans le conteneur où se trouve votre RODC et d’accéder aux propriétés à l’aide d’un clic droit (Bien entendu il faudra réaliser la manipulation depuis un contrôleur de domaine accessible en écriture). Une fois dans les propriétés, il faudra tout simplement se rendre dans l’onglet « géré par » et ajouter l’utilisateur ou le groupe voulu à l’aide du bouton « Modifier… ».
Nous en avons désormais fini avec RODC! Nous espérons que l'ensemble des articles sur le sujet vous aura permis de comprendre et d'appréhender correctement cette fonctionnalité qui est loin d'être un pis-aller. Il en a séduit et devra en séduire plus d'un !
