Problema

En entornos donde aplicaciones de terceros usan autenticación basada en Azure AD, es frecuente excluir esas apps de políticas de Conditional Access que obligan a MFA. Cuando Microsoft introduce el Baseline Scopes enforcement (una característica de preview), la exclusión tradicional puede dejar de ser suficiente. El síntoma típico es que usuarios que deberían autenticarse sin MFA reciben errores como AADSTS50076 o AADSTS50079, indicando que se requiere MFA aunque la aplicación esté excluida.

Este comportamiento afecta a cualquier cliente que utilice credenciales estáticas (usuario/contraseña) – por ejemplo, iPads que acceden a PaperCut, impresoras con autenticación LDAP‑Azure AD, o scripts automatizados que usan client‑credentials. El problema se vuelve crítico cuando ocurre de forma repentina, sin cambios visibles en la configuración de la app, y los logs de sign‑in muestran que la solicitud también está dirigida al recurso Microsoft Graph (ID 00000002-0000-0000-c000-000000000000).

En resumen, el patrón es: exclusión de app + nueva evaluación de Baseline Scopes → MFA inesperada → fallos de autenticación.

Causa

1. Evaluación dual de recursos

Con Baseline Scopes, Azure AD evalúa la solicitud contra dos recursos:

  1. El app registrado (p.ej., PaperCut Entra ID Sync).
  2. El recurso legacy Microsoft Graph (también llamado “Windows Azure Active Directory”).

Si la política de Conditional Access está configurada para requerir MFA en el recurso legacy, la exclusión de la app no cubre esa segunda evaluación. El motor de autorización interpreta que la solicitud está intentando acceder a un recurso protegido y dispara la política de MFA.

2. Políticas de Conditional Access demasiado amplias

Muchas organizaciones crean políticas basadas en grupos de usuarios (estudiantes, empleados) sin especificar explícitamente los recursos. Cuando la política incluye “All cloud apps” o “All Microsoft services”, cualquier recurso adicional introducido por Baseline Scopes queda atrapado.

3. Falta de placeholder de exclusión

El portal de Azure permite crear un app placeholder que representa “todos los recursos legacy”. Si no se excluye este placeholder, la política sigue aplicándose al segundo recurso, provocando el error.

4. Configuración de “Baseline scope settings (Preview)”

Al activar la opción Customize behavior, Azure deja la puerta abierta para que el administrador defina qué recursos deben ser excluidos. Si se deja en modo predeterminado, la exclusión automática de la app no se propaga al recurso legacy.

Solución

La solución consiste en añadir una exclusión explícita para el recurso legacy mediante un placeholder app y asegurarse de que todas las políticas de Conditional Access que requieren MFA excluyan tanto la app original como el placeholder. El proceso es reutilizable para cualquier aplicación que sufra este problema.

Paso 1: Crear un placeholder app (solo una vez por tenant)

  1. En Azure Portal, navega a Azure Active Directory → App registrations → New registration.
  2. Asigna un nombre descriptivo, por ejemplo Baseline Scopes Legacy Target.
  3. Deja la URL de redirección vacía (no se usará).
  4. Completa el registro. El Application (client) ID será necesario más adelante.

Paso 2: Añadir el placeholder a las políticas de Conditional Access

  1. Ve a Azure AD → Security → Conditional Access.
  2. Selecciona cada política que tenga MFA required (o cualquier control que cause el bloqueo).
  3. En la sección Assignments → Cloud apps or actions, elige Select apps y marca:
    • La aplicación original (p.ej., PaperCut Entra ID Sync).
    • El placeholder creado en el paso 1.
  4. Guarda los cambios.

Paso 3: Configurar Baseline Scopes (Preview) para usar la exclusión personalizada

  1. Dentro de Conditional Access, abre Baseline scope settings (Preview).
  2. Cambia el modo a Customize behavior.
  3. En Legacy target apps, selecciona el placeholder que acabas de crear.
  4. Asegúrate de que la opción Enforce baseline scopes esté activada.

Paso 4: Verificar que la exclusión funciona

  1. Inicia sesión desde el cliente problemático (iPad, script, etc.) con credenciales de usuario que pertenece al grupo excluido.
  2. Observa que la autenticación se completa sin solicitar MFA y sin errores AADSTS50076/50079.
  3. Revisa los logs de sign‑in en Azure AD; la columna Conditional Access debe mostrar grant y No MFA required para ambos recursos.

Alternativas

  • Desactivar Baseline Scopes: Si la organización no necesita la característica, puede desactivarla temporalmente en la misma sección de Baseline scope settings.
  • Crear una política de “grant” específica: En lugar de excluir, crear una política que grant access sin MFA solo para el recurso legacy y el app. Esta opción es más granular pero añade complejidad.

Cuándo aplicar esta solución

  • Síntomas: errores AADSTS50076/50079 en aplicaciones que usan autenticación username/password; logs que indican intento de acceso a Microsoft Graph además del app registrado.
  • Entorno: cualquier tenant que haya activado Baseline scope settings (Preview) y tenga políticas de MFA basadas en grupos de usuarios.
  • Escenarios típicos: dispositivos móviles (iOS/Android) que usan apps de terceros, impresoras con autenticación Azure AD, scripts de automatización que usan credenciales estáticas.

No aplicar si:

  • No se ha habilitado Baseline Scopes (la exclusión tradicional sigue funcionando).
  • La política de MFA ya está configurada con exclusiones de recursos legacy específicas.

Código

# Crear placeholder app (Azure CLI)
az ad app create --display-name "Baseline Scopes Legacy Target" --sign-in-audience AzureADMyOrg

# Obtener el clientId para usarlo en la política
APP_ID=$(az ad app list --display-name "Baseline Scopes Legacy Target" --query "[0].appId" -o tsv)

echo "Placeholder App ID: $APP_ID"

Verificación

  1. Reproducir el fallo: intenta iniciar sesión con un usuario afectado antes de aplicar la exclusión. Anota el error y el ID de recurso en los logs.
  2. Aplicar la solución siguiendo los pasos anteriores.
  3. Volver a probar la autenticación. El flujo debe completarse sin MFA y sin errores.
  4. Consultar los logs: en Azure AD → Sign‑in logs, filtra por el usuario y verifica que la columna Conditional Access muestre grant y que el Result sea Success para ambos recursos (app y Graph).

Si los logs siguen indicando MFA required para el recurso legacy, revisa que la política incluya el placeholder y que la opción Customize behavior esté activada.

Notas adicionales

  • Orden de evaluación: Azure AD evalúa primero la política de la app y luego la del placeholder. Si alguna política posterior vuelve a requerir MFA, el acceso será bloqueado. Mantén la exclusión al final de la lista de políticas.
  • Impacto en otros clientes: la exclusión del placeholder afecta a todas las apps que usan el recurso legacy. Asegúrate de que no haya otras aplicaciones que realmente necesiten MFA en ese recurso.
  • Auditoría: registra el clientId del placeholder en un documento interno. Facilita la trazabilidad y evita crear múltiples placeholders por accidente.
  • Actualizaciones futuras: Microsoft podría cambiar la forma en que Baseline Scopes se aplican. Revisa periódicamente la documentación oficial y los cambios de versión de Azure AD.

Con estos pasos, la mayoría de los fallos de autenticación provocados por la nueva evaluación de Baseline Scopes pueden resolverse de forma rápida y reutilizable, evitando interrupciones en dispositivos críticos como iPads en entornos educativos o cualquier otro cliente que dependa de credenciales estáticas.