PI Services

Password Hash Sync ou PHS est une des methodes d'authentification préconisée par Microsoft pour l'authentfication des utilisateurs dans un environnement hybride sur des services Azure.

Un environnement hybride dans le contexte de l'Active Directory est caractérisé par la co-éxistence d'une infrastructure Active Directory (AD) OnPremises et d'un tenant Azure AD. Ces deux milieux sont fortement liés à travers des solutions telles qu'Azure AD Connect ou ADFS.

PHS permet à un utilisateur dont la source de l'identité se trouve dans l'AD OnPremises de se connecter à un service Azure sans devoir requêter les contrôleurs de domaines (DC) OnPremises.

Par défaut, un utilisateur qui utilise l'authentification PHS a la synchronisation de l'expiration son mot de passe OnPremises décorrélé de son identité Azure AD. De plus dans ce cas de figure, le mot de passe de l'identité Azure AD n'expire jamais.

Concrétement, cela veut dire que lorsque le mot de passe OnPremises d'un utilisateur expire, si celui-ci ne se connecte qu'à des services Azure, il ne lui sera jamais demandé de changer de mot de passe.

Est-ce alarmant ?

Microsoft considère que l'expiration des mots de passe rend les futurs mots de passe prévisibles, car les utilisateurs ont tendance à ne changer que quelques caractères d'un mot de passe à l'autre.

Par exemple dans le portail admin.microsoft.com > Settings Org settings > Security & privacy > Password expiration policy

Le lien mène vers l'article Microsoft suivant : Password policy recommendations for Microsoft 365 passwords

Password expiration requirements do more harm than good, because these requirements make users select predictable passwords, composed of sequential words and numbers that are closely related to each other. In these cases, the next password can be predicted based on the previous password. Password expiration requirements offer no containment benefits because cybercriminals almost always use credentials as soon as they compromise them.

Il est néanmoins souhaitable que la non-expiration des mots de passe soit un choix conscient.

Synchroniser l'expiration des mots de passe OnPremises vers Azure AD

Etape 1 : activer la synchronisation des mots de passe OnPremises vers Azure AD

Les commandes suivantes peuvent être saisies avec compte Global Administrator du tenant. Le module MSOnline doit être installé sur l'ordinateur exécutant les commandes.

#Commande qui permet d'initier une connexion avec le tenant Office 365
Connect-MsolService

#Commande qui permet de récupérer le statut de synchronisation actuel de l'expiration des mots de passe
Get-MsolDirSyncFeatures -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers

#Si la valeur de l'attribut Enable est déjà en True, passer directement à l'étape 2

#Commande qui permet de synchroniser l'expiration des mots de passe de l'Active Directory OnPremises vers Azure AD
#Taper Yes quand la commande affichera Enable
Set-MsolDirSyncFeatures -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers

#La commande de Get précédente peut être entrée à nouveau pour vérifier que la commande de Set à fonctionnée
Get-MsolDirSyncFeatures -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers

Etape 2 : vérifier le statut des stratégies de mots de passe des utilisateurs Azure AD

La stratégie de mot passe d'un utilisateur Azure AD garde la valeur à DisablePasswordExpiration jusqu'au prochain changement de mot de passe.
Etant donné que si l'utilisateur ne se connecte jamais à un service OnPremises, il ne lui sera jamais demandé de changer de mot de passe, il faut pouvoir identifier les utilisateurs Azure AD dont le mot de passe n'expire pas et les forcer à changer leur mot de passe.
La configuration de l'étape 1 s'appliquera néanmoins à tous les utilisateurs créés après l'activation du paramètre.

La commande suivante permet de récupérer la stratégie des mots de passe de l'ensemble des utilisateurs Azure AD

Get-AzureADUser -All $true | Select-Object ObjectID, UserPrincipalName, AccountEnabled, PasswordPolicies

Etape 3 : forcer l'expiration des mots de passe des utilisateurs Azure AD

Une fois la liste des utilisateurs Azure AD, dont le mot de passe doit expirer, établie, la commande suivante peut être tapée pour chaque utilisateur.

#Remplacer [User] par la valeur de l'UPN ou de l'ObjectId de l'utilisateur dont le mot de passe doit expirer
Set-AzureADUser -ObjectId [User] -PasswordPolicies None

Lors de la prochaine connexion de l'utilisateur vers un service Azure ou Office 365, il lui sera demandé de changer son mot de passe.

#Informations récupérées : suffixe des userPrincipalName (UPN) et fréquence d'utilisations dans les domaines choisis

#Prérequis : l'utilisateur qui lance le script doit pouvoir lire l'Active Directory en PowerShell

#List de paramètres qui permettent de récupérer soit la fréquence des UPN de l'ensemble des domaines Active Directory (AD) de la forêt ou de spécifier les domaines dans lesquels chercher
#Exemple 1 d'utilisation du script : .\Get-UPNSuffixFrequency.ps1 -SearchInAllDomainsOfTheForest
#Exemple 2 d'utilisation du script : .\Get-UPNSuffixFrequency.ps1 -SpecifyDomains customer.intern, technical.intern
Param
( 	
	#Paramètre de type switch qui s'il est utilisé va récupérer la fréquence des suffixes UPN de l'ensemble des domaines AD de la forêt
	[Parameter(Mandatory=$false)]
    [switch]$SearchInAllDomainsOfTheForest,

	#Paramètre de type tableau qui s'il est utilisé va réucupérer la fréquence des suffixes UPN dans les domaines AD mentionnés
    [Parameter(Mandatory=$false)]
    [array]$SpecifyDomains
)

#Importe le module Active Directory qui contient des commandes utilisées dans le script
Import-Module ActiveDirectory

#Si le paramètre de type switch $SearchInAllDomainsOfTheForest est utilisé, récupère les noms de tous les domaines dans la forêt AD
if ($SearchInAllDomainsOfTheForest)
{
	$Domains = Get-ADForest | Select-Object Domains
	$Domains = $Domains.Domains
}

#Si le paramètre de type tableau $SpecifyDomains est utilisé, ajoute les noms des domaines spécifiés comme base de recherche pour la fréquence des suffixes UPN
if ($SpecifyDomains)
{
	$Domains = $SpecifyDomains
}

#Variable globale qui va contenir l'ensemble des UPN des utilisateurs des domaines requêtés
$AllUsersObjects = @()

