Bloquer l'accès des utilisateurs aux comptes Microsoft 365
Plusieurs techniques disponibles pour empêcher les gens de se connecter
Mise à jour le 20 février 2024
Un article récent sur l'utilisation de PowerShell pour contrôler les politiques d'accès conditionnel d'Entra ID m'a amené à réfléchir aux techniques utilisées pour bloquer l'accès des utilisateurs à Office 365. Il y a quatre ans, j'ai évoqué le problème dans un article de Petri.com inspiré d'une loi française pour permettre aux gens de se déconnecter pendant le week-end. Dans d’autres pays que la France, la nécessité de préserver l’espace entre le temps personnel et le temps de travail est devenue plus évidente alors que la pandémie de Covid-19 a contraint de nombreuses personnes à travailler à domicile. Certains travaillaient plus, d’autres moins, et la frontière entre temps personnel et temps de travail s’estompait. Aujourd’hui, les progrès du temps et l’évolution de la technologie se combinent pour rendre raisonnable de réexaminer le problème.
Mise à jour : Microsoft a mis en œuvre une évaluation continue des accès (CAE) pour les événements critiques tels que les changements de mot de passe ou les blocages de compte dans tous les locataires. L'effet net du CAE est que la privation de l'accès d'un utilisateur à un compte fonctionne beaucoup plus rapidement (presque immédiatement).
Arrêt des connexions de messagerie temporairement ou définitivement
Le problème de la désactivation du service aux utilisateurs ne consiste pas seulement à empêcher les gens de travailler le week-end ou lorsqu’ils sont en vacances. Cela s’applique également lorsque des personnes quittent une entreprise. Au fil des années, différentes techniques ont évolué, à l’origine pour la connectivité du courrier électronique, car c’est là que le problème est apparu pour la première fois.
Étant donné qu'Exchange Online prend en charge un riche ensemble de protocoles de connectivité pour les boîtes aux lettres, vous pouvez désactiver des protocoles individuels en exécutant la cmdlet Set-CASMailbox. Dans cet exemple, nous désactivons la connectivité mobile pour une boîte aux lettres pour Exchange ActiveSync (EAS) et la technologie de synchronisation Microsoft utilisée par Outlook mobile :
Set-CASMailbox -Identity Ken.Bowers@Office365itpros.com -ActiveSyncEnabled:$False
Set-CASMailbox -Identity Ken.Bowers@Office365itpros.com -OutlookMobileEnabled:$False
Pourquoi désactiver les deux protocoles ? Outlook mobile utilise la technologie de synchronisation Microsoft pour activer de nombreuses fonctionnalités avancées telles que l'accès délégué aux boîtes aux lettres, mais d'autres clients comme les applications de messagerie incluses dans les systèmes d'exploitation iOS et Android utilisent EAS pour la connectivité de messagerie de base avec Exchange Online. Si vous ne désactivez pas les deux, vous créez une situation dans laquelle un utilisateur peut toujours se connecter à sa boîte aux lettres avec une autre application. En fait, pour être complet, vous devez également désactiver les protocoles IMAP4 et POP3 pour éliminer toute chance qu'un appareil mobile puisse se connecter à une boîte aux lettres.
La faiblesse de se concentrer sur la désactivation des protocoles est que certaines fuites d’informations peuvent toujours se produire. Prenons l'exemple d'Outlook mobile. Vous pouvez désactiver la technologie de synchronisation Microsoft pour empêcher les clients d'envoyer et de télécharger des messages sur l'appareil, mais iOS et Android utilisent tous deux des services pour informer les utilisateurs de l'arrivée de nouveaux messages. Les notifications contiennent des extraits de nouveaux messages pour permettre aux utilisateurs de décider s'ils doivent lire l'intégralité du message. Ces notifications continuent d'arriver après avoir désactivé le protocole de synchronisation.
En réalité, si vous souhaitez réellement contrôler les appareils mobiles, vous devez déployer une solution de gestion des appareils mobiles (MDM) comme Intune, qui vous permet d'effacer à distance les données d'entreprise de l'appareil si nécessaire.
Arrêt de l'accès à Office 365
Le courrier électronique n’est pas la seule application qui fait perdre du temps le week-end. Teams, Planner, Yammer, SharePoint Online et OneDrive for Business consomment tous des heures si les gens le permettent. La méthode classique pour bloquer l’accès consiste à bloquer le compte de quelqu’un. Cela peut être fait via le centre d'administration Microsoft 365 en sélectionnant le compte et en choisissant Bloquer la connexion (Figure 1).
Le blocage du compte définit la propriété AccountEnabled sur False. Lorsqu'un compte est désactivé, l'utilisateur ne peut pas se connecter à son compte :
Forcer les déconnexions des applications
Empêcher un compte de se connecter définit également la propriété RefreshTokensValidFromDateTime du compte sur la date et l'heure auxquelles l'action s'est produite. L'effet est d'invalider les jetons d'actualisation émis aux applications pour un utilisateur et les jetons émis pour les cookies de session dans les navigateurs et oblige l'utilisateur à se réauthentifier pour continuer à utiliser les applications. Le centre d'administration Microsoft 365 inclut une option permettant de déconnecter un utilisateur de toutes les sessions, vous pouvez donc le faire sans bloquer de compte.
Vous pouvez également forcer la déconnexion d'un compte avec PowerShell en exécutant la cmdlet Revoke-MgUserSignInSession :
$RevokeStatus = Revoke-MgUserSignInSession -UserId $User.IdLa réinitialisation des connexions pour un compte définit RefreshTokensValidFromDateTime sur la date et l'heure actuelles et AccountEnabled sur True. L'utilisateur peut désormais se connecter. Lorsque cela se produit, les navigateurs et les applications reçoivent de nouveaux jetons valides. Cela peut prendre jusqu'à 15 minutes avant que l'utilisateur puisse se connecter à toutes les applications.
Bloquer des comptes avec PowerShell
L'applet de commande Update-MgUser bloque l'accès à un compte utilisateur :
Update-MgUser -UserId 'Ken.Bowers@office365itpros.com' -AccountEnabled:$False
L'approche recommandée consiste à exécuter Update-MgUser pour bloquer le compte, suivi de Revoke-MgUserSignInSession pour garantir que le compte est bloqué avec une déconnexion forcée pour toutes les applications.
Implémentation d'un bloc week-end
Revenons au problème initial, à savoir comment déconnecter les utilisateurs de Microsoft 365 pour une raison ou une autre. Supposons que nous souhaitions que cela se produise uniquement pour une certaine catégorie d’utilisateurs, comme ceux qui travaillent dans un pays spécifique. Si ces personnes sont membres d’un groupe, nous pouvons utiliser ce groupe pour piloter le processus de déconnexion. Dans cet exemple, une liste de distribution définit les comptes à déconnecter :
[Array]$Accounts = Get-DistributionGroupMember -Identity "BlockWeekend" | Select WindowsLiveID, ExternalDirectoryObjectId
ForEach ($Account in $Accounts) {
Write-Host "Turning Off Office 365 Access for" $Account.WindowsLiveID
Update-MgUser -UserId $Account.ExternalDirectoryObjectId -AccountEnabled:$False
$RevokeStatus = Revoke-MgUserSignInSession -UserId $Account.ExternalDirectoryObjectId }
Une liste de distribution dynamique pourrait être un meilleur choix car l'adhésion est alors déterminée par des propriétés telles que le pays ou la ville. Pour récupérer l'ensemble des utilisateurs d'une liste de distribution dynamique, nous utilisons le filtre des destinataires de la liste pour trouver les membres :
$AccountFilter = (Get-DynamicDistributionGroup -Identity "French Country Users").RecipientFilter
[Array]$Accounts = Get-Recipient -RecipientPreviewFilter $AccountFilter | Select-Object WindowsLiveID, ExternalDirectoryObjectId
Bien sûr, vous pouvez utiliser l'applet de commande Get-MgGroupMember pour récupérer les détails des membres du groupe si vous préférez. Par exemple:
[array]$GroupId = (Get-MgGroup Filter "DisplayName eq 'BlockWeekend'").Id
[array]$GroupMembers = Get-MgGroupMember -GroupId $GroupId | Select-Object additionalProperties
$GroupMembers.displayNameCette syntaxe fonctionne avec les listes de distribution, les groupes de sécurité, les groupes Microsoft 365 et les groupes Microsoft 365 dynamiques. Cela ne fonctionne pas avec les listes de distribution dynamiques car ces objets n'existent pas dans Entra ID
La tâche de déconnexion des utilisateurs est simple. Chaque vendredi soir, nous exécutons le script PowerShell pour désactiver l'accès et exécutons un autre script pour inverser le processus le lundi matin. Le gros inconvénient est la façon dont Teams traite les comptes bloqués pour les supprimer des listes d’équipe (sans affecter l’adhésion au groupe). Si vous pouvez vivre avec ce problème pendant que Microsoft réfléchit à la manière d'améliorer la situation, le blocage des comptes pendant de courtes périodes pourrait fonctionner pour votre organisation.
Utiliser une politique d'accès conditionnel
Les stratégies d'accès conditionnel s'exécutent après qu'un utilisateur s'est authentifié avec succès pour décider s'il peut se connecter à la ressource demandée. L'appartenance à un groupe est l'une des conditions prises en charge, ce qui signifie qu'il est facile de créer une stratégie pour bloquer l'accès aux applications pour un groupe. Étant donné que nous souhaitons bloquer l’accès le week-end, nous pourrions ajouter une autre condition pour indiquer que l’accès est correct si l’utilisateur se trouve dans un lieu d’entreprise, mais pas s’il est chez lui ou ailleurs.
La figure 3 montre les grandes lignes d’une telle politique. Toute personne spécifiée dans la liste de distribution du week-end bloqué (vous pouvez également utiliser un groupe de sécurité ou un groupe Microsoft 365) est bloquée si elle tente d'accéder à une application Office 365 :
Lorsqu'un utilisateur tente d'accéder à une application est bloqué par une stratégie d'accès conditionnel, il est informé que sa connexion a réussi (l'authentification a fonctionné), mais qu'il n'est pas autorisé à accéder à la ressource :
S'ils sont déjà connectés à une application et que celle-ci tente de renouveler son jeton d'accès, la politique d'accès conditionnel bloquera l'émission du jeton. La figure 5 montre ce que l'utilisateur voit lorsque cela se produit dans Teams (l'application est très polie !) :
Contrôler les politiques d'accès conditionnel avec PowerShell
Les politiques d'accès conditionnel permettent aux organisations d'exercer un contrôle granulaire sur l'accès des utilisateurs aux applications. Dans notre scénario, nous souhaitons permettre un accès gratuit pendant la semaine. Nous pourrions désactiver la politique d'accès conditionnel pendant la semaine de travail et l'activer uniquement pour le week-end. Cela se fait facilement en modifiant la stratégie dans le centre d'administration Entra ou avec PowerShell. Par exemple, voici comment activer la stratégie :
$Policy = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'Block Weekend Access'"
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $Policy.Id -State 'Enabled'
Pour désactiver la stratégie après le week-end, exécutez :
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $Policy.Id -State 'Disabled'Modification des conditions de la politique d'accès conditionnel
Mais parce que nous voulons illustrer les possibilités qui existent pour travailler avec des politiques d'accès conditionnel via PowerShell, supposons que la politique est toujours active car elle est utilisée pendant la semaine pour limiter l'accès de certains utilisateurs (identifiés par un groupe) à certains emplacements. Au cours du week-end, nous devons mettre à jour la politique avec un autre groupe.
Les utilisateurs bloqués par une politique d'accès conditionnel sont définis comme une condition de politique. Pour voir quels utilisateurs sont concernés par une politique, nous pouvons examiner ses conditions. Nous voyons ici qu'un seul groupe est inclus dans la politique :
((Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $PolicyId).Conditions).Users | Format-List
IncludeUsers : {}
ExcludeUsers : {}
IncludeGroups : {468a9356-cf88-4189-bf85-40b096e3c37f}
ExcludeGroups : {}
IncludeRoles : {}
ExcludeRoles : {}
Nous savons qu'il s'agit d'un groupe plutôt que d'un utilisateur individuel, car il est répertorié dans la condition IncludeGroups. Le groupe est référencé par son identifiant unique (un GUID). Pour savoir quel groupe est répertorié, exécutez la cmdlet Get-MgGroup :
Get-MgGroup -GroupId 468a9356-cf88-4189-bf85-40b096e3c37f
DisplayName Id MailNickname Description GroupTypes
----------- -- ------------ ----------- ----------
Users Blocked for Weekend Access 468a9356-cf88-4189-bf85-40b096e3c37f BlockWeekend {}
Pour remplacer un groupe par un autre dans une stratégie, nous devons créer une table de hachage spécifiant l'identifiant du groupe à inclure dans la stratégie, puis appeler la cmdlet Update-MgConditionalAccessPolicy pour effectuer la modification.
Voici un exemple de code pour mettre à jour notre politique d'accès conditionnel. Vous pouvez voir que le GUID d’un groupe différent est écrit dans l’ensemble de conditions :
# Update the policy with a new group
$UpdateSettings = @{
Conditions = @{
users = @{
includeGroups = @(
"5c011293-7cc7-41c4-a0fc-3e3bb98db834"
)
}
}
}
Update-MgIdentityConditionalAccessPolicy -BodyParameter $UpdateSettings -ConditionalAccessPolicyId $Policy.IdEn quelques minutes, la politique d’accès conditionnel mise à jour est effective et le blocage est en place.
Pour inverser le processus une fois le week-end terminé, mettez à jour la stratégie avec le GUID du groupe d’origine. Consultez cet article pour plus d’informations sur la gestion des stratégies d’accès conditionnel avec PowerShell.
Options et choix
Les politiques d'accès conditionnel nécessitent des licences Entra ID P1. Si vous possédez déjà ces licences et avez donc investi dans un accès conditionnel, il n’est pas difficile d’ajouter une nouvelle politique pour contrôler l’accès le week-end. La possibilité de contrôler les politiques avec PowerShell facilite l'automatisation de l'activation ou de la désactivation automatique de l'accès.
En revanche, si vous ne disposez pas de licences Entra ID P1, vous pouvez toujours bloquer les comptes utilisateurs avec quelques lignes de PowerShell. Et si vous ne souhaitez pas bloquer l’accès et simplement rappeler aux gens qu’ils devraient travailler moins le week-end, la technique consistant à utiliser une règle de transport pour apposer des clauses de non-responsabilité sur le « droit de déconnexion » sur le courrier interne est peut-être une bonne solution.
Le choix est sympa…