Les permissions Microsoft Graph.

Les permissions attribuées au sein d'un Tenant Microsoft 365 (types et étendues) peuvent avoir un impact sur ce dernier, il est donc important de bien identifier votre besoin pour les attribuer.

Lorsque l'on délègue des permissions Microsoft Graph à une App dans un Tenant, celle-ci peut se voir attribuer deux types "Delegated" ou "Application", nous allons tenter de voir la différence entre les deux.

Pour illustrer ces deux types nous allons nous référer à la présentation de Microsoft ci dessous.

Delegated Permissions

Permet à une application, d'agir en tant que l'utilisateur pour une action spécifique.

Ces permissions sont orientées pour des applications qui accèdent en tant que l'utilisateur identifié et, ne pourront excéder la porté de l'utilisateur.

Prenons par exemple l'App "Demo-DelegatedPerm" cette dernière possède le droit "Mail.Send".

Ce qui implique que lorsque l'utilisateur va vouloir utiliser cette application un consentement va lui être demandé.

A partir du moment ou l'utilisateur aura donné son consentement l'application sera autorisé a envoyer des mails en son nom.

Attention : Dans ce type de délégation l'approbation peut être donnée soit :

• Par l'utilisateur lorsqu'il utilise l'application.
• Par l'Administrateur pour tous les utilisateurs du Tenant lorsqu'il donne les permissions. 

Application Permissions

Permet à une application d'agir en tant qu'elle même, au lieu d'un utilisateur spécifique.

Ces permissions sont orientées pour des applications qui accèdent en tant qu'application elles mêmes et, auront une porté d'action sur l'ensemble du Tenant.

Prenons ici l'App "Demo-ApplicationPerm" cette dernière possède le droit "Mail.Send".

Ce qui implique que lorsque l'Administrateur va approuver les droits, cette application sera en mesure d'envoyer des mails depuis n'importe quelle boite aux lettres du tenant.

Qu'est ce que ça implique ?

En terme d'accès nous pouvons constater que l'un est beaucoup plus permissif que l'autre (encore que cela soit discutable si c'est l'administrateur qui a consenti) et, qu'il faut à minima restreindre la porté de l'accès.

En effet dans un contexte de moindre privilèges, l'attribution des droits via "Application Permissions" doit être contenu / restreint afin d'en limiter sa portée; ainsi nous pourrons nous prémunir d'une application avec une trop grande portée d'action sur l'environnement.

Besoin :

On ne peut pas identifier simplement les noms de groupes qui sont membres du groupe local "Administrateurs" sur une machine joint à l'Azure AD.

Si on fait Windows+R et on tape "lusrmgr.msc" pour afficher les utilisateurs et groupes locaux d'une machine, on souhaite par exemple afficher les membres du groupe Administrateurs, on n'aura pas les noms des groupes membres mais plutôt leurs SID.

Ces SID doivent être convertis en GUID pour pouvoir chercher les noms des groupes dans Azure AD.

Solution :

J'ai utilisé ce script PowerShell pour convertir le SID en GUID :

function Convert-AzureAdSidToObjectId {
<#
.SYNOPSIS
Convert a Azure AD SID to Object ID
 
.DESCRIPTION
Converts an Azure AD SID to Object ID.
Author: Oliver Kieselbach (oliverkieselbach.com)
The script is provided "AS IS" with no warranties.
 
.PARAMETER ObjectID
The SID to convert
#>

    param([String] $Sid)

    $text = $sid.Replace('S-1-12-1-', '')
    $array = [UInt32[]]$text.Split('-')

    $bytes = New-Object 'Byte[]' 16
    [Buffer]::BlockCopy($array, 0, $bytes, 0, 16)
    [Guid]$guid = $bytes

    return $guid
}

$sid = "S-1-12-1-1943430372-1249052806-2496021943-3034400218"
$objectId = Convert-AzureAdSidToObjectId -Sid $sid
Write-Output $objectId


# Output:

# Guid
# ----
# 73d664e4-0886-4a73-b745-c694da45ddb4

N.B : Il faut renseigner le SID dans la variable $sid pour que le script retourne son GUID

Dans un précédent article j'expliquais comment réaliser un hard match (https://blog.piservices.fr/post/2021/04/01/o365-realiser-un-hard-match).

J'ai récemment eu à me servir de nouveau des cmdlets et ces dernières ne fonctionnaient pas correctement, il est possible de le faire via API Graph, mais les commande Azure AD permettent encore de le faire si besoin.

# Get GUID for User
$User = Get-ADUser jdupont | select ObjectGUID,UserPrincipalName
$Upn = $User.UserPrincipalName
$Guid = $User.ObjectGUID.Guid
 