#Parcours chaque domaine requêté et récupère l'ensemble des UPN des utilisateurs
foreach ($Domain in $Domains)
{
	#Récupére l'ensemble des utilisateurs du domaine actuellement requêté
    $UsersObjectsFromDomain = Get-ADUser -Filter * -Server $Domain -Properties userPrincipalName | Select-Object userPrincipalName

	#Ajoute les utilisateurs du domaine actuellement requêté a la variable globale qui va contenir l'ensemble des UPN des utilisateurs des domaines requêtés
    $AllUsersObjects += $UsersObjectsFromDomain
}

#Commande qui va récupérer l'ensemble des suffixes UPN utilisables dans l'AD
$ADForestObject = Get-ADForest | Select-Object UPNSuffixes

#Créer un tableau qui contiendra l'ensemble des suffixes UPN et leur fréquence
$Array = @()

#Parcours l'ensemble des suffixes UPN dans l'AD et les compare à la liste de l'ensemble des utilisateurs des domaines requêtés
foreach ($UPNSuffixe in $ADForestObject.UPNSuffixes)
{
	#Initialise la fréquence du suffixe UPN actuellement requêté à 0
	$UPNSuffixeOccurence = 0

	#Créer un objet PowerShell qui contiendra le suffixe UPN actuellement requêté et sa fréquence d'utilisation dans les domaines requêtés
    $Line = New-Object PSObject

	#Ajoute à l'object PowerShell précédemment crée, le suffixe UPN actuellement requêté
	$Line | Add-Member -MemberType NoteProperty -Name "UPNSuffixe" -Value $UPNSuffixe

	#Boucle qui va comparer le suffixe UPN actuellement requêté avec chaque utilisateur des domaines requêtés et comptabilise la fréquence d'utilisation
	foreach ($UserObject in $AllUsersObjects)
	{
		#Vérifie que l'UPN de l'utilisateur actuellement requêté n'est pas vide
		if ($UserObject.userPrincipalName)
		{
			#Sépare le préfixe du suffixe UPN de l'utilisateur actuellement requêté
			$UserUPNSuffixe = (($UserObject.userPrincipalName).Split('@'))[1]

			#Compare la valeur du suffixe UPN de l'utilisateur actuellement requêté avec le suffixe UPN actuellement requêté
			if ($UserUPNSuffixe -eq $UPNSuffixe)
			{
				#Si la valeur du suffixe UPN de l'utilisateur actuellement requêté et le suffixe UPN actuellement requêté sont égaux, incrémente de 1 le nombre d'utilisation du suffixe UPN
				$UPNSuffixeOccurence += 1
			}
		}
	}

	#Une fois que l'ensemble des suffixes UPN des utilisateurs des domaines requêtés ont été comparés au suffixe UPN actuellement requêté, ajoute la fréquence du suffixe UPN à l'objet PowerShell précédemment crée
	$Line | Add-Member -MemberType NoteProperty -Name "UPNSuffixeOccurence" -Value $UPNSuffixeOccurence

	#Ajoute à la variable globale qui contient l'ensemble des suffixes UPN et leur fréquence, l'objet PowerShell précédemment crée lors de l'itération courante
    $Array += $Line

	#Supprime les valeurs des variables propres au suffixe UPN actuellement requêté
    Clear-Variable UPNSuffixe, Line
}

#Affiche sous forme de liste tableau l'ensemble des suffixes UPN et leurs fréquences d'utilisation
$Array

<# Exemple d'affichage
UPNSuffixe             UPNSuffixeOccurence
----------             -------------------
customer.intern                         47
technical.intern                        42
#>

#Informations récupérées : Nom du contrôleur de domaine (DC), domaine Active Directory (AD) d'appartenance, OS, présence ou non des KB recherchées, date d'installation des KB

#Prérequis : l'utilisateur qui lance le script doit pouvoir requêter en remote PowerShell Administrator l'ensemble des DC de la forêt

#Paramètre obligatoire qui doit contenir la liste des KB à récupérer
#Par exemple pour appeler le script avec une liste de KB : .\Get-DomainControllerKB.ps1 -DCHotFixIDs KB5022511, KB4589208
Param
( 	
	[Parameter(Mandatory=$true)]
    [array]$DCHotFixIDs
)

#Importe le module Active Directory qui contient des commandes utilisées dans le script
Import-Module ActiveDirectory

#Permet de récupérer les noms de tous les domaines dans la forêt AD
$Domains = Get-ADForest | Select-Object Domains
$Domains = $Domains.Domains

#Créer un tableau qui contiendra l'ensemble des statuts des KB des DC de chaque domaine de la forêt
$Array = @()

