Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

PowerShell – Récupérer la configuration système des contrôleurs de domaine d’une forêt Active Directory

<pre class="wp-block-syntaxhighlighter-code">#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
#></pre>

 

Azure AD – Déployer le passwordless avec Microsoft Authenticator

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

Azure AD – Présentation du passwordless

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