Office 365 : comment convertir un compte synchronisé en compte Cloud ?
Sommaire
I. Présentation
Dans ce tutoriel, nous allons voir comment convertir un compte utilisateur synchronisé à partir d'un Active Directory on-premise (local) en compte Cloud sur votre tenant Office 365.
Lorsque l'on utilise Azure AD Connect, les comptes de l'Active Directory local sont synchronisés sur Office 365. Les objets synchronisés et disponibles sur le tenant Office 365 sont donc liés à ceux de l'Active Directory local. Dans certains cas, on peut avoir besoin de convertir un compte synchronisé en compte Cloud, ce qui permet de dissocier les deux comptes et de les rendre indépendants. De cette façon, on peut désactiver (voire supprimer) le compte dans l'AD local sans impacter le compte du tenant Office 365.
Vous l'aurez compris, dans cet exemple j'utilise un tenant Office 365, un domaine Active Directory et l'outil Azure AD Connect pour synchroniser mon annuaire Active Directory avec Office 365. Un grand classique !
II. Convertir un compte utilisateur synchronisé en compte Cloud
Plusieurs étapes sont nécessaires pour convertir un compte synchronisé à partir d'un Active Directory local en compte Cloud sur Office 365. L'exemple ci-dessous peut s'appliquer à un ou plusieurs utilisateurs et PowerShell sera notre allié une fois de plus pour automatiser ce processus de conversion.
A. Désynchroniser l'utilisateur d'Office 365
Le compte "[email protected]" est créé dans l'Active Directory et il est synchronisé sur le tenant Office 365. Il suffit de regarder la valeur de la colonne "État de synchronisation" pour s'en convaincre.
Dans un premier temps, nous devons désynchroniser cet utilisateur c'est-à-dire qu'il ne doit plus être dans le périmètre de la synchronisation. Deux cas de figure avec Azure AD Connect :
- Synchronisation basée sur l'appartenance à une unité d'organisation (OU) de l'AD : vous devez déplacer l'utilisateur dans une unité d'organisation qui n'est pas synchronisée.
- Synchronisation basée sur l'appartenance à un groupe de sécurité : vous devez retirer l'utilisateur du groupe en question, car seuls les membres sont synchronisés sur votre tenant.
Lorsque c'est fait, vous pouvez forcer une synchronisation d'Azure AD Connect ou patienter jusqu'à la prochaine synchronisation automatique.
Attention, cette action n'est pas sans conséquence !
Lorsqu'un utilisateur n'est plus dans le périmètre de la synchronisation, il sera supprimé du tenant Office 365 ! Autrement dit, il ira dans la corbeille en ligne de votre tenant puisqu'Azure AD Connect ne le verra plus dans l'AD local. Si le compte est en cours d'utilisation, vous devez prévenir l'utilisateur qu'il va y avoir des perturbations comme par exemple Outlook qui se déconnecte du compte.
Rassurez-vous, les données ne seront pas perdues ! Lorsqu'un compte est supprimé, il est récupérable pendant 30 jours, sans perte des données.
Une fois cette opération de désynchronisation effectuée, je ne parviens plus à trouver mon utilisateur dans les utilisateurs actifs (sur l'interface d'Office 365).
Par contre, dans les "Utilisateurs supprimés", je retrouve bien "[email protected]". Nous pouvons dire qu'il est bien désynchronisé.
Passons à la seconde étape.
B. Restaurer l'utilisateur Office 365 avec PowerShell
Nous devons restaurer l'utilisateur. Il est possible d'effectuer cette action via l'interface graphique, mais aussi en PowerShell. Via l'interface graphique, il suffit de cliquer sur l'utilisateur supprimé et de cliquer sur le bouton "Restaurer l'utilisateur".
Voyons comment faire en PowerShell, ce qui sera bien utile s'il y a de nombreux comptes concernés par l'opération. Tout d'abord, il vous faut le module MSOnline sur votre machine.
Install-Module MSOnline
Ensuite, il faut s'authentifier sur le tenant Office 365. Exécutez la commande suivante :
Connect-MsolService
Pour lister tous les utilisateurs supprimés, on utilise Get-MsolUser avec l'option -ReturnDeletedUsers et -All pour obtenir la liste complète :
Get-MsolUser -ReturnDeletedUsers -All
Pour cibler seulement "[email protected]", c'est tout simple :
Get-MsolUser -UserPrincipalName "[email protected]" -ReturnDeletedUsers
Résultat :
UserPrincipalName DisplayName isLicensed ----------------- ----------- ---------- [email protected] Utilisateur 1 True
Enfin, pour restaurer l'utilisateur il suffit de s'appuyer sur la commande prévue pour cela : Restore-MsolUser. Ce qui donne :
Restore-MsolUser -UserPrincipalName "[email protected]"
Dans le cas où l'on veut restaurer tous les utilisateurs situés dans la "Corbeille" d'Office 365 :
Get-MsolUser -ReturnDeletedUsers -All | Restore-MsolUser
On pourrait aussi faire une boucle Foreach pour restaurer une liste d'utilisateurs spécifiques, en s'appuyant sur un fichier CSV ou une liste de comptes d'une OU.
Après cette opération de restauration, l'utilisateur "[email protected]" est de retour dans les utilisateurs actifs du tenant ! Si l'on regarde l'état de synchronisation de ce compte, on peut voir que l'icône a changé : il s'agit désormais d'un compte Cloud ! C'est un succès ! 🙂
Ensuite, l'utilisateur peut se reconnecter à son compte, avec le même mot de passe (et c'est tant mieux). Par contre, vous ne devez pas remettre l'utilisateur dans le périmètre de la synchronisation Azure AD Connect afin qu'il reste indépendant de l'utilisateur Cloud.
Dernier conseil : pour vous roder, créez un compte de test. 😉
Bonsoir Florian
As tu la manipulation pour basculer d un compte cloud en synchronise ?
Merci
Hello Morgan,
Avec un compte équivalent déjà existant dans l’AD (donc plus une fusion de comptes) ou vraiment transformer un compte Cloud en compte synchronisé ?
Hello,
Pour synchroniser un compte AD avec un compte Cloud, il y a deux méthodes :
Solution 1 -> Récupérer l’ObjectGUID du compte AD, le convertir en base64, puis l’ajouter au compte Cloud ImmutableID. Synchroniser ensuite le compte AD, qui fera la fusion en hard match, sous réserve que la configuration AAD Connect ne soit pas spécifique/
Solution 2 -> Mettre les mêmes champs UserPrincipalName, email, prénom, nom au compte Cloud et compte AD, puis synchroniser les comptes, ça « devrait » fonctionner en « soft match ». En cas de problème, supprimer le compte en trop, et se référer à la solution 1 si besoin.
@Florian, pour faire « propre » et éviter toute synchronisation ultérieure, le champ ImmutableID des nouveaux comptes Cloud peut être vidé, et éviter ainsi une maladresse par la suite.
Simple question (légèrement hors sujet), je te vois régulièrement utiliser le module MSOnline, or il est recommandé d’utiliser le module AzureAD depuis déjà quelques temps vu que c’est la « V2 » du module MSOnline (plus mis à jour depuis 2 ans presque)…
Est-ce un choix de ta part ? Est-ce que tu penses qu’utiliser MSOnline est encore viable et safe aujourd’hui ?
Merci d’avance pour ta réponse et encore merci pour tes articles !
Hello 🙂
C’est vrai que je l’utilise un peu par habitude, quand j’ai besoin de faire des choses simples il ne me pose pas de soucis. Je pense (et j’espère) qu’il est encore safe, mais je te remercie pour ta remarque car dans les articles il vaut mieux montrer le bon exemple avec le module AzureAD ! 😉
Je vais mettre à jour cet article et les articles récents sur le sujet pour apporter cette précision.
Bonne soirée
Florian
Hello Adrien,
Avec le module AzureAD, tu sais comment on fait pour retrouver les commandes « Msol » comme Get-MsolUser du module MSOnline ? À moins qu’elles aient changé de nom ?
Merci 🙂
Hello,
Toutes les commandes ont changées il me semble en effet.
Ce serait plutôt Get-AzureAdUser du coup je dirais…
Un exemple via les commandes AzureAD pour attribuer une licence à un user (pour rebondir sur ton article du 01/09/2021) : https://pastebin.com/0HanbPJU
ça te fera peut-être gagner du temps ! 😀
Bonjour,
Petite question idiote mais importante, si le compte en question est « admin et propriétaire » du compte Azure, comment cela se passe ?
Je pose cette question dans le cadre d’une migration Ad on-premise vers du Full Cloud pour une petite PME.
Merci.
Bonjour As-t’on un équivalent avec MsGraph ?
A priori, il y a un bug pour utiliser $null avec Update-MgUser … donc pour supprimer l’immutableID, je ne sais pas comment faire sans utiliser MSOL …