#Parcours chaque domaine AD de la forêt et récupére la liste des DC
foreach ($Domain in $Domains)
{
	#Récupére l'ensemble des DC du domaine AD actuellement requêté
	$DCs = Get-ADDomainController -Server $Domain -Filter * | Select-Object Name, HostName, OperatingSystem

	#Parcours chaque DC du domaine AD actuellement requêté
    foreach ($DC in $DCs)
    {
		#Vérifie pour chaque KB si elle est présente sur le DC actuellement requêté
		foreach ($DCHotFixID in $DCHotFixIDs)
		{
			#Créer un objet PowerShell qui contiendra les informations sur la KB actuellement requêtée du DC actuellement requêté
			$Line = New-Object PSObject

			#Ajoute à l'objet PowerShell précédemment crée, le nom du DC actuellement requêté
			$Line | Add-Member -MemberType NoteProperty -Name "DomainController" -Value $DC.HostName

			#Ajoute à l'objet PowerShell précédemment crée, le domaine AD d'appartenence du DC actuellement requêté
			$Line | Add-Member -MemberType NoteProperty -Name "Domain" -Value $Domain

			#Ajoute à l'objet PowerShell précédemment crée, le système d'exploitation du DC actuellement requêté
			$Line | Add-Member -MemberType NoteProperty -Name "OperatingSystem" -Value $DC.OperatingSystem

			#Ajoute à l'objet PowerShell précédemment crée, le numéro de la KB actuellement requêté du DC actuellement requêté
			$Line | Add-Member -MemberType NoteProperty -Name "HotFixIDSearched" -Value $DCHotFixID

			#Commande qui va vérifier si la KB actuellement requêtée est présente sur le DC actuellement requêté
			$HotFixObject = Get-HotFix -ComputerName $DC.HostName -ID $DCHotFixID -ErrorAction SilentlyContinue | Select-Object Description, HotFixID, InstalledBy, InstalledOn

			#Si la KB actuellement requêtée est PRESENTE sur le DC actuellement requêté, ajoute les informations relatives à son installation dans l'objet PowerShell précédemment créé
			if ($HotFixObject)
			{
				#Ajoute à l'objet PowerShell précédemment crée, le statut présent ou absent de la KB actuellement requêtée du DC actuellement requêté
				$Line | Add-Member -MemberType NoteProperty -Name "KBIsInstalled" -Value "Success"

				#Ajoute à l'objet PowerShell précédemment crée, le nom de l'utilisateur qui a réalisé l'installation de la KB actuellement requêtée du DC actuellement requêté
				$Line | Add-Member -MemberType NoteProperty -Name "HotFixInstalledBy" -Value $HotFixObject.InstalledBy

				#Ajoute à l'objet PowerShell précédemment crée, la date d'installation, arrondi au jour prêt, de la KB actuellement requêtée du DC actuellement requêté
				$Line | Add-Member -MemberType NoteProperty -Name "HotFixInstalledOn" -Value $HotFixObject.InstalledOn

				#Ajoute à l'objet PowerShell précédemment crée, le type de KB actuellement requêté du DC actuellement requêté
				$Line | Add-Member -MemberType NoteProperty -Name "HotFixDescription" -Value $HotFixObject.Description

				#Supprime les valeurs des variables propres à la KB actuellement requêté du DC actuellement requêté
				Clear-Variable HotFixObject
			}

			#Si la KB actuellement requêtée est ABSENTE sur le DC actuellement requêté, ajoute des valeurs Fail ou NULL pour ses informations dans l'objet PowerShell précédemment créé
			else
			{
				$Line | Add-Member -MemberType NoteProperty -Name "KBIsInstalled" -Value "Fail"
				$Line | Add-Member -MemberType NoteProperty -Name "HotFixInstalledBy" -Value "NULL"
				$Line | Add-Member -MemberType NoteProperty -Name "HotFixInstalledOn" -Value "NULL"
				$Line | Add-Member -MemberType NoteProperty -Name "HotFixDescription" -Value "NULL"
			}

			#Ajoute à la variable globale qui contient l'ensemble des statuts des KB des DC de chaque domaine, l'objet PowerShell précédemment crée lors de l'itération courante
			$Array += $Line

			#Supprime les valeurs des variables propres à la KB actuellement requêtée du DC actuellement requêté
			Clear-Variable DCHotFixID, Line
		}

		#Supprime les valeurs des variables propres au DC actuellement requêté
        Clear-Variable DC
    }

	#Supprime les valeurs des variables propres au domaine actuellement requêté
    Clear-Variable Domain, DCs
}

#Affiche sous forme de liste l'ensemble des KB requêtées des DC de chaque domaine avec leurs status
$Array

<#Exemple d'affichage
DomainController  : DC01.customer.intern
Domain            : customer.intern
OperatingSystem   : Windows Server 2022 Standard
HotFixIDSearched  : KB5022511
KBIsInstalled     : Fail
HotFixInstalledBy : NULL
HotFixInstalledOn : NULL
HotFixDescription : NULL

DomainController  : DC01.customer.intern
Domain            : staff.nsi.dir
OperatingSystem   : Windows Server 2022 Standard
HotFixIDSearched  : KB4589208
KBIsInstalled     : Fail
HotFixInstalledBy : NULL
HotFixInstalledOn : NULL
HotFixDescription : NULL

DomainController  : DC02.technical.intern
Domain            : technical.intern
OperatingSystem   : Windows Server 2019 Standard
HotFixIDSearched  : KB5022511
KBIsInstalled     : Success
HotFixInstalledBy : NT AUTHORITY\SYSTEM
HotFixInstalledOn : 15/02/2023 00:00:00
HotFixDescription : Update

DomainController  : DC02.technical.intern
Domain            : technical.intern
OperatingSystem   : Windows Server 2019 Standard
HotFixIDSearched  : KB4589208
KBIsInstalled     : Success
HotFixInstalledBy : NT AUTHORITY\SYSTEM
HotFixInstalledOn : 28/01/2021 00:00:00
HotFixDescription : Update
#>

#Informations récupérées : Nom du contrôleur de domaine, domaine AD, adresse IP, OS, CPU, taille du disque C, taille restante du disque C, RAM
#Evolution du script : certains attributs non utilisés sont récupérés pour pouvoir éventuellement augmenter le nombre d'informations récupéré 

#Prérequis 1 : l'utilisateur qui lance ce script doit pouvoir requêter les bases WMI de tout les contrôleurs de domaine (DC) de la forêt
#Prérequis 2 : le script suppose qu'un seul adapteur réseau de chaque DC posséde une ou plusieurs adresses IP
#Prérequis 3 : le script suppose que le système d'exploitation de chaque DC est installé sur C:

#Importe le module Active Directory qui contient des commandes utilisées dans le script
Import-Module ActiveDirectory

#Permet de récupérer le nom des domaines de la forêt de façon dynamique
$Domains = Get-ADForest | Select-Object Domains
$Domains = $Domains.Domains

#Créer un tableau qui contiendra l'ensemble des DC de tout les domaines de la forêt
$DCToGetConfiguration = @()

#Parcours un par un chaque domaine de la forêt
foreach ($Domain in $Domains)
{
	#Pour chaque domaine de la forêt, récupére l'ensemble des DC du domaine
	$DomainControllersFromCurrentDomain = (Get-ADDomainController -Server $Domain -Filter * | Select-Object HostName, Domain, IPv4Address).HostName

	#Pour chaque domaine de la forêt, ajoute l'ensemble des DC du domaine à l'ensemble des DC de la forêt
	$DCToGetConfiguration += $DomainControllersFromCurrentDomain
}

#Créer un tableau qui contiendra chaque DC de la forêt avec sa configuration
$Array = @()

