Partager via

Meilleures pratiques de migration des applications et de l’authentification vers Microsoft Entra ID

  • Article

Vous avez entendu dire qu’Azure Active Directory s’appelle désormais Microsoft Entra ID et pensez que le moment est venu de migrer vos services de fédération Active Directory (AD FS) vers l’authentification cloud (AuthN) dans Microsoft Entra ID. Lorsque vous passez en revue vos options, consultez nos nombreuses ressources pour migrer des applications vers Microsoft Entra ID, ainsi que les meilleures pratiques.

Protégez vos ressources locales avec Microsoft Defender pour Identity, jusqu’à ce que vous puissiez migrer AD FS vers Microsoft Entra ID. Vous pouvez trouver et corriger les vulnérabilités de manière proactive. Utilisez des évaluations, des analyses et des données, un scoring de priorité d’investigation utilisateur et une réponse automatique aux identités compromises. La migration vers le cloud signifie que votre organisation peut tirer parti de l’authentification moderne, comme les méthodes sans mot de passe pour s’authentifier.

Voici des raisons pour lesquelles vous pouvez choisir de ne pas migrer AD FS :

  • Votre environnement a des noms d’utilisateur plats (tels que l’ID d’employé).
  • Vous avez besoin d’autres options pour les fournisseurs d’authentification multifacteur personnalisés.
  • Vous utilisez des solutions d’authentification d’appareil à partir de systèmes de gestion des appareils mobiles (GPM) tiers comme VMware.
  • Votre AD FS est doublement alimenté avec plusieurs clouds.
  • Vous avez besoin d’isoler les réseaux.

Migrer des applications

Planifiez un déploiement de migration d’applications par étapes et sélectionnez les utilisateurs à authentifier auprès de Microsoft Entra ID pour le test. Utilisez des conseils pour planifier la migration d’applications vers Microsoft Entra ID et les ressources de migration des applications vers Microsoft Entra ID.

En savoir plus dans la vidéo suivante, Migration d’application sans effort avec Microsoft Entra ID.

Outil de migration d’applications

Actuellement en préversion, Migration d’applications AD FS pour déplacer des applications AD FS vers Microsoft Entra ID est un guide pour les administrateurs informatiques de migrer des applications basées sur les revendications AD FS d’AD FS vers Microsoft Entra ID. L'assistant de migration d'application AD FS vous offre une expérience unifiée pour découvrir, évaluer et configurer de nouvelles applications Microsoft Entra. Il fournit une configuration en un clic pour les URL SAML de base, le mappage des revendications et les affectations d’utilisateurs pour intégrer une application à Microsoft Entra ID. Les fonctionnalités suivantes fournissent une prise en charge de bout en bout de la migration d’applications AD FS locales :

  • Pour vous aider à identifier l’utilisation et l’impact de l’application, évaluez les activités de connexion des applications basées sur les revendications AD FS
  • Pour vous aider à déterminer les obstacles à la migration et les actions requises pour migrer les applications vers Microsoft Entra ID, analysez la faisabilité de la migration d'AD FS vers Microsoft Entra
  • Pour configurer automatiquement une nouvelle application Microsoft Entra pour une application AD FS, configurez les nouvelles applications Microsoft Entra avec un processus de migration d'application en un clic

Phase 1 : Découverte et étendue des applications

Quand vous découvrez des applications, incluez les applications en développement et en planification. Programmez-les de façon à utiliser Microsoft Entra ID pour s’authentifier une fois la migration terminée.

Utilisez le rapport d’activité pour déplacer des applications AD FS vers Microsoft Entra ID. Ce rapport vous permet d’identifier les applications qui peuvent être migrées vers Microsoft Entra ID. Il évalue les applications AD FS pour la compatibilité avec Microsoft Entra, vérifie les problèmes et donne des conseils sur la préparation des applications individuelles pour la migration.

Utilisez l’outil de migration d’applications AD FS vers Microsoft Entra pour collecter les applications de confiance de votre serveur AD FS et analyser la configuration. À partir de cette analyse, le rapport indique quelles applications sont éligibles pour la migration vers Microsoft Entra ID. Pour les applications non éligibles, vous pouvez consulter les raisons pour lesquelles elles ne peuvent pas être migrées.

