Archives de la catégorie ‘Active Directory’

 

Hello tout le monde,

Si vous souhaitez récupérer (exporter) toute la structure de vos OUs, présentes sur un environnement AD spécifique et la migrer vers un nouvel environnement avec un nouveau domaine AD, cet article est fait pour vous :).

Un de mes clients a simplement souhaité récupérer la structure complètes des OUs et leur sous-OU ainsi que les groupes et m’a fait part de ce besoin récemment.

J’ai donc décidé de partager la technique permettant de réaliser cette opération avec vous :).

Alors comment ça marche ?!

D’abord, quels outils utilisés o__O ?

The best of the Best pour ce type d’opération reste le Wonderful CLI : LDIFDE.exe

Cet outil en ligne de commande est natif dans les OS Windows Server 2012 /2012 R2 et ultérieur.

HowTo ?
La structure d’OUs « Source »

Mon environnement /domaine AD source (hkvlab.lan) présente la structure d’OUs suivante :

 

Pour exporter toute la structure /arborescence d’OUs, la commande suivante est exécutée depuis une invite de commande (CMD.exe), lancée en tant qu’Administrateur :

ldifde -f c:\All_OUs.ldf -r “(objectClass=organizationalUnit)” -l objectClass,description

Note important : avant d’importer le fichier ldf « All_OUs.ldf », vous devez d’abord l’éditer et remplacer l’ancien DN du domaine par le nouveau.

To Do : Notez que dans le fichier All_OUs.ldf exporté, une entrée pour l’OU par défaut « Domain Controllers » existe. Celle-ci doit être supprimée du fichier car l’OU « Domain Controllers » existe déjà sur votre domaine de destination. Si vous ne supprimez pas le bloc de texte illustré dans l’image ci-dessous, la procédure d’import échouera !

Dans l’exemple suivant, le D(istinguished) N(ame) de mon ancien domaine est le suivant : DC=hkvlab,dc=lan

Le DN du nouveau domaine est : DC=hknewvlab,dc=lan

Une fois modifié, mon fichier ldf ressemble à l’image ci-après :

Enfin, ouvrez une Session sur un DC du nouveau Domaine (Domain de destination) ou une machine d’administration ayant les outils RSAT AD DS installés, copiez /collez le fichier ldf précédemment modifié avec le DN du nouveau domaine, et saisissez la commande suivante pour importer correctement votre structure d’OUs :

ldifde -i -f c:\All_OUs.ldf

Comme vous pouvez le constater, 27 entrées ont été modifiées suite à l’import via le fichier All_OUs.ldf, il s’agit des 27 OUs et sous-OUs importées.

Vous pouvez le vérifier en lancant la console DSA.msc depuis votre DC appartenant au nouveau domaine AD et visualiser la structure d’OUs :

N’hésitez pas à vous abonner pour être informé pour toute nouvelle publication sur mon Blog.

HK o____O

Publicités

Microsoft a publié (le 10/08/2017) la version 1.1 de l’outil gratuit « Active Directory Replication Status Tool »

Pour rappel, AD Replication Status Tool est un outil gratuit qui vous permet d’analyser l’état de réplication de vos DCs (Domain Controllers) dans un domaine ou une forêt Active Directory.

Les principales fonctionnalités offertes par AD Replication Status Tool sont :

  • Exposer les problèmes de réplications parvenus au niveau d’un domaine ou une forêt Active Directory
  • Prioriser les erreurs de réplication devant être résolues pour éviter toute création de « Lingering Objects » au niveau d’une forêt Active Directory
  • Aide les IT Admins  à résoudre les problèmes et erreurs de réplication AD en les liant au contenu /Base TechNet (Contenu AD Replication TroubleShooting) qui regroupe plusieurs centaines de « Problèmes connus » qui peuvent les aider à identifier et résoudre rapidement des problèmes /erreurs de réplication AD
  • permet l’export des données de réplication collectées pour une analyse « Offline » ultérieur

 

What Next ?

Télécharger l’outil Active Directory Replication Status Tool, V1.1

Hello everyone,

Si vous êtes amenés à créer des tâches planifiées pour exécuter des scripts PowerShell (script de check, d’audit, lancement d’opérations spécifiques…), eh bien notez que vous devez d’abord prendre connaissance de certaines informations pour que vos scripts se déclenchent correctement à l’heure schedulée.

Mon besoin

