Création d'un custom attribute dans ActiveDirectory

La création d'un custom attribute dans ActiveDirectory est une opération nécessitant de modifier le schéma. Une réflexion est nécessaire en amont car il n'est pas possible de supprimer un custom attribute une fois que celui-ci a été écrit dans le schéma.

Si votre infrastructure comporte un serveur Exchange par exemple, alors votre AD contient déjà des attributs personnalisés. En effet, lors de l'installation, Exchange modifie le schéma pour y ajouter ses custom attributes lui permettant de stocker des informations dont il a besoin.

Dans cet exemple, je vais créer un custom attribute nommé CreatedBy permettant de stocker dans une chaîne de caractères le nom de l'utilisateur qui procède à la création d'un objet.

Il est nécessaire de faire partie du groupe Schema Admins pour pouvoir créer un custom attribute, le groupe Domain Admins n'est pas suffisant.

Se connecter à un serveur en RDP, puis ouvrir une console MMC vide, et y ajouter le snap-in Active Directory Schema (File > Add/Remove Snap-in). Si celui-ci n'apparaît pas, il faut alors l'enregistrer ; dans une invite de commande, saisir ceci :

regsvr32.exe schmmgmt.dll

Normalement, la MMC doit donc ressembler à ceci :

En faisant un clic droit sur Attributes puis Create Attribute, un message apparaît indiquant que la création d'un attribut personnalisé est irrémédiable ; on arrive ensuite sur une fenêtre avec plusieurs détails à remplir.

  • Le Common Name est le nom que l'on souhaite donner à son attribut ;
  • Le LDAP Display Name est le nom LDAP, c'est celui-ci qui apparaîtra lors de requêtes LDAP directes ou via Powershell par exemple, ou encore dans l'ADSI Edit ;
  • Le Unique X500 Object ID est un identifiant qui doit être généré en fonction du domaine, je vais venir sur ce point juste après ;

Ensuite, en fonction du type de données que l'on souhaite stocker dans cet attribut, il faut choisir une syntaxe. Celle-ci peut être un booléen, une chaîne de caractères, un entier, etc.

Le point le plus sensible lors de la création de l'attribut est la génération de l'identifiant unique X500. En effet, cet identifiant est basé sur une suite de chiffres qui est unique par domaine. Il n'est donc pas possible d'en choisir un au hasard. Microsoft propose ce script VBS permettant de récupérer la racine de l'identifiant unique, à laquelle on rajoutera par exemple un incrément. Par exemple, si l'OID retourné par le script se finit en 4941237, l'identifiant unique pourra finir par 4941237.1. De nombreux topics d'aide sont disponibles sur le technet en cas d'incompréhension sur ce point.

Une fois l'attribut créé, il faut le rattacher à une classe (plus communément type d'objet). Dérouler les classes, puis dans le cadre de l'exemple, ouvrir les propriétés de la classe user d'un clic-droit > Properties. Ensuite, dans l'onglet Attributes, il est possible d'ajouter l'attribut que nous venons de créer, et de définir si il est obligatoire ou optionnel.

Appliquer, la création du custom attribute et son rattachement aux objets de type user est terminée. On peut ensuite requêter via Powershell l'AD par exemple sur cet attribut :

Powershell : repadmin sur tous les DC du domaine

Je vais partager aujourd'hui un snippet qui va me servir de base pour implémenter un contrôle des réplications qui fonctionne aujourd'hui uniquement sur base d'un appel de dcdiag.

Ce snippet récupère donc les contrôleurs de domaine et récupère les timestamp des dernières réplications. Ensuite, pour chaque DC, il affiche en vert celles qui date de moins d'une heure et en rouge celles qui datent de plus d'une heure.

$dc = (Get-AdDomain).ReplicaDirectoryServers
$csvpath = "C:\temp\replications.csv"
$dc | Foreach { 
	if(Test-Path $csvpath) { Remove-Item $csvpath }
	Add-Content -Path $csvpath -Value (repadmin /showrepl $_ -csv)
	$csvcontent = Import-CSV $csvpath
	Write-Host -ForegroundColor Cyan `r`n$_
	$csvcontent | foreach {
        if(([datetime]$_.'Last Success Time').AddHours(1) -gt (Get-Date)) { Write-Host -ForegroundColor Green ($_.'Source DSA')($_.'Naming Context')($_.'Last Success Time') }
        else {  Write-Host -ForegroundColor Red ($_.'Source DSA')($_.'Naming Context')($_.'Last Success Time') }
    }
} 
if(Test-Path $csvpath) { Remove-Item $csvpath }

