Ce document explique comment migrer des comptes personnels vers des comptes utilisateur gérés contrôlés par Cloud Identity ou Google Workspace.
Si votre organisation n'a jamais utilisé Cloud Identity ou Google Workspace, il est possible que certains de vos employés se servent de comptes personnels pour accéder aux services Google. Certains de ces comptes personnels peuvent utiliser une adresse e-mail professionnelle telle que alice@example.com comme adresse e-mail principale.
Les comptes personnels sont détenus et gérés par les personnes qui les ont créés. Votre organisation n'a donc aucun contrôle sur la configuration, la sécurité et le cycle de vie de ces comptes.
Avant de commencer
Pour migrer des comptes personnels vers Cloud Identity ou Google Workspace, vous devez remplir les conditions préalables suivantes :
- Vous avez identifié un plan d'intégration approprié et remplissez toutes les conditions préalables pour regrouper vos comptes utilisateur existants.
- Vous avez créé un compte Cloud Identity ou Google Workspace et avez préparé l'unité organisationnelle par défaut pour accorder l'accès approprié aux comptes utilisateur migrés.
Chaque compte personnel que vous envisagez de migrer doit répondre aux critères suivants :
- Il ne peut pas s'agir d'un compte Gmail.
- Il doit utiliser une adresse e-mail principale correspondant au domaine principal ou secondaire d'un compte Cloud Identity ou Google Workspace. Dans le cadre d'une migration de compte personnel, les adresses e-mail secondaires et les domaines d'alias sont ignorés.
- Son propriétaire doit pouvoir recevoir des e-mails sur l'adresse e-mail principale du compte.
Pour qu'un compte personnel puisse être converti en compte géré, l'utilisateur qui l'a créé doit transférer le contrôle du compte et des données associées à votre organisation. Votre entreprise peut exiger que ses employés signent et adhèrent à une politique d'utilisation acceptable de la messagerie interdisant l'usage d'adresses e-mail d'entreprise à des fins privées. Dans ce cas, vous pouvez supposer sans risque qu'un compte personnel n'est utilisé qu'à des fins professionnelles. Toutefois, si votre organisation ne dispose pas d'une telle politique ou si elle autorise un usage personnel dans une certaine mesure, le compte personnel peut être associé à une combinaison de données personnelles et professionnelles. Dans cette situation, vous ne pouvez pas forcer la migration d'un compte personnel vers un compte géré. Une migration nécessite donc toujours le consentement de l'utilisateur.
Traiter
La migration de comptes personnels vers des comptes gérés est un processus en plusieurs étapes que vous devez planifier avec soin. Les sections suivantes vous guident tout au long du processus.
Présentation du processus
L'objectif de la migration est de convertir un compte personnel en compte utilisateur géré tout en conservant l'identité du compte telle que reflétée par son adresse e-mail ainsi que les données associées au compte.
Au cours de cette migration, un compte peut posséder l'un des quatre états mentionnés dans le schéma suivant.
Lorsque vous ajoutez et validez un domaine dans Cloud Identity ou Google Workspace, tout compte personnel qui utilise une adresse e-mail associée à ce domaine devient un compte non géré. Cela n'affecte pas l'utilisateur, qui peut se connecter et accéder à ses données normalement.
L'ajout d'un domaine dans Google Workspace ou Cloud Identity ne concerne que les utilisateurs dont l'adresse e-mail correspond exactement à ce domaine. Par exemple, si vous ajoutez example.com, le compte johndoe@example.com est identifié comme un compte non géré. En revanche, le compte johndoe@corp.example.com ne l'est pas, sauf si vous ajoutez également corp.example.com au compte Cloud Identity ou Google Workspace.
En tant qu'administrateur Cloud Identity ou Google Workspace, vous pouvez voir les comptes non gérés. Vous pouvez ensuite demander à l'utilisateur de transférer son compte vers un compte géré.
Dans le schéma précédent, si l'utilisateur johndoe accepte un transfert, le compte non géré est converti en compte géré. L'identité reste la même, mais c'est Cloud Identity ou Google Workspace qui contrôle désormais le compte, y compris toutes ses données.
Si l'utilisateur johndoe n'accepte pas un transfert de données, mais que vous créez un compte dans Cloud Identity ou Google Workspace avec la même adresse e-mail, un compte en conflit est alors généré. Un compte en conflit est en réalité constitué de deux comptes (un personnel et un géré) associés à la même identité, comme dans le schéma suivant.
Un utilisateur qui se connecte à l'aide d'un compte en conflit voit un écran l'invitant à sélectionner le compte géré ou le compte personnel pour reprendre le processus de connexion.
Pour éviter de créer des comptes en conflit, il est utile de comprendre plus en détail les états de compte.
Processus détaillé
Le schéma suivant illustre les états de compte plus en détail. Les cases rectangulaires à gauche indiquent les actions qu'un administrateur Cloud Identity ou Google Workspace peut effectuer. Les cases rectangulaires à droite indiquent les activités que seul le propriétaire d'un compte personnel peut effectuer.
Rechercher des comptes utilisateur non gérés
Lors de votre inscription à Cloud Identity ou Google Workspace, vous devez fournir un nom de domaine, puis en valider la propriété. Une fois le processus d'inscription terminé, vous pouvez ajouter et valider des domaines secondaires.
En validant un domaine, vous lancez automatiquement une recherche des comptes personnels qui utilisent ce domaine dans leur adresse e-mail. Dans un délai d'environ 12 heures, ces comptes apparaissent sous la forme de comptes utilisateur non gérés dans l'outil de transfert pour les utilisateurs non gérés.
La recherche de comptes personnels prend en compte le domaine principal enregistré dans Cloud Identity ou Google Workspace, ainsi que tout domaine secondaire validé. La recherche tente de faire correspondre ces domaines à l'adresse e-mail principale des comptes personnels. En revanche, les domaines d'alias enregistrés dans Cloud Identity ou Google Workspace, ainsi que les adresses e-mail secondaires des comptes personnels, ne sont pas pris en compte.
Les utilisateurs des comptes personnels concernés ne sont pas informés que vous avez validé un domaine ou que vous avez identifié leur compte comme étant non géré. Ils peuvent continuer à utiliser leur compte normalement.
Lancer un transfert
En plus d'afficher tous les comptes non gérés, l'outil de transfert pour les utilisateurs non gérés vous permet de transférer un compte en envoyant une demande de transfert. Les comptes sont initialement répertoriés avec la mention Non invité, ce qui signifie qu'aucune demande de transfert n'a été envoyée.
Si vous sélectionnez un utilisateur et que vous envoyez une demande de transfert de compte, l'utilisateur reçoit un e-mail semblable au suivant. De plus, le compte passe à l'état Invité.
Accepter ou refuser un transfert
Après avoir reçu la demande de transfert, un utilisateur concerné peut simplement ignorer la demande et continuer à utiliser le compte normalement. Dans ce cas, vous pouvez répéter la procédure et envoyer une autre demande.
L'utilisateur peut également suivre l'e-mail, mais refuser le transfert. Il apparaît alors avec la mention Refusée dans l'outil de transfert. Si vous pensez que ce refus n'était pas intentionnel, vous pouvez répéter la procédure en envoyant une autre demande.
Dans les deux cas, les fonctionnalités du compte non géré ne sont pas altérées. Les utilisateurs peuvent se connecter et accéder à leurs données normalement. Toutefois, le processus de migration des données de compte vers Google Workspace ou Cloud Identity est entravé tant qu'un utilisateur continue d'ignorer ou de refuser une demande de transfert. Pour éviter cela, assurez-vous de communiquer votre plan de migration à vos employés avant d'envoyer les premières demandes de transfert. Veillez également à bien les informer des motifs et des conséquences liées à l'acceptation ou au refus d'une demande de transfert.
Plutôt que de refuser une demande, un utilisateur peut également modifier l'adresse e-mail du compte. Si l'utilisateur change l'adresse e-mail principale pour utiliser un domaine qui n'a pas été validé par un compte Cloud Identity ou Google Workspace, le compte redevient alors un compte personnel. Bien que l'outil de transfert puisse encore répertorier temporairement l'utilisateur en tant que compte non géré, vous ne pouvez plus transférer le compte.
Créer un compte en conflit
Si, à un moment donné, vous créez un compte utilisateur dans Cloud Identity ou Google Workspace avec la même adresse e-mail qu'un compte utilisateur non géré, la console d'administration vous avertit d'un conflit imminent :
Si vous ignorez cet avertissement et créez quand même le compte, ce nouveau compte, ainsi que le compte non géré deviennent un compte en conflit. La création d'un compte en conflit est utile si vous souhaitez supprimer un compte personnel indésirable, mais il est préférable de l'éviter si votre objectif est de migrer un compte personnel vers un compte Cloud Identity ou Google Workspace.
La création d'un compte en conflit peut se produire involontairement. Après vous être inscrit à Cloud Identity ou Google Workspace, vous pouvez décider de configurer l'authentification unique en faisant appel à un fournisseur d'identité externe tel qu'Azure Active Directory (AD) ou Active Directory. Une fois configuré, le fournisseur d'identité externe peut créer automatiquement des comptes dans Cloud Identity ou Google Workspace pour tous les utilisateurs pour lesquels vous avez activé l'authentification unique, créant par inadvertance des comptes en conflit.
Utiliser un compte en conflit
Chaque fois que l'utilisateur se connecte à l'aide d'un compte en conflit, un écran de sélection semblable au suivant s'affiche.
Lorsque l'utilisateur sélectionne la première option, le processus de connexion continue d'utiliser la partie gérée du compte en conflit. L'utilisateur est invité à saisir le mot de passe défini pour le compte géré, ou est redirigé vers le site d'un fournisseur d'identité externe si vous avez configuré l'authentification unique. Une fois authentifié, il peut utiliser le compte comme n'importe quel autre compte géré. Toutefois, comme aucune donnée n'a été transférée depuis le compte personnel d'origine, il s'agit en réalité d'un nouveau compte.
Lorsqu'il sélectionne la deuxième option, l'utilisateur est invité à modifier l'adresse e-mail de la partie personnelle du compte en conflit.
En modifiant l'adresse e-mail, l'utilisateur résout le conflit en s'assurant que le compte géré et le compte personnel ont à nouveau des identités différentes. Il dispose ainsi d'un compte personnel qui contient toutes ses données d'origine ainsi que d'un compte géré qui ne peut pas accéder aux données d'origine.
L'utilisateur peut choisir de renommer le compte ultérieurement en cliquant sur Do this later (Ignorer pour l'instant). Cette action fait passer le compte à l'état Évincé. Dans cet état, l'utilisateur voit le même écran de sélection à chaque connexion et une adresse e-mail temporaire gtempaccount.com est attribuée au compte jusqu'à ce qu'il soit renommé.
Une autre façon de résoudre le conflit consiste à supprimer le compte géré dans Cloud Identity ou Google Workspace, ou dans le fournisseur d'identité externe, s'il utilise l'authentification unique. Ainsi, l'écran de sélection ne s'affichera pas lors de la prochaine connexion avec le compte, mais l'utilisateur devra modifier l'adresse e-mail du compte.
Si l'utilisateur modifie l'adresse e-mail par une adresse e-mail privée, le compte reste un compte personnel. S'il décide de rétablir l'adresse e-mail d'entreprise d'origine, le compte redevient un compte non géré.
Effectuer un transfert
Si un utilisateur accepte le transfert, le compte s'affiche dans Cloud Identity ou Google Workspace. Il est désormais considéré comme un compte géré, et toutes les données associées au compte personnel d'origine sont transférées vers le compte géré.
Si Cloud Identity ou Google Workspace n'est pas configuré pour faire appel à un fournisseur d'identité externe pour l'authentification unique, l'utilisateur peut se connecter à l'aide de son mot de passe d'origine et continuer à utiliser son compte normalement.
Si vous exploitez l'authentification unique, l'utilisateur ne peut plus se connecter à l'aide de son mot de passe existant et est redirigé vers la page de connexion de votre fournisseur d'identité externe. Pour que cela fonctionne, le fournisseur d'identité externe doit reconnaître l'utilisateur et autoriser l'authentification unique. Dans le cas contraire, le compte est verrouillé.
Bonnes pratiques
Si vous envisagez de migrer des comptes personnels existants vers Cloud Identity ou Google Workspace, planifiez et coordonnez les étapes de migration à l'avance. Une bonne planification évite de perturber vos utilisateurs et réduit le risque de créer accidentellement des comptes en conflit.
Tenez compte des bonnes pratiques suivantes lorsque vous planifiez une migration de compte personnel :
- Si vous utilisez un fournisseur d'identité externe, veillez à configurer la gestion des comptes utilisateur et l'authentification unique de manière à ne pas gêner la migration des comptes personnels.
Informez les utilisateurs concernés avant la migration. La migration de comptes personnels vers des comptes gérés nécessite le consentement des utilisateurs et peut également les affecter personnellement s'ils ont utilisé leur compte à des fins privées. Par conséquent, il est essentiel que vous informiez les utilisateurs concernés de vos plans de migration.
Transmettez-leur les informations suivantes avant de débuter la migration :
- Motif et importance de la migration des comptes
- Impact sur les données personnelles associées aux comptes existants
- Délai dans lequel les utilisateurs peuvent s'attendre à recevoir une demande de transfert
- Délai dans lequel vous vous attendez à ce que les utilisateurs acceptent ou refusent le transfert
- Modifications concernant le processus de connexion après la migration (ne s'applique qu'à la migration avec fédération)
- Instructions permettant de transférer la propriété de fichiers Google Docs privés à un compte personnel
Si vous annoncez la migration par e-mail, certains utilisateurs peuvent supposer qu'il s'agit d'une tentative d'hameçonnage. Pour éviter ce problème, envisagez d'utiliser également un autre moyen de communication.
Pour obtenir un exemple d'e-mail d'annonce, consultez l'article Communication préalable pour la migration des comptes utilisateur.
Lancer des transferts par lots. Commencez avec un petit groupe d'environ 10 utilisateurs et augmentez la taille de votre lot au fur et à mesure.
Laissez suffisamment de temps aux utilisateurs concernés pour réagir aux demandes de transfert. N'oubliez pas que certains employés sont peut-être en vacances ou en congés parentaux et ne peuvent pas réagir rapidement.
Assurez-vous qu'en acceptant un transfert, les utilisateurs ne perdent pas l'accès aux données ou aux services Google dont ils ont besoin.
Étape suivante
- Découvrez comment évaluer les comptes utilisateur existants.
- Découvrez comment évincer des comptes personnels indésirables.