ACTIVE DIRECTORY
Je me suis aperçu que retrouver rapidement des rôles FSMO, lorsqu’on fait un audit ou qu’on s’apprête à mener une belle opération sur son infra, pouvait paraître lourd. Effectivement, ouvrir plusieurs consoles n’est pas très confortable. Alors juste un petit rappel. Pour lister les rôles FSMO de votre magnifique forêt, rien de tel que la commande dans une console DOS ou Posh:
netdom query fsmo
Et voilà!
Et non: pas de bras, pas de chocolat! Tic tac, le temps passe mais suis-je à l’heure? Mon poste de travail est il à l’heure, mon serveur est-il à l’heure lui aussi?
Dans une forêt Active Directory, le temps est par défaut garanti par le premier contrôleur de domaine de la forêt, celui-ci portant le rôle FSMO de PDC. Mais la garantie est toute relative. Pour une véritable synchronisation horaire, on reliera le serveur référent à une source NTP (Network Time Protocol) externe (ex: horloge atomique). A titre d’exemple, les horloges atomiques de type « fontaine atomique » au Césium peuvent-elles avoir une marge d’erreur de l’ordre d’une seconde pour 20 millions d’années!
En supposant une forêt multidomaine, les contrôleurs de domaine du domaine racine vont venir se synchroniser avec leur PDC. Par défaut, les serveurs membres et les postes de travail de ce domaine racine viendront se synchroniser sur n’importe quel contrôleur de domaine.
Dans un domaine enfant de la forêt, le PDC du domaine va se synchroniser à n’importe quel contrôleur de domaine du domaine parent. Les autres contrôleurs du domaine enfant vont se synchroniser soit:
Les serveurs membres et postes de travail du domaine enfant se synchronisent sur n’importe quel contrôleur de leur domaine.
Pour assurer le service de temps les serveurs Windows 2000 utilisaient le SNTP (Simple Network Time Protocol), port 123, quand les serveurs de version ultérieure use du NTP, port 123 également. Le service « Windows Time » s’y rattachant est visible par la console des services et paramétrable via l’utilitaire « w32tm ».
Un contrôleur de domaine (DC) utilise un répertoire partagé spécial pour répliquer les scripts de connexion et les GPO avec les autres contrôleurs du domaine, le SYSVOL. Sur Windows 2000 et Windows 2003, la réplication se faisait par FRS. Sur Windows 2008 comme Windows 2008 R2, cette réplication se fait en DFS, pour peu que le niveau fonctionnel du domaine soit en 2008.
Parmi les pré-requis à la migration, on va ainsi se garantir que chaque DC présente les partages NETLOGON et SYSVOL, que le niveau fonctionnel du domaine soit au minimum en Windows 2008. De plus, la migration réalisant un doublon des données, on va s’assurer que le disque dispose d’un espace libre suffisant pour recevoir une copie du SYSVOL. Aussi, il nous faudra vérifier l’état des réplications AD (par l’outil repadmin) comme des réplications FRS (par l’outil Ultrasound).
La migration est à voir comme un graphe d’états. Chaque DC va passer d’un état stable à un autre état stable via des états transitoires propres.
A l’origine, les DC sont à l’état stable 0. Cet état est à relié à l’usage du FRS. Pour initier le processus de migration, on utilise l’outil « dfsrmig » en l’appelant comme suit:
dfsrmig /SetGlobalState 1
Cette commande exécutée sur le PDC va déclencher une mise à jour sur l’ensemble des DC du domaine. Les DC passent par des états transitoires, réalisant une copie du SYSVOL local dans un répertoire nommé SYSVOL_DFSR, le FRS restant opérationnel et le répertoire SYSVOL restant utilisé à la connexion. A l’issue, tous les DC sont à l’état 1, « Prepared State » (dfsrmig permet de vérifier la bonne transition locale et globale). Le SYSVOL reste répliqué par FRS et le SYSVOL_DFSR est répliqué par DFS.
Il est alors temps de passer à l’état stable suivant, l’état 2 « Redirected State »:
dfsrmig /SetGlobalState 2
Ici les DC vont réaliser la redirection du partage SYSVOL, le faisant pointer sur le SYSVOL_DFSR. Les répertoires SYSVOL et SYSVOL_DFSR sont toujours répliqués et accessibles.
Vient le dernier état stable de la migration, l’état « Eliminated State »:
dfsrmig /SetGlobalState 3
Comme son nom l’indique, cet état permet l’élimination complète du répertoire SYSVOL d’origine. Il se peut que le répertoire reste, mais il est probablement vide. On vérifiera, comme en pré-migration, que sur chaque DC les deux partages NETLOGON et SYSVOL sont disponibles et que la réplication AD est opérationnelle…
Avec Windows 2008, est arrivé une option de la console ADUC, bien sympathique permettant de sécuriser à minima les objets présents dans votre annuaire Active Directory. Auparavant cette opération certes réalisable était un peu plus laborieuse. Cette option, présentée sur la figure ci-dessous s’intitule « Protect object from accidental deletion ».
Option de protection de l'objet
Présentée ci-dessus sur un objet User, cette option est également disponible pour les objets groupes, les unités organisationnelles. C’est ce dernier point qui peut vite être intéressant, lorsqu’il s’agit de sécuriser l’architecture logique de l’annuaire.
Sur l’exemple ci-dessous, l’OU « Head Office »de notre annuaire est sécurisé en cochant la fameuse case.
Case cochée pour protéger l'OU
En la cochant, une nouvelle ACE (Access Control Entry) est générée. On peut effectivement voir que le groupe Everyone se voit affublé d’une permission spéciale de type « Deny » sur l’OU seule. Cette permission spéciale porte sur les droits « Delete » et « Delete subtree ».
Nouvelle ACE liée à la case cochée
On le voit, pratique lorsqu’on a une petite organisation voire lorsqu’on crée manuellement l’unité organisationnelle, cette option reste accessible lorsqu’on fait du traitement de masse. A une condition: que l’on dispose d’un serveur 2008 R2 avec les commandlets Powershell pour AD. Pour protéger l’ensemble des OU, on pourra passer la commande suivante:
Get-ADOrganizationalUnit -filter * | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true
SCCM 2012 arrive et avec lui, une extension de schéma de votre annuaire ActiveDirectory est à prévoir. SCCM apporte effectivement son lot de classes et attributs garantissant le bon fonctionnement de certaines fonctionnalités.
On usera d’un compte membre du groupe « Admins du Schéma » pour cette extension qui sera lancée sur le contrôleur de domaine portant le rôle FSMO « maître du schéma ».
L’exécutable « Extadsch » délivré avec SCCM réalise l’ensemble de l’opération. Notons qu’il est également possible d’étendre le schéma en usant de ldifde et du fichier « ConfigMgr_ad_schema.LDF ».
L’extension porte sur l’ajout des attributs et classes suivants:
Si vous disposez de versions précédentes à SCCM 2012 et avez étendu votre schéma, vous verrez que certains attributs et classes sont déjà présents dans le schéma.
Le résultat de l’extension du schéma est lisible par le fichier Extadsch.log à la racine du lecteur système. Cette extension est également vérifiable dans l’EventViewer.
myactivedirectory 