Compartir a través de

El impacto de la autenticación multifactor en Azure PowerShell en escenarios de automatización

En este artículo se explora cómo afecta la autenticación multifactor (MFA) a las tareas de automatización que usan identidades de usuario de Microsoft Entra y proporciona instrucciones sobre enfoques alternativos para la automatización ininterrumpida.

Importante

Se requiere acción si usa identidades de usuario de Microsoft Entra para la automatización.

Los requisitos de MFA le impiden usar identidades de usuario de Microsoft Entra para la autenticación en escenarios de automatización. Las organizaciones deben cambiar a los métodos de autenticación diseñados para la automatización, como identidades administradas o entidades de servicio, que admiten casos de uso de automatización no interactivos.

Limitaciones de las identidades de usuario que utilizan MFA en la automatización

Nota:

Es posible que encuentre el mensaje de error: Se necesita autenticación interactiva al usar una identidad de usuario con automatización.

  • Autenticación interactiva: MFA se desencadena durante los inicios de sesión interactivos cuando se usa una identidad de usuario de Microsoft Entra. Para los scripts de automatización que dependen de una identidad de usuario, MFA interrumpe el proceso porque requiere pasos de comprobación adicionales. Por ejemplo, aplicación autenticadora, llamada telefónica, etc., que no se puede automatizar. Esta comprobación impide que la automatización se ejecute a menos que la autenticación se controle de forma no interactiva, como con una identidad administrada o una entidad de servicio.

  • Errores de inicio de sesión scriptados: En escenarios de automatización como la ejecución de scripts de Azure PowerShell de forma desatendida, una identidad de usuario habilitada para MFA provoca que el script falle al intentar autenticarse. Dado que MFA requiere interacción del usuario, no es compatible con scripts no interactivos. Esto significa que debe cambiar a una identidad administrada o a un principal de servicio, los cuales utilizan autenticación no interactiva.

  • Consideraciones de seguridad: aunque MFA agrega una capa adicional de seguridad, puede limitar la flexibilidad de automatización, especialmente en entornos de producción en los que la automatización debe ejecutarse sin intervención manual. El cambio a identidades administradas, entidades de servicio o identidades federadas, diseñadas para fines de automatización y no requieren MFA, es más práctica y segura en dichos entornos.

Escenarios que requieren actualizaciones

En la lista siguiente se proporcionan escenarios de ejemplo en los que los clientes pueden usar una identidad de usuario de Microsoft Entra para la automatización con Azure PowerShell. Esta lista no es exhaustiva de todos los escenarios.

Advertencia

Cualquier escenario de automatización que use una identidad de usuario de Microsoft Entra requiere la actualización.

  • Permisos personalizados o específicos: tareas de automatización que requieren permisos específicos del usuario, como acciones vinculadas al rol de un individuo o a atributos específicos de Id. de Microsoft Entra.

  • Flujo ROPC de OAuth 2.0: El flujo de concesión de tokens de credenciales de propietario de recursos (ROPC) de OAuth 2.0 no es compatible con MFA. Los escenarios de automatización que usan ROPC para la autenticación producen un error cuando se requiere MFA, ya que no se puede completar MFA en un flujo no interactivo.

  • Acceso a recursos externos a Azure: escenarios de automatización que requieren acceso a recursos de Microsoft 365. Por ejemplo, SharePoint, Exchange u otros servicios en la nube vinculados a la cuenta Microsoft de un usuario individual.

  • cuentas de servicio sincronizadas entre Active Directory y Microsoft Entra ID: organizaciones que usan cuentas de servicio sincronizadas desde Active Directory (AD) a Microsoft Entra ID. Es importante tener en cuenta que estas cuentas también están sujetas a requisitos de MFA y desencadenan los mismos problemas que otras identidades de usuario.

  • Contexto de usuario para auditoría o cumplimiento: casos en los que es necesario que las acciones puedan ser auditadas a nivel de usuario individual por motivos de cumplimiento.

  • Configuración sencilla para la automatización a pequeña escala o de bajo riesgo: para tareas de automatización a pequeña escala o de bajo riesgo. Por ejemplo, un script que administra algunos recursos.

  • automatización controlada por el usuario en entornos que no son de producción: si la automatización está pensada para entornos personales o no de producción en los que un usuario individual es responsable de una tarea.

  • Automatización dentro de la propia suscripción de Azure de un usuario: si un usuario necesita automatizar tareas en su propia suscripción de Azure donde el usuario ya tiene permisos suficientes.

El cambio a una identidad administrada o una entidad de servicio es necesario para escenarios de automatización debido a la obligatoriedad de la aplicación de MFA para las identidades de usuario de Microsoft Entra.

Cómo empezar

Para migrar los scripts de Azure PowerShell que usan Connect-AzAccount con una cuenta de usuario y contraseña de Microsoft Entra ID, siga estos pasos:

  1. Determine qué identidad de carga de trabajo es la mejor para usted.

    • Entidad de servicio
    • Identidad administrada
    • Identidad federada

  2. Obtenga los permisos necesarios para crear una nueva identidad de carga de trabajo o póngase en contacto con el administrador de Azure para obtener ayuda.

  3. Creación de una identidad de carga de trabajo.

  4. Asigne roles a la nueva identidad. Para más información sobre las asignaciones de roles de Azure, consulte Pasos para asignar un rol de Azure. Para asignar roles mediante Azure PowerShell, consulte Asignación de roles de Azure mediante Azure PowerShell.

  5. Actualice los scripts de Azure PowerShell para iniciar sesión con una entidad de servicio o una identidad administrada.

