Partager via

Impact de l’authentification multifacteur sur Azure CLI dans les scénarios d’automatisation

Cet article explique comment l’authentification multifacteur (MFA) affecte les tâches d’automatisation qui utilisent les identités utilisateur Microsoft Entra et fournit des conseils sur d’autres approches pour une automatisation ininterrompue.

Important

L’action est requise si vous utilisez des identités utilisateur Microsoft Entra pour l’automatisation. Les exigences MFA vous empêchent d’utiliser les identités utilisateur Microsoft Entra pour l’authentification dans les scénarios d’automatisation. Les organisations doivent passer aux méthodes d’authentification conçues pour l’automatisation, telles que les identités managées ou les principaux de service, qui prennent en charge les cas d’utilisation d’automatisation non interactive.

Limitations des identités utilisateur avec MFA dans l’automatisation

Remarque

Vous pouvez rencontrer le message d’erreur : l’authentification interactive est nécessaire lorsque vous utilisez une identité utilisateur avec automatisation.

  • Authentification interactive: L'authentification multifacteur est déclenchée pendant les connexions interactives utilisant une identité d'utilisateur Microsoft Entra. Pour les scripts d’automatisation qui s’appuient sur une identité utilisateur, l’authentification multifacteur interrompt le processus, car elle nécessite des étapes de vérification supplémentaires. Par exemple, l’application d’authentification, l’appel téléphonique, etc., que vous ne pouvez pas automatiser. Cette vérification empêche l’automatisation de s’exécuter, sauf si l’authentification est gérée de manière non interactive, par exemple avec une identité managée ou un principal de service.

  • échecs de connexion scriptés: dans des scénarios d’automatisation tels que l’exécution de scripts Azure CLI sans assistance, une identité utilisateur compatible MFA entraîne l’échec du script lors de la tentative d’authentification. Étant donné que l’authentification multifacteur nécessite une interaction utilisateur, elle n’est pas compatible avec les scripts non interactifs. Cela signifie que vous devez basculer vers une identité managée ou un principal de service, qui utilisent l’authentification non interactive.

  • considérations relatives à la sécurité: tandis que l’authentification multifacteur ajoute une couche de sécurité supplémentaire, elle peut limiter la flexibilité de l’automatisation, en particulier dans les environnements de production où l’automatisation doit s’exécuter sans intervention manuelle. Le passage aux identités managées, aux principaux de service ou aux identités fédérées, conçues à des fins d’automatisation et qui ne nécessitent pas d’authentification multifacteur, est plus pratique et sécurisée dans ces environnements.

Scénarios nécessitant des mises à jour

La liste suivante fournit des exemples de scénarios dans lesquels les clients peuvent utiliser une identité utilisateur Microsoft Entra pour l’automatisation avec Azure CLI. Cette liste n’est pas exhaustive de tous les scénarios.

Avertissement

Tout scénario d’automatisation qui utilise une identité utilisateur Microsoft Entra nécessite la mise à jour.

  • autorisations personnalisées ou spécifiques: tâches Automation nécessitant des autorisations spécifiques à l’utilisateur, telles que des actions liées au rôle d’un individu ou à des attributs Microsoft Entra ID spécifiques.

  • flux ROPC OAuth 2.0: la procédure d'octroi de jetons ROPC (Resource Owner Password Credentials) OAuth 2.0 est incompatible avec l’authentification multifacteur. Les scénarios d’automatisation utilisant ROPC pour l’authentification échouent lorsque l’authentification multifacteur est requise, car l’authentification multifacteur ne peut pas être effectuée dans un flux non interactif.

  • Accès aux ressources externes à Azure: scénarios Automation nécessitant un accès aux ressources Microsoft 365. Par exemple, SharePoint, Exchange ou d’autres services cloud liés au compte Microsoft d’un utilisateur individuel.

  • comptes de service synchronisés entre Active Directory et Microsoft Entra ID: organisations utilisant des comptes de service synchronisés à partir d’Active Directory (AD) avec l’ID Microsoft Entra. Il est important de noter que ces comptes sont également soumis aux exigences de l’authentification multifacteur et déclenchent les mêmes problèmes que les autres identités utilisateur.

  • Contexte utilisateur pour l’audit ou la conformité: cas où les actions doivent être auditées au niveau d’un utilisateur individuel pour des raisons de conformité.

  • Configuration simple pour l’automatisation à petite échelle ou à faible risque: pour les tâches d’automatisation à petite échelle ou à faible risque. Par exemple, un script qui gère quelques ressources.

  • automatisation pilotée par l’utilisateur dans les environnements hors production: si l’automatisation est destinée à des environnements personnels ou non de production où un utilisateur individuel est responsable d’une tâche.

  • Automation au sein du propre abonnement Azure d’un utilisateur: si un utilisateur doit automatiser des tâches dans son propre abonnement Azure où l’utilisateur dispose déjà d’autorisations suffisantes.

Le passage à une identité managée ou à un principal de service est nécessaire pour les scénarios d’automatisation en raison de l’application obligatoire de l’authentification multifacteur pour les identités utilisateur Microsoft Entra.

Comment commencer