# Convert GUID to ImmutableID
$ImmutableId = [System.Convert]::ToBase64String(([GUID]($User.ObjectGUID)).tobytearray())
 
# Connect Azure AD
Connect-AzureAD

# Retrieve my user
$User = Get-AzureADUser -SearchString "jdupont @mydomain.com"

# Set ImmutableID to user
Set-AzureADUser -ObjectId $User.ObjectID -ImmutableId $ImmutableId

Besoin :

On souhaite identifier le SID d'un groupe Azure AD mais l'attribut n'existe pas.

Solution :

J'ai utilisé ce script PowerShell pour convertir le GUID en SID :

function Convert-AzureAdObjectIdToSid {
<#
.SYNOPSIS
Convert an Azure AD Object ID to SID
 
.DESCRIPTION
Converts an Azure AD Object ID to a SID.
Author: Oliver Kieselbach (oliverkieselbach.com)
The script is provided "AS IS" with no warranties.
 
.PARAMETER ObjectID
The Object ID to convert
#>

    param([String] $ObjectId)

    $bytes = [Guid]::Parse($ObjectId).ToByteArray()
    $array = New-Object 'UInt32[]' 4

    [Buffer]::BlockCopy($bytes, 0, $array, 0, 16)
    $sid = "S-1-12-1-$array".Replace(' ', '-')

    return $sid
}

$objectId = "73d664e4-0886-4a73-b745-c694da45ddb4"
$sid = Convert-AzureAdObjectIdToSid -ObjectId $objectId
Write-Output $sid

# Output:

# S-1-12-1-1943430372-1249052806-2496021943-3034400218

N.B : il faut renseigner le GUID dans la variable $objectId pour que le script retourne son SID

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.

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.

Scénario:

Créer un groupe d'appreils dynamique dans Azure AD qui regroupe les ordinateurs qui sont gérés par Intune ou Co-managed (Mode de gestion hybride: MECM+INTUNE).

Solution:

Dans Azure AD, créer un groupe d'appareils dynamique en utilisant une règle d'appartenance dynamique basée sur la propriété Mobile Device Management Type.

Dans la configuration de la règle, nous devons sélectionner la propriété deviceManagementAppId.

En tant que valeur, il faut renseigner l'un des identifiants ci-dessous :

• 54b943f8-d761-4f8d-951e-9cea1846db5a pour Co-managed
• 0000000a-0000-0000-c000-000000000000 pour Intune

Exemple:

Ceci est un exemple de configuration d'une règle dynamique pour un groupe d'appareils Co-managed:

Selon l'opérateur que vous préférez, vous devez entrer l'intégralité de l'ID ou pouvez utiliser une partie de l'ID.

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

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

Créer et déléguer une Administrative Unit

Lorsqu'une Administrative Unit est en phase de création, il est proposé de réaliser la délégation via Privileged Identity Management (PIM).

Création d'une Administrative Unit

Choix du nom de la nouvelle AU

En bas de la blade choisir Next: Assign roles >

Affecter les rôles qui doivent être délégués à des utilisateurs.

Remarque : il n'est pas possible d'affecter des groupes depuis cette blade, néanmoins il est possible de le faire après que l'AU soit créé en l'éditant.

Dans l'exemple suivant, le rôle User Administrator sera affecté

Une fois l'affectation faite, finir la création en cliquant sur Next: Review + create >

Puis Create

L'Administrative Unit créé est alors affiché

Déléguer une Administrative Unit à un groupe

Cliquer sur le nom de l'AU précédemment créée, puis sous Manage choisir la blade Roles and administrators et clique sur le rôle a délégué

La blade affichée n'est plus la même que lors de la création de l'AU, c'est la blade de délégation PIM qui s'affiche. Cliquer sur Active assignments puis Add assignments

Cliquer sur No member selected et choisir le groupe à déléguer

Cliquer sur Next

Choisir le mode d'affectation, il est recommandé de choisir un Assignment type Active avec une durée d'affectation Permanently assigned étant donné que les AU sont déjà restreintes en termes de périmètre et des opérations disponibles.

Clique sur Assign

Les affectations sont visibles depuis le sous-menu PIM précédémment évoqué

Les délégations des Administrative Units les plus utiles en septembre 2022

Remarque : il n'est pas possible de créer des utilisateurs directement depuis une AU

Remarque 2 : les autres rôles donnent soient trop de permissions et ne sont pas conseillés, car proche des droits sur tout le tenant soit n'ont aucune répercussion de délégation.

Pour aller plus loin

Sur le même blog : PowerShell - créer et déléguer des Administrative Units