Conceptos clave del service principal

  • Una identidad no humana que puede acceder a varios recursos de Azure. Una entidad de servicio es utilizada por muchos recursos de Azure y no está vinculada a un único recurso de Azure.
  • Puede modificar las propiedades y las credenciales de un principal de servicio según sea necesario.
  • Ideal para las aplicaciones que necesitan acceder a varios recursos de Azure en distintas suscripciones.
  • Se considera más flexible que las identidades administradas, pero menos seguras.
  • A menudo se le conoce como un "objeto de aplicación" en un inquilino de Azure o un directorio de identificación de Microsoft Entra.

Para más información sobre las entidades de servicio, consulte:

Para obtener información sobre cómo iniciar sesión en Azure mediante Azure PowerShell y una entidad de servicio, consulte Inicio de sesión en Azure con una entidad de servicio mediante Azure PowerShell.

Conceptos clave de identidad administrada

  • Asociado a un recurso de Azure específico que permite que ese único recurso acceda a otras aplicaciones de Azure.
  • Las credenciales no son visibles para usted. Azure controla secretos, credenciales, certificados y claves.
  • Ideal para los recursos de Azure que necesitan acceder a otros recursos de Azure dentro de una sola suscripción.
  • Se considera menos flexible que las entidades de servicio, pero más seguras.
  • Hay dos tipos de identidades administradas:
    • Asignado por el sistema: este tipo es un vínculo de acceso de 1:1 (uno a uno) entre dos recursos de Azure.
    • Usuario asignado: este tipo tiene una relación de 1:M (uno a varios) en la que la identidad administrada puede acceder a varios recursos de Azure.

Para más información sobre las identidades administradas, consulte Identidades administradas para recursos de Azure.

Para obtener información sobre cómo iniciar sesión en Azure mediante Azure PowerShell y una identidad administrada, consulte Inicio de sesión en Azure con una identidad administrada mediante Azure PowerShell.

Conceptos clave de identidad federada

  • Una identidad federada permite que las entidades de servicio (registros de aplicaciones) y las identidades administradas asignadas por el usuario confíen en tokens de un proveedor de identidades externo (IdP), como GitHub o Google.
  • Una vez creada esa relación de confianza, la carga de trabajo de software externa intercambia tokens de confianza desde el IdP externo por tokens de acceso de la plataforma de identidad de Microsoft.
  • A continuación, la carga de trabajo de software utiliza ese token de acceso para acceder a los recursos protegidos de Microsoft Entra a los que se ha concedido acceso a la carga de trabajo.
  • Las identidades federadas suelen ser la mejor solución para los escenarios siguientes:
    • Carga de trabajo que se ejecuta en cualquier clúster de Kubernetes
    • Acciones de GitHub
    • Carga de trabajo que se ejecuta en plataformas de computación de Azure mediante identidades de aplicaciones
    • Google Cloud
    • Amazon Web Services (AWS)
    • Carga de trabajo que se ejecuta en plataformas de proceso fuera de Azure

Para más información sobre las identidades federadas, consulte:

Solución de problemas

Error de ROPC: debido a un cambio de configuración realizado por el administrador

Use el flujo de credenciales de contraseña del propietario del recurso (ROPC) cuando inicie sesión en Azure mediante una contraseña. Este método de autenticación no admite MFA. Este es un ejemplo:

Connect-AzAccount -Credential $Credential

Si la cuenta de usuario requiere MFA, el comando produce el siguiente error:

Connect-AzAccount : UsernamePasswordCredential authentication failed: Response status code does not indicate success: 400 (BadRequest).
See the troubleshooting guide for more information
https://aka.ms/azsdk/net/identity/usernamepasswordcredential/troubleshoot

Solución: Use un método de autenticación compatible con MFA.

Advertencia entre inquilinos: error de autenticación en el arrendatario

Si tiene acceso a varios inquilinos y uno de ellos requiere MFA, Azure PowerShell puede mostrar la advertencia siguiente:

WARNING: Unable to acquire token for tenant '00000000-0000-0000-0000-000000000000' with error 'Authentication failed against tenant 00000000-0000-0000-0000-000000000000. User interaction is required. This may be due to the conditional access policy settings such as multi-factor authentication (MFA). If you need to access subscriptions in that tenant, please rerun 'Connect-AzAccount' with additional parameter '-TenantId 00000000-0000-0000-0000-000000000000.'

Azure PowerShell intenta iniciar sesión con el primer inquilino encontrado durante el inicio de sesión. Si ese inquilino aplica MFA, es posible que se produzca un error en la autenticación. Para evitar este problema, especifique explícitamente el inquilino de destino mediante el parámetro TenantId :

Connect-AzAccount -TenantId 00000000-0000-0000-0000-000000000000

Esto garantiza que la autenticación se intente en el inquilino correcto, lo que reduce la probabilidad de errores relacionados con MFA.

Más información sobre la autenticación multifactor

El sitio de documentación de Microsoft Entra ID ofrece más detalles sobre MFA.

Consulte también