#Parcours un par un chaque DC de chaque domaine de la forêt, récupéré précédemment
foreach ($ServerToGetConfiguration in $DCToGetConfiguration)
{
	#Créer un objet PowerShell qui contiendra la configuration du DC actuellement requêté
    $Line = New-Object PSObject

	#Ajoute à l'objet PowerShell précédemment crée, le nom du DC actuellement requêté
    $Line | Add-Member -MemberType NoteProperty -Name "HostName" -Value $ServerToGetConfiguration

	#Récupére le domaine AD d'appartenance du DC actuellement requêté
	$WMIComputerSystemObject = Get-WmiObject -Class Win32_ComputerSystem -ComputerName $ServerToGetConfiguration | Select-Object Name, Domain

	#Ajoute à l'objet PowerShell précédemment crée, le domaine AD d'appartenance du DC actuellement requêté
	$Line | Add-Member -MemberType NoteProperty -Name "Domain" -Value $WMIComputerSystemObject.Domain

	#Récupére l'adresse IP du DC actuellement requêté
	$WMINetworkAdapterConfigurationObjects = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -ComputerName $ServerToGetConfiguration | Select-Object PSComputerName, IPAddress, IPSubnet, DefaultIPGateway, DNSServerSearchOrder

	#La commande Get-WmiObject -Class Win32_NetworkAdapterConfiguration récupére les adaptateurs réseaux, certains d'entre eux ne comportent pas de carte réseau
	#La boucle suivante ne permet de récupérer que la carte réseau qui contient une adresse IP
	#Cette portion du script ne marchera pas si plusieurs cartes réseaux contiennent chacune une IP
	foreach ($NetworkAdapterConfigurationObject in $WMINetworkAdapterConfigurationObjects)
	{
		if ($NetworkAdapterConfigurationObject.IPAddress)
		{
			$Line | Add-Member -MemberType NoteProperty -Name "IPAddress" -Value ([string]($NetworkAdapterConfigurationObject.IPAddress))
		}
	}

	#Récupére le système d'exploitation du DC actuellement requêté
	$WMIOperatingSystemObject = Get-WmiObject -Class Win32_OperatingSystem -ComputerName $ServerToGetConfiguration | Select-Object PSComputerName, Caption, BuildNumber

	#Ajoute à l'objet PowerShell précédemment crée, système d'exploitation du DC actuellement requêté
	$Line | Add-Member -MemberType NoteProperty -Name "OperatingSystem" -Value $WMIOperatingSystemObject.Caption
	
	#Récupére les CPU du DC actuellement requêté
    $WMIProcessorObjects = Get-WmiObject -Class Win32_Processor -ComputerName $ServerToGetConfiguration | Select-Object PSComputerName, Name, MaxClockSpeed, Manufacturer, NumberOfCores, NumberOfEnabledCore, NumberOfLogicalProcessors

	#Boucle qui va additioner l'ensemble des CPU du DC requêté pour obtenir le nombre total de CPU
	$CPUNumbers = 0
	foreach ($WMIProcessorObject in  $WMIProcessorObjects)
	{
		$CPUNumbers += 1
	}

	#Ajoute à l'objet PowerShell précédemment crée, le nombre total de CPU du DC actuellement requêté
	$Line | Add-Member -MemberType NoteProperty -Name "CPU_total" -Value $CPUNumbers

	#Récupére l'espace disque du DC actuellement requêté
	$WMILogicalDiskObjects = Get-WMIObject -Class Win32_LogicalDisk -ComputerName $ServerToGetConfiguration | Select-Object PSComputerName, DeviceID, FileSystem, MaximumComponentLength, Size, FreeSpace

	#Boucle qui va parcourir chaque disque du DC requêté et ajoute à l'objet PowerShell précédemment crée, l'espace disque total et restant de C: et l'affiche en GB
	foreach ($WMILogicalDiskObject in $WMILogicalDiskObjects)
	{
		if ($WMILogicalDiskObject.DeviceID -eq "C:")
		{
			$Line | Add-Member -MemberType NoteProperty -Name "Disk_size(GB)" -Value ([math]::truncate(($WMILogicalDiskObject.Size)/1GB))
			$Line | Add-Member -MemberType NoteProperty -Name "Disk_free(GB)" -Value ([math]::truncate(($WMILogicalDiskObject.FreeSpace)/1GB))
		}
	}

	#Récupére les RAM du DC actuellement requêté
	$WMIPhysicalMemoryObjects = Get-WmiObject -Class Win32_PhysicalMemory -ComputerName $ServerToGetConfiguration | Select-Object PSComputerName, BankLabel, Capacity, Manufacturer

	#Boucle qui va additionner l'ensemble des RAM du DC requêté pour obtenir le nombre total de RAM
	$RAMnumbers = 0 
	foreach ($WMIPhysicalMemoryObject in $WMIPhysicalMemoryObjects)
	{
		$RAMnumbers += $WMIPhysicalMemoryObject.Capacity
	}
	
	#Ajoute à l'objet PowerShell précédemment crée, le nombre total de RAM du DC actuellement requêté
	$Line | Add-Member -MemberType NoteProperty -Name "Memory(MB)" -Value ([math]::truncate(($RAMnumbers)/1MB))

	#Ajoute à la variable globale qui contient l'ensemble des configuration des DC, l'objet PowerShell précédemment crée de l'itération courante
	$Array += $Line

	#Supprime les valeurs des variables propres au DC actuellement requêté
	Clear-Variable Line, WMIComputerSystemObject, WMINetworkAdapterConfigurationObjects, WMIOperatingSystemObject, CPUNumbers, WMILogicalDiskObjects, WMIPhysicalMemoryObject
}

#Affiche sous forme de liste l'ensemble des DC avec leurs configurations
$Array

<#Exemple d'affichage
HostName        : DC01.customer.intern
Domain          : customer.intern
IPAddress       : 192.168.1.50
OperatingSystem : Microsoft Windows Server 2019 Standard
CPU_total       : 4
Disk_size(GB)   : 50
Disk_free(GB)   : 30
Memory(MB)      : 16384

HostName        : DC02.technical.intern
Domain          : technical.intern
IPAddress       : 192.168.1.51
OperatingSystem : Microsoft Windows Server 2022 Standard
CPU_total       : 4
Disk_size(GB)   : 100
Disk_free(GB)   : 60
Memory(MB)      : 16384
#>

Une présentation du passwordless a été faite dans ce post : Azure AD - Présentation du passwordless

Microsoft Authenticator est un logiciel pratique qui permet à la fois de faire du l'authentification multifacteur, mais également de faire du passwordless. Cet article explique comment préparer son environnement pour pouvoir se connecter en passwordless avec Microsoft Authenticator.

Les configurations ci-après sont réalisées avec un compte Global Administrator (GA).

