Partage via

Transition vers le cloud

  • Article

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 :

Remarque

Déplacer des groupes de gestion

Pour transformer des groupes et des listes de distribution :

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.

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 :

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 :

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 :

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 :

  1. 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.

  2. 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.

  3. 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é.

  4. 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

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.

  1. Connectez un réseau virtuel Azure au réseau local via un réseau privé virtuel (VPN) ou Azure ExpressRoute.

  2. 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.

  3. Effectuer un lift-and-shift des applications héritées sur les machines virtuelles du réseau virtuel Azure qui sont jointes à un domaine.

  4. 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é.

  5. Enfin, désactivez l’infrastructure Active Directory locale et exécuter entièrement Active Directory sur le réseau virtuel Azure.

  6. 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.

  1. Déployez une nouvelle instance Active Directory en tant que machines virtuelles sur un réseau virtuel Azure.

  2. 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.

  3. 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é.

  4. 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 :

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.

Étapes suivantes