Bonjour à tous.
Soyez les bienvenus sur ce site dédié à cette solution technique qu’est Active Directory de Microsoft. Vous trouverez sur ce blog des articles traitant effectivement de cet annuaire comme d’éléments s’y rapportant. Il y en aura pour tous les goûts.
Ce blog sera régulièrement alimenté par certains des collaborateurs OZITEM dont les prestations sont orientées Active Directory.
Bonne visite, bonne lecture!
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à!
Les GPOs ces objets étranges, tels des particules élémentaires, se retrouvent sous deux formes.
La première forme se situe dans votre Active Directory: il s’agit d’un objet de classe « groupPolicyContainer » (GPC) dont l’attribut « cn » a pour valeur le GUID associé. Comme le nom de la classe l’indique, il s’agit d’un container.
Container GPC
Par défaut, lors d’une installation d’Active Directory, deux GPOs sont créées et liées. Il s’agit de la GPO « Default Domain Policy » et la GPO « Default Domain Controllers Policy », créées dans le container « Policies », situé dans le container System comme le présente la figure ci-dessus. La première GPO se trouve liée au domaine nouvellement créé, la seconde se trouve liée à l’unité organisationnelle « Domain Controllers ». Les attributs « cn » des deux GPC associés, sont toujours les mêmes:
Dans ces containers, nous retrouvons entre autre le chemin UNC du répertoire associé à la GPO. Le chemin est lisible dans l’attribut « gPCFileSysPath », comme présenté sur la figure ci-dessous:
gPCFileSysPath
Dans le domaine, l’unité organisationnelle, on pourra retrouver le lien de la GPO par l’attribut « gpLink ».
Comme nous venons de l’indiquer, la seconde partie de la GPO se trouve sous forme de fichiers. Dans le répertoire partagé SYSVOL de chaque contrôleur de domaine, on trouve un sous-répertoire « Policies » qui contient l’ensemble des GPOs du domaine. A chacune des GPOs y correspondra, comme le montre la figure suivante, un répertoire au nom équivalant au GUID précédent signalé.
Répertoire des GPOs
Dans ces répertoires, se retrouvent les modèles administratifs, les paramètres de sécurité, les scripts ou applications à installer. Tout ceci constitue les Group Policy Templates (GPT).
Toute machine membre d’un domaine Active Directory établit un « canal sécurisé » avec un contrôleur de domaine, qui va permettre l’authentification du poste dans le domaine. Le mot de passe de l’ordinateur est stocké sur la machine (on parle du secret LSA) mais également avec le compte Active Directory de l’ordinateur. Le service NetLogon utilise ce mot de passe pour établir le lien avec le contrôleur de domaine. Si pour quelque raison que ce soit, les secret LSA et mot de passe du compte ordinateur viennent à être désynchronisés, l’ordinateur ne sera plus à même de s’authentifier dans le domaine.
Pour tester le canal sécurisé sur un poste de travail ou un serveur, on peut exécuter la commande
nltest /server:<ComputerName> /sc_query:<DomainName>
où <ComputerName> est le nom du poste (ou serveur) et <DomainName> est le nom du domaine dans lequel se trouve ce poste (ou serveur). La commande renvoie le nom du contrôleur de domaine approuvé ainsi que l’état de la connexion.
Pour réinitialiser le compte d’ordinateur, on pourra utiliser la commande dsmod.exe. La commande nécessite de rejoindre l’ordinateur au domaine à l’issue.
dsmod computer « <ComputerDN> » -reset
où <ComputerDN> est le « Distinguished Name » de l’objet computer. Une autre solution est d’utiliser la commande netdom.exe. La commande permet de réinitialiser le compte sans avoir à rejoindre l’ordinateur au domaine.
netdom reset <ComputerName> /Domain <DomainName> /User0 <UserUPN> /Password0 *
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
Kerberos supporte, sur Windows 2003, divers types de chiffrement et longueurs de clé. On y retrouve:
Avec Windows 2008, apparaît également:
Ci-dessous, une configuration d’utilisateur indiquant que le DES n’est pas utilisé: la case « Use Kerberos DES ecryption types for this account » n’y est pas cochée.
Propriétés d'encryptage d'un objet User
Notons d’ailleurs que pour les serveurs Windows 2008 R2 comme les postes de travail Windows 7, le DES n’est plus utilisé par défaut. On s’empressera (avant toute extinction hâtive) de vérifier si des applicatifs tiers le nécessitent.
L’usage du type de chiffrement peut se définir à plusieurs niveaux. On l’a vu précédemment côté utilisateur. Pour les postes de travail, les serveurs membres et les contrôleurs de domaine, il est également possible de préciser les algorithmes de chiffrement retenus, au moyen d’une GPO par exemple. Comme présenté ci-dessous, on pourra activer le DES comme l’AES en activant le paramètre « Network security : Configure encryption types allowed for Kerberos ». Les types non cochés ne seront alors pas disponibles.
Paramètre de GPO autorisant le DES
Notons enfin que le type de chiffrement utilisé peut avoir un impact non négligeable sur le temps de connexion.
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.
SPN, voilà un bien bel acronyme. SPN signifie « Service Principal Name », soit mais après ? Un équivalent dans le monde « DNS » serait un enregistrement de ressource de type CNAME. Bref un alias. Là, il s’agit d’un alias dans le monde « KERBEROS ».
Lorsqu’un client souhaite accéder à un service, il va d’abord chercher à savoir qui porte le service. Dans Active Directory, cette information est stockée dans l’attribut multivalué « servicePrincipalName » d’objets computer ou user.
Ci-dessous un exemple de SPN, sur un contrôleur de domaine Windows 2008 R2.
Attribut "servicePrincipalName" d'un objet Computer
Un SPN suit le format <service>/<hôte>.
Il arrive que l’on trouve un voire deux autres paramètres constituant le SPN comme le port utilisé par l’instance du service et un nom optionnel. Dans ce cas, on trouvera le SPN sous la forme <service>/<hôte>:<port>/<nom>.
Si on imagine facilement qu’un compte Computer puisse porté ce type d’information, il n’en reste effectivement pas moins qu’un compte User peut également voir cet attribut renseigné. On retrouve ce cas pour certains « comptes de service ».
myactivedirectory 