I. Présentation

L'audit et la surveillance de son infrastructure sont essentiels, l'Active Directory n'échappe pas à cette règle, que ce soit pour journaliser les actions de création, modification et suppression d'un utilisateur, la connexion d'un utilisateur sur un poste, etc... Il peut être également intéressant de garder un œil sur les stratégies de groupe (GPO), notamment sur les dernières GPO modifiées. Sait-on jamais, s'il y avait une modification anormale...

Avec la méthode que l'on va voir, par script PowerShell, vous pourrez ensuite le faire tourner en automatique sur l'un de vos contrôleurs de domaine, et, pourquoi pas vous envoyer un rapport chaque jour ou semaine pour savoir quelles sont les GPO modifiées récemment.

II. Voir les GPO modifiées via PowerShell

Pour parvenir à visualiser de manière simple quelles sont les GPO modifiées récemment, il est nécessaire de passer par un script, car la console graphique de gestion des GPO ne permet pas d'avoir cette vue d'ensemble.

Pour ma part, j'ai pris le temps de coder une fonction pour afficher les GPO modifiées sur les X derniers jours, je vous glisse le code de cette fonction ci-dessous, accompagnée de son lot d'explications.

function Show-GPOEditLastXDays{
     
     # Deux paramètres obligatoires, le premier pour le nom complet du domaine
     # et le second pour le nombre de jours à prendre en compte pour détecter les modifs
     param(
     [parameter(Mandatory=$true)][string]$DomainName,
     [parameter(Mandatory=$true)][int]$LastXDays
     )

# Création d'un objet COM pour utiliser l'API de la console GPMC
$GPM = New-Object -ComObject GPMgmt.GPM

try{

  # Etablir la connexion avec le domaine AD
  $GPMDomain =$GPM.GetDomain("$DomainName", "", $GPMConstants.UseAnyDC)
 
  # Définir un critère de recherche, en l'occurrence vide car on voudra toutes les GPO
  $GPMSearchCriteria = $GPM.CreateSearchCriteria()
 
  # Récupérer la liste de toutes les GPO du domaine
  $GPMAllGpos = $GPMDomain.SearchGPOs($GPMSearchCriteria)

  # Initialiser le compteur, sera incrémenté pour compter le nombre de GPO modifiées
  $Counter = 0

  # Pour chaque GPO, on regarde si elle a été modifiée depuis les X derniers jours
  # Selon la valeur du paramètre "$LastXDays"
  foreach ($GPO in $GPMAllGpos) {

    if ($GPO.ModificationTime -ge (Get-Date).AddDays(-$LastXDays)) {

    # Pour chaque GPO qui matche, on crée un objet custom
    # contenant le nom de la GPO et la date de dernière modification
    [PSCustomObject] @{
    "GPOName" = $GPO.DisplayName ;
    "GPOModificationTime" = $GPO.ModificationTime
    }

    $Counter++
    }

  } # foreach ($GPO in $GPMAllGpos)
 
  # Si le compteur est égal à 0 c'est qu'il n'y a pas eu de GPO modifiées
  # donc on donne l'info dans la console, pour éviter une sortie vide
  if($Counter -eq 0){
     Write-Output "0 GPO modified in the last $LastXDays day(s)"
  } # if($Counter -eq 0)

}catch{

  Write-Output "ERROR ! Impossible to get the list of edited GPO, it's possible that the domain name is incorrect"
 
 }
}

Maintenant, si l'on exécute la fonction, avec les bons arguments, par exemple :

Show-GPOEditLastXDays -DomainName "it-connect.local" -LastXDays 7

On voit qu'un tableau est retourné avec 2 colonnes correspondantes au nom de la GPO et à la date de dernière modification. Bien entendu, la liste contient uniquement les GPO modifiées lors des 7 derniers jours, pour obtenir les GPO modifiées sur les dernières 24 heures, il suffit d'indiquer "1" pour l'option LastXDays.

Par curiosité, on peut ouvrir la console des GPO sur le serveur pour vérifier que les infos sont bonnes, ce qui est bien le cas ! 🙂

Avec cette API très puissante pour la gestion des GPO, il est possible de faire beaucoup de choses... comme créer une GPO ou dupliquer une GPO, en plus de pouvoir explorer toutes les propriétés. Il y a possibilité de faire de belles choses notamment en matière d'audit. 🙂

Retrouvez le script sur mon GitHub : Audit - Quelles sont les GPO modifiées lors des X derniers jours ?

I. Présentation

Après avoir vu récemment comment détecter un changement au sein des stratégies de groupe, nous allons voir comment détecter un changement dans un groupe de l'Active Directory. Nous n'utiliserons pas de logiciels tiers pour parvenir à réaliser cette surveillance, bien que des solutions existent (notamment chez Netwrix).

L'objectif n'est pas de surveiller le groupe "Secrétariat" mais plutôt les groupes critiques et sensibles, tels que Admins du domaine, les administrateurs de l'entreprise et du schéma, etc... Que ce soit dans le cadre d'une mauvaise manipulation, ou bien si vous êtes la cible d'une attaque, il y a des chances pour qu'un compte utilisateur suspect soit ajouté au sein d'un de ces groupes.

Avec la méthode que nous allons utiliser, qui s'appuie tout simplement sur un script PowerShell, il sera possible de détecter un ajout ou une suppression au sein d'un des groupes surveillés.

Pour parvenir à mes fins, j'ai pris un script existant comme base que j'ai ensuite personnalisé pour obtenir ce que je souhaitais. Voici le lien vers le script original : https://gallery.technet.microsoft.com/scriptcenter/Detect-Changes-to-AD-Group-012c3ffa

II. Comment fonctionne le script "Get-AdGroupMembershipChange.ps1" ?

Retrouvez ma version de ce script, qui reprend comme base le travail mentionné précédemment, sur mon GitHub : Get-AdGroupMembershipChange

Je ne vais pas coller ici le code du script, ça n'aurait pas d'intérêt, je vous invite à le consulter et le récupérer directement depuis le lien.

• Voici quelques informations quant au script :

- Lors de la première exécution, le script va générer un fichier CSV qui sera utilisé comme référence. En effet, à partir de la deuxième exécution, le script va comparer le contenu du fichier CSV avec l'état actuel de l'AD à l'instant t. Le script sait si c'est la première exécution ou non en testant l’existence du fichier CSV de référence.

- Lorsque le script va comparer le CSV de référence et l'état des groupes à l'instant t, il y aura 2 balayages effectués pour la comparaison, un premier dans un sens pour détecter les suppressions éventuelles, et un dans le sens inverse pour détecter les ajouts.

- Pour la partie notification, un e-mail sera envoyé en cas de changement, que ce soit un ajout ou une suppression, au sein de l'un ou de plusieurs des groupes surveillés. Il faudra configurer la partie serveur de messagerie au sein du script directement.

-Si vous ne souhaitez pas recevoir de notification par e-mail, vous pouvez choisir l'affichage en mode console directement au sein d'une table, ou alors un export au sein d'un fichier HTML. Le rapport HTML sera équivalent au contenu du rapport par e-mail.

- Dans la version de base, un e-mail de notification est envoyé par changement détecté. Dans cette version, il y a seulement un e-mail récapitulatif envoyé par exécution.

• Par exemple, une liste de groupes à surveiller :

- Administrateurs de l’entreprise
- Administrateurs du schéma
- Admins du domaine
- Administrateurs
- Opérateurs de sauvegarde

• Les journaux

Ci-dessous un exemple d'exécution du script avec l'ensemble des paramètres, que je vais vous expliquer.

.\Get-AdGroupMembershipChange.ps1 -Email "florian.burnel@mydomain.fr" -SendByMail:$true -ExportAsHTML "C:\Logs\Audit_Get-AdGroupMembershipChange\rapport.html" -LogFilePath "C:\Logs\Audit_Get-AdGroupMembershipChange\Audit_log.csv" -GroupFilePath "C:\Logs\Audit_Get-AdGroupMembershipChange\Audit_list_reference.csv" -Group "Administrateurs de l’entreprise", "Administrateurs du schéma", "Admins du domaine", "Administrateurs", "Opérateurs de sauvegarde"

Finalement, il n'y a pas tant de paramètres que ça... Seulement 4 mais ce sont les valeurs associées qui peuvent rendre la commande longue.

Email : Destinataire pour envoyer la notification par e-mail en cas de changement (rapport HTML dans le corps du mail)

LogFilePath : Le fichier de log pour consigner l'activité du script, format CSV

GroupFilePath : Le fichier de référence qui stocke l'état des groupes audités à l'instant t, format CSV

Group : La liste des groupes à auditer, surveiller

ExportAsHTML : Si vous souhaitez générer un rapport HTML, indiquez le chemin vers le rapport.

SendByMail : Un booléen pour indiquer si oui ou non il faut envoyer le rapport HTML par mail (directement en mode contenu HTML)

Après quelques secondes d'exécution, le verdict va arriver directement dans votre boîte mail 🙂

Au fil des exécutions, le fichier de log va se remplir et vous permettra d'avoir un historique au format texte :

08-18-2017 17:07:23.391+000: The log file [C:\Logs\Audit_Get-AdGroupMembershipChange\Audit_list_reference.csv] does not exist yet. Creating file.
08-18-2017 17:07:23.562+000: Querying Active directory domain for group memberships...
08-18-2017 17:07:23.781+000: Querying the [Administrateurs de l’entreprise] group for members...
08-18-2017 17:07:23.812+000: Found [7] members in the [Administrateurs de l’entreprise] group
08-18-2017 17:07:23.859+000: [Administrateurs de l’entreprise] not found in log file. Dumping all members into it...
08-18-2017 17:07:23.937+000: Reading previous [Administrateurs de l’entreprise] group members...
08-18-2017 17:07:24.16+000: No members have been removed since last check
08-18-2017 17:07:24.31+000: Found [1] members that have been added since last check
08-18-2017 17:07:24.141+000: Emailed change notification to florian.burnel@mydomain.fr
08-18-2017 17:07:24.141+000: Querying the [Administrateurs du schéma] group for members...

...Ou encore :

08-18-2017 17:11:31.394+000: Reading previous [Admins du domaine] group members...
08-18-2017 17:11:31.409+000: Found [2] members that have been removed since last check
08-18-2017 17:11:31.409+000: Emailed change notification to florian.burnel@mydomain.fr

III. Les notifications

Le script génère un rapport au format HTML, qu'il est ensuite possible de consulter facilement, comme vous le verrez sur l'image ci-dessous. J'ai essayé de le faire le plus clair possible, en mettant en évidence les changements, avec d'un côté les ajouts et d'un autre les suppressions.

Le script peut envoyer le contenu du rapport directement dans un e-mail en tant que contenu HTML, ce qui permet d'avoir le compte-rendu directement visible dans sa messagerie, par exemple :