Installez Microsoft Entra Connect pour les environnements locaux avec les agents d’intégrité AD FS Microsoft Entra Connect.

En savoir plus sur Qu’est-ce que Microsoft Entra Connect ?

Phase 2 : Classifier les applications et planifier le pilote

La classification de la migration des applications est un exercice important. Planifiez la migration d’applications et la transition en phases après avoir décidé de l’ordre dans lequel vous migrez des applications. Incluez les critères suivants dans la classification des applications :

  • Protocoles d’authentification modernes, tels que les applications SaaS (software as a service) tierces dans la galerie d’applications Microsoft Entra, mais pas via Microsoft Entra ID.
  • Protocoles d’authentification hérités à moderniser, tels que les applications SaaS tierces (pas dans la galerie, mais que vous pouvez y ajouter).
  • Les applications fédérées qui utilisent AD FS et peuvent migrer vers Microsoft Entra ID.
  • Protocoles d’authentification hérités à NE PAS moderniser. La modernisation peut exclure les protocoles derrière le Proxy d'application Web (WinSCP (WAP)) qui peuvent utiliser le Proxy d’application Microsoft Entra et les contrôleurs de réseau de distribution d'applications/de distribution d'applications qui peuvent utiliser Accès hybride sécurisé.
  • Nouvelles applications métier (LOB).
  • Les applications à déprécier peuvent avoir des fonctionnalités redondantes avec d’autres systèmes et aucun propriétaire, ni aucune utilisation dans l’entreprise.

Ne complexifiez pas les choses lorsque vous choisissez les premières applications pour la migration. Les critères peuvent inclure des applications SaaS dans la galerie qui prennent en charge plusieurs connexions de fournisseur d’identité (IdP). Il existe des applications avec un accès à l’instance de test, des applications avec des règles de revendication simples et des applications contrôlant l’accès au public.

Phase 3 : Planifier votre migration et votre test

Les outils de migration et de test comprennent le kit de ressources de migration des applications Microsoft Entra pour découvrir, classifier et migrer des applications. Reportez-vous à la liste des Didacticiels d’application SaaS et du plan de déploiement Microsoft Entra Single Sign-on (SSO) qui parcourent le processus de bout en bout.

Découvrez le proxy d'application Microsoft Entra et utilisez le plan complet de déploiement du proxy d'application Microsoft Entra. Envisagez d’utiliser l’accès hybride sécurisé (SHA) pour protéger vos applications d’authentification héritées locales et dans le cloud en les connectant à Microsoft Entra ID. Utilisez Microsoft Entra Connect pour synchroniser les utilisateurs et groupes AD FS avec Microsoft Entra ID.

Phase 4 : Planifier la gestion et les insights

Après avoir migré des applications, suivez les instructions de gestion et d’insight pour vous assurer que les utilisateurs peuvent accéder et gérer des applications en toute sécurité. Acquérir et partager des insights sur l’utilisation et l’intégrité des applications.

À partir du Centre d’administration Microsoft Entra, auditez toutes les applications à l’aide de ces méthodes :

  • Auditez les applications à l’aide de Applications d’entreprise, Audit ou accédez aux mêmes informations à partir de l’API de création de rapports Microsoft Entra pour les intégrer à vos outils préférés.
  • Affichez les autorisations d’application avec Applications d’entreprise, Autorisations pour les applications utilisant Open Authorization (OAuth)/OpenID Connect.
  • Obtenez des insights de connexion avec Applications d’entreprise, Connexions et à partir de l’API de création de rapports Microsoft Entra.
  • Visualisez l’utilisation de l’application à partir des classeurs Microsoft Entra.

Préparer l’environnement de validation

Gérez, dépannez et signalez les produits et services Microsoft Identity avec MSIdentityTools dans PowerShell Gallery. Surveillez votre infrastructure AD FS avec Microsoft Entra Connect Health. Créez des applications de test dans AD FS et générez régulièrement l'activité des utilisateurs, en surveillant l'activité dans le centre d'administration Microsoft Entra.

Lorsque vous synchronisez des objets avec Microsoft Entra ID, vérifiez les règles de revendication d’approbation de partie de confiance AD FS pour les groupes, les utilisateurs et les attributs utilisateur utilisés sur les règles de revendication disponibles dans le cloud. Vérifiez la synchronisation des conteneurs et des attributs.

