Transition vers le cloud
Après avoir aligné votre organisation sur l’arrêt de la croissance de l’empreinte Active Directory, vous pouvez vous concentrer sur le déplacement des charges de travail locales existantes vers Microsoft Entra ID. Cet article décrit les divers flux de travail de la migration. Vous pouvez exécuter les flux de travail de cet article en fonction de vos priorités et ressources.
Un flux de travail de migration typique présente les phases suivantes :
Découvrir : découvrir ce que vous avez actuellement dans votre environnement.
Tester : déployer de nouvelles fonctionnalités cloud sur une petite partie d’utilisateurs, d’applications ou d’appareils, selon le flux de travail.
Élargir : étendre le test pilote pour procéder à la transition d’une fonctionnalité au cloud.
Basculer (le cas échéant) : arrêter d’utiliser l’ancienne charge de travail locale.
Utilisateurs et groupes
Activer la réinitialisation de mot de passe en libre-service
Nous recommandons un environnement sans mot de passe. Tant que ce n’est pas le cas, vous pouvez migrer les workflows de réinitialisation de mot de passe en libre-service à partir de systèmes locaux vers Microsoft Entra ID pour simplifier votre environnement. La réinitialisation de mot de passe en libre-service (SPSPR) Microsoft Entra ID permet aux utilisateurs de changer ou de réinitialiser leur mot de passe, sans l’intervention d’un administrateur ou d’un agent du support technique.
Pour activer les fonctionnalités en libre-service, choisissez les méthodes d’authentification appropriées pour votre organisation. Une fois les méthodes d’authentification mises à jour, vous pouvez activer la fonctionnalité de mot de passe en libre-service utilisateur pour votre environnement d’authentification Microsoft Entra. Pour bénéficier de conseils de déploiement, consultez Considérations relatives au déploiement de la réinitialisation de mot de passe en libre-service Microsoft Entra.
Les considérations supplémentaires incluent :
- Déployez la Protection par mot de passe Microsoft Entra sur un sous-ensemble des contrôleurs de domaine avec le mode Audit pour collecter des informations sur l’impact des stratégies modernes.
- Activez progressivement l’inscription combinée pour SSPR et l’authentification multifacteur Microsoft Entra. Par exemple, déployez par région, filiale, département pour tous les utilisateurs.
- Procédez à un cycle de changement de mot de passe pour tous les utilisateurs afin de vous débarrasser des mots de passe faibles. Une fois le cycle terminé, implémentez l’heure d’expiration de la stratégie.
- Basculez la configuration de la protection par mot de passe dans les contrôleurs de domaine dont le mode est défini sur Appliqué. Pour plus d’informations, consultez Activer la protection par mot de passe Microsoft Entra locale.
Remarque
- La communication avec les utilisateurs finaux et l’évangélisation sont recommandées pour un déploiement fluide. Consultez les exemples de supports de déploiement SSPR.
- Si vous utilisez Microsoft Entra ID Identity Protection, activez la réinitialisation de mot de passe en tant que contrôle dans les stratégies d’accès conditionnel pour les utilisateurs marqués comme à risque.
Déplacer des groupes de gestion
Pour transformer des groupes et des listes de distribution :
Pour les groupes de sécurité, utilisez votre logique métier existante qui attribue les utilisateurs aux groupes de sécurité. Migrez la logique et la fonctionnalité vers Microsoft Entra ID et les groupes d’appartenance dynamique.
Pour les fonctionnalités de groupe auto-géré fournies par Microsoft Identity Manager, remplacez la fonctionnalité par la gestion des groupes en libre-service.
Vous pouvez convertir les listes de distribution en groupes Microsoft 365 dans Outlook. Cette approche est un excellent moyen de donner aux listes de distribution de votre organisation toutes les fonctionnalités et fonctionnalités des groupes Microsoft 365.
Mettez à niveau vos listes de distribution avec des groupes Microsoft 365 dans Outlook et désaffectez votre serveur Exchange local.
Déplacer le provisionnement des utilisateurs et des groupes vers des applications
Vous pouvez simplifier votre environnement en supprimant les flux de provisionnement d’applications des systèmes de gestion des identités (IDM) locaux tels que Microsoft Identity Manager. Selon votre découverte d’application, catégorisez votre application en fonction des caractéristiques suivantes :
Applications de votre environnement qui ont une intégration de provisionnement à la Galerie d’applications Microsoft Entra.
Applications qui ne sont pas dans la galerie mais qui prennent en charge le protocole SCIM 2.0. Ces applications sont compatibles en mode natif avec le service de provisionnement cloud Microsoft Entra.
Les applications locales qui disposent d’un connecteur ECMA sont disponibles. Ces applications peuvent être intégrées au provisionnement d’applications locales Microsoft Entra.
Pour plus d’informations, consultez Planifier un déploiement de provisionnement automatique d’utilisateurs pour Microsoft Entra ID.
Déplacer le provisionnement RH cloud
Vous pouvez réduire votre empreinte locale en déplaçant les workflows de provisionnement RH des systèmes IDM locaux, tels que Microsoft Identity Manager, vers Microsoft Entra ID. Deux types de comptes sont disponibles pour le provisionnement RH cloud Microsoft Entra :
Pour les nouveaux employés qui se servent exclusivement d’applications qui utilisent Microsoft Entra ID, vous pouvez choisir de provisionner des comptes uniquement cloud. Ce provisionnement vous permet de contenir l’empreinte d’Active Directory.
Pour les nouveaux employés qui ont besoin d’accéder aux applications qui dépendent d’Active Directory, vous pouvez provisionner des comptes hybrides.
Le provisionnement RH cloud Microsoft Entra peut également gérer les comptes Active Directory pour les employés existants. Pour plus d’informations, consultez Planifier une application RH cloud pour le provisionnement d’utilisateurs Microsoft Entra et Planifier le projet de déploiement.
Déplacer les workflows du cycle de vie
Évaluez l’applicabilité et la pertinence de vos workflows et processus d’intégration/départ/mutation existants pour votre environnement cloud Microsoft Entra. Vous pouvez ensuite simplifier ces workflows et en créer de nouveaux à l'aide des workflows de cycle de vie.
Déplacer la gestion des identités externes
Si votre organisation provisionne des comptes dans Active Directory ou d’autres annuaires locaux pour des identités externes telles que des fournisseurs, des prestataires ou des consultants, vous pouvez simplifier votre environnement en gérant ces objets utilisateur tiers en mode natif dans le cloud. Voici quelques possibilités :
Pour les nouveaux utilisateurs externes, utilisez Microsoft Entra External ID, qui arrête l’empreinte Active Directory des utilisateurs.
Pour les comptes Active Directory existants que vous provisionnez pour des identités externes, vous pouvez supprimer la surcharge de gestion des informations d’identification locales (par exemple, les mots de passe) en les configurant pour une collaboration B2B. Suivez les étapes décrites dans Inviter des utilisateurs internes à une collaboration B2B.
Utilisez la Gestion des droits d’utilisation Microsoft Entra pour accorder l’accès aux applications et aux ressources. La plupart des entreprises disposent de systèmes et de flux de travail dédiés à cet effet que vous pouvez maintenant enlever des outils locaux.
Utilisez les révisions d’accès pour supprimer les droits d’accès et/ou les identités externes qui ne sont plus nécessaires.
Appareils
Déplacer les stations de travail non-Windows
Des stations de travail non-Windows peuvent être intégrées à Microsoft Entra ID pour améliorer l’expérience utilisateur et tirer parti des fonctionnalités de sécurité basées sur le cloud telles que l’accès conditionnel.
Pour macOS :
Inscrivez macOS auprès de Microsoft Entra ID et inscrivez/gérez-les à l’aide d’une solution de gestion des appareils mobiles.
Déployez le plug-in Microsoft Enterprise SSO (authentification unique) pour les appareils Apple.
Planifiez le déploiement de l’authentification unique de plateforme pour macOS 13.
Pour Linux, vous pouvez vous connecter à une machine virtuelle Linux à l’aide des informations d’identification Microsoft Entra.
Remplacer les autres versions Windows utilisées comme station de travail
Si vous disposez des systèmes d’exploitation suivants sur des stations de travail, envisagez d’effectuer une mise à niveau vers les dernières versions pour tirer parti de la gestion native cloud (jonction Microsoft Entra et gestion unifiée des points de terminaison) :
Windows 7 oU 8.x
Windows Server
Solution VDI
Ce projet a deux initiatives principales :
Nouveaux déploiements : Déployez une solution VDI (Virtual Desktop Infrastructure) gérée par le cloud, telle que Windows 365 ou Azure Virtual Desktop, qui ne nécessite pas Active Directory local.
Déploiements existants : si votre déploiement VDI existant dépend d’Active Directory, utilisez des objectifs métier pour déterminer si vous conservez la solution ou si vous la migrez vers Microsoft Entra ID.
Pour en savoir plus, consultez :
Applications
Pour aider à conserver un environnement sécurisé, Microsoft Entra ID prend en charge les protocoles d’authentification modernes. Pour migrer l’authentification d’applications d’Active Directory vers Microsoft Entra ID, vous devez :
Déterminer quelles applications peuvent migrer vers Microsoft Entra ID sans modification.
Déterminer quelles applications ont un chemin de mise à niveau qui vous permet de migrer avec une mise à niveau.
Déterminer quelles applications nécessitent un remplacement ou des modifications de code significatives à migrer.
Le résultat de votre initiative de découverte d’application consiste à créer une liste de priorités utilisée pour migrer votre portefeuille d’applications. La liste contient également des applications qui :
Demandent une mise à niveau ou une mise à jour vers le logiciel, avec un chemin de mise à niveau disponible.
Demandent une mise à niveau ou une mise à jour vers le logiciel, sans chemin de mise à niveau disponible.
En vous aidant de la liste, vous pouvez évaluer davantage les applications qui n’ont pas de chemin de mise à niveau existant. Déterminer si la valeur métier justifie la mise à jour du logiciel ou s’il doit être retiré. Si le logiciel doit être mis hors service, déterminez si vous avez besoin d’un remplacement.
Sur la base des résultats, vous pouvez reconcevoir différents aspects de votre transformation d’Active Directory vers Microsoft Entra ID. Il existe des approches que vous pouvez utiliser pour étendre Active Directory local à l’infrastructure en tant que service (IaaS) Azure (lift-and-shift) pour les applications avec des protocoles d’authentification non pris en charge. Nous vous recommandons de définir une stratégie qui nécessite une exception pour utiliser cette approche.
Découverte des applications
Une fois que vous avez segmenté votre portefeuille d’applications, vous pouvez prioriser la migration en fonction de la valeur métier et de la priorité métier. Vous pouvez utiliser des outils pour créer ou actualiser votre inventaire des applications.
Il existe trois façons principales de catégoriser vos applications :
Applications d’authentification modernes : ces applications utilisent des protocoles d’authentification modernes (tels que OIDC, OAuth2, SAML ou WS-Federation) ou un service de fédération tel que Services ADFS (AD FS).
Outils WAM (Web Access Management) : Ces applications utilisent des en-têtes, des cookies et des techniques similaires pour l’authentification unique. Ces applications nécessitent généralement un fournisseur d’identité WAM, tel que Symantec SiteMinder.
Applications héritées : Ces applications utilisent des protocoles hérités tels que Kerberos, LDAP, Radius, Bureau à distance, NTLM (non recommandé).
Microsoft Entra ID peut être utilisé avec chaque type d’application pour fournir des niveaux de fonctionnalité qui se traduisent par différentes stratégies de migration, complexité et compromis. Certaines organisations disposent d’un inventaire des applications, qui peut être utilisé comme base de référence de découverte. (Il est courant que cet inventaire ne soit pas terminé ou mis à jour.)
Pour découvrir les applications à authentification moderne :
Si vous utilisez AD FS, utilisez le rapport d’activité d’application AD FS.
Si vous utilisez un autre fournisseur d’identité, utilisez les journaux et la configuration.
Les outils suivants peuvent vous aider à découvrir les applications qui utilisent LDAP :
Event1644Reader : Exemple d’outil permettant de collecter des données sur les requêtes LDAP effectuées sur les contrôleurs de domaine à l’aide des journaux Field Engineering.
Microsoft 365 Defender pour Identity : Solution de sécurité qui utilise une fonctionnalité de supervision des opérations de connexion. (Notez qu’il capture les liaisons à l’aide du protocole LDAP, et non du protocole LDAP sécurisé.)
PSLDAPQueryLogging : Outil GitHub pour la création de rapports sur les requêtes LDAP.
Migrer AD FS ou les autres services de fédération
Lorsque vous planifiez votre migration vers Microsoft Entra ID, envisagez d’abord de migrer les applications qui utilisent des protocoles d’authentification modernes (tels que SAML et OpenID Connect). Vous pouvez reconfigurer ces applications pour vous authentifier auprès de Microsoft Entra ID via un connecteur intégré de notre galerie d’applications Azure ou en inscrivant l’application dans Microsoft Entra ID.
Une fois que vous avez déplacé les applications SaaS qui étaient fédérées vers Microsoft Entra ID, quelques étapes sont nécessaires pour désactiver le système de fédération local :
Déplacer l’authentification des applications vers Microsoft Entra ID
Déplacer l’accès à distance aux applications internes, si vous utilisez le proxy d’application Microsoft Entra
Important
Si vous utilisez d’autres fonctionnalités, vérifiez que ces services sont déplacés avant de désactiver les Services ADFS.
Déplacer les applications d’authentification WAM
Ce projet est axé sur la migration de la capacité d’authentification unique des systèmes WAM vers Microsoft Entra ID. Pour en savoir plus, consultez Migrer des applications de Symantec SiteMinder vers Microsoft Entra ID.
Définir une stratégie de gestion des serveurs d’applications
En termes de gestion d’infrastructure, les environnements locaux ont souvent recours à un mélange d’objets de stratégie de groupe (GPO) et de fonctionnalités Microsoft Configuration Manager pour segmenter les tâches de gestion. Par exemple, les tâches peuvent être segmentées en gestion des stratégies de sécurité, gestion des mises à jour, gestion de la configuration et surveillance.
Active Directory est destiné aux environnements informatiques locaux, et Microsoft Entra ID est destiné aux environnements informatiques basés sur le cloud. La parité une-à-une des fonctionnalités n’est pas présente ici. Vous pouvez donc gérer les serveurs d’applications de plusieurs façons.
Par exemple, Azure Arc permet d’intégrer un grand nombre de fonctionnalités d’Active Directory dans une vue unique lorsque vous utilisez Microsoft Entra ID pour la gestion des identités et des accès (IAM). Vous pouvez également utiliser Microsoft Entra Domain Services pour joindre au domaine des serveurs dans Microsoft Entra ID, en particulier lorsque vous souhaitez que ces serveurs utilisent des GPO pour des raisons professionnelles ou techniques spécifiques.
Utilisez le tableau suivant pour déterminer quels outils basés sur Azure vous pouvez utiliser pour remplacer l’environnement local :
| Domaine de gestion | Fonctionnalité locale (Active Directory) | Fonctionnalité de Microsoft Entra équivalente |
|---|---|---|
| Gestion des stratégies de sécurité | GPO, Microsoft Configuration Manager | Microsoft 365 Defender for Cloud |
| Gestion des mises à jour | Microsoft Configuration Manager, Windows Server Update Services | Azure Automation Update Management |
| Gestion des configurations | GPO, Microsoft Configuration Manager | Azure Automation – State Configuration |
| Surveillance | System Center Operations Manager | Azure Monitor Log Analytics |
Voici plus d’informations que vous pouvez utiliser pour la gestion des serveurs d’applications :
Azure Arc active les fonctionnalités Azure pour des machines virtuelles non-Azure. Par exemple, vous pouvez l'utiliser pour obtenir des fonctionnalités Azure pour Windows Server lorsqu'il est utilisé sur site ou sur Amazon Web Services, ou vous authentifier sur des machines Linux avec SSH.
Gérez et sécurisez votre environnement de machine virtuelle Azure.
Si vous devez attendre pour la migration ou effectuer une migration partielle, vous pouvez utiliser des GPO avec Microsoft Entra Domain Services.
Si vous avez besoin d’une gestion des serveurs d’applications avec Microsoft Configuration Manager, vous ne pouvez pas répondre à cette exigence en utilisant Microsoft Entra Domain Services. Microsoft Configuration Manager n’est pas pris en charge pour s’exécuter dans un environnement Microsoft Entra Domain Services. Au lieu de cela, vous devez étendre votre instance Active Directory sur site à un contrôleur de domaine exécuté sur une machine virtuelle Azure. Ou, vous devez déployer une nouvelle instance Active Directory sur un réseau virtuel Azure IaaS.
Définir la stratégie de migration pour les applications héritées
Les applications héritées ont des dépendances comme celles-ci à Active Directory :
Authentification et autorisation utilisateur : Kerberos, NTLM, LDAP Bind, ACL.
Accès aux données d’annuaire : requêtes LDAP, extensions de schéma, lecture/écriture d’objets d’annuaire.
Gestion des serveurs : comme déterminé par la stratégie de gestion de serveurs.
Pour réduire ou éliminer ces dépendances, vous avez trois approches principales.
Approche 1
Avec l’approche préférée, entreprenez des projets pour migrer des applications héritées vers des alternatives SaaS qui utilisent une authentification moderne. Les alternatives SaaS s’authentifient directement auprès de Microsoft Entra ID :
Déployez Microsoft Entra Domain Services sur un réseau virtuel Azure et étendez le schéma pour incorporer des attributs supplémentaires requis par les applications.
Effectuez un lift-and-shift des applications héritées sur les machines virtuelles du réseau virtuel Azure qui sont jointes à un domaine sur Microsoft Entra Domain Services.
Publiez des applications héritées dans le cloud à l’aide du proxy d’application Microsoft Entra ou d’un partenaire d’accès hybride sécurisé.
Comme les applications héritées sont mises hors service via l’attrition, désactivez Microsoft Entra Domain Services exécuté sur le réseau virtuel Azure.
Remarque
- Utilisez Microsoft Entra Domain Services si les dépendances sont alignées avec les scénarios de déploiement courants pour Microsoft Entra Domain Services.
- Pour vérifier si Microsoft Entra Domain Services convient, vous pouvez utiliser des outils tels que Service Map sur la Place de marché Azure et le mappage automatique des dépendances avec Service Map et Live Maps.
- Vérifiez que vos instanciations SQL Server peuvent être migrées vers un autre domaine. Si votre service SQL s’exécute sur des machines virtuelles, suivez ces conseils.
Approche 2
Si la première approche n’est pas possible et qu’une application a une forte dépendance avec Active Directory, vous pouvez étendre Active Directory local à Azure IaaS.
Vous pouvez replateformer pour prendre en charge l’hébergement serverless moderne, en utilisant par exemple la plateforme en tant que service (PaaS). Vous pouvez également mettre à jour le code pour prendre en charge l’authentification moderne. Vous pouvez également autoriser l’application à s’intégrer directement à Microsoft Entra ID. Découvrez la bibliothèque d’authentification Microsoft dans le Plateforme d'identités Microsoft.
Connectez un réseau virtuel Azure au réseau local via un réseau privé virtuel (VPN) ou Azure ExpressRoute.
Déployez de nouveaux contrôleurs de domaine pour l’instance Active Directory local en tant que machines virtuelles dans le réseau virtuel Azure.
Effectuer un lift-and-shift des applications héritées sur les machines virtuelles du réseau virtuel Azure qui sont jointes à un domaine.
Publiez des applications héritées dans le cloud à l’aide du proxy d’application Microsoft Entra ou d’un partenaire d’accès hybride sécurisé.
Enfin, désactivez l’infrastructure Active Directory locale et exécuter entièrement Active Directory sur le réseau virtuel Azure.
Comme les applications héritées sont retirées à l’usure, désactivez l’instance Active Directory exécutée sur le réseau virtuel Azure.
Approche 3
Si la première migration n’est pas possible et qu’une application a une forte dépendance avec Active Directory, vous pouvez déployer une nouvelle instance Active Directory sur Azure IaaS. Laissez les applications comme applications héritées pour le moment ou supprimez -les quand l’occasion se présentera.
Cette approche vous permet de séparer l’application de l’instance Active Directory pour réduire la surface d’exposition. Nous vous recommandons de le considérer uniquement comme un dernier recours.
Déployez une nouvelle instance Active Directory en tant que machines virtuelles sur un réseau virtuel Azure.
Effectuer un lift-and-shift des applications héritées sur les machines virtuelles du réseau virtuel Azure qui sont jointes à un domaine sur la nouvelle instance Active Directory.
Publiez des applications héritées dans le cloud à l’aide du proxy d’application Microsoft Entra ou d’un partenaire d’accès hybride sécurisé.
Comme les applications héritées sont retirées à l’usure, désactivez l’instance Active Directory exécutée sur le réseau virtuel Azure.
Comparaison des stratégies
| Stratégie | Microsoft Entra Domain Services | Étendre Active Directory à IaaS | Instance Active Directory indépendante dans IaaS |
|---|---|---|---|
| Découplage d’Active Directory local | Oui | No | Oui |
| Autorisation des extensions de schéma | Non | Oui | Oui |
| Contrôle administratif complet | Non | Oui | Oui |
| Reconfiguration potentielle des applications requises (par exemple, listes de contrôle d’accès ou autorisation) | Oui | No | Oui |
Déplacer l’authentification VPN
Ce projet est axé sur le déplacement de votre authentification VPN vers Microsoft Entra ID. Il est important de savoir qu’il existe différentes configurations disponibles pour les connexions aux passerelles VPN. Vous devez déterminer la configuration qui correspond le mieux à vos besoins. Pour plus d’informations sur la conception d’une solution, consultez Conception d’une passerelle VPN.
Voici quelques points clés concernant l’utilisation de Microsoft Entra ID pour l’authentification VPN :
Vérifiez si vos fournisseurs VPN prennent en charge l’authentification moderne. Par exemple :
Pour les appareils Windows 10, envisagez d’intégrer la prise en charge de Microsoft Entra au client VPN intégré.
Après avoir évalué ce scénario, vous pouvez implémenter une solution pour supprimer votre dépendance au local pour vous authentifier auprès du VPN.
Déplacer l’accès à distance vers des applications internes
Pour simplifier votre environnement, vous pouvez utiliser le proxy d’application Microsoft Entra ou des partenaires d’accès hybride sécurisé afin de fournir un accès à distance. Cela vous permet de supprimer la dépendance vis-à-vis des solutions de proxy inverse sur site.
Il est important de mentionner que l’activation de l’accès à distance à une application à l’aide des technologies précédentes est une étape intermédiaire. Vous devez faire plus de travail pour découpler complètement l'application d'Active Directory.
Microsoft Entra Domain Services vous permet de migrer les serveurs d’applications vers IaaS cloud et de les séparer d’Active Directory, tout en utilisant un proxy d’application Microsoft Entra pour activer l’accès à distance. Pour en savoir plus sur ce scénario, consultez Déployer le proxy d’application Microsoft Entra pour Microsoft Entra Domain Services.