Désactiver le MFA historique

La méthode moderne de faire du MFA est via l'accès conditionnel Azure, il est nécessaire de désactiver le MFA historique pour éviter d'avoir des conflits.

Se connecter successivement à portal.azure.com > Cliquer sur l'icône des 3 traits horizontaux > Azure Active Directory > Users >  Per-user MFA

Pour chaque utilisateur qui doit pouvoir faire du passwordless, il faut désactiver le MFA

Combiner les informations de sécurité SSPR et MFA

Les étapes sont décrites dans l'article : Azure - Combiner les informations de sécurité SSPR et MFA

(Optionnel) Activer le MFA via accès conditionnel Azure

Active le MFA n'est pas obligatoire pour l'authentification via Microsoft Authenticator mais, est fortement recommandé.

Pour créer un nouvel accès conditionnel Azure ou conditional access (CA), se connecter successivement à portal.azure.com > Cliquer sur l'icône des 3 traits horizontaux > Azure Active Directory > Security > Policies > New policy

Dans Users choisir les utilisateurs qui doivent faire du passwordless, attention de toujours garder quelques comptes de bris de glace qui ne sont pas concernés par la politique

Dans Cloud apps or actions, cocher All cloud apps

Dans Conditions, uniquement, s'il faut exclure certains utilisateurs en se basant sur des critères prédéfinis

Dans Enable policy choisir On

Dans Grant, cocher Grant access et Require multifactor authenticator puis cliquer sur Select

Enfin cliquer sur Create

Dorénavant, les utilisateurs configurés dans la CA devront s'authentifier en MFA. Lors de la première connexion, il leur sera demandé d'enregistrer des facteurs d'authentifications, Microsoft Authenticator étant plus que recommandé sans quoi l'authentification passwordless ne pourra pas se faire.

Identifier les domaines fédérés et planifier la migration de l'authentification vers Azure

Dans le cas où l'environnement disposerait d'une ferme ADFS, les domaines fédérés ne peuvent pas être utilisés pour faire du passwordless.

En fonction de comment est gérer l'authentification des utilisateurs OnPremises versus Azure, les actions à réaliser peuvent être plus ou moins chronophages.

Se référer à la documentation Microsoft : Migrate from federation to cloud authentication

Il est donc nécessaire de réaliser cette transition de l'authentification vers le cloud Azure pour pouvoir faire du passwordless.

Configurer l'authentification passwordless via Microsoft Authenticator

Se connecter successivement à portal.azure.com > Cliquer sur l'icône des 3 traits horizontaux > Azure Active Directory > Security > Authentication Methods > Microsoft Authenticator

Dans Enable and Target, activer Enable

Dans Include, choisir Select groups puis choisir le groupe qui contient les utilisateurs qu'il faut déployer passwordless, ici le groupe s'appelle Passwordless-test
Dans Authentication mode choisir Any, any inclut la possibilité de faire du passwordless

Cliquer sur Save

Cela conclut la configuration de l'authentification passwordless via Microsoft Authenticator

Configuration par l'utilisateur final la possibilité de faire de l'authentification passwordless avec Microsoft Authenticator

Chaque utilisateur souhaitant s'authentifier en passwordless doit activer l'option dans son application Microsoft Authenticator

Une fois sur le compte d'entreprise, cliquer sur Enable phone sign-in

L'importance du passwordless

Posséder une bonne stratégie de mot de passe demeure essentiel, mais ne permet pas de s'affranchir du maillon le plus à risque de la chaîne d'authentification à savoir l'utilisateur. Cet utilisateur peut être invité de façon frauduleuse à fournir ses identifiants de connexions à un pirate informatique, c'est ce que l'on appelle le phising.

Le passwordless consiste à fournir à l'utilisateur des méthodes d'authentifications qui ne se reposent pas sur l'utilisation d'un mot de passe.

Augmenter la sécurité est souvent lié à plus de contraintes, c'est le cas par exemple pour le MFA ou multi-factor authentification qui nécessite une étape supplémentaire lors de la connexion.

Le passwordless, en outre de fournir un meilleur niveau de sécurité que le MFA traditionnel permet de réduire directement ou indirectement ces impératifs lourds de connexion lourd intrinséque au MFA

Un autre avantage du passwordless Azure est sa liberté d'implémentation, il est possible d'autoriser les utilisateurs à utiliser en conjonction leurs identifiants standards et le passwordless. Cela permet en termes de déploiement d'avoir une meilleure adhésion des utilisateurs au passwordless et d'identifier en amont les éventuels problèmes avant de restreindre l'utilisation des mots de passe.

Les solutions pour faire du passwodless via Azure

• L'application Microsoft Authenticator, disponible sur Android et iOS, prisée pour l'authentification MFA, permet également de faire du passwordless. Concrètement, lorsqu'un utilisateur tente de se connecter à une application, son mot de passe ne lui sera pas demandé, mais une notification apparaîtra dans son application Microsoft Authenticator.

• Windows Hello for Business, une solution implémentée dans les systèmes d'exploitation Windows 10 et postérieur, propose à l'utilisateur d'utiliser un code PIN ou des informations biométriques pour se connecter. Le code PIN à l'instar du mot de passe traditionnel ne peut pas être utilisé sur un autre équipement que le PC sur lequel il a été configuré et n'est pas transmis à un autre équipement ou application.

• Une clé de sécurité FIDO2, aussi courament appelée token, est un équipement physique qui s'apparente à une clé USB, l'utilisateur lorsqu'il veut se connecter doit brancher sa clé FIDO2 à son PC et entrer le code PIN pour débloquer la clé.

Passwodless vs MFA

L'augmentation des attaques informatiques sur les dernières années à pousser les entreprises à améliorer la sécurité de leur système d'information. Nombreuses d'entre elles ont donc décidé d'implémenter du MFA ou multi-factor authentification.
Le MFA dans son implémentation la plus fréquente consiste à demander en plus du jeu identifiant et mot de passe pour l'authentification d'un utilisateur, un deuxième moyen à l'utilisateur de prouver son identité, par exemple un code d'authentification reçu par SMS.

L'obtention de certifications demande l'implémentation de solutions de MFA, on est donc en droit de se demander si le passwordless est de l'authentification MFA ?

Le MFA consiste à utiliser à minima 2 des 3 éléments suivants :