Différences dans les scénarios de migration d’applications

Votre plan de migration d’applications a besoin d’une attention particulière lorsque votre environnement inclut les scénarios suivants. Suivez les liens pour obtenir des instructions supplémentaires.

Planifier le processus de migration des applications

Envisagez d’inclure les étapes suivantes à votre processus de migration des applications.

  • Clonez la configuration de l’application AD FS. Configurez une instance de test de l’application ou utilisez une application fictive sur un client Microsoft Entra de test. Mappez les paramètres AD FS aux configurations Microsoft Entra. Planifiez une restauration. Basculez l’instance de test vers Microsoft Entra ID et validez.
  • Configurez les revendications et les identificateurs. Pour confirmer et résoudre les problèmes, Imitez les applications de production. Pointez une instance de test de l’application vers l’application de test Microsoft Entra ID. Validez et dépannez l’accès en mettant à jour la configuration en fonction des besoins.
  • Préparez l’instance de production pour la migration. Ajoutez l’application de production à Microsoft Entra ID en fonction des résultats de test. Pour les applications qui autorisent plusieurs fournisseurs d’identité (IdP), configurez Microsoft Entra ID comme fournisseur d’identité ajouté à l’instance de production.
  • Changer d’instance de production pour utiliser Microsoft Entra ID. Pour les applications qui autorisent plusieurs fournisseurs d’identité simultanés, remplacez le fournisseur d’identité par défaut par Microsoft Entra ID. Sinon, configurez Microsoft Entra ID en tant que fournisseur d’identité pour l’instance de production. Mettez à jour l'instance de production pour utiliser l'application de production Microsoft Entra comme fournisseur d'identité principal.
  • Migrez la première application, exécutez des tests de migration et corrigez les problèmes. État de la migration de référence dans les rapports d’activité d’application AD FS qui fournissent des conseils sur la façon de résoudre les problèmes de migration potentiels.
  • Migrez à grande échelle. Migrez des applications et des utilisateurs en phases. Utilisez Microsoft Entra ID pour gérer les applications et les utilisateurs migrés tout en testant suffisamment l’authentification.
  • Supprimez la fédération. Vérifiez que votre batterie de serveurs AD FS n’est plus utilisée pour l’authentification. Utilisez la restauration automatique, la sauvegarde et l’exportation des configurations associées.

Migrer l’authentification

Lorsque vous préparez la migration de l’authentification, décidez quelles méthodes d’authentification sont nécessaires pour votre organisation.

Stratégies de mot de passe et d’authentification

Avec des stratégies dédiées pour AD FS local et Microsoft Entra ID, alignez les stratégies d’expiration de mot de passe localement et dans Microsoft Entra ID. Envisagez d’implémenter une stratégie de mot de passe combinée et la vérification de mot de passe faible dans Microsoft Entra ID. Après avoir basculé vers un domaine managé, les deux stratégies d’expiration de mot de passe s’appliquent.

Permettre aux utilisateurs de réinitialiser les mots de passe oubliés avec la réinitialisation de mot de passe en libre-service (SSPR) pour réduire les coûts du support technique. Limitez les méthodes d’authentification basées sur les appareils. Moderniser votre stratégie de mot de passe pour ne pas avoir d’expirations périodiques avec la possibilité de révoquer en cas de risque. Bloquez les mots de passe faibles et vérifiez les mots de passe par rapport aux listes de mots de passe interdits. Activez la protection par mot de passe pour AD FS local et le cloud.

Migrez les paramètres de stratégie hérités Microsoft Entra ID qui contrôlent séparément l’authentification multifacteur et la réinitialisation de mot de passe en libre-service vers une gestion unifiée avec la stratégie de méthodes d’authentification. Migrez les paramètres de stratégie avec un processus réversible. Vous pouvez continuer à utiliser des stratégies d’authentification multifacteur et de réinitialisation de mot de passe en libre-service à l’échelle du locataire pendant que vous configurez des méthodes d’authentification précisément pour les utilisateurs et les groupes.

Étant donné que la connexion Windows et d’autres méthodes sans mot de passe nécessitent une configuration détaillée, activez la connexion avec Microsoft Authenticator et les clés de sécurité FIDO2. Utilisez des groupes pour gérer les utilisateurs de déploiement et d’étendue.