J’ai besoin de surveiller les changements apportés à un groupe AD à « Haut privilèges » tel que le groupe « Admins du domaine ». L’audit de ce groupe se fera via l’utilisation d’un script PowerShell (basé sur les Cmd-Lets du Module PS ActiveDirectory) et l’envoi de notification par mail se fera simplement via l’utilisation d’un serveur SMTP disponible sur le réseau (Cmd-Let Send-MailMessage).

Pour éviter d’investir du $$ dans une solution tierce de monitoring /alerte, j’utiliserais simplement une tâche planifiée qui exécute mon script d’audit AD chaque heure et qui m’envoi des notifications par mail pour rester informé de toute modification ayant eu lieu sur le groupe Domain Admins.

Comment ça marche ?

Dans l’exemple suivant, une tâche planifiée nommée « DA_Check » (Domain Admins_Check) sera créée, celle-ci sera configurée pour déclencher /exécuter de manière quotidienne le script D:\MyScripts\DA_Checker.ps1

Vous lancez le planificateur de tâches et vous créez votre tâche de manière classique

Arrivée à l’étape illustrée dans l’image ci-après, vous sélectionnez « Démarrer un programme »

Remplissez le champ « Programme/script » en respectant la syntaxe suivante : PowerShell -File « Emplacement_de_votre_script_PS »

Dans notre exemple, le script devant être exécuté par la tâche planifiée est placé dans D:\MyScripts\DA_Checker.ps1, la ligne de code à spécifier est donc :

Eh voilà, le tour est joué :).

A bientôt

HK

Restauration de l’état du système

Vous pouvez effectuer une restauration autoritaire de SYSVOL lors de la restauration de l’état du système, soit en ligne de commande avec « WBAdmin » en ajoutant « –authsysvol », soit avec l’interface graphique en mode restauration d’annuaire en cochant la case :

Par contre si vous faites une restauration complète depuis le support d’installation, vous devez utiliser les procédures présentées au prochain paragraphe.

Restauration autoritaire avec NTFRS

Vous pouvez configurer la restauration autoritaire de SYSVOL après la restauration du premier DC de chaque domaine en modifiant la valeur « BurFlags » du registre sur « D4 » :

« HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NtFrs\Parameters\Backup/Restore\Process at Startup » 

  • D4 : restauration faisant autorité sur les autres DCs
  • D2 : restauration non autoritaire uniquement pour ce DC

Après la modification du registre, vous devez redémarrer le serveur ou le service NTFRS :

Net stop NTFRS

Net Start NTFRS

Ou plus simplement :

Net Stop NTFRS && Net Start NTFRS

Restauration autoritaire avec DFS-R

Vous pouvez effectuer une restauration autoritaire de « SYSVOL » lors de la restauration du premier DC en utilisant la méthode suivante.

Ouvrez la console « Utilisateurs et Ordinateurs Active Directory ». Dans affichage, sélectionnez les options « Utilisateurs, contact,… en tant que conteneur » et « Fonctionnalités avancées » :

Dans le menu de gauche, allez sous « Domain Controllers », ouvrez le détail de votre contrôleur de domaine, puis allez sous « DFS-LocalSettings », « DomainSystem Volume »

Dans le panneau central faites un clic droit sur « Domain System Volume » et sélectionnez propriétés. Dans « éditeur d’attributs », recherchez « msDFSR-Options » et définissez la valeur à «»

Si vous souhaitez effectuer une restauration autoritaire de « SYSVOL » en dehors d’une procédure de restauration d’une forêt, je vous conseille de lire l’article suivant :

https://support.microsoft.com/en-us/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-for-dfsr-replicated-sysvol-like-d4-d2-for-frs

====================================================================

Cet article est un extrait de l’eBook « Active Directory 2012 et 2021 R2 – Sauvegarde et Restauration« , disponible sur BecomeITExpert.com

A propos de cet eBook

La sauvegarde et la restauration d’Active Directory sont des opérations particulières. Souvent un peu perdu au milieu de la stratégie de sauvegarde de l’entreprise, la sauvegarde AD répond à certaines règles particulières.

Un annuaire AD intègre est un ensemble cohérent de contrôleurs de domaine d’une même forêt qui possèdent des éléments communs et des objets particuliers pour chaque domaine de la forêt. La restauration Active Directory nécessite de conserver cette cohérence.

