Introduction
Microsoft Entra autorise les droits d’accès aux ressources sécurisées via le contrôle d’accès en fonction du rôle Azure (Azure RBAC).Lorsqu’un rôle Azure est attribué à un principal de sécurité Microsoft Entra, Azure octroie l’accès à ces ressources pour ce principal de sécurité. Un principal de sécurité Microsoft Entra peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée pour les ressources Azure.
Besoin
La gestion des permissions Azure RBAC au niveau des abonnements Azure se fait de façon centralisée par les administrateur ayant des permissions privilégiées Aussi, les rôles RBAC s'attribue sur des scopes souvent larges.
Dans certains scénario, un contrôle d'accès plus fin que celui offert par RBAC est nécessaire. Par exemple, il peut être indispensable d'accorder l'accès à certaines ressources, mais pas à toutes, dans une hiérarchie. Ou encore accorder les permission uniquement à des ressources ayant des tags spécifiques.
Aussi, des utilisateurs ont parfois besoin de gérer les permissions d'une service principal sur le scope pour lequel ils ont des droits.
Solution
Azure ABAC (Attribute Based Access Control) c'est les conditions qui se rajoutent au moment de l'attribution de rôle RBAC permettant ainsi une autre vérification que vous pouvez ajouter à votre attribution de rôle pour fournir un contrôle d’accès encore plus précis.
Exemple d'utilisation : Attribuer à un groupe Entra ID un rôle permettant d'assigner toutes les permissions RBAC à tout type d'identité (utilisateur, groupe, SPN ou identités managées) à l'exception de certaines permissions privilégiées.
Si un jour vous souhaitez faire un état des lieux de ce qui est déjà en place en terme de partage, voici quelques liges de Powershell qui permettent de sortir la liste des OneDrive ayant un partage avec un invité.
Prenez soin de remplacer l'url de connexion au portail d'admin Sharepoint.
# Connect to Sharepoint Online
Connect-SPOService -Url https://MonTenant-admin.sharepoint.com/
# Collect all Sharepoint Sites and filter on OneDrive
$AllOneDrive = Get-SPOSite -IncludePersonalSite $true -Limit all -Filter "Url -like '-my.sharepoint.com/personal/'"
# Define variabes
$ArrayOneDriveMembers = @()
$SortOneDrive = $AllOneDrive | sort Url
$SortOneDrive | foreach {
$OneDriveUrl = $_.Url
$OneDriveOwner = $_.Owner
$OneDriveStorageQuota = $_."Storage Quota"
$OneDriveTitle = $_.Title
# Get the list of members for the current OneDrive
Try {
$OneDriveMembers = Get-SPOUser -Site $OneDriveUrl -ErrorAction stop
}
Catch {
Write-Output "$OneDriveUrl;$OneDriveTitle" | Add-Content C:\temp\Onedriveerrors.txt
}
# Define a new variable
$OneDriveExternal = $OneDriveMembers.where({$_.Usertype -eq "Guest"})
# Check if the new variable is empty, if not collect logs
If ($OneDriveExternal.count -ne 0) {
# Display some informations
Write-Host "External Users are present in $OneDriveTitle" -ForegroundColor Green
$OneDriveExternal.count
# Store Data
$OneDriveExternal | foreach {
$DisplayName = $_.DisplayName
$LoginName = $_.LoginName
$ArrayOneDriveMembers += New-Object psobject -Property @{
OneDriveUrl = $OneDriveUrl
OneDriveOwner = $OneDriveOwner
OneDriveStorageQuota = $OneDriveStorageQuota
OneDriveTitle = $OneDriveTitle
DisplayName = $DisplayName
LoginName = $LoginName
}
# Release Variables
$DisplayName = $null
$LoginName = $null
}
}
# Release variables
$OneDriveUrl = $null
$OneDriveOwner = $null
$OneDriveStorageQuota = $null
$OneDriveTitle = $null
$OneDriveMembers = $null
}
$ArrayOneDriveMembers | Export-Csv c:\temp\ExternalOneDriveMembers.csv -Encoding UTF8 -Delimiter ";" -NoTypeInformation
SSPR et MFA
Face aux nombreuses attaques informatique ces dernières années, les entreprises répondent en renforçant la sécurité de leur système d'information (SI).
SSPR (Self-Service Password Reset) et MFA (Multi-factor authentication) y contribuent.
SSPR permet à un utilisateur de réinitialiser son mot de passe dans Azure de façon autonome via des méthodes de récupération qu'il aura configuré préalablement, SMS, appel téléphonique, questions secrètes..
MFA demande à un utilisateur un deuxième moyen de prouver son identité, c'est par exemple parfois le cas suite à un achat en ligne, un code à usage unique (OTP) pour valider la transaction est envoyé par SMS à un téléphone dont le numéro a été communiqué au fournisseur de service en amont. D'autres méthodes existent tel que l'application Microsoft Authenticator ou l'appel d'un numéro de téléphone.
On observe donc que certaines méthodes d'authentification sont communes entre SSPR et MFA, les utilisateurs seront donc invités à renseigner plusieurs fois les mêmes informations ce qui détériore leurs expériences et par conséquent amoindris leurs adhésions à ces outils.
Combiner les informations de sécurité SSPR et MFA
Il existe dans Azure un paramètre qui permet de combiner les informations de sécurité SSPR et MFA.
Se connecter avec un compte administrateur global à portal.azure.com > User settings > Manage user feature settings
Choisir ensuite All dans User can use the combined security information registration experience
Selected permet d'activer ce paramètre pour des utilisateurs nominatif
Pour aller plus loin
Documentation officielle Microsoft sur la combinaison des informations de sécurité SSPR et MFA
Les souscriptions, des ressources Azure aux permissions isolées
Le rôle Azure administrateur global (global administrateur) est le rôle absolu, il octroie le droit de vie ou de mort sur un tenant Azure, cependant, les irrésistibles souscriptions (subscriptions) n'en ont que faire et un global administrator se fera jeter comme un simple utilisateur s'il tente d'accéder à une ressource Azure auquel il n'a pas accès si tenté qu'il puisse déjà la voir, à moins que..
S'octroyer les permissions sur toutes les souscriptions
Il existe une fonctionnalité Azure qui permet à un Global admin de se conférer des droits sur toutes les subscriptions existantes et ceci en un clic, pour ce faire :
Connectez-vous à portal.azure.com avec votre compte Global admin et dans la liste déroulante de gauche, ouvrez Properties
En bas de la fenêtre dans la section Access management for Azure ressources basculez le bouton en Yes
Attention, ce rôle ne fournit pas le rôle Propriétaire (Owner) sur les subscriptons, il fournit le rôle User Access Administrator à la racine ce qui permet d'accéder au RBAC Azure de la subscription et de s'octroyer les droits voulus.
Pensez à retirer vos droits de la subscription avant de basculer à nouveau le bouton évoqué précédemment en No
Pour aller plus loin
Article officiel de Microsoft sur la délégation de permissions sur les souscriptions Azure en tant qu'administrateur global
Article officiel de Microsoft sur le RBAC Azure
Un peu de contexte
Dans certains environnements la connexion réseau vers Internet et notamment vers Azure peut présenter des défaillances.
Lorsque qu'un administrateur se connecte de façon interactive en PowerShell à Azure, un simple échec importe peu et une nouvelle tentative est souvent fructueuse, lorsque c'est une tâche automatisée qui est exécutée c'est une autre histoire, toutes les actions qui dépendent de cette connexion échouerons si la connexion vers Azure AD est un échec.
Le code
$i = 0 #Variable qui sera incrémentée à chaque nouvelle tentative de connexion à Azure
$ConnectAzureAD = "Fail" #Variable qui permet de sortir de la boucle si une tentative de connexion vers Azure AD est réussite
do #Do until permet d'exécuter un script en boucle tant qu'une condition n'est pas atteinte
{
try #Try catch permet de choisir comment les erreurs de cmdlet seront gérés, ici on s'en sert pour attendre avant la prochaine tentative de connexion et potentiellement faire du logging
{
$i++ #Permet d'incrémenter la variable $i
Connect-AzureAD #Cmdlet qui permet de se connecter à Azure AD, dans un script automatisé, les identifiants d'un compte de service seront utilisé à l'aide du paramètre -Credential $Credentials (objet PSCredential à créer)
$ConnectAzureAD = "Success" #La connexion à Azure AD est un succès puisque nous sommes dans le try, on peut donc modifier la variable $ConnectAzureAD pour pouvoir sortir de la boucle, code qui fonctionne de paire avec la condition dans le until
#Il est recommandé de consacrer une ligne pour faire du logging
}
catch
{
#A nouveau il est recommandé de consacrer une ligne pour faire du logging
Start-Sleep 10 #Permet de faire une pause de 10 secondes avant la nouvelle tentative de connexion
}
}
until ($ConnectAzureAD -eq "Success" -or $i -eq 6) #Si une connexion vers Azure AD est réussie ou si 6 tentatives infructueuses ont été observées, le script arrêtera d'essayer de se connecter à Azure AD
En résumé, le script tentera de se connecter à Azure AD en powershell jusqu'à ce qu'une connexion soit établie ou que 6 tentatives de connexions aient échouées.
Vous avez créé un accès conditionnel pour bloquer toutes les applications à l'exception de Teams mais Teams est toujours bloqué ?
Vous êtes au bon endroit, cet article vous explique tout ce qu'il y a à savoir sur les dépendances de Teams dans l'accès conditionnel Azure.
La configuration de l'accès conditionnel
Commençons par rappeler la configuration de l'accès conditionnel dont il est question:
Ci-dessous l'utilitaire qui permet de créer un accès conditionnel :
- Block access
- Cet accès conditionnel applique un refus de connexion (en opposition à grant/autoriser)
- All cloud apps included and 1 app excluded
- Cet accès conditionnel concerne toutes les applications Azure à l'exception d'une application
- Exclude
- Permet d'exclure des applications de l'accès conditionnel
- Microsoft Teams
- Teams est exclu de l'accès conditionnel
Les dépendances de Teams
Teams est dépendant d'autres applications Microsoft : SharePoint, Exchange, Planner, etc.
Ces applications doivent être également exclues dans l'accès conditionnel pour que Teams puisse fonctionner pleinement.
A noter qu'il existe deux types de dépendances :
- Des applications qui sont Early-bound policy enforcement
- Cela signifie que la vérification que l'application dont dépend Teams est présente dans l'accès conditionnel se fait avant la connexion de l'utilisateur. En d'autres termes si l'application n'est pas dans la liste d'exclusion de l'accès conditionnel l'utilisateur ne pourra pas se connecter.
- Des applications qui sont Late-bound policy enforcement
- En opposition au Early-bound policy enforcement, l'utilisateur pourra se connecter à Teams mais ne pourra pas bénéficier des services d'une application non exclue dans l'accès conditionnel
Voici un schéma récapitulatif :
- Les traits pleins sont des Early-bound policy enforcement
- Les traits en pointillés sont des Late-bound policy enforcement
Pour aller plus loin
Article officiel de Microsoft sur les dépendances de Teams dans l'accès conditionnel
Il arrive dans certain cas de figure que nous souhaitions forcer le changement de mot de passe des comptes O365.
S'il s'agit d'un seul utilisateur voici la commande :
Set-MsolUserPassword -UserPrincipalName jdupont@mondomaine.com -ForceChangePasswordOnly $true -ForceChangePassword $true
Prenez soin de modifier le Userprincipalname de la commande sous peine d'obtenir une erreur.
En revanche si l'on veut forcer l'intégralité de la société à changer de mot de passe cela va nécessiter quelques lignes de plus.
# Variables
$LogFolder = "C:\temp"
$LogFile = "$LogFolder\LogO365_Reset.txt"
$LogFileError = "$LogFolder\LogO365_Reset_Error.txt"
# check
If (!(Test-Path $LogFolder)) {
New-Item $LogFolder -ItemType Directory
}
# Exceptions
$FilteredUsers = "Userprincipalname1", "Userprincipalname2", "Userprincipalname3" # Ajouter les UPN à ne pas reset (exemple le compte Admin du Tenant)
# Connect to O365
Connect-MsolService
# Get users
$AllUsers = Get-MsolUser -MaxResults 10000 | select UserPrincipalName
# Force to change Password
$AllUsers | foreach {
$UPN = $_.UserPrincipalName
If ($FilteredUsers -eq $UPN) {
Write-Host "Do not reset Password For $UPN because we had filtered him" | Add-Content $LogFile
}
Else {
Try {
Set-MsolUserPassword -UserPrincipalName $UPN -ForceChangePasswordOnly $true -ForceChangePassword $true
Write-Output "Succesfully reset Password For $UPN" | Add-Content $LogFile
}
Catch {
$Date = Get-Date
Write-Warning "At $Date the following Error Appear $($_)" | Add-Content $LogFileError
}
}
}
Bon courage au service IT pour le nombre d'appel qu'il va recevoir.
Comme expliqué dans l'article précédent "O365 : Soft Match (SMTP) et Hard Match (ImmutableID)" le Hard Match intervient lorsque le Soft Match n'a pas fonctionné.
Les étapes à suivre sont les suivantes:
- Récupérer le GUID du compte dans l'Active Direcotry
- Convertir ce dernier en ImmutableID
- Appliqué cet ImmutableID au compte Azure Active Directory
- Relancer une synchronisation via Ad connect
Voici donc les commandes pour cela.
# 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 MsolService
Connect-Msolservice
# Set ImmutableID to msoluser
Set-MsolUser -UserPrincipalName $Upn -ImmutableId $ImmutableId
Et voila, vous n'avez plus qu'a relancer une Synchor AD Connect via la commande suivante.
Start-ADSyncSyncCycle -PolicyType Delta
Qu'est-ce que SSPR ?
SSPR ou Self-service password reset est une fonctionnalité d'Azure Active Directory permettant aux utilisateurs de réinitialiser eux-même leur mot de passe.
Quels sont les avantages de SSPR ?
- Autonomie des utilisateurs pour réinitialiser leur mot de passe et par conséquent réduction du nombre de sollicitations des IT
- Les méthodes de récupérations proposées par SSPR sont connus et facile à prendre en main : question secrètes, vérification par SMS etc
- Les options de configuration de SSPR peuvent être aisément changées
- L'utilisation de SSPR est loguée et ces logs sont facilement accessible
Comment configurer SSPR ?
1. Rendez-vous dans portal.azure.com et connectez-vous avec un compte qui possède le rôle Global Administrator
2. Cliquez sur l'icone des triples barres horizontales pour afficher le menu du portail Azure puis cliquer sur Azure Active Directory
3. Dans le menu cliquez sur Password Reset
4. Vous arrivez directement dans l'onglet Properties, choisissez si vous voulez que SSPR soit activé pour l'ensemble des utilisateurs All ou pour un nombre restreint Selected
5. Cliquez sur Authentication methods et choisissez les paramètres voulus : méthodes de récupération disponible pour les utilisateurs, nombre de méthodes de récupération minimum nécessaire etc
6. Cliquez sur l'onglet Registration, vous pouvez forcer l'inscription des utilisateurs à SSPR lors de leur prochaine connexion au portail office. Vous devez également choisir au bout de combien de jours les utilisateurs doivent confirmer leurs informations de méthodes de récupération.
7. Vous avez d'autres options de configurations dans les onglets Notifications et Customization. L'onglet On-premises integration est quant à lui utilisé dans les environnements hybrides.
Quelle est l'expérience utilisateur lors de l'inscription à SSPR ?
1. Si vous n'avez pas obligé l'utilisateur à s'inscrire, vous devez lui fournir ce lien : aka.ms/ssprsetup sinon il aura l'image suivante à sa prochaine connexion
2. L'utilisateur devra ensuite confirmer son mot de passe actuel puis sera invité à s'inscrire à SSPR, les méthodes de récupération que vous avez choisi précédemment seront proposées à l'utilisateur. Il peut les configurer en cliquant sur set up now à coté de la méthode de récupération
3. Après avoir configuré le nombre minimum de méthodes de récupération, il peut alors cliquer sur looks good pour finir son inscription à SSPR
Comment l'utilisateur peut utiliser SSPR pour réinitialiser son mot de passe ?
1. L'utilisateur peut soit utiliser le lien suivant : aka.ms/sspr soit se rendre sur portal.office.com et cliquer sur Can't access your account?
2. Il lui sera alors demandé d'entrer l'UPN de son compte et de valider un captcha. Il pourra ensuite choisir parmi les méthodes de récupération qu'il a configuré pour réinitialiser son mot de passe
3. L'utilisateur sera alors invité à saisir un nouveau mot de passe
Dans certain cas de figure (mariage, divorce...) les utilisateurs de l'AD change de nom, ceux qui a pour impact un renommage du compte Active Directory, jusque la pas de problème mais (parce qu'il en faut un) lorsque vous utilisez "AD Connect" pour synchroniser vos utilisateurs locaux (votre Active Directory) avec Office 365 (Azure Active Directory), certains paramètres ne sont pas synchronisés.
Parmi ces paramètres le UserPrincipalName, plus communément appelé UPN ne peut être modifié depuis l'AD et répliqué vers O365.
Pour modifier l'UPN côté O365 vous devrez utiliser la commande Powershell suivante:
Set-MsolUserPrincipalName -UserPrincipalName AncienUPN@mondomaine.com -NewUserPrincipalName NouvelUPN@mondomaine.com