Vous pouvez configurer l’accélération automatique de la connexion à l’aide de la découverte du domaine d’accueil. Découvrez comment utiliser la connexion d’accélération automatique permettant d’ignorer l’écran d’entrée du nom d’utilisateur et de transférer automatiquement les utilisateurs vers les points de terminaison de connexion fédérés. Empêchez l’accélération automatique de la connexion à l’aide de la stratégie de découverte du domaine d’accueil pour avoir plusieurs façons de contrôler où les utilisateurs s’authentifient et de quelle manière.

Stratégies d’expiration du compte

L’attribut accountExpires de la gestion des comptes d’utilisateur ne se synchronise pas avec Microsoft Entra ID. Par conséquent, un compte Active Directory expiré dans un environnement configuré pour la synchronisation de hachage du mot de passe est toujours actif dans Microsoft Entra ID. Utilisez un script PowerShell planifié pour désactiver les comptes d’utilisateurs Microsoft Windows Server Active Directory après leur expiration, comme l’applet de commande Set-ADUser. À l’inverse, lors de la suppression de l’expiration d’un compte Microsoft Windows Server Active Directory, réactivez le compte.

Avec Microsoft Entra ID, vous pouvez prévenir les attaques à l’aide du verrouillage intelligent. Verrouillez les comptes dans le cloud avant de les verrouiller localement pour prévenir les attaques par force brute. Ayez un intervalle plus court pour le cloud, en garantissant que le seuil sur site est au moins deux à trois fois supérieur au seuil Microsoft Entra. Définissez la durée de verrouillage de Microsoft Entra plus longue que la durée sur site. Une fois votre migration terminée, configurez la protection AD FS ESL (Extranet Smart Lockout).

Planifier le déploiement de l’accès conditionnel

La flexibilité de la stratégie d’accès conditionnel nécessite une planification minutieuse. Pour obtenir les étapes de planification, accédez à Planifier un déploiement d’accès conditionnel Microsoft Entra. Voici les points clés à garder à l’esprit :

  • Rédigez des stratégies d’accès conditionnel avec des conventions d’affectation de noms significatives
  • Utilisez une feuille de calcul de points de décision de conception avec les champs suivants :
    • Facteurs d’affectation : utilisateur, applications cloud
    • Conditions : emplacements, type d’appareil, type d’applications clientes, risque de connexion
    • Contrôles : bloc, authentification multifacteur requise, jointure hybride Microsoft Windows Server Active Directory, appareil conforme requis, type d’application cliente approuvé
  • Sélectionnez de petits ensembles d’utilisateurs test pour les stratégies d’accès conditionnel
  • Tester les stratégies d’accès conditionnel en mode rapport seul
  • Valider les stratégies d’accès conditionnel avec l’outil de stratégie « what if »
  • Utiliser des modèles d’accès conditionnel, en particulier si votre organisation est nouvelle pour l’accès conditionnel

Stratégies d’accès conditionnel

Lorsque vous terminez l’authentification de premier facteur, appliquez des stratégies d’accès conditionnel. L’accès conditionnel n’est pas une défense de première ligne pour les scénarios tels que les attaques par déni de service (DoS). Toutefois, l’accès conditionnel peut utiliser des signaux à partir de ces événements, tels que le risque de connexion et l’emplacement d’une demande pour déterminer l’accès. Le flux d’une stratégie d’accès conditionnel examine une session et ses conditions, puis il alimente les résultats dans le moteur de stratégie centrale.

Grâce à l’accès conditionnel, limitez l’accès aux applications clientes approuvées avec une authentification moderne auxquelles des stratégies Intune App Protection sont appliquées. Pour les applications clientes plus anciennes qui ne prennent peut-être pas en charge les stratégies de protection des applications, les administrateurs peuvent restreindre l’accès aux applications clientes approuvées.

Protégez automatiquement les applications en fonction des attributs. Pour modifier les attributs de sécurité personnalisés, utilisez le filtrage dynamique des applications cloud pour ajouter et supprimer l’étendue de la stratégie d’application. Utilisez des attributs de sécurité personnalisés pour cibler des applications internes Microsoft qui n’apparaissent pas dans le sélecteur d’applications de l’accès conditionnel.