En exécutant ce script via une tâche planifiée de manière régulière sur votre Active Directory, vous serez en mesure de détecter tout comportement suspect au niveau des groupes Active Directory sensibles. Ceci me paraît indispensable alors je vous encourage à mettre en place ce type de surveillance, que ce soit par l'intermédiaire de ce script, ou d'un autre outil/script.

Sinon concernant le script que je vous propose, avez-vous des idées d'amélioration ?

I. Présentation

Le titre de ce tutoriel est un peu trompeur, car par défaut, au sein d'un Active Directory, les accès anonymes sont déjà désactivés. Mais êtes-vous sûr que c'est toujours le cas aujourd'hui après des années d'utilisation et tout un historique ? Ça, c'est une bonne question. Après la lecture de cet article, vous serez capable de vérifier si l'accès est bien désactivé en quelques minutes ! Voire même quelques secondes puisque je vais vous fournir un code PowerShell pour vérifier la valeur de DsHeuristics dans l'Active Directory.

DsHeuristics est une valeur Unicode stockée dans l'annuaire Active Directory au niveau des propriétés du Directory Service. Elle contient une suite de chiffres qui correspondent chacun à une option, elle ne sert pas uniquement à gérer les accès anonymes.

Vous auriez pu, à un moment donné, activer l'accès anonyme au sein de votre Active Directory pour autoriser une application ou un service externe à venir authentifier les utilisateurs, par exemple. Ce que l'on appelle le binding Active Directory est désormais implémenté (dans l'outil tiers) de manière à gérer l'authentification, ce qui permet au service ou à l'application de s'authentifier auprès de l'AD avant de le requêter. C'est très important, car ça permet de ne pas avoir à activer l'accès anonyme qui est dangereux !

II. Éditer la valeur DsHeuristics

Ouvrez la console de modification ADSI sur votre contrôleur de domaine. Ensuite, via un clic droit sur "Modification ADSI", cliquez sur "Connexion".

Cliquez sur "Sélectionnez un contexte d'attribution de noms connu" et choisissez "Configuration" puis validez.

Parcourez ensuite l'arborescence : "CN=Configuration,DC=domain,DC=fr" puis "CN=Services" et enfin "CN=Windows NT". Effectuez un clic droit sur "CN=Directory Service" et cliquez sur "Propriétés".

Au sein de l'onglet "Éditeur d'attributs" en parcourant la liste, vous allez trouver un attribut nommé "dsHeuristics". Si la valeur est "non défini" ou alors qu'avec des zéros, alors c'est parfait, l'accès anonyme est désactivé sur votre AD !

Par contre, s'il y a une valeur alors c'est peut-être autorisé mais ce n'est pas sûr ! La valeur de dsHeuristics est forcément une chaîne de chiffres, dont le 7ème correspond à l'accès anonyme sur votre Active Directory. Il se peut que la septième valeur ne soit pas renseignée, dans ce cas c'est tout bon. Il faut vraiment se concentrer sur le septième chiffre de la chaîne, s'il est égal à "2" alors l'accès anonyme est autorisé sur votre annuaire.

Exemple n°1 : valeur = 0010002002 -> accès anonyme autorisé

Exemple n°2 : valeur = 002 -> accès anonyme non autorisé par septième valeur absente

Pour désactiver l'accès anonyme alors qu'il est actif, il faut :

• Remplacer le septième chiffre (qui doit être un 2) par un 0
• Effacer complètement la valeur dsHeuristics (via le bouton "Effacer") si seul le septième chiffre de la suite est renseigné, sinon vous risquez d'affecter d'autres options.

Il ne reste plus qu'à valider et le tour est joué !

Pour simplifier la procédure et l'analyse de la valeur dsHeuristics, je vous propose un petit script PowerShell, codé par moi-même.

Sur PowerShell Gallery : Get-ADAnonymousAccessStatus

I. Présentation

Lorsque l'on audit un annuaire Active Directory ou que l'on est en phase de migration, il est intéressant de voir la version du schéma de l'annuaire Active Directory. La version du schéma détermine notamment les fonctionnalités disponibles ou non au sein de votre annuaire, et ceci dépend directement de la version du système d'exploitation de vos contrôleurs de domaine.

Nous allons voir comment afficher la version du schéma Active Directory avec PowerShell ou dsquery.

Voici un tableau qui récapitule la version du schéma AD en fonction de l'OS :

II. Visualiser la version du schéma AD avec PowerShell

Ouvrez une console PowerShell en tant qu'administrateur et saisissez la commande suivante :

Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion

La propriété "ObjectVersion" retourne la version de votre schéma Active Directory. Dans l'exemple ci-dessous, la version est 87.

Passons maintenant à la méthode suivante.

III. Visualiser la version du schéma AD avec dsquery

L'utilitaire dsquery est également capable de récupérer la version du schéma AD, il peut être exécuté depuis la console DOS ou PowerShell. La commande est un peu différente et présente l'inconvénient de devoir être adapté au domaine ciblé. Cependant, elle présente l'intérêt d'être indépendant de PowerShell.

Voici la commande pour le domaine it-connect.local :

dsquery * CN=Schema,CN=Configuration,dc=it-connect,dc=local -scope base -attr objectVersion

La valeur est directement retournée dans la console :

Vous voilà désormais en mesure de récupérer la version du schéma Active Directory !

I. Présentation

Un domaine Active Directory est généralement composé de plusieurs contrôleurs de domaine qui peuvent être répartis sur plusieurs sites physiques, selon l'implantation de votre entreprise. Ces contrôleurs de domaine sont alors rattachés à un site, lui-même rattaché à différents réseaux, ce qui permet à un poste de travail de localiser le contrôleur de domaine le plus proche de lui lorsqu'une requête est envoyée, notamment pour l'ouverture de session.

En regardant les enregistrements DNS liés à votre domaine Active Directory au sein de la console DNS, vous remarquerez que le serveur disposant du rôle FSMO d'émulateur PDC est systématiquement référencé, même s'il n'est pas directement sur le site en question. De plus, le poids et la priorité sont identiques sur tous les contrôleurs de domaine par défaut, ce qui implique que votre poste de travail n'ira pas obligatoirement vers le DC du site où il se situe.

Chaque poste de travail membre d'un domaine Active Directory s'appuiera sur le composant "DCLocator" intégré au service "Netlogon" pour localiser un contrôleur de domaine. Plusieurs paramètres vont rentrer en compte pour sélectionner le contrôleur de domaine, dont les enregistrements SRV du DNS, ce qui donne de l'importance au poids et à la priorité.

Ce mode de fonctionnement peut causer des problèmes de performances au sein d'infrastructures multi-sites puisque certains postes de travail peuvent se connecter sur le contrôleur de domaine étant émulateur PDC même s'il se situe sur un distant.

Pour agir directement sur le service Netlogon, on va pouvoir s'appuyer sur deux paramètres : LdapSrvWeight et LdapSrvPriority pour gérer respectivement le poids et la priorité. Par défaut, chaque contrôleur de domaine à une priorité de 0 et un poids de 100.

II. LdapSrvWeight

Le paramétrage qui va suivre, aussi bien pour cette valeur que pour celle de l'étape d'après, doit être effectué uniquement sur le serveurs contrôleurs de domaine.

Conseil : Au préalable je vous recommande de faire un tableau avec le nom de vos DC et les valeurs que vous souhaitez attribuer au poids et à la priorité, pour bien positionner les valeurs avant de les passer en production.

Nous allons maintenant créer la valeur à l'aide de l'éditeur de registre.

Chemin vers la clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters

Vous devez créer une valeur REG_DWORD nommée "LdapSrvWeight" à cet endroit et lui attribuer une valeur décimale comprise entre 0 et 65335. Rappelez-vous, plus la valeur est haute, plus le poids sera élevé/prioritaire.

La commande PowerShell suivante permet de créer la valeur (en adaptant la valeur pour LdapSrvWeight) :

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\services\Netlogon\Parameters" -Name "LdapSrvWeight" -Value "100" -PropertyType DWORD

III. LdapSrvPriority

Comme précédemment, créons cette valeur via l'éditeur de registre.

Chemin vers la clé (identique à LdapSrvWeight) : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters

Vous devez créer une valeur REG_DWORD nommée "LdapSrvPriority" à cet endroit et lui attribuer une valeur décimale comprise entre 0 et 65335. Rappelez-vous, plus la valeur est basse, plus la priorité sera élevé (l'inverse que pour le poids, en fait).

Note : S'il y a plusieurs serveurs avec la même priorité, le poids est alors utilisé pour les départager.

Ce qui nous donne la commande suivante :

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\services\Netlogon\Parameters" -Name "LdapSrvPriority" -Value "0" -PropertyType DWORD

IV. Comment modifier la priorité d'un DC ?

Etant donné que ces données sont visibles dans les enregistrements DNS, on pourrait être tenté de modifier directement depuis la console de gestion du DNS. Ce qui serait une erreur et risquerait de créer des enregistrements en doublon, la bonne méthode consiste à passer par l'éditeur de registre (regedit).

Après avoir modifié l'une de ces deux valeurs, ou les deux, vous devrez redémarrer le service Netlogon.

En PowerShell, vous pouvez effectuer cette action très facilement :

Restart-Service netlogon

Vous devez désormais patienter le temps que les modifications prennent effet et que la réplication se déclenche entre les différents contrôleurs de domaine. Je vous conseille également de purger le cache DNS sur vos postes de travail :

ipconfig /flushdns

Astuce : sur un poste client, la variable d'environnement LOGONSERVER permet de savoir auprès de quel DC un client s'est authentifié. Vous pouvez lister les variables d'environnement en CMD (set) ou PowerShell (Get-Childitem env:).

En résumé, les contrôleurs de domaine ayant le poids le plus élevé et la priorité la plus basse sont le plus souvent sélectionnés lors du processus Netlogon.

Ajoutez à ça l'affinité de base liée au site et vous pouvez contrôler vers quel(s) contrôleur(s) de domaine se tourneront en priorité les clients de chaque site.

Ceci vous permettra d'avoir un meilleur client sur l'authentification des clients et sur les requêtes de connexion.

I. Présentation

Sur les domaines Active Directory migrés à partir de Windows Server 2003, vous pouvez avoir encore des traces de FRS (ntfrs) pour la réplication du SYSVOL au sein de votre environnement. Suite à une migration vers une version plus récente, notamment Windows Server 2012 R2 ou même Windows Server 2016, vous devez migrer la réplication SYSVOL de FRS vers DFSR qui est désormais le standard. Ceci n'est pas automatique.

Si vous installez un domaine à partir de zéro sur un OS récent, il utilisera directement DFSR.

Note : DFSR est le service de réplication du partage de données via DFS

Ce qui compte c'est qu'il ne faut plus avoir de contrôleur de domaine en Windows Server 2003 ou antérieur dans votre environnement pour pouvoir migrer vers DFSR. Dans cet exemple, l'infrastructure vient d'être migrée à partir de WS 2003 vers WS 2016.

II. Vérifier l'état de santé

Avant de se lancer tête baissée dans la migration vers DFSR, il est indispensable de vérifier que l'état de santé de votre Active Directory est bon.

Pour cela, je vous conseille d'utiliser les commandes repadmin et dcdiag, mais aussi de faire un tour dans l'observateur d'événements. L'utilitaire AD Replication Status Tool est intéressant aussi.

Avec dcdiag vous pouvez vérifier l'état de la réplication SYSVOL avec cette commande :

dcdiag /e /test:sysvolcheck /test:advertising

Ce qui retourne :

Vous pouvez aussi forcer une synchronisation globale de vos contrôleurs de domaine :

repadmin /syncall /AdeP

Et vérifiez ensuite que la synchronisation s'effectue sans erreur :

repadmin /showrepl

et

repadmin /replsum

Si tout va bien, avant de commencer la migration, vérifiez aussi ceci :

• Le niveau fonctionnel doit être au minimum Windows Server 2008
• Votre serveur dispose d'un espace disque suffisant pour stocker une copie du SYSVOL

Tout est bon ? Alors c'est parfait, on va pouvoir attaquer la migration.

III. Migration avec l'utilitaire "dfsrmig"

Tout va s'effectuer dans la ligne de commande avec l'utilitaire dfsrmig, déjà intégré à Windows. Vous allez voir que le processus est très simple, mais il ne faut pas aller trop vite.

Ouvrez une invite de commande en tant qu'administrateur sur votre DC qui est émulateur PDC et exécutez :

dfsrmig /setglobalstate 1

La migration passe en mode préparation, une copie du SYSVOL va être créée avec le nom SYSVOL_DFSR.

Avant de continuer, il faut exécuter la commande suivante :

dfsrmig /getmigrationstate

Elle permet de visualiser l'état d'avancement de l'étape que l'on vient de lancer. Si un ou plusieurs DC sont retournés c'est que ce n'est pas encore terminé, il faut encore patienter.

Vous pouvez relancer la commande de temps en temps... Jusqu'à obtenir ceci :

On peut donc passer à la deuxième étape grâce à la commande suivante :

dfsrmig /setglobalstate 2

La copie SYSVOL_DFSR va être montée sur le partage SYSVOL à la place de la copie qui fonctionne sur FRS. Pendant cette opération il faut patienter à nouveau.

Comme pour la première étape, suivez l'évolution avec la même commande, pour rappel :

dfsrmig /getmigrationstate

Quand vous obtenez ce message, vous pouvez poursuivre à la 3ème étape.

Il s'agit de la 3ème et dernière étape, où l'on va retirer complètement FRS et son SYSVOL, pour basculer entièrement sur DFSR. Saisissez la commande suivante :

dfsrmig /setglobalstate 3

Il faut patienter le temps que FRS soit retiré sur tous les DC et que DFSR soit opérationnel.

Lorsque vous arrivez à cet état, vous pouvez considérer que la réplication est migrée sur DFSR !

Si vous accédez à l'observateur d'événement, vous pourrez remarquer différents events liés à DFSR. Ceci reprend avec un peu plus de détails ce que l'on a pu voir en ligne de commande avec dfsrmig.

Vous constaterez le message "La migration DFSR pour le contrôleur de domaine mon-serveur est terminée" au sein d'un événement avec l'ID 8019.

Enfin, si vous regardez sur vos contrôleurs de domaine vous avez un dossier "SYSVOL_DFSR" qui est partagé en tant que SYSVOL et correspond désormais à votre SYSVOL en production.

Si votre antivirus se montre méfiant avec le SYSVOL, pensez à modifier le chemin d'exclusion de SYSVOL en SYSVOL_DFSR.

Bon courage pour votre migration !

I. Présentation

Pour mettre en place les services de domaine Active Directory, il est bien entendu possible de le faire par l'interface graphique mais aussi en ligne de commande par PowerShell. Ceci sera utile notamment sur un serveur en mode core, mais également pour automatiser la création d'un domaine, que ce soit pour votre lab perso ou pour une mise en oeuvre.

Des outils d'automatisation, comme PowerShell DSC pourrons vous permettre de déployer ADDS ou un contrôleur de domaine rapidement en s'appuyant sur PowerShell. Pour cet exemple, on utilisera simplement des commandes PowerShell qu'il est tout à fait possible de mettre dans un script.

Voyons ensemble comment déployer Active Directory avec PowerShell.

Besoin d'aide ? Retrouvez notre cours sur les bases Active Directory

II. Nom d'hôte

Commençons par renommer le serveur, dans cet exemple "FB-ADDS01" puis redémarrons le serveur. Ce qui nous donne ces deux commandes :

Rename-Computer -NewName FB-ADDS01 -Force
Restart-Computer

Lorsque le serveur aura redémarré, il aura son joli petit nom !

III. Configuration réseau

Maintenant, on va définir la configuration réseau du serveur, toujours via PowerShell. Dans cet exemple, j'attribue l'adresse IP 192.168.1.10 en IP, avec un masque 255.255.255.0 (/24) et une passerelle par défaut 192.168.1.1.

New-NetIPAddress -IPAddress "192.168.1.10" -PrefixLength "24" -InterfaceIndex (Get-NetAdapter).ifIndex -DefaultGateway "192.168.1.1"

Set-DnsClientServerAddress -InterfaceIndex (Get-NetAdapter).ifIndex -ServerAddresses ("127.0.0.1")

Rename-NetAdapter -Name Ethernet0 -NewName LAN

Si tout va bien, votre serveur a un nom définitif et une configuration réseau adéquate. Nous pouvons passer à la phase la plus intéressante : la mise en place du domaine Active Directory.

IV. Installation des rôles

Pour cette installation, nous aurons besoin de trois fonctionnalités : les services de domaine Active Directory (AD-Domain-Services), le DNS (DNS) et les outils d'administration graphique (RSAT-AD-Tools) mais ceci est facultatif.

$FeatureList = @("RSAT-AD-Tools","AD-Domain-Services","DNS")

Foreach($Feature in $FeatureList){

   if(((Get-WindowsFeature-Name $Feature).InstallState)-eq"Available"){

     Write-Output"Feature $Feature will be installed now !"

     Try{

        Add-WindowsFeature-Name $Feature-IncludeManagementTools -IncludeAllSubFeature

        Write-Output"$Feature : Installation is a success !"

     }Catch{

        Write-Output"$Feature : Error during installation !"
     }
   } # if(((Get-WindowsFeature -Name $Feature).InstallState) -eq "Available")
} # Foreach($Feature in $FeatureList)

Vous pourrez réutiliser le bloc de code ci-dessus, il va installer les trois fonctionnalités une à une, et vous indiquer le résultat à chaque fois. Si vous ne rencontrez pas d'erreur, vous pouvez passer à la suite.

V. Créer le domaine Active Directory

Ce qui va suivre correspond à la création du domaine, ce qui est l'équivalent du - célèbre - processus dcpromo.  En fait, nous allons définir notre nom de domaine DNS dans la variable $DomainNameDNS et le nom Netbios de ce domaine dans $DomainNameNetbios.

Pour le reste, on va stocker tous les paramètres de configuration dans la variable $ForestConfiguration. Les paramètres par défaut peuvent être conservés, sauf si vous avez des besoins spécifiques. Le répertoire SYSVOL sera à son chemin habituel, tout comme la base de données ntfs.dit.

Lorsque vous êtes prêt, vous pouvez lancer la création du domaine avec la commande Install-ADDSForest qui créera un nouveau domaine dans une nouvelle forêt.

$DomainNameDNS = "it-connect.fr"
$DomainNameNetbios = "IT-CONNECT"

$ForestConfiguration = @{
'-DatabasePath'= 'C:\Windows\NTDS';
'-DomainMode' = 'Default';
'-DomainName' = $DomainNameDNS;
'-DomainNetbiosName' = $DomainNameNetbios;
'-ForestMode' = 'Default';
'-InstallDns' = $true;
'-LogPath' = 'C:\Windows\NTDS';
'-NoRebootOnCompletion' = $false;
'-SysvolPath' = 'C:\Windows\SYSVOL';
'-Force' = $true;
'-CreateDnsDelegation' = $false }

Import-Module ADDSDeployment
Install-ADDSForest @ForestConfiguration

Si tout va bien, je vous invite à redémarrer votre serveur pour finaliser le processus d'installation. Une fois redémarré, votre domaine Active Directory doit être opérationnel. Différents cmdlets comme Get-ADForest et Get-ADDomain vous permettront d'obtenir des infos sur votre domaine et vérifier qu'il correspond à vos souhaits !

Finalement, c'est plutôt simple et pratique de pouvoir déployer un domaine directement en ligne de commande !

I. Présentation

Au sein de l'Active Directory, chaque objet "utilisateur" dispose d'un attribut nommé "proxyAddresses" qui est utilisé pour la messagerie. Il est généralement utilisé lors de la mise en place de la synchronisation entre Active Directory et Office 365 via Azure AD Connect.

Cet attribut à valeur multiple contient l'adresse e-mail principale de l'utilisateur, et éventuellement ses alias de messagerie. Dans ce tutoriel, nous allons justement voir comment ajouter par script plusieurs valeurs dans cet attribut, le tout avec PowerShell.

II. Modifier proxyAddresses avec PowerShell

Pour modifier un utilisateur dans l'Active Directory, nous allons utiliser le cmdlet "Set-ADUser" qui est très puissant et permet de modifier l'ensemble des attributs (autorisés) d'un utilisateur. Pour définir plusieurs valeurs proxyAddresses, nous pouvons utiliser un tableau de valeur.

Note : Pour rappel, l'adresse principale doit être définie avec "SMTP", et les alias avec "smtp" - La casse est donc très importante.

Commençons par définir nos adresses e-mails :

$EmailPrincipale  = "florian@domaine.fr"
$EmailSecondaire = "flo@domaine.fr"

On va ensuite construire notre tableau de valeurs (il peut y en avoir plus de deux, selon le nombre d'alias) :

$UserEmails = @("SMTP:$EmailPrincipal","smtp:$EmailSecondaire")

On va ensuite venir remplacer la valeur de l'attribut proxyAddress de notre utilisateur par le contenu de notre variable $UserEmails.

$DomainController = "SRV-DC"
$SamAccountName = "florian"
Set-ADUser -Identity $SamAccountName -Server $DomainController -Replace @{proxyAddresses=$UserEmails}

Cette commande Set-ADUser va ajouter l'adresse principale SMTP et l'alias smtp.

Maintenant, on pourrait avoir besoin de le faire en deux temps, d'abord ajouter l'adresse principale avec SMTP et ensuite l'alias avec smtp. On va toujours utiliser Set-ADUser, puis dans un premier temps on va écraser l'attribut proxyAddresses pour mettre l'adresse principale (-Replace) et on va venir ajouter l'alias (-Add).

Ce qui nous donne ces deux commandes :

Set-ADUser -Identity $SamAccountName -Server $DomainController -Replace {proxyAddresses="SMTP:$EmailPrincipale" }
Set-ADUser -Identity $SamAccountName -Server $DomainController -Add {proxyAddresses="smtp:$EmailSecondaire" }

Je vous laisse rafraîchir votre console Active Directory pour vérifier que le changement est bien pris en compte ! Sinon, pour le fun on peut aussi le vérifier en ligne de commande :

Get-ADUser -Filter 'SamAccountName -eq "florian"' -Properties proxyAddresses -Server $DomainController

Voilà, à vous de jouer !

I. Présentation

Dans un environnement Active Directory, chaque objet utilisateur dispose de différents attributs. Dans cette longue liste d'attributs par défaut, on retrouve l'attribut samAccountName et un autre nommé UserPrincipalName appelé également "UPN". Dans cet article, je vais vous expliquer la différence entre les deux.

Pour en savoir plus : Cours Active Directory

II. Un peu d'histoire...

Dans les environnements pré-Windows 2000, on utilisait le samAccountName comme identifiant pour se connecter sur les postes de travail. Attention, cela ne veut pas dire qu'il ne peut plus être utilisé sur les environnements récents. Au contraire, il est encore très utilisé. La nouvelle façon de se connecter sur les environnements depuis Windows 2000 est l'utilisation du UserPrincipalName comme identifiant de connexion.

Aujourd'hui, on a donc deux manières de se connecter sur un poste pour ouvrir sa session : le samAccountName et le UserPrincipalName. Mais alors, quel est l'intérêt de chacun ? Comment se constituent-ils ?

III. L'attribut samAccountName

Commençons par l'attribut le plus ancien : samAccountName. Il est formé de la manière suivante : <NomNetbiosDuDomaine>\<utilisateur>. Par exemple, pour le domaine "it-connect.fr" ayant "ITCONNECT" comme nom NetBios, l'utilisateur "florian" se connectera de cette façon : ITCONNECT\florian. Il pourrait même simplement se connecter avec "florian" car Windows reprend automatiquement le nom NetBios.

Quelques précisions :

- Il est limité à 20 caractères, bien que la limite soit fixée à 256 caractères dans le schéma Active Directory pour des raisons de rétro-compatibilité il n'excède pas 20 caractères. Ceci peut être gênant selon votre convention de nommage pour les logins car ça peut vous obliger à tronquer le nom de la personne par exemple.

- Il doit être unique au niveau du domaine (pour les objets).

- La variable d'environnement %USERNAME% fréquemment utilisée s'appuie sur le samAccountName et non le UserPrincipalName, même si vous êtes connecté sur la machine avec l'UPN.

Maintenant que vous en savez un peu plus sur le samAccountName, passons au UserPrincipalName.

IV. L'attribut UserPrincipalName

La syntaxe pour se connecter en utilisant le UserPrincipalName est différente par rapport au samAccountName. Ici, on utilisera un identifiant suivi du nom de domaine. Par exemple, pour le domaine "it-connect.fr" et l'utilisateur "florian", on se connectera avec l'identifiant suivant : florian@it-connect.fr.

La partie identifiant du samAccountName et de l'UPN peut être différente à chaque fois, ça pourrait être "florian" pour le samAccountName et "florian.burnel" pour l'UPN. Il s'agit bien de deux attributs distincts dans l'annuaire donc deux champs différents.

Quelques précisions :

- L'attribut UserPrincipalName du fait qu'il intègre le domaine peut être identique à l'adresse e-mail de l'utilisateur, ce qui est pratique : un seul identifiant à retenir. Si votre domaine utilise une extension non routable telle que ".local" et que vous souhaitez unifier avec le domaine de messagerie de votre entreprise, c'est envisageable en créant un alias UPN.

- Comme le samAccountName, il doit être unique au niveau du domaine (pour les objets).

- Le format de cet identifiant respecte le standard RFC 822

- Il n'y a pas la limitation de 20 caractères

- L'attribut UserPrincipalName est facultatif, contrairement au samAccountName - Je vous recommande de le renseigner.

Lorsque vous créez un utilisateur dans l'Active Directory, ces deux valeurs doivent être définies, elles correspondent aux champs suivants :

Il est bien entendu possible de modifier ces valeurs par la suite, en accédant aux propriétés d'un utilisateur. Sur une machine où l'on est connecté avec un compte du domaine, si l'on affiche les variables d'environnements (avec la commande "set" en cmd / commande "gci env:" en PowerShell), vous verrez que c'est bien le SamAccountName de l'utilisateur qui est affecté à la variable "USERNAME" :

Suite à ces explications, j'espère que vous y voyez plus clair entre le SamAccountName et le UserPrincipalName.

I. Présentation

Pour lister les rôles FSMO sur un serveur contrôleur de domaine et visualiser quel serveur est en possession de chaque rôle, on peut passer par l'interface graphique, ou alors par la ligne de commande avec la fameuse requête "netdom query fsmo". Il est aussi possible d'utiliser PowerShell pour afficher les rôles FSMO, c'est ce que nous allons voir.

II. Lister les rôles FSMO avec PowerShell

Pour obtenir la liste des propriétaires des rôles FSMO du domaine :

Get-ADDomain | Select-Object DistinguishedName, InfrastructureMaster, PDCEmulator, RIDMaster

Ensuite, pour obtenir le propriétaire des rôles Maître du Schéma et le Maître d'attribution des noms de domaine, qui sont tous les deux uniques au niveau de la forêt, il faut utiliser le cmdlet "Get-ADForest", ce qui nous donne :

Get-ADForest | Select-Object Name, SchemaMaster, DomainNamingMaster

Vous obtenez un résultat semblable à celui-ci :

Une dernière commande qui peut être intéressante, c'est "Get-ADDomainController" car elle contient la propriété "OperationMasterRoles", ce qui peut nous permettre de récupérer la liste de tous les contrôleurs de domaine, et pour chaque DC afficher les rôles FSMO dont il est master.

Voici la commande complète (si un contrôleur de domaine n'est pas maître d'au moins un rôle, il n'apparaît pas dans la sortie) :

Get-ADDomainController -Filter * | Select-Object Name, Domain, Forest, OperationMasterRoles | Where-Object {$_.OperationMasterRoles}

La commande ci-dessus vous retourne un tableau avec 4 colonnes : le nom du contrôleur de domaine, le nom du domaine, le nom de la forêt, et les rôles FSMO dont le DC est maître.

Maintenant, vous n'avez plus d'excuse, avec PowerShell vous êtes capable de récupérer des infos sur les rôles FSMO !

I. Présentation

Avec une autorité de certification, vous pourrez gérer vos certificats numériques, de la délivrance d'un certificat à sa révocation. Cette couche de sécurité offrira notamment les avantages suivants : intégrité, authentification, non répudiation et confidentialité. Ceci est possible grâce à l'utilisation à la fois de certificats, mais aussi de clés, c'est pour cela que l'on parle souvent de PKI :  Public Key Infrastructure, ou en français : IGC - Infrastructure de gestion de clés.

Sous Windows Server, la mise en oeuvre d'une autorité de certification s'effectue par l'intermédiaire du rôle ADCS : Active Directory Certificate Services. Il existe des outils open source pour mettre en place une CA sous Unix/Linux.

Une autorité de certification peut s'avérer utile et peut être sollicitée dans le cadre de nombreux projets : mise en place d'un serveur NPS (Network Policy Server) pour obtenir un certificat valide pour utiliser le 802.1X, mise en place des flux sécurisés et chiffrés pour votre serveur WSUS, ou votre Active Directory, authentification renforcée sur des applications, accès VPN.... Tant de projets pour lesquels vous pourriez avoir besoin de la solution ADCS.

Cette autorité de certification Microsoft sera capable également de signer vos scripts PowerShell pour que leur exécution soit autorisée sur les serveurs et les postes clients de votre entreprise. Ce qui vous évitera de modifier la politique d'exécution des scripts et d'exposer vos postes aux problèmes que ça implique.

L'autorité de certification est un vaste sujet, qui peut s'avérer complexe, et nécessite à minima un serveur mais selon vos besoins et les rôles à déployer, plusieurs serveurs peuvent être nécessaires.

Dans ce tutoriel, nous allons créer une autorité de certification racine d'entreprise, sous Windows Server 2016, intégrée au sein du domaine it-connect.fr. Le serveur se nomme FB-ADCS et il est déjà intégré au domaine.

II. Installer le rôle ADCS

Pour débuter l'installation, il faut installer le rôle ADCS ainsi que les outils de gestion en mode graphique. Pour réaliser cette installation, ouvrez une console PS en tant qu'administrateur et saisissez :

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

La partie installation s'arrête ici, ensuite ce n'est que de la configuration.

III. Créer l'autorité de certification racine

Il est à noter que cette configuration peut être réalisée entièrement en PowerShell, mais pour faire vos premiers pas je pense que c'est bien de passer par l'assistant, pour y aller étape par étape, et comprendre ce que vous faites. Avant de commencer, connectez-vous avec un compte utilisateur étant admin du domaine.

Commencez par démarrer le gestionnaire de serveur, et cliquez sur l'icône drapeau en haut à droite pour démarrer la configuration.

Cliquez directement sur suivant si vous êtes bien connecté avec un compte administrateur, sinon indiquez un compte admin du domaine. Ceci est impératif car des données doivent être écrites dans l'Active Directory.

Plusieurs rôles sont proposés, sélectionnez uniquement "Autorité de certification".

Sélectionnez ensuite "Autorité de certification d'entreprise". Mais au fait, c'est quoi la différence entre une CA d'entreprise et une CA autonome ?

La CA d'Entreprise nécessite un serveur intégré au domaine et elle stockera des données directement dans votre annuaire Active Directory (certificats, clés privées, etc. avec une notion d'archivage), et facilitera la distribution de certificats auprès des postes intégrés au domaine notamment car ils seront automatiquement approuvés car dit de confiance. Une CA autonome peut être installée sur un serveur hors domaine, par conséquent elle ne stocke aucune donnée dans votre annuaire AD, ce qui empêche notamment d'utiliser l'inscription automatique.

Comme il s'agit de la première Autorité de certification de notre infrastructure, sélectionnez "Autorité de certification racine".

Nous allons créer une nouvelle clé privée car nous partons de zéro.

Pour sécuriser notre clé privée avec un algorithme de hachage suffisamment robuste, sélectionnez "SHA256". Le SHA1 est déprécié par Microsoft depuis janvier 2017 qui lui préfère SHA256. Notez que SHA1 reste aujourd'hui très largement utilisé et il est malgré tout robuste, mais ne représente pas l'avenir donc je vous conseil de partir directement sur SHA256. Une longueur de clé de 2048 sera suffisante.

Indiquez un nom pour votre autorité de certification, il s'agit d'un nom qui sera indiqué dans les différents certificats que vous allez émettre avec votre CA.

Spécifiez la durée de validité du certificat généré pour votre CA, par défaut la valeur est de 5 années. Vous pouvez laisser comme ceci.

Laissez par défaut les chemins indiqués pour stocker la base de données des certificats et les logs associés. Poursuivez directement.

Il ne vous reste plus qu'à valider et après quelques minutes, vous devriez obtenir un joli message "Configuration réussie".

La console ADCS vous permettra de gérer votre autorité de certification, mais n'oubliez pas, PowerShell est également votre allié !

Dans un prochain tutoriel, nous verrons comment signer un script PowerShell avec un certificat de notre autorité de certification.

I. Présentation

La flexibilité de PowerShell s'avère très pratique lorsqu'il s'agit d'interroger un annuaire Active Directory. Notamment si l'on souhaite récupérer la liste des utilisateurs (ou d'un autre type d'objets) au sein de plusieurs OU, sans prendre tout l'annuaire.

Grâce à un script PowerShell simple, nous allons pouvoir générer facilement cette liste d'utilisateurs sans passer par des exports multiples dans la console Active Directory, qu'il faudra ensuite fusionner... Bref, pas pratique.

II. Le script

La première étape consiste à définir un tableau qui va servir à lister les OU pour lesquelles nous souhaitons récupérer les utilisateurs. Dans la variable $OUList sera stocké le tableau. Par exemple, pour 4 OU différentes, cela donne :

$OUList = @("OU=Comptabilite,DC=it-connect,DC=local", 
            "OU=Secretariat,DC=it-connect,DC=local", 
            "OU=Direction,DC=it-connect,DC=local", 
            "OU=Commercial,DC=it-connect,DC=local")

La suite est simple : pour chaque OU du tableau, nous allons récupérer la liste des utilisateurs grâce à Get-ADUser qui sera utilisé avec le paramètre SearchBase qui aura notre OU comme valeur. Ainsi, on récupère que les utilisateurs de l'OU, et cela pour nos 4 OU. Dans cet exemple, je sélectionne uniquement le SamAccountName mais vous pouvez ajouter d'autres propriétés.

Ce qui donne le script complet suivant :

$OUList = @("OU=Comptabilite,DC=it-connect,DC=local",
            "OU=Secretariat,DC=it-connect,DC=local",
            "OU=Direction,DC=it-connect,DC=local",
            "OU=Commercial,DC=it-connect,DC=local")

$Users = Foreach($OU in $OUList){

    Get-ADUser -Filter * -SearchBase $OU | Select-Object SamAccountName

}

$Users | Export-CSV -Path "C:\Users.csv" -NoTypeInformation

La variable $Users contient tous les utilisateurs, nous pouvons facilement l'exporter vers un fichier CSV grâce au cmdlet Export-CSV comme vous pouvez le voir sur la dernière ligne du script ci-dessus.

Voilà, simple mais efficace, non ? 👀

I. Présentation

Lorsque l'on requête un annuaire Active Directory, notamment lorsqu'il s'agit de faire du tri, ou dans le cadre d'un audit, on peut chercher à obtenir la liste des groupes de sécurité vides. Dans cet article, je vais partager avec vous un bout de code PowerShell qui permet de récupérer la liste des groupes vides dans l'Active Directory.

Libre à vous ensuite d'exploiter cette liste, pour supprimer les groupes en question, par exemple.

II. PowerShell et Get-ADGroupMember

Le module Active Directory de PowerShell est relativement bien fourni. Il intègre un cmdlet nommé Get-ADGroupMember et qui sert à récupérer la liste des membres d'un groupe. Cela est intéressant, car ça nous permettra de récupérer de compter les membres de chaque groupe.

Ce que l'on cherche à faire : récupérer la liste de tous les groupes, et, pour chaque groupe, lister le nom de ceux qui sont vides.

Le bout de code suivant permet d'exécuter une action sur tous les groupes avec 0 membre :

Get-ADGroup -Filter * | Foreach{ 

          if($((Get-ADGroupMember -Identity $_).Count) -eq 0){
              <action à réaliser>
          }
}

Ensuite, il ne reste plus qu'à afficher le nombre du groupe dans la console, ou d'ajouter son nom dans un fichier, ce qui donne :

Get-ADGroup -Filter * | Foreach{ 

          if($((Get-ADGroupMember -Identity $_).Count) -eq 0){

                Write-Output "Groupe $_"
                Add-Content -Path "C:\Log_GroupsEmpty.log" -Value $_
          }
}

Enfin, nous pouvons aller plus loin en supprimant les groupes vides grâce à la commande Remove-ADGroup. Grâce au fichier de log, nous aurons une liste des groupes supprimés.

Pour supprimer les groupes vides de l'Active Directory, cela donne :

Get-ADGroup -Filter * | Foreach{ 

          if($((Get-ADGroupMember -Identity $_).Count) -eq 0){

                Write-Output "Groupe $_"
                Add-Content -Path "C:\Log_GroupsEmpty.log" -Value $_

                Remove-ADGroup -Identity $_ -Confirm:$false
          }
}

Voilà, à vous de jouer... Mais attention quand même avec ce type de script. Je vous recommande de l'exécuter sans la commande Remove-ADGroup dans un premier temps pour voir vérifier quelques groupes qui ressortent 🙂

Débutant avec PowerShell ? ➡👀 Débuter avec PowerShell

I. Présentation

Une fois de plus, je vous propose de parler Active Directory et PowerShell, pour répondre à la question suivante : comment récupérer la liste des utilisateurs créés à une date précise ? Il peut y avoir tout un tas de raison de vouloir faire cette requête, surement au sein d'un script beaucoup plus global, mais cela dépendra de vos besoins. L'intérêt est de vous proposer un snippet prêt à l'emploi 😉

Personnellement, je l'ai utilisé pour regarder combien il y avait eu de comptes créés dans l'Active Directory à une date précise, une date qui peut-être le jour même.

II. PowerShell - Récupérer la liste

Pour le script, nous allons appliquer le principe suivant :

1 - Récupérer la date du jour

2 - Stocker dans une variable la date et heure de début de journée, c'est-à-dire à minuit 00:00

3 - Stocker dans une variable la date et heure de fin de journée, c'est-à-dire à 23:59

4 - Rechercher dans l'Active Directory les comptes qui ont une date de création "plus grande" que la date de début de journée et "plus petite" que la date de fin de journée

Si l'on veut récupérer les comptes créés à une date précise, autre que la date du jour, il faudra agir sur la variable $Date avec la méthode AddDays pour calculer la date souhaitée, ou, directement l'indiquer en chaîne de caractères dans la variable $Date en conservant le type [datetime].

Pour récupérer la date du jour, cela donne :

[datetime]$Date = Get-Date -Format "MM/dd/yyyy"

Par contre, si l'on veut une date précise, on peut l'indiquer comme ça (exemple :19 octobre 2019) :

[datetime]$Date = "10/19/2019"

Nous pouvons aussi calculer la date en soustrayant un nombre de jours, par exemple pour avoir la date de la veille :

$Date = ($Date).AddDays(-1)

Maintenant, nous allons créer deux variables : $DateOn et $DateOff pour avoir la date et l'heure de début de journée et celle de fin de journée. Nous allons utiliser les méthodes AddHours, AddMinutes et AddSeconds pour définir l'heure.

Pour définir l'heure de début à 00:00:00, cela donne :

$DateOn = $Date.AddHours(00).AddMinutes(00).AddSeconds(00)

Ensuite, pour l'heure de fin à 23:59:59 :

$DateOff = $Date.AddHours(23).AddMinutes(59).AddSeconds(59)

Maintenant que nous avons notre plage de recherche, il ne reste plus qu'à envoyer la requête sur l'annuaire Active Directory. Chaque utilisateur dispose d'un attribut natif nommé "WhenCreated" et qui contient la date de création de l'objet 👍

Donc, pour lister les utilisateurs nous allons utiliser Get-ADUser (commande du module Active Directory de PowerShell) et réaliser un filtre sur l'attribut WhenCreated, ce qui donne :

Get-ADUser -Filter 'whenCreated -ge $DateOn -and whenCreated -lt $DateOff' -Properties whenCreated

Au lieu de lister les utilisateurs, nous pouvons aussi les compter :

$Nb = (Get-ADUser -Filter 'whenCreated -ge $DateOn -and whenCreated -lt $DateOff' -Properties whenCreated | Measure-Object).count

Ce qui au final nous donne le bout de code PowerShell suivant :

[datetime]$Date = Get-Date -Format "MM/dd/yyyy"
$Date = ($Date).AddDays(-1)
$DateOn = $Date.AddHours(00).AddMinutes(00).AddSeconds(00)
$DateOff = $Date.AddHours(23).AddMinutes(59).AddSeconds(59)

Get-ADUser -Filter 'whenCreated -ge $DateOn -and whenCreated -lt $DateOff' -Properties whenCreated

Voilà, il ne reste plus qu'à utiliser ces quelques lignes dans votre script, vous pouvez en faire une fonction également 😉

I. Présentation

Je vous rappelle que, par défaut, lorsque l'on crée un domaine Active Directory, tous les utilisateurs ont le droit d'ajouter 10 machines dans le domaine. Cela est possible sans avoir besoin d'être "Admin du domaine", enfin il faut tout de même être admin de la machine.

Il y a plusieurs années, je vous proposait un article pour corriger cela et restreindre l'ajout de machines à qui de droit : Restreindre l'ajout de machines au domaine. Si cela n'est pas corrigé au sein de votre domaine, je vous encourage à réaliser la modification.

Pour compléter cet article, je vous propose de voir comment déléguer l'ajout d'ordinateurs au domaine. Cela est utile pour autoriser un compte utilisateur spécifique à ajouter des ordinateurs au domaine, ce qui pourrait être le compte utilisé par votre serveur de déploiement MDT pour la jonction au domaine.

II. Procédure - déléguer l'ajout d'ordinateurs au domaine

Commencez par ouvrir la console "Users and Computers Active Directory" (Utilisateurs et ordinateurs Active Directory). Imaginons que l'on souhaite tout simplement autoriser l'ajout d'ordinateurs dans l'OU "Computers", effectuez un clic droit dessus et cliquez sur "Delegate Control" (Délégation de contrôle).

Note : la délégation doit être réalisée sur chacune des OU au sein desquels l'utilisateur doit pouvoir créer des objets ordinateurs. Il faut être le plus précis et le plus restrictif possible par mesure de sécurité.

Ajoutez le compte utilisateur pour lequel vous souhaitez ajouter l'autorisation, ou autrement dit, déléguer le droit. Il est tout à fait possible d'utiliser un groupe de sécurité.

Nous allons créer une délégation spécifique, choisissez "Create a custom task to delegate".

Cochez la case "Only the following objectifs in the folder" pour autoriser uniquement la création d'objets de type "ordinateurs" nous choisirons ensuite "Computer objects". Enfin, cochez "Create selected objects in this folder" pour autoriser la création de objets de ce type.

Au niveau des permissions à déléguer, il est nécessaire de cocher "General" et "Creation/deletion of specific child objects", puis la permission "Create All Child Objects".

Maintenant que nous avons indiqué l'utilisateur à qui attribuer les droits, que l'on a indiqué précisément les droits à lui déléguer, il ne reste plus qu'à valider 😉

Vous l'aurez compris, il faut répéter cette action si vous souhaitez déléguer les droits pour cet utilisateur sur d'autres unités d'organisation.

I. Présentation

Un annuaire Active Directory est vivant : il évolue au rythme des arrivées et des départs dans l'entreprise, mais il est également lié à votre parc machine puisqu'elles seront probablement intégrées au domaine.

Par conséquent, l’annuaire contient des comptes utilisateurs et ordinateurs plus utilisés mais actifs (au niveau annuaire), ces comptes doivent être gérés et ne pas être laissés en l’état.

L’ANSSI recommande d’appliquer les règles suivantes pour la gestion des comptes inactifs :

• Définir une politique de désactivation automatique des comptes non utilisés pendant un certain laps de temps
• Conserver les comptes désactivés et inutilisés afin d’avoir un historique des comptes utilisateurs au sein du système d’information
• Placer les comptes désactivés dans une unité d’organisation (« OU ») spécifique
• Retirer les droits et privilèges des comptes désactivés

II. Comment rechercher les utilisateurs et ordinateurs inactifs ?

Le cmdlet "Search-ADaccount" va permettre assez facilement de rechercher les objets inactifs au sein de l'annuaire, que ce soit les ordinateurs ou les utilisateurs. Le paramètre Timespan sert à indiquer un nombre de jours, par exemple si l'on indique 180 jours, cela correspond à 6 mois, et la requête nous retournera les objets inactifs depuis au moins 180 jours.

Mais au fait, qu'entendons-nous par inactif ? Lorsqu'un utilisateur ou un ordinateur réalise une connexion auprès d'un contrôleur de domaine, cela actualise l'attribut LastLogon de l'objet. La valeur de cet attribut correspond à la date de dernière connexion de l'utilisateur/ordinateur auprès d'un contrôleur de domaine.

• Pour rechercher les comptes utilisateurs inactifs depuis 180 jours :

Search-ADaccount -UsersOnly -AccountInactive -Timespan 180

• Pour rechercher les comptes utilisateurs inactifs depuis 180 jours :

Search-ADaccount -ComputersOnly -AccountInactive -Timespan 180

Remarque : les comptes qui ne se sont jamais connectés seront considérés comme étant inactifs, même si le compte vient d'être créé.

Il se peut que cette commande indique certains comptes built-in comme étant inactifs, par exemple le compte "Invité" ou le compte "krbtgt" qui sert à distribuer les tickets Kerberos. Pour éviter une mésaventure, il peut être intéressant d'exclure de la recherche l'OU "Users". Ce qui nous donne :

Search-ADaccount -UsersOnly -AccountInactive -Timespan 180 | Where{ $_.DistinguishedName -notmatch "CN=Users" }

Ah oui, au fait, j'allais oublier : nous allons ajouter une autre condition dans la clause Where pour récupérer uniquement les comptes activés dans l'annuaire. Sinon, les utilisateurs seront traités à chaque fois que le script s'exécute. Voici la commande mise à jour :

Search-ADaccount -UsersOnly -AccountInactive -Timespan 180 | Where{ ($_.DistinguishedName -notmatch "CN=Users") -and ($_.Enabled -eq $true) }

III. Retirer l'utilisateur des groupes dont il est membre

Maintenant que nous sommes en capacité de récupérer la liste des objets inactifs, nous devons le supprimer des groupes auxquels il appartient. Prenons l'exemple d'un utilisateur nommé "une-comptable-01" et qui appartient à deux groupes : "Comptabilité" et "Utilisateurs du domaine". Nous allons lui laisser seulement le groupe par défaut (Utilisateurs du domaine).

Commençons par stocker le SamAccountName de l'utilisateur dans une variable :

$SamAccountName "ma-comptable-01"

Puis, nous allons le retirer des groupes :

Get-AdPrincipalGroupMembership -Identity $SamAccountName | Where-Object { $_.Name -Ne "Utilisateurs du domaine" } | Remove-AdGroupMember -Members $SamAccountName -Confirm:$false

Nous ne demanderons pas de confirmation pour plus de simplicité. Le tour est joué pour cette partie 🙂

IV. Désactiver l'utilisateur et le déplacer

Pour désactiver ce même utilisateur, nous allons utiliser la commande suivante :

Set-ADUser -Identity $SamAccountName -Enabled:$false -Description "Désactivé le $(Get-Date -Format dd/MM/yyyy)"

Dans l'attribut "description" nous allons indiquer la date afin d'avoir une traçabilité 👍

La dernière étape consiste à déplacer l'utilisateur dans une unité d'organisation dédiée aux comptes archivés / inactifs. Avec le cmdlet Move-ADObject, nous allons utiliser le DistinguishedName de l'utilisateur, via la variable $DN. Cette valeur sera récupérée automatiquement dans le script final.

Par exemple :

$DN = "CN=Une Comptable,OU=Personnel,DC=IT-CONNECT,DC=LOCAL"

On déplace l'utilisateur vers l'OU "OU=Archivage,DC=IT-CONNECT,DC=LOCAL" :

Move-ADObject -Identity "$DN" -TargetPath "OU=Archivage,DC=IT-CONNECT,DC=LOCAL"

V. Script de gestion des comptes inactifs

Maintenant que nous avons vu les différentes actions traduites en commandes PowerShell, on peut regrouper tout cela dans un script. Afin d'avoir un seul script qui gère aussi bien les ordinateurs que les utilisateurs inactifs, il faut penser à ne pas indiquer UsersOnly ou ComputersOnly dans la commande Search-ADAccount.

Il faut également adapter certaines commandes, en fonction de s'il s'agit un objet utilisateur ou ordinateur à traiter. Pour cela, on va se baser sur l'attribut ObjectClass qui nous indique si l'objet est de type user ou computer.

$InactivesObjects = Search-ADaccount -AccountInactive -Timespan 180 | Where{ ($_.DistinguishedName -notmatch "CN=Users") -and ($_.Enabled -eq $true) }

Foreach($Object in $InactivesObjects){

  $SamAccountName = $Object.SamAccountName
  $DN = $Object.DistinguishedName
  $ObjectClass = $Object.ObjectClass

  Write-Output "L'objet $SamAccountName est inactif !"

# Si c'est un utilisateur...
if($ObjectClass -eq "user"){

  # Retirer l'utilisateur des groupes (sauf "Utilisateurs du domaine")
  Get-AdPrincipalGroupMembership -Identity $SamAccountName | Where-Object { $_.Name -Ne "Utilisateurs du domaine" } | Remove-AdGroupMember -Members $SamAccountName -Confirm:$false -ErrorVariable ClearObject

  # Désactiver l'utilisateur
  Set-ADUser -Identity $SamAccountName -Enabled:$false -Description "Désactivé le $(Get-Date -Format dd/MM/yyyy)" -ErrorVariable +ClearObject

# Sinon, si c'est un ordinateur...
}elseif($ObjectClass -eq "computer"){

  # Retirer l'ordinateur des groupes (sauf "Ordinateurs du domaine")
  Get-AdPrincipalGroupMembership -Identity $SamAccountName | Where-Object { $_.Name -Ne "Ordinateurs du domaine" } | Remove-AdGroupMember -Members $SamAccountName -Confirm:$false -ErrorVariable ClearObject

  # Désactiver l'ordinateur
  Set-ADComputer -Identity $SamAccountName -Enabled:$false -Description "Désactivé le $(Get-Date -Format dd/MM/yyyy)" -ErrorVariable +ClearObject
}

# Déplacer l'utilisateur/ordinateur
Move-ADObject -Identity "$DN" -TargetPath "OU=Archivage,DC=IT-CONNECT,DC=LOCAL" -ErrorVariable +ClearObject

if($ClearUser){
  Write-Output "ERREUR ! objet concerné : $SamAccountName ($ObjectClass)"
}else{
  Write-Output "Traitement de l'objet $SamAccountName de type $ObjectClass avec succès ! :-)"
}
  Clear-Variable ClearUser
}

Voilà, ne reste plus qu'à améliorer ce bout de code 😉

En espérant que ces commandes et conseils vous seront utiles ! N'hésitez pas à partager votre retour d'expérience dans la gestion des objets inactifs.

I. Présentation

L'Active Directory s'enrichit au fil des versions de mécanismes de protection pour protéger les comptes disposant de privilèges élevés sur l'infrastructure. Depuis Windows Server 2012 R2, Microsoft a intégré un nouveau groupe baptisé "Protected Users" : mais qu'est-ce qu'il apporte vraiment ?

Pour sécuriser les comptes d'administration, l'Active Directory va modifier certains comportements sur les comptes ajoutés au groupe Protected Users. L'idée est notamment d'éviter que les identifiants soient dérobés sur une machine où le compte est utilisé.

II. Protected Users : quels impacts (et bénéfices) ?

Lorsqu'un compte utilisateur est ajouté au groupe Protected Users, s'appliquent notamment les règles suivantes :

• Les identifiants ne sont pas mis en cache sur les machines. Sur une machine déconnectée du réseau, il ne sera pas possible de se connecter, même si la session a déjà était ouverte sur le poste en question. Le contrôleur de domaine doit être joignable impérativement.
• Le ticket Kerberos (TGT) est délivré à la connexion de l'utilisateur et il ne sera pas renouvelé automatiquement lorsqu'il devient invalide (4 heures, par défaut sur ces comptes).
• Impossible d'utiliser DES ou RC4 pour la pré-authentification Kerberos, d'utiliser NTLM pour s'authentifier, ni CredSSP.

Exemple n°1 : si vous utilisez un compte admin du domaine pour vous authentifier en VPN au travers de l'authentification basée sur l'AD, ça ne fonctionnera plus pour ce compte si il est ajouté au groupe Protected Users.

Exemple n°2 : pour vous connecter en RDP sur un serveur, il sera nécessaire d'utiliser le nom FQDN du serveur, avec l'adresse IP l'accès ne sera pas possible.

Tout cela pour dire qu'il ne faut pas ajouter des utilisateurs à ce groupe sans réfléchir, il convient de réaliser des tests sur votre infrastructure pour bien identifier les éventuelles problématiques.

Attention, ce groupe n'est pas fait pour contenir des objets ordinateurs ou des comptes de service.

Note : les fonctionnalités du groupe Protected Users sont supportées sur Windows Server 2012 R2 et Windows 8.1, et les versions ultérieures donc Windows 10 bien sûr et WS 2016 / 2019.

III. Gérer les membres du groupe

Pour lister les membres du groupe Protected Users et ajouter un nouveau membre, nous avons plusieurs méthodes : tout simplement via le Centre Active Directory, la console Utilisateurs et ordinateurs Active Directory, mais aussi avec PowerShell bien sûr. Ce groupe se situe dans l'OU built-in Users.

Voici la commande :

Get-ADGroupMember -Identity "Protected Users"

Pour ajouter un nouvel utilisateur à ce groupe, c'est également possible en mode graphique et en PowerShell. Par exemple pour ajouter le compte "fb.itconnect" :

Get-ADGroup -Identity "Protected Users" | Add-ADGroupMember –Members "CN=fb.itconnect,CN=Users,DC=IT-CONNECT,DC=LOCAL"

IV. Démo avec mimikatz

Mimikatz est une application gratuite qui est très réputée et répandue lorsqu'il s'agit de s'attaquer à un environnement Windows, et plus particulièrement lorsqu'il s'agit de postes intégrés à un domaine Active Directory.

Sur Windows, le processus lsass.exe (Local Security Authority SubSystem) gère les informations d'identifications, et ils sont notamment stockés en mémoire. Avec Mimikatz, ils peuvent être extrait, notamment dans le but de récupérer le hash NTLM des comptes actifs sur la machine. Imaginez s'il s'agit des informations correspondantes à un compte "Administrateur" sur le domaine : cela peut-être dramatique.

Nous allons voir le comportement dans deux cas : avec un compte administrateur qui n'est pas dans le groupe "Protected Users" et ensuite nous mettrons ce compte dans le groupe pour voir la différence.

L'outil Mimikatz est disponible sur Github. Pour ma part, je vais l'utiliser sur une machine Windows 10 et l'exécuter en tant qu'administrateur (pour gagner du temps...). Attention : de nombreux antivirus bloquent l'exécution de Mimikatz, il faudra donc désactiver Windows Defender pour pouvoir mener à bien cette attaque.

Commençons par réaliser une élévations de privilèges avec Mimikatz sur la machine locale :

privilege::debug
token::elevate

Ensuite, il y a plusieurs commandes disponibles pour afficher des informations... Pour ma part, j'ai utilisé la commande ci-dessous qui affiche notamment des informations sur les utilisateurs connectés :

sekurlsa::logonPasswords

Dans la liste des informations et comptes qui s'affichent, on retrouve assez rapidement le compte "fb.itconnect". Qu'est-ce que je vois comme information : NTLM, soit le hash NTLM du mot de passe de ce compte. Ça sent pas bon pour mon administrateur car avec ce hash en main, des portes s'ouvrent...!

Maintenant, on reprend tout à zéro : imaginons que ce compte est membre du groupe "Protected Users". Si je réalise de nouveau la même opération avec Mimikatz, voici ce que j'obtiens :

Sur la copie d'écran ci-dessus, on peut voir que le hash NTLM n'apparaît plus. Voilà l'un des bénéfices du groupe "Protected Users" où l'on est obligé d'utiliser Kerberos.

Comme je le disais précédemment, un compte membre du groupe "Protected Users" ne sera pas mis en cache sur une machine. Pour pouvoir ouvrir la session, le poste doit être en mesure de joindre le contrôleur de domaine. Avec un compte classique, les identifiants sont mis en cache (pour 10 utilisateurs par défaut), ce qui permettra d'ouvrir la session en mode hors ligne : ce qui est dangereux pour les comptes sensibles.

Les informations des identifiants en cache sont stockées dans le registre au sein de la clé : HKEY_LOCAL_MACHINE\Security\Cache

De façon plus radicale, la mise en cache peut être désactivée sur les postes par l'intermédiaire d'une GPO. Il faudra modifier le paramètre de GPO suivant : "Ouverture de session interactive : nombre de demandes d’ouverture de session à mettre en cache (au cas où le contrôleur de domaine ne serait pas disponible)" qui se trouve sous : Configuration Ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité

Tout cela pour dire qu'il est vivement recommandé d'utiliser le groupe "Protected Users" pour sécuriser les comptes sensibles de l'Active Directory. Bien que ce ne soit pas la seule action à mener, c'est une couche de sécurité intéressante que Microsoft a implémentée depuis Windows Server 2012 R2. A exploiter autant que possible 😉

I. Présentation

Chaque domaine Active Directory contient un compte utilisateur nommé "krbtgt", désactivé par défaut et il ne doit pas être supprimé ! Le mot de passe de ce compte est utilisé pour générer les tickets Kerberos, vous voyez son importance.

Le mot de passe de ce compte se ne renouvelle pas automatiquement, ce qui représente un risque en matière de sécurité. Ce compte mémorise deux mots de passe : celui qui est actif, et l'ancien, cela permet de conserver la validité des tickets Kerberos déjà émis. Tout en sachant que par défaut, la durée maximale d'un ticket Kerberos est de 10 heures.

II. Procédure pour gérer le mot de passe du compte krbtgt

La modification du mot de passe du compte krbtgt doit s'opérer selon une méthode très précise, qu'il faut suivre à la lettre, sous peine de rencontrer des problèmes d'authentification. En effet, les tickets en cours deviendraient invalides.

Dans la pratique, nous devons réinitialiser le mot de passe du compte krbtgt une première fois. Ensuite, il faut s'assurer que le mot de passe est répliqué sur l'ensemble des contrôleurs de domaine. Il va falloir réinitialiser une seconde fois le mot de passe du compte (puisqu'il en mémorise 2) afin de mener l'opération jusqu'au bout.

Avant cela, il vaut mieux attendre au moins 10 heures après le premier changement de mot de passe pour être sur que tous les tickets en cours de validité intègre le nouveau mot de passe (le deuxième reste l'ancien). Ensuite, il faudra réinitialiser une seconde fois le mot de passe : le compte krbtgt aura alors deux nouveaux mots de passe.

Sur le site Technet, un script est disponible pour réaliser cette opération. Celui-ci contient une documentation que je vous recommande de lire avant de réaliser l'opération, et il respecte la bonne procédure. Il dispose de trois modes pour vous accompagner dans la démarche :

• Mode n°1 pour effectuer les contrôles et analyser l'environnement, indispensable avant de lancer l'opération
• Mode n°2 pour simuler l'opération sans réellement modifier le mot de passe
• Mode n°3 pour réinitialiser le mot de passe

Voici le lien : Script krbtgt

III. Utiliser le script

Ce script n'étant pas signé il faut, tout d'abord, modifier la politique d'exécution ou alors débloquer ce fichier ; au choix.

Unblock-File .\New-CtmADKrbtgtKeys.ps1

Ensuite, exécutez le script et il faudra choisir un mode.

Lorsque l'on démarre le mode n°1, le script va vérifier différentes choses, notamment : la présence des modules PowerShell nécessaires, le nom du domaine, le niveau fonctionnel du domaine, la durée maximale d'un ticket Kerberos, si tous les tickets basés sur la clé n-1 (mot de passe) sont expirés ainsi que la connectivité avec les différents DC.

Note : si vous rencontrez une erreur sur le test RPC alors que votre serveur est bien joignable, je vous invite à lire la partie suivante de cet article.

Dans le dossier où se situe le script, un fichier de log sera créé à chaque fois, voici un exemple :

Lorsque tout est prêt, il est ne reste plus qu'à choisir le mode 3 pour réinitialiser une première fois le mot de passe. Il faudra saisir "y" est valider pour déclencher l'opération.

Si vous cherchez à relancer une deuxième modification maintenant, le script va vous avertir que vous n'avez pas attendu que les tickets Kerberos en cours soient arrivés à expiration, c'est plutôt bien pensé et cela permet de sécuriser l'opération 🙂

Le script s'occupe de générer un mot de passe complexe de 32 caractères, et il vérifie également la réplication avec les autres contrôleurs de domaine.

Voici la commande exécutée pour réinitialiser le mot de passe :

Set-ADAccountPassword -Identity (Get-ADUser krbtgt -Server $Server).DistinguishedName -Server $Server -Reset -NewPassword (ConvertTo-SecureString ((New-CtmADComplexPassword 32).ToString()) -AsPlainText -Force

IV. Cas particulier sur une version française de Windows Server

Si comme moi, vous avez testé le script sur une version française de Windows Server, vous avez dû faire face à un erreur liée au RPC. Ce qui donne lieu à un joli "RpcToDCsPassed : False" dans le fichier de log.

Pourtant, si l'on test manuellement la communication RPC vers son serveur dans une console, en exécutant la même commande que le script, ça semble fonctionner :

rpcping.exe -s SRV-ADDS-01.it-connect.local -u 9 -a connect

En fait, le problème se situe directement dans le code du script. A la ligne 62, on considère la connexion RPC opérationnelle si la commande rpcping.exe retourne le mot "completed" dans le résultat :

 # Check output of RPCPING for success
If ($RpcPingResult -like "*Completed*")....

Sauf qu'en français, l'utilitaire rpcping.exe répond d'une autre façon donc forcément cela pose problème. Nous allons devoir modifier la ligne n°62 dans le script : remplacez le mot "Completed" par "appels effectu".

Il y a un autre problème similaire, cette fois-ci avec la commande repadmin.exe à la ligne 84.

 # Check output of REPADMIN for success
If ($RepAdminResult -like "*Successfully replicated object*")

Sur cette ligne, remplacez la phrase "Successfully replicated object" par "correctement r‚pliqu". Enregistrez : le tour est joué 😉

Tous les combien de temps faut-il réinitialiser le mot de passe du compte krbtgt ? Je pense que tous les 6 mois, c'est une bonne chose.

I. Présentation

L'outil Active Directory Topology Diagrammer est proposé par Microsoft depuis 2011, et bien qu'il soit vieillissant, il peut encore rendre quelques services. Il reste compatible aujourd'hui avec les versions récentes de Windows Server malgré son grand âge.

Ce logiciel s'appuie sur Microsoft Visio pour générer un diagramme de votre infrastructure Active Directory en se connectant en LDAP à votre annuaire. Ce diagramme pourra inclure plus ou moins d'éléments en fonction des options cochées, à savoir les différentes domaines, les sites, les unités d'organisation, les informations sur DFS-R, etc.

Ce diagramme est généré au format Visio donc il est possible de l'éditer ensuite, ce qui est plutôt intéressant.

Cet outil s'avère intéressant en phase d'audit mais aussi pour réaliser un minimum de documentation sur son infrastructure.

Vous pouvez le récupérer sur cette page : ADTD

Pour fonctionner, l'outil requiert que le .NET Framework 2.0 et Visio (2003 minimum) soient installés sur l'hôte où il va être utilisé.

II. Configuration de Visio

Compte-tenu de l'ancienneté du logiciel, il crée un fichier Visio dans une ancienne version. Si vous utilisez une version récente de Vision, il faut le configurer pour autoriser ces fichiers.

Ouvrez Visio et accédez au "Centre de gestion de la confidentialité" via les options. Ensuite, cliquez sur "Paramètres de blocage des fichiers".

Concernant les deux premières lignes, décochez les cases qui le sont, afin de permettre l'utilisation des fichiers VSD. Comme ceci :

Validez, et nous allons pouvoir passer à l'utilisation de l'outil ADTD.

III. Utiliser l'outil ADTD

L'outil est relativement simple à utiliser, il faut commencer par indiquer le nom d'un contrôleur de domaine (catalogue global) ou le nom DNS du domaine au niveau du champ "Server/Domain" dans le haut de l'interface.

Ensuite, il y a différents onglets où vous pouvez cocher/décocher des options pour ajouter/supprimer des informations à intégrer aux schémas.

Il est notamment possible d'afficher :

• Les relations d'approbations [Domains]
• Le nombre d'utilisateurs par domaine [Domains]
• L'architectures des unités d'organisation pour chaque domaine (avec un nombre de niveaux spécifique) [OUs]
• Lister les GPOs [OUs]
• Dessiner les sites avec les informations comme les subnets [Sites]
• Dessiner l'organisation Exchange on-premise avec le nombre de mailbox et les connecteurs [Exchange]
• Réplication DFS-R [DFS-R]
• Afficher les serveurs avec la version et le nom FQDN [Servers]

Lorsque vous êtes prêt, cliquez sur le bouton "Discover!", patientez... puis appuyez sur le bouton "Draw" quand le bouton devient disponible ! 😉

Le schéma généré va alors afficher vos différentes sites et domaines, avec les contrôleurs de domaine associés et des informations complémentaires en fonction des options choisies. En fonction des options choisies, il sera éclaté en plusieurs schémas pour faciliter la lecture, en fait il y aura un schéma VSD par onglet : n'hésitez pas à faire des tests. Désolé pour le flou sur l'exemple ci-dessous, mais les informations sont confidentielles.

A vous de jouer !

I. Présentation

Dans ce tutoriel, nous allons voir comment préparer son infrastructure à l'utilisation des comptes de service gMSA, ainsi que l'utilisation et la gestion des comptes gMSA sur des serveurs sous Windows Server.

Windows Server 2008 a apporté les comptes de type MSA (Managed Services Accounts) appelé également sMSA (standalone Managed Service Account) et Windows Server 2012 quant à lui a apporté dans son sac de nouveautés les gMSA (group Managed Service Accounts) qui sont une version améliorée des MSA.

Ce qu'il faut savoir au sujet des gMSA :

- Un même gMSA est utilisable sur plusieurs serveurs

- Les gMSA sont stockés dans le container "Managed Service Account" dans l'Active Directory

- Un gMSA est utilisable uniquement sur Windows Server 2012 et ultérieur

- Nécessite l'utilisation de Microsoft Key Distribution Service (kdssvc.dll) pour la gestion automatique des mots de passe et la création des comptes

- un gMSA s'apparente à un groupe de sécurité dans lequel on va associer des objets ordinateurs qui seront autorisés à utiliser ce compte de service sécurisé

- Le niveau fonctionnel de votre forêt Active Directory doit être Windows Server 2012 au minimum

- Le mot de passe est géré par l'Active Directory, il est très très complexe et personne ne le connaît

Avec un compte MSA ou gMSA, la gestion du mot de passe est automatique par l'Active Directory lui-même, contrairement à l'utilisation d'un compte utilisateur classique, que l'on peut utiliser pour un service mais pour lequel vous devez gérer vous même le renouvellement du mot de passe. Bien souvent, comme c'est contraignant et chronophage, les mots de passe de ces comptes ne sont pas renouvelés par les administrateurs. D'où l'utilité de s'appuyer sur la solution gMSA, qui en plus offre une sécurité accrue au niveau des credentials.

Un compte MSA peut-être associé à seulement un serveur, contrairement au gMSA, ce qui est contraignant lorsque vous avez besoin d'utiliser un compte de service sur un service qui est redondé entre plusieurs serveurs.

Au niveau de la compatibilité, les comptes gMSA fonctionnent avec différents types d'applications et de fonctionnalités, notamment :

- Des services Windows
- Des tâches planifiées
- Des serveurs IIS (Pool d'applications), SQL Server, ADFS, etc.

II. Prérequis - générer une clé KDS racine

Pour être en mesure de créer des comptes gMSA sur notre infrastructure Active Directory, le service Key Distribution Service doit être en cours d'exécution et une clé racine doit être générée. Pour créer une clé à partir du contrôleur de domaine, nous allons utiliser PowerShell et le cmdlet Add-KdsRootKey.

Il est possible de différer l'activation de la clé générée grâce à l'utilisation du paramètre -EffectiveTime suivi d'une date. Si l'on utilise le paramètre -EffectiveImmediately la clé sera utilisable 10 heures après sa création (comportement par défaut) afin de s'assurer qu'elle soit répliquée entre les différents DC.

Voici la commande à exécuter :

Add-KdsRootKey -EffectiveImmediately

Dans le cadre d'un lab, si vous souhaitez pouvoir utiliser la clé KDS dès maintenant sans devoir attendre 10 heures, il est possible de tricher en utilisant cette commande :

Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))

La clé créée est identifiable avec un Guid.

📌 Add-KdsRootKey

La clé peut-être affichée simplement en exécutant la commande ci-dessous :

Get-KdsRootKey

Ce qui retourne un résultat sous cette forme :

AttributeOfWrongFormat :
KeyValue : {174, 194, 208, 151...}
EffectiveTime : 16/04/2020 18:43:58
CreationTime : 16/04/2020 18:43:58
IsFormatValid : True
DomainController : CN=SRV-ADDS-01,OU=Domain Controllers,DC=IT-CONNECT,DC=LOCAL
ServerConfiguration : Microsoft.KeyDistributionService.Cmdlets.KdsServerConfiguration
KeyId : 907a7443-1e9e-4026-b06b-03ae9adf9ce6
VersionNumber : 1

Si vous souhaitez vérifier la validité d'une clé racine, le cmdlet Test-KdsRootKey est utilisable. Il suffit de préciser le Guid de la clé à vérifier. Par exemple :

Test-KdsRootKey -KeyId 907a7443-1e9e-4026-b06b-03ae9adf9ce6

Si la clé est valide, la valeur true sera retournée dans la console.

Les clés Kds sont visibles dans la console "Sites et services Active Directory", en activant l'option "Afficher le nœud des services" dans le menu "Affichage".

Ensuite, parcourez de cette façon : Services > Group Key Distribution Service > Master Root Keys

Maintenant que ce prérequis est réalisé, nous pouvons passer à la suite.

III. Créer un gMSA

Pour créer un gMSA sur notre infrastructure Active Directory, nous allons utiliser le cmdlet New-ADServiceAccount et différents paramètres. Voici la commande à exécuter pour créer et activer un gMSA nommé "gMSA-01" avec un mot de passe qui se renouvelle tous les 30 jours. Le compte d'ordinateur "SRV-MGMT-01$" sera autorisé à utiliser ce gMSA.

New-ADServiceAccount -Name "gMSA-01" `
                     -Description "gMSA pour IIS - www.it-connect.fr" `
                     -DNSHostName "gmsa-01.it-connect.local" `
                     -ManagedPasswordIntervalInDays 30 `
                     -PrincipalsAllowedToRetrieveManagedPassword "SRV-MGMT-01$" `
                     -Enabled $True

Quelques explications supplémentaires sur les paramètres :

• ManagedPasswordIntervalInDays : sert à indiquer que le mot de passe doit être réinitialisé tous les X jours. Cette action est automatique et ne nécessite aucune action de maintenance. Cet attribut est à définir lors de la création du gMSA, ensuite il est en lecture seule (read only).
• PrincipalsAllowedToRetrieveManagedPassword : sert à indiquer l'objet qui pourra utiliser ce gMSA et va écrire l'attribut msDS-GroupMSAMembership au niveau de l'objet gMSA. Bien entendu, il est possible d'autoriser d'autres objets par la suite puisqu'un gMSA est utilisable par plusieurs hôtes.
• DNSHostName : nom DNS de cet objet gMSA

📌 New-ADServiceAccount

Lorsque le gMSA est créé, nous pouvons le retrouver dans l'annuaire Active Directory au sein du container "Managed Service Account".

L'objet gMSA étant créé, il faut que l'on ajoute ce compte de service à notre objet ordinateur SRV-MGMT-01 pour l'associer. Pour cette action, le cmdlet à utiliser est Add-ADComputerServiceAccount, avec deux paramètres : -Identity pour le nom du serveur et -ServiceAccount pour le nom ou des services à lier.

Ce qui donne :

Add-ADComputerServiceAccount -Identity SRV-MGMT-01 -ServiceAccount gMSA-01

Si l'on regarde notre objet ordinateur dans l'AD, à savoir l'objet "SRV-MGMT-01", on peut voir qu'il y a eu une modification de l'attribut msDS-HostServiceAccount. Cet attribut contient désormais une valeur correspondante à notre gMSA "gMSA-01".

La création du gMSA est terminée, passons à la suite.

IV. Ajouter le gMSA sur le serveur

Pour être utilisé sur un serveur, le gMSA doit être installé sur ce serveur à l'aide d'un cmdlet qui est intégré au module PowerShell "ActiveDirectory". Si vous intervenez sur un serveur qui n'est pas contrôleur de domaine, vous devez installer ce module. Cela s'effectue tout simplement avec la commande suivante :

Add-WindowsFeature RSAT-AD-PowerShell

L'installation prendra seulement quelques secondes et ne nécessite pas de redémarrer le serveur.

Dès lors que le module PowerShell cité précédemment est installé, le compte gMSA peut être installé sur le serveur. Il suffit d'appeler le cmdlelt Install-ADServiceAccount et de préciser le nom du gMSA à installer, comme ceci :

Install-ADServiceAccount gMSA-01

Une fois installé, vous pouvez tester que c'est OK grâce à la commande suivante :

Test-AdServiceAccount -Identity gMSA-01

Cette commande doit retourner "true" dans la console si tout est opérationnel.

Note: pour utiliser un compte gMSA sur un serveur, ce dernier doit être membre du domaine.

Tout est prêt, j'entends par là que le gMSA est correctement associé à notre serveur et qu'il est intégré sur le serveur.

V. Utiliser le gMSA

Comme je vous le disais, pour utiliser un gMSA sur un serveur, celui-ci doit être membre du domaine Active Directory, mais aussi et c'est important, il doit exécuter au minimum Windows Server 2012.

La dernière étape consiste à l'associer à votre tâche planifiée, votre service, etc... Par exemple, on peut l'utiliser sur un pool d'application IIS. Ce qui est important, c'est de bien laisser le champ mot de passe vide quand vous utilisez un gMSA. Autre chose importante, quand vous indiquez le nom du compte gMSA, pensez à ajouter un "$" à la fin et en préfixe le nom NETBIOS du domaine. Pour le compte gMSA "gMSA-01", cela donne :

IT-CONNECT\gMSA-01$

VI. Désinstaller un gMSA

Si le gMSA que vous avez installé sur votre serveur n'a plus d'utilité, le mieux c'est de le désinstaller de votre serveur. Pour cela, depuis le serveur sur lequel il est installé, exécutez la commande suivante (exemple avec le gMSA "gMSA-01") :

Uninstall-ADServiceAccount "gMSA-01"

Cette fois-ci, la commande de test doit retourner "false".

Test-AdServiceAccount -Identity gMSA-01

Ce tutoriel est terminé, à vous de jouer... Si vous recherchez des informations supplémentaires, vous pouvez utiliser la documentation Microsoft : gMSA