• Ce que je sais, par exemple un mot de passe ou un code PIN
• Ce que je possède, par exemple une clé FIDO2 ou un téléphone portable
• Ce que je suis, ce qui est lié a de la biométrie, par exemple un iris, un visage ou une empreinte

L'application Microsoft Authenticator utilise donc les facteurs : ce que je sais et ce que je posséde

Windows Hello For Business, utilise donc une combinaison des 3 facteurs en fonction de l'authentification choisie. Dans le cas de l'utilisation du code PIN, un argument serait que seul le facteur ce que je sais entre en jeu, cependant le PC qui est utilisé pour l'authentification du passwordless doit être enregistrée dans le tenant Azure de l'organisation. Le PC peut donc être considéré de facto comme le facteur ce que je posséde.

La clé de sécurité FIDO2 utilise donc les 2 facteurs : ce que je sais et ce que je possède

Le périmètre d'application du passwordless

Le passordless Azure comme son nom l'indique est fondamentalment lié à Azure, il est donc nécessaire que l'application qui demande à l'utilisateur de s'authentifier soit compatible avec les méthodes d'authentification fortes d'Azure.

Pour la connexion aux portails Azure et Office 365, c'est nativement le cas.

Pour l'ouverture d'une session Windows, des pré-requis doivent être satisfaits et des configurations réalisées

Pour les applications tierces ou développées en interne, l'authentification doit supporter des méthodes d'authentification modernes Azure tel que le SSO

Pour aller plus loin

Définir sa stratégie de déploiement passwordless : Article officiel de Microsoft

L'accès conditionnel d'Azure ou Conditional Access (CA) est un service Azure qui permet d'autoriser les connexions vers des applications ou services Azure selon des conditions tels que la plage IP publique d'accès, le type de device ou le niveau de risque de l'utilisateur. Avec la popularisation des VPN, il est difficile de réellement restreindre les connexions depuis un pays donné. Une fonctionnalité récente sortie en 2021 permet dorénavant de demander les coordonnés GPS d'un utilisateur lorsqu'une CA est configurée.

Prérequis pour utiliser la localisation GPS avec l'accès conditionnel Azure

• Chaque utilisateur qui utilise un accès conditionnel doit avoir une licence Azure AD Premium P1
• Le compte qui configure l'accès conditionnel doit avoir un de ces rôles : Security Administrator, Conditional Access Administrator ou Global Administrator
• Les utilisateurs doivent avoir l'application Microsoft Authenticator installée et configurée avec leur compte Azure AD

Créer un emplacement nommé basé sur la localisation GPS

Un emplacement nommé ou name location est un groupement d'IP ou de pays qui sera consommé par une CA pour appliquer une restriction d'accès.

1. Se connecter au tenant Azure AD via le lien portal.azure.com avec le compte qui a les privilèges requis pour configurer une CA

2. Cliquer sur Azure AD > Security > Named locations > + Countries location

3. Dans la blade (fenêtre Azure) qui s'est ouverte :

• Dans le champs Name choisir un nom à donner à cette named location
• Dans le deuxième champs dont la valeur par défaut est Determine location by IP address (IPv4 only) choisir Determine location by GPS coordinates

4. Il est possible de cocher l'option Include unknown countries/regions, cela permet d'inclure les plages IP qui n'appartiennent à aucun pays et les IPv6 qui ne sont pas incluses par défaut.

5. Dans cet exemple, on souhaite configurer la named location en France, scroller jusqu'à trouver France et cocher la checkbox associée puis cliquer sur Create

Créer un accès conditionnel basé sur la localisation GPS

1. Se connecter au tenant Azure AD via le lien portal.azure.com avec le compte qui a les privilèges requis pour configurer une CA

2. Cliquer sur Azure AD > Security > Conditional Access > Policies > + New policy

3. Dans le champs Name entrer le nom de la CA puis cliquer successivement sur Conditions > Locations > Configure > Include > Selected locations

4. Dans la blade qui est apparue à droite, entrer le nom de la named location précédemment entrée et cocher la checkox associé puis cliquer sur Select

5. Il est ensuite possible d'utiliser les différentes options pour choisir les éléments qui doivent être bloqués, par exemple :

• Users or workload identites permet de choisir si la CA doit s'appliquer à l'ensemble des utilisateur ou à un groupe d'utilisateur spécifique
• Cloud apps or actions permet de choisir l'application Azure à conditionner
• Grant permet de configurer la CA en tant qu'autorisation ou réfutation

6. Une fois les éléments de configuration de la CA choisis, il est possible de la configurer en Report-only pour ne pas qu'elle s'applique réellement, mais pour pouvoir avoir un aperçu de ses effets au travers des Sign-in logs des utilisateurs.

SYSVOL est un partage de fichier créé par défaut et partagé entre chaque contrôleur de domaines (DC) dans un Active Directory (AD). DFSR est le mécanisme en charge de la réplication du contenu du SYSVOL entre chaque DC. La santé de la réplication DFSR sysvol est essentielle, car certains services de l'AD en dépendent pour leur fonctionnement, tel que les GPO.

Prérequis pour identifier les problèmes de réplication DFSR sysvol et forcer la restauration

• Avoir un compte Domain Admin
• Avoir accès au DC qui a des problèmes de réplications
• Avoir accès à la commande Dfsrdiag depuis le DC qui a des problèmes de réplications, si la commande n'est pas accessible, elle peut être installée depuis Server Manager > Add Roles and Features > Features > Role Administration Tools > File Services Tools > DFS Management Tools

Identifier les problèmes de réplication DFSR sysvol

Pour les exemples qui vont suivre, le DC2 présente des problèmes de réplications DFSR sysvol depuis le DC1 qui est sain. 

Plusieurs éléments qui ne nécessitent pas d'investiguer des logs peuvent alerter d'un problème de réplication DFSR sysvol :

• Lorsqu'une GPO créée sur le DC1 n'est pas accessible depuis le DC2, exemple de message d'erreur dans la console Group Policy Management : The system cannot find the file specified.
• Lorsqu'un fichier est créé dans le SYSVOL du DC1 \\DC1.domain.intern\SYSVOL\domain.intern et qu'il n'est pas répliqué dans le SYSVOL du DC2 \\DC2.domain.intern\SYSVOL\domain.intern
• Lorsque le nombre de GPO du DC1 \\DC1.domain.intern\SYSVOL\domain.intern\Policies est différent du nombre de GPO du DC2 \\DC2.domain.intern\SYSVOL\domain.intern\Policies