Utilisez le contrôle de force d’authentification de l’accès conditionnel pour spécifier quelle combinaison de méthodes d’authentification accèdent à une ressource. Par exemple, en rendant les méthodes d’authentification résistantes au hameçonnage soient disponibles pour accéder à une ressource sensible.

Évaluez les contrôles personnalisés dans l’accès conditionnel. Les utilisateurs redirigent vers un service compatible pour répondre aux exigences d’authentification en dehors de Microsoft Entra ID. Microsoft Entra ID vérifie la réponse et, si l’utilisateur s’est authentifié ou a été validé, il progresse dans le flux d’accès conditionnel. Comme mentionné dans Modifications à venir apportées aux contrôles personnalisés, les fonctionnalités d'authentification fournies par les partenaires fonctionnent de manière transparente avec les expériences de l'administrateur et de l'utilisateur final de Microsoft Entra.

Solutions d’authentification multifacteur personnalisées

Si vous utilisez des fournisseurs d'authentification multifacteur personnalisés, envisagez de migrer du serveur Microsoft Azure Multi-Factor Authentication vers l'authentification multifacteur Microsoft Entra. Si nécessaire, utilisez l'utilitaire de migration du serveur Microsoft Azure Multi-Factor Authentication pour migrer vers l'authentification multifacteur. Personnalisez l’expérience utilisateur final avec les paramètres pour le seuil de verrouillage du compte, l’alerte de fraude et la notification.

Découvrez comment migrer vers l’authentification multifacteur et l’authentification utilisateur Microsoft Entra. Déplacez toutes les applications, le service d’authentification multifacteur et l’authentification des utilisateurs vers Microsoft Entra ID.

Vous pouvez activer l’authentification multifacteur Microsoft Entra et découvrir comment créer des stratégies d’accès conditionnel pour des groupes d’utilisateurs, configurer des conditions de stratégie qui demandent l’authentification multifacteur et tester la configuration de l’utilisateur et l’utilisation de l’authentification multifacteur.

L’extension NPS (Network Policy Server) pour l’authentification multifacteur ajoute des fonctionnalités d’authentification multifacteur basées sur le cloud à votre infrastructure d’authentification en utilisant vos serveurs. Si vous utilisez l’authentification multifacteur Microsoft Entra avec NPS, déterminez ce qui peut être migrer vers des protocoles modernes tels que SAML (Security Assertion Markup Language) et OAuth2. Évaluez le proxy d'application Microsoft Entra pour l'accès à distance et utilisez l'accès hybride sécurisé (SHA) pour protéger les applications héritées avec Microsoft Entra ID.

Surveiller les connexions

Utilisez Connect Health pour intégrer les connexions AD FS pour mettre en corrélation plusieurs ID d’événements à partir d’AD FS, selon la version du serveur, pour plus d’informations sur les détails de la demande et des erreurs. Le rapport de connexions Microsoft Entra contient des informations sur le moment où les utilisateurs, les applications et les ressources managées se connectent à Microsoft Entra ID et accèdent aux ressources. Ces informations sont mises en corrélation avec le schéma de rapport de connexion Microsoft Entra et apparaissent dans l’expérience utilisateur de rapport de connexion Microsoft Entra. Avec le rapport, un flux Log Analytics fournit des données AD FS. Utilisez et modifiez le modèle de classeur Azure Monitor pour l’analyse des scénarios. Par exemple, les verrouillages de compte AD FS, les tentatives de mot de passe incorrectes et des augmentations de tentatives de connexion inattendues.

Microsoft Entra journalise toutes les connexions dans un locataire Azure, qui inclut les applications et ressources internes. Passez en revue les erreurs et schémas de connexion pour obtenir des informations précieuses sur la façon dont vos utilisateurs accèdent aux applications et aux services. Les journaux de connexion dans Microsoft Entra ID sont des journaux d’activité utiles pour l’analyse. Configurez les journaux avec jusqu’à 30 jours de conservation des données, en fonction des licences et exportez-les vers Azure Monitor, Sentinel, Splunk et d’autres systèmes SIEM (Gestion des informations et des événements de sécurité).

Revendications dans le périmètre du réseau d’entreprise

