Passer de la fédération à l’authentification cloud

Dans cet article, vous apprendrez à déployer l’authentification des utilisateurs dans le cloud avec la Synchronisation du hachage des mots de passe (PHS) ou l’Authentification directe (PTA) Azure Active Directory. Bien que nous présentions le cas d’utilisation pour le passage d’Active Directory Federation Services (AD FS) à des méthodes d’authentification cloud, ces conseils s’appliquent également à d’autres systèmes locaux.

Avant de poursuivre, nous vous suggérons de consulter notre guide sur le Choix de la méthode d’authentification appropriée et de comparer les méthodes les plus adaptées à votre organisation.

Nous vous recommandons d’utiliser PHS pour l’authentification cloud.

Déploiement par étapes

Le lancement intermédiaire est un excellent moyen de tester des groupes d’utilisateurs de manière sélective avec des fonctionnalités d’authentification cloud comme Azure AD Multi-Factor Authentication (MFA), l’accès conditionnel, Identity Protection pour les informations d’identification divulguées ou Identity Governance avant le basculement de vos domaines.

Reportez-vous au plan de mise en œuvre du déploiement par étapes pour comprendre les scénarios pris en charge et non pris en charge. Nous vous recommandons d’utiliser le déploiement par étapes pour effectuer des tests avant de découper les domaines.

Pour savoir comment configurer le déploiement par étapes, consultez le Guide interactif du déploiement par étapes (migration vers l’authentification cloud à l’aide du déploiement par étapes dans Azure AD).

Flux du processus de migration

Process flow for migrating to cloud auth

Prérequis

Avant de commencer votre migration, assurez-vous que vous respectez ces conditions préalables.

Rôles nécessaires

Pour utiliser le lancement intermédiaire, vous devez être l’administrateur général de votre locataire.

Pour activer l’authentification unique transparente sur une forêt Windows Active Directory particulière, vous devez être l’administrateur de domaine.

Passer à la version supérieure du serveur Azure AD Connect

Installez Azure Active Directory Connect (Azure AD Connect) ou mettez-le à niveau vers la dernière version. Lorsque vous passez un serveur Azure AD Connect à une édition supérieure, vous réduisez le temps nécessaire à la migration d’AD FS vers les méthodes d’authentification cloud de plusieurs heures à quelques minutes.

Documenter les paramètres de fédération actuels

Pour trouver le paramètre de fédération actuel, exécutez l’applet de commande Get-MsolDomainFederationSettings.

Vérifiez les paramètres qui peuvent avoir été personnalisés pour la conception de votre fédération et la documentation du déploiement. En particulier, recherchez les personnalisations dans PreferredAuthenticationProtocol, SupportsMfa et PromptLoginBehavior.

Sauvegarder les paramètres de fédération