Il est possible d'utiliser la console DFS Management pour faire des tests de réplication, mais ceux-ci ne sont pas assez granulaires.

Depuis le DC qui a des problèmes de réplications, dans une invite de commande PowerShell, la commande Dfsrdiag est utilisée pour avoir un état des lieux du statut des objets en attente de réplication.

PS C:\Windows\system32> Dfsrdiag replicationstate
Summary

  Active inbound connections: 0
  Updates received: 0

  Active outbound connections: 0
  Updates sent out: 0

Operation Succeeded

Le résultat de la commande précédente montre une réplication saine. Lorsque des objets sont en attente de réplication, la liste des objets non répliqués s'affiche.
La valeur de Sending member indique le DC (par exemple DC1) depuis lequel le DC actuel (par exemple DC2) essaye de répliquer les objets du SYSVOL.

Le paramètre syncnow de la commande Dfsrdiag peut être utilisé pour tenter de forcer la réplication des objets en attente.

Dfsrdiag syncnow /partner:DC1.domain.intern /time:5 /RGName:"Domain System Volume"

#synnow permet de forcer la réplication depuis le DC spécifié après le paramètre /partner. Le Sending member précédent peut être utilisé.

#/time est la durée en minutes pendant laquelle la réplication est forcée. 5 minutes sont choisies, car c'est suffisant pour répliquer une centaine d'objets si la réplication fonctionne.

#/RGName est le nom du partage DFS, pour sysvol il s'agit de Domain System Volume

Suite à cette commande, il faut revérifier le statut de la réplication avec la commande Dfsrdiag replicationstate.

Il est possible de tenter la réplication depuis un partenaire différent ou de laisser plus de temps à la réplication.
Si le nombre d'objets en attente de synchronisation ne varie pas, il faut procéder à une restauration du DFSR sysvol.

Forcer la restauration DFSR sysvol d'un contrôleur de domaine

La restauration du DFSR sysvol consiste à faire une synchronisation non authoritative depuis un DC sain. C'est-à-dire que le contenu SYSVOL du DC2 qui a des problèmes de synchronisation sera écrasé par le contenu du SYSVOL du DC1. Les méthodes utilisées précédemment : le fonctionnement par défaut de DFSR et la commande dfsrdiag syncnow tentent de faire des synchronisation avec gestion des conflits, mais certains conflits de versions ne peuvent être résolus par les algorithmes internes.

1. Se connecter au DC2 qui a des problèmes de réplications

2. Ouvrir la console ADSI Edit, faire un clique droit sur ADSI Edit et cliquer sur Connect to..

3. Dans Connection Point choisir Select a well known Naming Context puis choisir Default naming context, dans Computer choisir Select or type a domain or server puis entrer le nom du DC qui a des problèmes de réplication puis cliquer sur OK

4. Déplier les dossiers Default naming context > <Domain> > OU = Domain Controllers > CN=<Nom du DC qui a des problèmes de réplications> > CN =DFSR-LocalSettings > CN = Domain System Volume > faire un clic droit sur CN = SYSVOL Subscription > Properties

5. Dans l'onglet Attribute Editor chercher l'attribut msDFSR-Enabled, faire un clic droit sur cet attribut et changer la valeur de True à False. Cette action à permis de désactiver la réplication DFSR sysvol pour le DC2

6. Depuis le DC2 ouvrir une console PowerShell et entrer la commande

repadmin /syncall /AdP

Cette commande permet de forcer la synchronisation des AD du DC2

7. Depuis le PowerShell du DC2 entrer la commande

Dfsrdiag PollAD

Cette commande permet de récupérer la configuration DFSR sans attendre qu'une réplication AD s'exécute.

8. Il est possible de vérifier que la réplication DFSR a bien été arrêté en consultant l'Event Viewer du DC2 et notamment l'Event ID 4114 dans Applications and Services Logs > DFS Replication

9. Réactiver la synchronisation DFSR sysvol sur le DC2 en suivant les étapes 1 à 5. Cette fois passer la valeur de msDFSR-Enabled de False a True

10. Forcer la réplication AD et DfsrDiag depuis le DC2 avec les commandes des étapes 6 et 7

11. Vérifier le statut de la synchronisation non authoritative DFSR sysvol du DC2 en ouvrant l'Event Viewer depuis le DC2, depuis le dossier Applications and Services Logs > DFS Replication > consulter les logs et notamment la présence de l'Event ID 4614

12. Depuis le DC2 dans une console PowerShell, utiliser la commande Dfsrdiag replicationstate pour vérifier s'il existe toujours des objets non répliqués

13. Faire un test de réplication SYSVOL DFSR en crééant un fichier sur le DC1 (sain) \\DC1.domain.intern\SYSVOL\domain.intern puis se connecter sur le SYSVOL du DC2 (réparé) \\DC2.domain.intern\SYSVOL\domain.intern et vérifier que le fichier est présent

Pour aller plus loin

Documentation officielle Microsoft How to force authoritative and non-authoritative synchronization for DFSR-replicated sysvol replication

Lorsqu'une instance est créé dans un serveur SQL, l'authentification des utilisateurs peut être configurée de 2 façons différentes :