Quelle que soit la provenance des requêtes ou les ressources auxquelles elles accèdent, le modèle Confiance Zéro nous apprend à « ne jamais faire confiance, toujours vérifier ». Sécurisez tous les emplacements comme s’ils se trouvaient en dehors du réseau d’entreprise. Déclarez les réseaux internes en tant qu’emplacements approuvés pour réduire les faux positifs de protection des identités. Appliquez l’authentification multifacteur pour tous les utilisateurs et mettez en place des stratégies d’accès conditionnel basées sur les appareils.

Exécutez une requête sur les journaux de connexion pour découvrir les utilisateurs qui se connectent depuis le réseau d’entreprise, mais qui ne sont pas conformes ou à jointure hybride Microsoft Entra. Tenez compte des utilisateurs sur des périphériques conformes et l’utilisation de navigateurs non pris en charge tels que Firefox ou Chrome sans l’extension. Utilisez plutôt le domaine de l’ordinateur et l’état de conformité.

Test et basculement de migration d’authentification par étapes

Pour les tests, utilisez l’authentification cloud Microsoft Entra Connect avec Déploiement par étapes pour contrôler l’authentification utilisateur test avec des groupes. Testez sélectivement des groupes d’utilisateurs avec des fonctionnalités d’authentification cloud telles que l’authentification multifacteur Microsoft Entra, l’accès conditionnel et Protection Microsoft Entra ID. Toutefois, n’utilisez pas le Déploiement par étapes pour les migrations incrémentielles.

Pour effectuer votre migration vers l’authentification cloud, utilisez le Déploiement par étapes pour tester les nouvelles méthodes de connexion. Convertissez les domaines d’une authentification fédérée en authentification managée. Commencez par un domaine de test ou avec le domaine contenant le moins d’utilisateurs.

Planifiez le basculement de domaine pendant les heures creuses, au cas où une restauration serait nécessaire. Pour planifier la restauration, utilisez les paramètres de fédération actuels. Consultez le Guide de conception et de déploiement de fédération.

Incluez la conversion de domaines managés en domaines fédérés dans votre processus de restauration. Utilisez le cmdlet New-MgDomainFederationConfiguration. Si nécessaire, configurez des règles de revendications supplémentaires. Pour vous assurer que le processus est terminé, attendez 24 à 48 heures après le basculement pour effectuer le déploiement par étapes de la restauration. Supprimez les utilisateurs et les groupes du déploiement par étapes, puis désactivez-le.

Après le basculement, tous les 30 jours, restaurez la clé pour l’authentification unique transparente :

Update-AzureADSSOForest -OnPremCredentials $creds -PreserveCustomPermissionsOnDesktopSsoAccount

Désaffectation d’AD FS

Surveillez l’activité AD FS à partir de Connect Health Analyse de l’utilisation pour AD FS. Tout d’abord, activez l’audit pour AD FS. Avant de désactiver la batterie de serveurs AD FS, vérifiez qu’il n’y a aucune activité AD FS. Utilisez le Guide de désactivation d’AD FS et la documentation de référence sur la désactivation d’AD FS. Voici un résumé des principales étapes de désactivation.

  1. Effectuez une sauvegarde finale avant de désactiver les serveurs AD FS.
  2. Supprimez les entrées AD FS des équilibreurs de charge internes et externes.
  3. Supprimez les entrées DNS (Domain Name Server) correspondantes pour les noms de batteries de serveurs AD FS.
  4. Sur le serveur AD FS principal, exécutez Get-ADFSProperties et recherchez CertificateSharingContainer.

    Remarque

    Supprimez le nom de domaine (DN) à la fin de l’installation, après quelques redémarrages et lorsqu’il n’est plus disponible.

  5. Supprimez la base de données de configuration AD FS si elle utilise une instance de base de données SQL Server comme magasin.
  6. Désinstallez les serveurs WAP.
  7. Désinstallez les serveurs AD FS.
  8. Supprimez les certificats SSL (Secure Sockets Layer) AD FS de chaque stockage serveur.
  9. Réinitialisez des serveurs AD FS avec un formatage complet du disque.
  10. Supprimez votre compte AD FS.
  11. Utilisez Active Directory Service Interfaces (ADSI) Edit pour supprimer le contenu du DN CertificateSharingContainer.

Étapes suivantes