Articles Tagués ‘Active Directory’

 

Suite à la réalisation de plusieurs audits Azure chez différents clients grand comptes (Banques, Assurances, …etc), j’ai pu constaté que la plupart de leurs DC (Domain Controllers AD) hébergés dans le Cloud Azure (sous forme de VM Azure : mode Infra-as-aService), n’ont pas été Setupés, configurés et protégés correctement.

Plusieurs « Best Practices » relatives à l’exécution des Domain Controllers sur Azure (VM) sont souvent « oubliés » et rarement pris en considération lors de la phase « Build/Implementation ».

Si vous avez décidé d’étendre votre infrastructure AD vers Azure, je vous invite à prendre connaissance des items détaillés ci-dessous avant de vous lancer dans la création/build de VMs DCs.

Note : Le terme « Étendre » ici fait référence à un nouveau site distant (Site Active Directory) qui sera simplement le VNET/Subnet Azure et non pas la synchronisation d’annuaires : AD to AAD (Azure AD).

 

Liste des « Best Practices » que vous devez connaître avant de déployer vos DCs sur Azure (VM)
  • #1 : Tout d’abord, bien lire le guide « Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines » proposé par MS. Ce document vous détaille et explique bien la différence entre le déploiement d’infrastructure AD OnPrem (Infra AD traditionnelle) et le déploiement des Contrôleurs de domaine sur Azure (sur VM, connectées à des VNET/Réseaux Virtuels Azure). Je vous invite à prendre le temps de lire et comprendre tous les items détaillés dans cet article.
  • #2 : Déployez au moins deux Contrôleurs de domaine AD (2 VMs Azure)
  • #3 : Créez un Groupe à Haute Disponibilité (Availability Set) et placez-y vos Contrôleurs de domaine (au moins 2 DCs) : consulter cet article pour en savoir plus.
  • #4 : Déployez des Contrôleurs de domaine en mode « Core » plutôt qu’en mode GUI (Graphical User Interface)
    • HK Recommendation : pensez à déployer des DCs en mode Core avec un full remote management (via RSAT depuis un Bastion Environnement). Si vous déployez encore des DC sous Windows Server 2012 ou 2012 R2, vous pouvez déployer des DCs en mode MSI (Core + Minimal Server Interface > All GUI Tools)
      • Note : je vous invite à consulter cet article pour en savoir plus sur les différents modes : GUI | MSI | Core
  • #5 : Déployez des RODC (Read-Only Domain Controller) plutôt que des WDC (Writable Domain Controller)
    • Note importante : avant de déployer des RODC, vérifiez que vous Applications (à intégrer dans l’AD) supportent bien ce type de DC. Si vos Apps ont besoin d’écrire dans la base AD, déployez plutôt des WDC. Je vous invite à consulter cet article si vous avez besoin de tester la comptabilité de vos applications avec le RODC.
  • #6 : Ensuite, (TRES, TRES IMPORTANT), configurez des @IP Statiques sur vos DCs, cela doit se faire via le Portail Azure, PowerShell ou Azure CLI (depuis les Propriétés de la NIC de la VM DC) et non pas via les propriétés TCP/IP v4 de la Guest NIC :
    • Tips : vous pouvez configurer l’adresse IP (Statique) sur vos DCs via :
      • Le Portail Azure : consulter cet article pour en savoir plus.
      • Windows PowerShell [Module PS Azure] : consulter cet article pour en savoir plus.
      • Azure CLI [commande az vm]: consulter cet article pour en savoir plus.
  • #7 : Créer/Utiliser un Compte de Stockage Azure dédié pour stocker les vDisks (VHD) des Domain Controllers
  • #8 : En plus du vDisk OS créé/attaché à la VM automatiquement lors de sa création/provisioning, il est important de créer/attacher un nouveau vDisk à la VM DC (Data Disk) pour y stocker/placer la base de données AD, Fichiers Logs,SYSVOL 
  • #9 NE JAMAIS configurer de « Host Cache Prerence », lors de l’ajout du nouveau vDisk DATA (Disque de données pour AD Database, Logs & SySVOL), choisissez « None » comme valeur.
  • #10 : Utiliser les fonctionnalités RBAC (Role-Based Access Control /Contrôle d’accès en fonction du rôle) pour limiter/contrôler QUI doit ACCEDER/GERER le compte de Stockage and les clés d’accès
  • #11 : Activer le chiffrement de disque Azure (Azure Disk Encryption) avec une clé de chiffrement (KEK : Key Encryption key) pour les disques systèmes (OS vDisk) mais aussi les disques de données (Data vDisk). Azure Key Vault sera utilisé pour stocker les clés, il doit être déployé/hébergé dans la même Région & Abonnement Azure
  • #12 : Même chose pour Le coffre Key Vault, pensez à définir/implémenter une stratégie RBAC pour limiter l’accès au Key Vault stockant vos clés.
  • #13 : A l’aide d’un NSG (Network Security Group), créez et configurer des règles pour :
    • Autoriser que le traffic « Entrant » requis (Ports requis) pour les Domain Controllers
    • Refuser tout autre traffic
  • #14 : Implémentez des règles AppLocker pour autoriser que les .EXE, scripts… requis/utilisés par les DCs
  • #15 : NE JAMAIS créer/définir une @IP public pour les VMs faisant office de Domain Controllers.
  • #16 : Et bien évidemment, ne jamais activer le RDP (Remote Desktop Protocol) sur les DCs, pour réduire la surface d’attaque, et puis, on est d’accord, ce sont des DCs et non pas des serveurs RDS ou Citrix XA :).
  • #17 : Déployer et configurer l’agent Antimalware (en suivant votre standard OnPrem)
  • #18 : Déployer et configurer l’agent de monitoring (en suivant votre standard OnPrem)
  • #19 : Si votre architecture réseau le permet, implémentez une IPSec Policy pour sécuriser les communications entre vos DCs OnPrem et ceux sur Azure.
  • #20 : Et enfin, veillez à bien documenter toutes les options/fonctionnalités de sécurité implémentées, ainsi que toute modification apportée, cela vous permettra d’identifier les effets de bord/impacts post-implémentation d’une ou plusieurs Security Features spécifiques. e.g : mauvaise implémentation d’IPSec peut avoir un impact sur toute la communication inter-site (deny any<>any by default).