• Windows Authentication - les comptes de la machine et/ou du domaine AD peuvent être utilisés pour se connecter avec différents niveaux de privilèges
• Mixed mode - l'authentification Windows ainsi que l'authentification SQL (accès avec des comptes locaux à l'instance) peuvent être utilisé

Lorsque Windows Authentication est choisi, le compte local à l'instance appelé sa qui est membre du groupe sysadmin est désactivé.

sa (system administrator) est un compte utilisateur par défaut local à l'instance SQL dont le mot de passe n'est pas connu

sysadmin est un groupe par défaut local à l'instance SQL dont les membres ont les permissions les plus élevées sur l'instance SQL

Dans l'éventualité ou la personne qui a créé l'instance n'est pas disponible et qu'elle n'a pas configuré ou communiqué des accès de secours, par exemple, mixed mode ou ajout d'autres IT en tant que sysadmin, les accès administrateurs à l'instance SQL semblent impossible.

Les prérequis pour récupérer les permissions sysadmin

• Être administrateur du serveur sur lequel le serveur SQL est installé
• Avoir SQL Server Managmement Studio (SSMS) installé sur le serveur
• Si l'instance concerne un environnement de production, avertir que lors de la récupération des accès, l'instance SQL sera indisponible

Récupérer les permissions sysadmin

1. Se connecter sur le serveur sur lequel le serveur SQL est installé

2. Ouvrir la console SQL Server Configuration Manager

3. Faire un clic droit sur l'instance SQL dont l'accès sysadmin doit être récupéré et cliquer sur Properties

4. Ouvrir l'onglet Startup Parameters, dans Specify a startup parameters saisir -m puis cliquer sur Add, le paramètre -m permet de mettre l'instance SQL en mode maintenance, un utilisateur qui est admin du serveur et qui se connecte à l'instance SQL via SSMS sera, dans ce mode, également sysadmin. Ce mode n'autorise qu'un seul utilisateur à se connecter à la fois.

5. Redémarrer l'instance SQL, dont l'accès sysadmin doit être récupéré, via la console SQL Server Configuration Manager en faisant un clic droit sur l'instance puis choisir Restart

6. Depuis la console SQL Server Configuration Manager, vérifier que le service SQL Server Agent n'est pas démarré, si c'est le cas l'arrêter, auquel cas il utilisera la seule connecxion disponible pour se connecter à l'instance SQL

7. Ouvrir la console SQL Server management Studio en tant qu'administrateur

8. Se connecter à l'instance SQL dont l'accès sysadmin doit être récupéré avec comme méthode d'authentification Windows Authentication

9. Dans l'arborescence de l'instance SQL, déplier le dossier Security puis faire un clic droit sur Logins et clique sur New login...

10. Dans l'onglet General, dans le champs Login name choisir le compte utilisateur ou le groupe qui sera sysadmin, choisir Windows Authentication

11. Aller dans l'onglet Server Roles et cocher sysadmin puis clique sur OK 

12. Le nouvel accès apparaît dans la liste des Login

13. Fermer SSMS

14. Dans SQL Server Configuration Manager retirer le paramètre -m de l'instance SQL dont les accès sysadmin ont été récupéré, en sélectionnant -m et en cliquant sur Remove

15. Depuis la console SQL Server Configuration Manager redémarrer l'instance SQL dont l'accès sysadmin a été récupéré

Une présentation des Administrative Units (AU) a été réalisée dans l'article suivant : Azure - présentation des Administrative Units

La délégation des Administrative Units en interface graphique a été expliquée dans l'article suivant :  Azure - déléguer les Administrative Units

Créer et déléguer des Administrative Units en PowerShell

#Import les modules AzureAD et AzureADPreview qui contient les commandes utilisées pour la création des Administrative Units (AU)
#Si certaines commandes ne sont pas reconnues, assurez vous d'avoir le module à jour avec la commande Update-Module
Import-Module AzureAD
Import-Module AzureADPreview

#Initie une connexion avec AzureAD dans la console PowerShell, un compte avec les droits Global Administrator ou Privileged Role Administrator est nécessaire
Connect-AzureAD

#Création d'une nouvelle AU, la commande est sauvegardé dans une variable car l'objectID doit être utilisé pour la délégation
#Par défaut l'affectation des objets à l'AU sera Assigned, pour faire de l'affectation dynamique utiliser les paramètres MembershipType, MembershipRuleProcessingState et MembershipRule 
New-AzureADMSAdministrativeUnit -Description "Test Administrative Unit created with PowerShell" -DisplayName "AdministrativeUnit-test2"

#Les propriétés de l'AU sont récupérées car l'object ID est nécessaire pour faire l'affectation des droits au groupe de délégation dans PIM
$NewAU = Get-AzureADAdministrativeUnit -Filter "displayname eq 'AdministrativeUnit-test2'"

#Création d'un groupe de délégation qui aura la délégation sur l'AU créée
#C'est un groupe de sécurité, la partie mail est donc désactivé (MailEnabled $False) et la partie sécurité est activé (SecurityEnabled $True)
#Le paramètre MailNickname est obligatoire, il est donc recommandé de rentrer la même valeur que le displayName
#Pour pouvoir affecter des rôles via PIM, il est nécessaire d'activer le paramètre IsAssignableToRole
#Le paramètre Visibility permet de modifier qui est autorisé à voir les membres du groupe, il est recommandé de choisir soit Private soit HiddenMembership
New-AzureADMSGroup -DisplayName "Group-to-manage-AdministrativeUnit-test2" -Description "Group that have the delegation on the AU AdministrativeUnit-test2" `
-MailEnabled $False -MailNickname "Group-to-manage-AdministrativeUnit-test2" -SecurityEnabled $True -IsAssignableToRole $True -Visibility "Private"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID du groupe de délégation
$NewAzureGroup = Get-AzureADGroup -Filter "displayname eq 'Group-to-manage-AdministrativeUnit-test2'"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID du rôle
#Cet ID peut être récupérer depuis portal.azure.com > Azure Active Directory > Administrative Units > {Cliquer sur une AU existante} >
#Roles and admininistrators > {Choisir le rôle a affecté} > Description > Template ID
#Le template ID choisi est celui d'User administrator
$RoleDefinitionID = Get-AzureADMSRoleDefinition -ID "fe930be7-5e62-47db-91af-98c3a49a38b1"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID de l'AU
$DirectoryScopeId = '/administrativeUnits/' + $NewAU.ObjectId

#Création de la délégation PIM du groupe Group-to-manage-AdministrativeUnit-test2 sur l'AU AdministrativeUnit-test2
New-AzureADMSRoleAssignment -DirectoryScopeId $DirectoryScopeId -RoleDefinitionId $RoleDefinitionID.Id -PrincipalId $NewAzureGroup.ObjectId

Vérification de la création et de la délégation

L'Administrative Unit a bien été créé

Le groupe de délégation ainsi que son affectation dans PIM est effective

Remarque : lors de l'installation du module AzureADPreview, celui-ci entre en conflit avec le module AzureAD s'il est déjà installé, lors de l'utilisation de la commande Install-Module, utiliser les paramètres AllowClobber et Force

Pour aller plus loin

Documentation officielle de la commande New-AzureADMSAdministrativeUnit
Documentation officielle de la commande Get-AzureADAdministrativeUnit
Documentation officielle de la commande New-AzureADMSGroup
Documentation officielle de la commande Get-AzureADGroup
Documentation officielle de la commande Get-AzureADMSRoleDefinition
Documentation officielle de la commande New-AzureADMSRoleAssignment