Si, au départ, je pensais avoir à manipuler le texte renvoyé par la commande pour extraire les bonnes informations, la commande repadmin avec l'argument showrepl accepte le paramètre -csv pour réaliser un export qui est ensuite facilement interprétable par Powershell.

Vous pouvez trouver toute la documentation nécessaire à l'utilisation de la commande repadmin sur le site de Microsoft.

Augmentation du MaxPageSize avec ntdsutil

Par défaut et principalement pour des raisons de sécurité, ActiveDirectory ne renvoie au maximum que 1000 entrées aux requêtes LDAP qui lui sont adressées et fonctionne grâce à un système de pages, permettant d'accéder aux autres éléments, toujours par tranche de 1000 maximum. Si un bon nombre d'applications ou de librairies sont capables de gérer ce système de pages, ce n'est pas le cas de toutes. Bien que cela ne soit pas recommandé par Microsoft, il est possible d'augmenter la variable MaxPageSize grâce à ntdsutil si besoin est.

L'exécutable ntdsutil peut être appelé depuis n'importe quel contrôleur de domaine, peu importe ses rôles ; il s'agit d'un paramètre de niveau domaine.

Une fois connecté à un DC, ouvrir un cmd avec élévation et exécuter ntdsutil :

ntdsutil

Ensuite, se connecter au serveur, dans cet exemple, le DC s'appelle dc01 ; à chaque instruction valider par entrée - le prompt va changer de ldap policy à server connections lors de la deuxième commande :

ldap policies
connections
connect to server dc01

Une fois que la connexion est faite, saisir "q" et valider pour revenir au prompt ldap policy. D'abord, afficher les paramètres courants :

show values

Ici, le MaxPageSize est bien réglé sur 1000. Pour le passer à 5000, par exemple :

set maxpagesize to 5000

Les éventuelles modifications apportées aux paramètres ne seront pas prises en compte tant que l'enregistrement de celles-ci ne sera pas effectué :

commit changes

En rappelant l'instruction show values, on vérifie que la modification a bien été écrite :

Désormais, ActiveDirectory retournera tout au plus 5000 éléments par requête LDAP.

Powershell : création d'un batch de users AD sur import CSV

Ce script permet de créer en masse des utilisateurs dans un AD sur base d'un fichier CSV.

$userlist = Import-CSV usertocreate.csv
foreach($user in $userlist){
	New-AdUser -Name $user.Name -GivenName $user.FirstName -Surname $user.LastName -Path $user.OrgUnit -StreetAddress $user.Address -City $user.City -PostalCode $user.PostalCode -Country FR -HomeDrive "U:" -HomeDirectory $user.HomeDir -AccountPassword (ConvertTo-SecureString -AsPlainText $user.MatriculeID -Force) -UserPrincipalName $user.UPN
    Enable-ADAccount $user.Name
	Set-ADUser -Identity $user.Name -ChangePasswordAtLogon $true
	$GrpList = $user.Groups
	while($GrpList.IndexOf(",") -ne -1) {
		$commaindex = $GrpList.IndexOf(",")
		Add-AdGroupMember -Identity $GrpList.SubString(0,$commaindex) -Members $user.Name
		$GrpList = $GrpList.SubString($commaindex+1,$GrpList.Length-($commaindex+1))
	}
	Add-AdGroupMember -Identity $GrpList -Members $user.Name
} 

Le script (une version commentée est disponible en fin d'article, comme toujours) prend quelques propriétés pour la création du compte en sus des usuelles. Il pourra donc être nécessaire d'en retirer, en rajouter ou de modifier les noms attribués dans le script pour s'adapter au fichier d'entrée qui pourra être généré à partir d'une application RH par exemple.

Le script ajoute également l'utilisateur fraîchement créé aux groupes AD spécifiés, en découpant la liste située entre guillemets (afin qu'elle soit interprétée comme une chaîne de caractères unique) en fractions séparées par une virgule.

Le mot de passe est basé sur un numéro matricule fictif que seul l'utilisateur final connaît ; cependant pour des raisons de sécurité, ce mot de passe sera à modifier à la première connexion.