Comme sur d’autres produits, il existe différents niveaux de granularité entre la restauration complète de la forêt et la restauration d’un utilisateur ou d’une stratégie de groupe, la démarche n’est pas identique. La maîtrise de ces processus passe par la connaissance de son environnement et de certains principes.
A la fin de ce livre, vous serez capable de :

Planifier et mettre en œuvre la sauvegarde d’Active Directory Domain Services
Définir et utiliser les outils de restaurations d’objet Active Directory (Utilisateurs, Ordinateurs, …)
Décrire et utiliser les outils de sauvegarde et restauration des stratégies de groupe
D’expliquer le principe de restauration autoritaire Active Directory / Sysvol
De restaurer l’intégralité d’une forêt Active Directory dans un environnement multi domaines.

N’attendez plus, apprenez dès aujourd’hui, à planifier et créer un plan de reprise d’activité (PRA) de votre infrastructure Active Directory

Très bon eBook écrit par Philippe BARTH, MVP Directory Services

L’eBook est disponible sur BecomeITexpert.com, cliquez sur l’image ci-après pour en savoir plus :

 

Hello tout le monde,

La liste complète des DCs de votre domaine AD peut être obtenu via :

Windows PowerShell (Cmd-lets Get-ADDomainController ou Get-ADGroupMember)

Outil CLI : NLTest.exe

 

Comment ça marche ?

Via la Cmd-let « Get-ADDomainController »

  • Lancez Windows PowerShell (en tant qu’Admin) depuis un DC ou un serveur d’administration ayant les outils RSAT AD DS installés
  • Saisissez la commande suivante : Get-ADDomainController -Filter * | Select Name

Via la Cmd-Let « Get-ADGroupMember »

  • Lancez Windows PowerShell (en tant qu’Admin) depuis un DC ou un serveur d’administration ayant les outils RSAT AD DS installés
  • Saisissez la commande suivante : Get-ADGroupMember « Contrôleurs de Domaine » | Select Name
    • Note importante : Cette commande retourne uniquement les WDC (Writable Domain Controllers), si vous souhaitez aussi lister les RODC (Read-Only Domain Controllers), vous devez exécuter la commande : Get-ADGroupMember « Read-Only Domain Controllers » | Select Name

Via l’outil CLI « NLTest.exe »

  • Lancez l’Invite de commande (CMD.exe) depuis un DC ou une machine d’administration et saisissez la commande suivante : NLTest /DCList:Nom_de_domaine

Un très bon article de Philippe BARTH [MVP Directory Services] sur le Sizing des DC (Domain Controller) pour une infrastructure Active Directory 2008, 2008 R2, 2012, 2012 R2 et 2016.

Ci-après un extrait

====================================================================

En lisant certains blogs, je suis tombé sur des valeurs un peu excessives au niveau du dimensionnement des contrôleurs de domaine, surtout pour des PME. Je me souviens par exemple d’un site qui préconise 8 Go de RAM minimum sur les DCs avec Windows Server 2012 R2, sans trop justifier cette valeur. Active Directory n’est pas un service très exigeant au niveau des performances en comparaison d’un serveur Exchange ou d’une base de données SQL Server.

Le premier point sur lequel je souhaite justement revenir est la mémoire. Il est recommandé pour des raisons de performances d’avoir suffisamment de mémoire pour conserver l’ensemble de l’annuaire dans la mémoire. A la création le fichier « NTDS.dit » à une taille inférieur à 50 Mo. Même si la taille de la base de données est variable en fonction du nombre d’utilisateurs, de groupe, si vous stocker des photos pour les utilisateurs etc…, vous verrez qu’un annuaire pour une société de moins de 300 personnes ne dépassera sans doute pas les 300Mo.

La quantité minimale de RAM devrait être supérieur à la somme de la taille de la base de données, la taille SYSVOL totale, le montant recommandé du système d’exploitation et les recommandations du fournisseur pour les agents (antivirus, surveillance, sauvegarde, etc.). Donc si on compte 1Go pour Windows 2012, 300Mo pour la base AD et 100 Mo pour le service DNS, dans une petite structure, 2 Go de mémoire peut être suffisant si le DC n’héberge pas d’autres rôles.
Dans une structure plus importante, par exemple avec une forêt multi-domaine, le rôle de catalogue global augmente la consommation de mémoire. De plus si vous installez des outils tiers comme System Center (client SCCM, agent SCOM) vous devrez peut-être prévoir un minimum de 3Go voir 4Go.

LIRE LA SUITE…