Pour migrer vos scripts Azure CLI à partir de az login avec un compte d’utilisateur et un mot de passe microsoft Entra ID, procédez comme suit :

  1. Déterminez quelle identité de charge de travail vous convient le mieux.

    • Service Principal
    • Identité managée
    • Identité fédérée

  2. Obtenez les autorisations nécessaires pour créer une identité de charge de travail ou contactez votre administrateur Azure pour obtenir de l’aide.

  3. Créez l’identité de charge de travail.

  4. Attribuez des rôles à la nouvelle identité. Pour plus d’informations sur les attributions de rôles Azure, consultez Étapes d’attribution d’un rôle Azure. Pour attribuer des rôles à l’aide d’Azure CLI, consultez Attribuer des rôles Azure à l’aide d’Azure CLI.

  5. Mettez à jour vos scripts Azure CLI pour vous connecter avec un principal de service ou une identité managée.

Concepts clés de service principal

  • Identité non humaine qui peut accéder à plusieurs ressources Azure. Un principal de service est utilisé par de nombreuses ressources Azure et n’est pas lié à une seule ressource Azure.
  • Vous pouvez modifier les propriétés et les informations d’identification d’un principal de service en fonction des besoins.
  • Idéal pour les applications qui doivent accéder à plusieurs ressources Azure sur différents abonnements.
  • Considéré comme plus flexible que les identités managées, mais moins sécurisé.
  • Souvent appelé « objet d’application » dans un locataire Azure ou un répertoire Microsoft Entra ID.

Pour en savoir plus sur les principaux de service, consultez :

Pour savoir comment vous connecter à Azure à l’aide d’Azure CLI et d’un principal de service, consultez se connecter à Azure avec un principal de service à l’aide d’Azure CLI

Concepts clés d’identité managée

  • Lié à une ressource Azure spécifique permettant à cette ressource unique d’accéder à d’autres applications Azure.
  • Les informations d’identification ne sont pas visibles pour vous. Azure gère les secrets, les informations d’identification, les certificats et les clés.
  • Idéal pour les ressources Azure qui doivent accéder à d’autres ressources Azure au sein d’un seul abonnement.
  • Considérées comme moins flexibles que les entités de service, mais plus sécurisées.
  • Il existe deux types d’identités managées :
    • assigné par le système : ce type est un lien d’accès 1:1 (un à un) entre deux ressources Azure.
    • utilisateur assigné: ce type a une relation 1:M (un à plusieurs) où l'identité gérée peut accéder à plusieurs ressources Azure.

Pour en savoir plus sur les identités managées, consultez identités managées pour les ressources Azure.

Pour savoir comment vous connecter à Azure à l’aide d’Azure CLI et d’une identité managée, consultez se connecter à Azure avec une identité managée à l’aide d’Azure CLI

Concepts clés d’identité fédérée

  • Une identité fédérée permet aux principaux de service (inscriptions d’applications) et aux identités managées affectées par l’utilisateur d’approuver des jetons provenant d’un fournisseur d’identité externe (IDP), comme GitHub ou Google.
  • Une fois la relation d’approbation créée, votre logiciel externe échange des jetons de confiance provenant du fournisseur d’identité externe contre des jetons d’accès de la plateforme d’identités Microsoft.
  • Votre charge de travail logicielle utilise ce jeton d’accès pour accéder aux ressources protégées Microsoft Entra auxquelles la charge de travail a accès.
  • Les identités fédérées sont souvent la meilleure solution pour les scénarios suivants :
    • Charge de travail en cours d’exécution sur n’importe quel cluster Kubernetes
    • GitHub Actions (actions de GitHub)
    • Charge de travail exécutée sur des plateformes de calcul Azure à l’aide d’identités d’application
    • Google Cloud
    • Amazon Web Services (AWS)
    • Charge de travail s’exécutant dans des plateformes de calcul en dehors d’Azure

Pour en savoir plus sur les identités fédérées, consultez :

Résolution des problèmes

Erreur ROPC : en raison d’une modification de configuration apportée par votre administrateur

Lorsque vous essayez de vous connecter à Azure à l’aide d’un mot de passe, il s’agit du flux ROPC (Informations d’identification du mot de passe du propriétaire de la ressource). Cette méthode d’authentification n’est pas prise en charge avec l’authentification multifacteur. Voici un exemple :

az login --username $username –password $password

Si l’authentification multifacteur est requise pour l’utilisateur, la commande ci-dessus échoue avec le message d’erreur suivant :

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access ‘’. Trace ID Correlation ID: Timestamp:

solution : basculer vers l’utilisation d’une méthode d’authentification compatible avec MFA.

Avertissement interlocataire : Échec de l’authentification du locataire

Si vous avez accès à plusieurs locataires et que l’un d’eux nécessite l’authentification multifacteur, Azure CLI peut afficher un message d’avertissement similaire à celui-ci :

Authentication failed against tenant 00000000-0000-0000-0000-000000000000 'Tenant Name': AADSTSXXXXX: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000000-0000-0000-0000-000000000000'. Trace ID: 00000000-0000-0000-0000-000000000000 Correlation ID: 00000000-0000-0000-0000-000000000000 Timestamp: yyyy-mm-dd hh:mm:ss.

Pendant la phase de connexion, Azure CLI tente de se connecter avec le premier locataire trouvé. Pendant que nous travaillons à la résolution de ce problème, spécifiez l'instance que vous désirez utiliser avec le paramètre --tenant :

az login --tenant 00000000-0000-0000-0000-000000000000

En savoir plus sur l’authentification multifacteur

Le site de documentation Microsoft Entra ID offre plus d'informations sur l'authentification multi-facteur.

Voir aussi