Bien que ce déploiement ne modifie aucune autre partie de confiance dans votre batterie AD FS, vous pouvez sauvegarder vos paramètres :

  • Utilisez l’outil de restauration rapide AD FS de Microsoft pour restaurer une batterie existante ou en créer une nouvelle.

  • Exportez l’approbation de la partie de confiance de la plateforme d’identité Microsoft 365 et les règles de revendication personnalisées associées que vous avez ajoutées à l’aide de l’exemple PowerShell suivant :

    
    (Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-RelyingPartyTrust.xml"
    
    

Planifier le projet

Quand des échecs se produisent pour des projets reposant sur la technologie, cela provient généralement d’une disparité des attentes en ce qui concerne l’impact, les résultats et les responsabilités. Pour éviter ces écueils, assurez-vous de faire appel aux bonnes personnes, et que les rôles des parties prenantes soient bien compris.

Planifier les communications

Après la migration vers l’authentification cloud, l’expérience de connexion de l’utilisateur pour accéder à Microsoft 365 et à d’autres ressources qui sont authentifiées par Azure AD change. Les utilisateurs qui sont en dehors du réseau voient seulement la page de connexion Azure AD.

Communiquez de manière proactive avec vos utilisateurs sur ce qui va changer, à quel moment les changements seront appliqués et comment ils peuvent obtenir de l’aide en cas de problème.

Planifier la fenêtre de maintenance

Après la conversion de domaine, Azure AD peut continuer à envoyer des requêtes d’authentification héritées d’Exchange Online à vos serveurs AD FS pendant une période maximale de quatre heures. Le retard est dû au fait que le cache d’Exchange Online pour l’authentification des applications héritées peut prendre jusqu’à 4 heures pour réaliser le passage de la fédération à l’authentification cloud.

Pendant cette période de quatre heures, vous pouvez inviter les utilisateurs à fournir des informations d’identification à plusieurs reprises lors de la réauthentification à des applications qui utilisent l’authentification héritée. Bien que l’utilisateur puisse toujours s’authentifier auprès d’AD FS, Azure AD n’accepte plus le jeton émis de l’utilisateur, car cette approbation de la fédération est maintenant supprimée.

Les clients hérités (Exchange ActiveSync, Outlook 2010/2013) ne sont pas affectés, car Exchange Online conserve un cache de leurs informations d’identification pour un laps de temps défini. Le cache est utilisé pour réauthentifier l’utilisateur en mode silencieux. L’utilisateur ne doit pas retourner à AD FS. Les informations d’identification stockées sur l’appareil pour ces clients sont utilisées pour se réauthentifier eux-mêmes en mode silencieux une fois le cache effacé. Les utilisateurs ne doivent normalement pas recevoir d’invites demandant un mot de passe à la suite du processus de conversion de domaine.

Les clients d’authentification moderne (Office 2016 et Office 2013, applications iOS et Android) utilisent un jeton d’actualisation valide pour obtenir de nouveaux jetons d’accès permettant de continuer à accéder aux ressources au lieu de retourner à AD FS. Ces clients sont protégés des demandes de mot de passe résultant du processus de conversion de domaine. Les clients continuent de fonctionner sans configuration supplémentaire.

Plan de restauration

Conseil

Envisagez de planifier le basculement des domaines pendant les heures creuses en cas d’exigences de restauration.

Pour planifier la restauration, utilisez les paramètres actuels documentés de la fédération et vérifiez la documentation sur la conception et le déploiement de la fédération.

Le processus de restauration comprend la conversion des domaines managés en domaines fédérés avec l’applet de commande Convert-MSOLDomainToFederated. Si nécessaire, configurez des règles de revendications supplémentaires.

Considérations relatives à la migration

Voici les principaux éléments à prendre en compte lors de la migration.

Planifier les paramètres de personnalisation

Le fichier onload.js ne peut pas être dupliqué dans Azure AD. Si votre instance AD FS est fortement personnalisée et s’appuie sur des paramètres de personnalisation spécifiques dans le fichier onload.js, vérifiez si Azure AD peut répondre à vos besoins actuels en matière de personnalisation et planifiez en conséquence. Communiquez ces modifications à venir à vos utilisateurs.

Expérience de connexion

Vous ne pouvez pas personnaliser l’expérience de connexion Azure AD. Quelle que soit la façon dont vos utilisateurs se sont connectés précédemment, vous avez besoin d’un nom de domaine complet, comme un nom d’utilisateur principal (UPN) ou un e-mail pour vous connecter à Azure AD.

Personnalisation de l’organisation

Vous pouvez personnaliser la page de connexion Azure AD. Certaines modifications visuelles sur les pages de connexion d’AD FS doivent être attendues après la conversion.

Notes

La personnalisation de l’organisation n’est pas disponible dans les licences Azure AD gratuites, sauf si vous disposez d’une licence Microsoft 365.

Planifier les stratégies d’accès conditionnel

Évaluez si vous utilisez actuellement l’accès conditionnel pour l’authentification, ou si vous utilisez des stratégies de contrôle d’accès dans AD FS.

Vous pouvez envisager de remplacer les stratégies de contrôle d’accès AD FS par des stratégies d’accès conditionnel et des règles d’accès du client Exchange Online d’Azure AD équivalentes. Vous pouvez utiliser des groupes Azure AD ou locaux pour l’accès conditionnel.

Désactiver l’authentification héritée - En raison du risque accru associé aux protocoles d’authentification traditionnels, créez une stratégie d’accès conditionnel pour bloquer l’authentification traditionnelle.

Planifier la prise en charge de l’authentification multifacteur

Chaque domaine fédéré dans Azure AD a un indicateur SupportsMFA.

Si l’indicateur SupportsMFA a la valeur True, Azure AD redirige les utilisateurs vers AD FS ou d’autres fournisseurs de fédération pour qu’ils effectuent l’authentification multifacteur. Par exemple, si un utilisateur accède à une application pour laquelle une stratégie d’accès conditionnel nécessitant l’authentification multifacteur a été configurée, l’utilisateur est redirigé vers AD FS. L’ajout d’Azure AD MFA comme méthode d’authentification dans AD FS permet d’appeler Azure AD MFA une fois vos configurations terminées.

Si l’indicateur SupportsMFA est défini sur False, il est probable que vous n’utilisez pas l’authentification multifacteur Azure ; vous utilisez probablement des règles de réclamation sur des parties de confiance d’AD FS pour déclencher l’authentification multifacteur.

Vous pouvez vérifier l’état de votre indicateur SupportsMFA avec la cmdlet Windows PowerShell suivante :

 Get-MsolDomainFederationSettings –DomainName yourdomain.com

Notes

Le serveur Microsoft MFA est proche de la fin de sa durée de vie du support et, si vous l’utilisez, vous devez passer à Azure AD MFA. Pour plus d’informations, consultez la documentation Migrer de Microsoft MFA Server vers Azure Multi-factor Authentication . Si vous envisagez d’utiliser Azure AD Multi-Factor Authentication, nous vous recommandons une inscription combinée à la réinitialisation de mot de passe en libre-service (SSPR) et à l’authentification multifacteur pour permettre à vos utilisateurs d’inscrire leurs méthodes d’authentification en une seule fois.

Planifier l’implémentation

Cette section comprend le pré-travail avant que vous basculiez votre méthode de connexion et convertissiez les domaines.

Créer les groupes nécessaires pour le déploiement par étapes

Si vous n’utilisez pas de déploiement intermédiaire, ignorez cette étape.

Créer des groupes pour le déploiement par étapes. Vous devrez également créer des groupes pour les stratégies d’accès conditionnel si vous décidez de les ajouter.

Nous vous recommandons d’utiliser un groupe maître dans Azure AD, également appelé groupe cloud uniquement. Vous pouvez utiliser des groupes de sécurité Azure AD ou des groupes Microsoft 365 pour déplacer les utilisateurs vers l’authentification multifacteur et pour les stratégies d’accès conditionnel. Pour plus d’informations, consultez Création d’un groupe de sécurité Azure AD et Vue d’ensemble des groupes Microsoft 365 pour les administrateurs.

Les membres d’un groupe sont automatiquement activés pour le lancement intermédiaire. Les groupes dynamiques et imbriqués ne sont pas pris en charge pour le lancement intermédiaire.

Pré-travail pour l’authentification unique

La version d’authentification unique que vous utilisez dépend du système d’exploitation de votre appareil et de l’état de jointure.

Pré-travail pour PHS et PTA

Selon le choix de la méthode d’inscription, effectuez le travail préalable pour PHS ou le pour PTA.

Implémenter votre solution

Enfin, vous devez basculer la méthode de connexion sur PHS ou PTA, comme prévu, et convertir les domaines de la fédération en authentification cloud.

Utilisation du déploiement par étapes

Si vous utilisez le déploiement échelonné, suivez les étapes indiquées dans les liens ci-dessous :

  1. Activez le lancement intermédiaire d’une fonctionnalité spécifique sur votre locataire.

  2. Une fois les tests terminés, convertissez les domaines de fédérés en managés.

Sans déploiement par étapes

Vous avez deux options pour permettre ce changement :

  • Option A : Basculer à l’aide d’Azure AD Connect

    Disponible si vous avez initialement configuré votre environnement AD FS/fédéré par ping avec Azure AD Connect.

  • Option B : Basculer en utilisant Azure AD Connect et PowerShell

    Disponible si vous n’avez pas initialement configuré vos domaines fédérés à l’aide d’Azure AD Connect ou si vous utilisez des services de fédération tiers.

Pour choisir l’une de ces options, vous devez connaître vos paramètres actuels.

Vérifier les paramètres d’Azure AD Connect actuels

Connectez-vous au portail Azure AD, sélectionnez Azure AD Connect et vérifiez les paramètres USER SIGN_IN comme indiqué dans ce diagramme :

Verify current Azure AD Connect settings

Pour vérifier la configuration de la fédération :

  1. Sur votre serveur Azure AD Connect, ouvrez Azure AD Connect et sélectionnez Configurer.

  2. Sous Tâches supplémentaires  Gérer la fédération, sélectionnez Voir la configuration de la fédération.

    View manage federation

    Si la configuration d’AD FS apparaît dans cette section, vous pouvez considérer qu’AD FS a été initialement configuré à l’aide d’Azure AD Connect. Consultez l’image ci-dessous comme exemple :

    View AD FS configuration

    Si AD FS n’est pas listé dans les paramètres actuels, vous devez convertir manuellement vos domaines de l’identité fédérée à l’identité managée avec PowerShell.

Option A

Passage de la fédération à la nouvelle méthode de connexion à l’aide d’Azure AD Connect

  1. Sur votre serveur Azure AD Connect, ouvrez Azure AD Connect et sélectionnez Configurer.

  2. Sous la page Tâches supplémentaires, sélectionnez Changer de connexion utilisateur, puis sélectionnez Suivant.

    View Additional tasks

  3. Sur la page Connexion à Azure AD, saisissez vos informations d’identification d’administrateur global.

  4. Sur la page Connexion de l’utilisateur :

    • Si vous sélectionnez le bouton d’option Authentification directe, cochez Activer l’authentification unique, puis sélectionnez Suivant.

    • Si vous sélectionnez le bouton d’option Synchronisation de hachage de mot de passe, assurez-vous de cocher la case Ne pas convertir les comptes d’utilisateur. L’option est dépréciée. Cochez Activer l’authentification unique, puis sélectionnez Suivant.

    Check enable single sign-on on User sign-in page

  5. Dans la page Activer l’authentification unique, entrez les informations d’identification d’un compte d’administrateur de domaine, puis sélectionnez Suivant.

    Enable single sign-on page

    Les informations d’identification du compte d’administrateur de domaine sont nécessaires pour activer l’authentification unique fluide. Le processus effectue les actions suivantes, qui nécessitent ces autorisations élevées :

    • Un compte d’ordinateur nommé AZUREADSSO (qui représente Azure AD) est créé dans votre instance Active Directory locale.
    • La clé de déchiffrement Kerberos du compte d’ordinateur est partagée de façon sécurisée avec Azure AD.
    • Deux noms de principal du service Kerberos sont créés pour représenter les deux URL utilisées lors de la connexion à Azure AD.

    Les informations d’identification d’administrateur de domaine ne sont pas stockées dans Azure AD Connect ou Azure AD et sont ignorées une fois le processus terminé. Elles sont utilisées pour activer cette fonctionnalité.

  6. Dans la page Prêt à configurer, vérifiez que la case Démarrez le processus de synchronisation une fois la configuration terminée est cochée. Ensuite, sélectionnez Configurer.

    Ready to configure page

Important

À ce stade, tous vos domaines fédérés passent à l’authentification managée. La méthode de connexion de l’utilisateur sélectionné est la nouvelle méthode d’authentification.

  1. Dans le Portail Azure AD, sélectionnez Azure Active Directory, puis Azure AD Connect.

  2. Vérifiez ces paramètres :

    • Fédération est défini sur Désactivé.
    • Authentification unique fluide est défini sur Activé.
    • Synchronisation de hachage de mot de passe est défini sur Activé.

 Reverify current user settings

  1. Si vous passez à PTA, effectuez les étapes suivantes.
Déployer davantage d’agents d’authentification pour PTA

Notes

Pour bénéficier de l’authentification directe, vous devez déployer des agents légers sur le serveur Azure AD Connect et sur vos serveurs locaux qui exécutent Windows Server. Pour réduire la latence, installez les agents aussi près que possible de vos contrôleurs de domaine Active Directory.

Pour la plupart des clients, deux ou trois agents d’authentification suffisent à offrir la haute disponibilité et la capacité nécessaire. Un locataire peut avoir un maximum de 12 agents inscrits. Le premier agent est toujours installé sur le serveur Azure AD Connect lui-même. Pour en savoir plus sur les limitations de l’agent et sur les options de déploiement des agents, consultez Authentification directe Azure AD : Limitations actuelles.

  1. Sélectionnez Authentification directe.

  2. Dans la page Authentification directe, sélectionnez le bouton Télécharger.

  3. Dans la page Télécharger l’agent, sélectionnez Accepter les conditions et télécharger.

    Le téléchargement des agents d’authentification supplémentaires démarre. Installez l’agent d’authentification secondaire sur un serveur joint à un domaine.

  4. Exécutez l’installation de l’agent d’authentification. Lors de l’installation, vous devez fournir les informations d’identification d’un compte d’administrateur général.

     Microsoft Azure AD Connect Authentication Agent

  5. Lorsque l’agent d’authentification est installé, vous pouvez revenir à la page d’intégrité de PTA pour vérifier l’état des autres agents.

Option B

Passage de la fédération à la nouvelle méthode de connexion à l’aide d’Azure AD Connect et de PowerShell

Disponible si vous n’avez pas initialement configuré vos domaines fédérés à l’aide d’Azure AD Connect ou si vous utilisez des services de fédération tiers.

Sur votre serveur Azure AD Connect, suivez les étapes 1 à 5 de l’Option A. Vous remarquerez que sur la page de connexion de l’utilisateur, l’option Ne pas configurer est présélectionnée.

 See Do not Configure option on the user sign-in page

  1. Dans le Portail Azure AD, sélectionnez Azure Active Directory, puis Azure AD Connect.

  2. Vérifiez ces paramètres :

  • Fédération est défini sur Activé.

  • Authentification unique fluide est défini sur Désactivé.

  • Synchronisation de hachage de mot de passe est défini sur Activé.

     Verify current user settings on the Azure portal

Dans le cas de PTA uniquement, suivez ces étapes pour installer d’autres serveurs agents PTA.

  1. Dans le Portail Azure AD, sélectionnez Azure Active Directory, puis Azure AD Connect.

  2. Sélectionnez Authentification directe. Vérifiez que l’état est Actif.

     Pass-through authentication settings

    Si l’agent d’authentification n’est pas actif, suivez ces étapes de dépannage avant de passer au processus de conversion du domaine de l’étape suivante. Si vous convertissez vos domaines avant de vérifier que vos agents d’authentification directe ont bien été installés et qu’ils sont à l’état Actif dans le portail Azure, vous risquez de provoquer une interruption de l’authentification.

  3. Déployez davantage d’agents d’authentification.

Convertir les domaines fédérés en domaines managés

À ce stade, l’authentification fédérée est toujours active et opérationnelle pour vos domaines. Pour poursuivre le déploiement, vous devez convertir chaque domaine de l’identité fédérée en identité managée.

Important

Vous n’êtes pas obligé de convertir tous les domaines en même temps. Vous pouvez choisir de démarrer avec un domaine de test sur votre locataire de production ou de démarrer avec votre domaine qui a le plus petit nombre d’utilisateurs.

Effectuez la conversion en utilisant le module PowerShell Azure AD :

  1. Dans PowerShell, connectez-vous au portail Azure en utilisant un compte d’administrateur général.

  2. Pour convertir le premier domaine, exécutez la commande suivante :

     Set-MsolDomainAuthentication -Authentication Managed -DomainName <domain name>
    

    Consultez Set-MsolDomainAuthentication

  3. Dans le portail Azure AD, sélectionnez Azure Active Directory  Azure AD Connect.

  4. Vérifiez que le domaine a été converti en domaine managé en exécutant la commande suivante :

    Get-MsolDomain -DomainName <domain name>
    

Terminer votre migration

Effectuez les tâches suivantes pour vérifier la méthode d’inscription et terminer le processus de conversion.

Tester la nouvelle méthode de connexion

Quand votre locataire utilisait l’identité fédérée, les utilisateurs étaient redirigés de la page de connexion d’Azure AD vers votre environnement AD FS. Maintenant que le locataire est configuré pour utiliser la nouvelle méthode de connexion au lieu de l’authentification fédérée, les utilisateurs ne sont pas redirigés vers AD FS.

Au lieu de cela, ils se connectent directement sur la page de connexion d’Azure AD.

Suivez les étapes de ce lien : Valider la connexion avec PHS/PTA et l’authentification unique fluide (si nécessaire)

Supprimer un utilisateur du lancement intermédiaire

Si vous avez utilisé le déploiement par étapes, n’oubliez pas de désactiver les fonctionnalités de lancement intermédiaire une fois que vous avez terminé le basculement.

Pour désactiver la fonctionnalité de déploiement intermédiaire, assurez-vous que le contrôle est sur Désactiver.

Synchroniser les mises à jour de userPrincipalName

Historiquement, les mises à jour de l’attribut UserPrincipalName, qui utilise le service de synchronisation à partir de l’environnement local, sont bloquées sauf si les deux conditions suivantes sont remplies :

  • L’utilisateur est dans un domaine d’identité (non fédérée) managée.
  • Aucune licence n’a été affectée à l’utilisateur.

Pour savoir comment vérifier ou activer cette fonctionnalité, consultez Synchroniser les mises à jour de userPrincipalName.

Gérer l’implémentation

Substituer la clé de déchiffrement Kerberos pour l’authentification unique fluide

Nous vous recommandons de changer la clé de déchiffrement Kerberos au moins tous les 30 jours, pour vous aligner sur la façon dont les membres du domaine Active Directory soumettent des changements de mot de passe. Comme aucun appareil n’est associé à l’objet de compte d’ordinateur AZUREADSSO, vous devez effectuer ce changement de clé manuellement.

Voir la FAQ : Comment puis-je substituer la clé de déchiffrement Kerberos du compte d’ordinateur AZUREADSSO ?.

Surveillance et journalisation

Surveillez les serveurs qui exécutent les agents d’authentification pour conserver la disponibilité de la solution. En plus des compteurs de performance généraux du serveur, les agents d’authentification exposent des objets de performance qui peuvent être utilisés pour comprendre les erreurs et les statistiques associées à l’authentification.

Les agents d’authentification consignent les opérations dans les journaux des événements Windows sous Application and Service Logs. Vous pouvez également activer la journalisation pour le dépannage.

Pour confirmer les différentes actions effectuées lors du déploiement par étapes, vous pouvez Vérifier les événements pour PHS, PTA ou authentification unique fluide.

Dépanner

Votre équipe de support doit comprendre comment résoudre les problèmes d’authentification qui surviennent pendant ou après le passage de l’authentification fédérée à l’authentification managée. Utilisez la documentation de dépannage suivante pour aider votre équipe de support à se familiariser avec les procédures de dépannage courantes, et les mesures à prendre pour isoler et résoudre le problème.

Désactiver l’infrastructure AD FS

Migrer l’authentification des applications d’AD FS vers Azure AD

La migration exige l’évaluation de la configuration locale de l’application, puis le mappage de cette configuration dans Azure AD.

Si vous envisagez de continuer à utiliser AD FS avec des applications locale et SaaS à l’aide de SAML/WS-FED ou du protocole OAuth, vous utiliserez à la fois AD ​​FS et Azure AD après avoir converti les domaines pour l’authentification utilisateur. Dans ce cas, vous pouvez protéger vos applications et ressources locales avec Secure Hybrid Access (SHA) via le Proxy d’application Azure AD ou l’une des intégrations partenaires d’Azure AD. À l’aide du Proxy d’application ou d’un de nos partenaires, vous pouvez fournir un accès à distance sécurisé à vos applications locales. Les utilisateurs bénéficient d’une connexion facile à leurs applications à partir de n’importe quel appareil après une authentification unique.

Vous pouvez déplacer les applications SaaS actuellement fédérées avec ADFS sur Azure AD. Reconfigurez pour vous authentifier auprès d’Azure AD via un connecteur intégré de notre galerie d’applications Azure App, ou en inscrivant l’application dans Azure AD.

Pour plus d’informations, consultez –

Supprimer une approbation de partie de confiance

Si vous disposez d’Azure AD Connect Health, vous pouvez surveiller l’utilisation depuis le portail Azure. Si l’utilisation ne montre aucune nouvelle requête d’authentification et après avoir vérifié le bon fonctionnement de l’authentification de tous les utilisateurs et clients via Azure AD, vous pouvez supprimer sans danger l’approbation de partie de confiance de Microsoft 365.

Si vous n’utilisez pas AD FS à d’autres fins (c’est-à-dire pour d’autres approbations de partie de confiance), vous pouvez mettre AD FS hors service sans problème.

Étapes suivantes