A bientôt, Keep in touch :).

#HK | Another IT Guy

Publicités

 

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

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

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

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

Une astuce AD qui peut vous être utile lors de vos audit Active Directory 🙂

Comment lister tous les comptes d’Ordinateurs Active Directory qui sont « Désactivés » ?

La réponse est simple, lancez Windows PowerShell (en tant qu’Admin) depuis un DC (Writable) du domaine ou serveur d’administration ayant les outils RSAT AD DS d’installés, et exécutez la commande suivante :

Get-ADComputer -Filter {(name -like « * ») -and (enabled -eq $FALSE)} -Properties * | Select Name, LastLogonDate | Ft -AutoSize

Vous pouvez trier (par Date) le résultat retourné par la commande en rajoutant un « Pipe » Sort-Object -Descending, la commande devient donc :

Get-ADComputer -Filter {(name -like « * ») -and (enabled -eq $FALSE)} -Properties * | Select Name, LastLogonDate | Sort-Object -Descending | FT -AutoSize

Enfin, le résultat (liste complète des Comptes Ordinateurs AD Désactivés) peut être exporté vers un fichier TXT ou CSV, et ce via l’utilisation d’un Pipe suivi de la Cmd-Let Export-CSV Chemin_d’Export, la commande finale est donc :

Get-ADComputer -Filter {(name -like « * ») -and (enabled -eq $FALSE)} -Properties * | Select Name, LastLogonDate | Sort-Object -Descending | Export-CSV C:\Liste_CompteOrdiAD_Desactives.csv

Il est important, avant de démarrer une migration des contrôleurs de domaine, de vérifier l’état de santé de son environnement. Les outils standards comme « DCDiag.exe » et « Repadmin.exe » sont présents par défaut à partir de Windows Server 2008. Dans les versions précédentes il faut installer les outils de support.

« DCDiag » réalise par défaut le diagnostic du contrôleur de domaine sur lequel il est exécuté. Il est possible de vérifier l’ensemble des DCs d’un site avec « /a » ou de la forêt avec « /e ». Il est possible de n’enregistrer que les erreurs avec « /q » ou de générer un rapport avec « /f:fichier.txt ». L’option « /i » permet d’ignorer les avertissements sans gravité. Il est recommandé de faire un test DNS « /test : DNS » en plus. Voici les trois exemples de test possibles avec la création d’un rapport sur « C:\Temp » qui porte le nom du DC :

DCDiag /a /i /f:c:\temp\%Computername%Full.txt

DCDiag /a /i /q /f:c:\temp\%Computername%Erreur.txt

DCDiag /test:DNS /f:c:\temp\%Computername%DNS.txt

Dans le rapport créé par « dcdiag », chaque commande apparaît avec un résultat. Vous devez vérifier qu’il n’y a pas d’échec.

La commande « Repadmin » permet de vérifier l’état de la réplication de l’annuaire Active Directory mais ne détecte pas les erreurs de réplication de « SYSVOL ». Pour vérifier la réplication des partitions d’annuaire, utilisez la commande suivante :

Repadmin /showrepl

Il est important de vérifier que le vérificateur de cohérence de la  topologie de réplication (KCC) n’est pas désactivé pour le site. S’il est désactivé, vous verrez dans les options de site le texte  « IS_AUTO_TOPOLOGY_DISABLED »

Dans ce cas, vous devrez sans doute ajouter manuellement des liens de réplications pour les nouveaux DC. La commande pour réactiver le KCC est :

Repadmin /SiteOptions /site:Paris

-IS_AUTO_TOPOLOGY_DISABLED

La commande suivante permet d’avoir un rapport général sur la réplication et sur la latence. Dans notre laboratoire nous n’avons pour le moment que deux DCs sur deux sites avec  une réplication inter-sites configuré à 180 minutes et la latence n’est pas négligeable.

Repadmin /replsummary

Il existe un autre outil qui vous permet d’analyser les problèmes de réplication des différentes partitions. Il indique des liens vers les KB (Knowledge Base) Microsoft en cas d’erreur. Il s’agit d’Active Directory Replication Status Tool disponible en téléchargement gratuit à l’URL suivante :

https://www.microsoft.com/en-us/download/details.aspx?id=30005

L’observateur d’événement est également un outil permettant d’obtenir de nombreuses informations. Je vous recommande de consulter les journaux :

  • Système
  • Réplication DFS (si SYSVOL utilise DFS-R)
  • Serveur DNS
  • Service de réplication de fichier (si SYSVOL utilise NTFRS)
  • Service D’annuaire

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

Cet article est un extrait de l’eBook « Migrer son infrastructure Active Directory vers Windows Server 2012 et 2012 R2« , disponible sur BecomeITExpert.com