Exigir la autenticación multifactor (MFA) para el inquilino del asociado

  • Artículo

Roles adecuados: Agente de administración | Agente de ventas | Agente de soporte técnico | Administrador de facturación | Administrador global

La seguridad y las medidas de seguridad y privacidad continuas se encuentran entre nuestras prioridades principales y seguimos contribuyendo a que los asociados protejan a sus clientes e inquilinos.

Para ayudar a los asociados a proteger sus negocios y clientes frente al robo de identidad y el acceso no autorizado, activamos más medidas de seguridad para los inquilinos de asociados. Estas medidas de seguridad exigen y comprueban la MFA. El mandato de MFA ayuda a los asociados a proteger su acceso a los recursos de los clientes frente a los riesgos de las credenciales.

En este artículo se proporcionan ejemplos detallados e instrucciones para exigir la autenticación multifactor (MFA) en el Centro de partners.

Los partners que participan en el programa Proveedor de soluciones en la nube (CSP), los proveedores de Panel de control (CPV) y los asesores deben implementar los requisitos de seguridad de los partners para mantenerse conformes.

Los partners tienen la obligación de aplicar MFA a todas las cuentas de usuario de su inquilino de partner, incluidos los usuarios invitados. Los usuarios deben completar la comprobación de MFA para las siguientes áreas:

Centro de partners

Algunas páginas del Centro de partners están protegidas con MFA, entre las que se incluyen:

  • Todas las páginas de la pestaña Clientes (es decir, todas las páginas con una dirección URL que comienza por https://partner.microsoft.com/commerce/*)
  • Todas las páginas de la pestaña Solicitudes al cliente de soporte>técnico (por ejemplo, todas las páginas a las que se accede con una dirección URL que comienza por https://partner.microsoft.com/dashboard/v2/support/customers/*)
  • Todas las páginas de la pestaña Facturación

Otras páginas del Centro de partners, como la página Información general y la página de comprobación de estado del servicio, no requieren MFA.

En la tabla siguiente se muestran los tipos de usuario autorizados para acceder a estas páginas protegidas por MFA (y se ven afectadas por esta característica).

Páginas protegidas con MFA Agentes administradores Agentes de ventas Agentes del departamento de soporte técnico Administrador global Administrador de facturación
Todas las páginas de la pestaña Clientes x x x
Todas las páginas de la pestaña Solicitudes al cliente de soporte > técnico x x
Página facturación x x x

Para acceder a estas páginas, primero debe completar la comprobación de MFA.

Opciones de MFA admitidas

  • Asociados que usan la autenticación multifactor de Microsoft Entra compatible con Microsoft. Para obtener más información, consulte Varias formas de habilitar la autenticación multifactor de Microsoft Entra (compatible con MFA).
  • Asociados que implementaron la autenticación federada de MFA integrada. Estos usuarios asociados pueden acceder al Centro de partners y administrar los clientes mediante GDAP. Consulte los proveedores de MFA integrados con ofertas de MFA disponibles con AD FS: Configurar métodos para AD FS.

Importante

Los asociados deben usar un proveedor de autenticación compatible con la notificación MFA integrada de Microsoft Entra ID. La notificación integrada indica el tipo de credencial real proporcionado durante la autenticación. Los asociados deben usar MFA integrado para administrar los inquilinos del cliente con GDAP.

Centro de partners y API

Para las siguientes API del Centro de partners, se requiere el acceso de app+usuario y MFA de compatibilidad con id. de Microsoft Entra:

  • Descubrir (precio/catálogo/promoción)
  • Transacción y administración
  • Facturación y conciliación
  • Administración de clientes mediante acceso delegado/AOBO
  • Asignación de usuarios y licencias (solo con DAP)
  • Asignación de usuarios y licencias (con GDAP)
  • Asignación de acceso y solicitud de relaciones de administrador pormenorizadas

Las siguientes opciones están disponibles para asociados:

Ejemplos de verificación

Para ilustrar cómo funciona la comprobación en el Centro de partners, tenga en cuenta los ejemplos siguientes.

Ejemplo 1: Partner ha implementado la autenticación multifactor de Microsoft Entra

  1. Alejandra trabaja para un CSP denominado Contoso. Contoso ha implementado MFA para todos sus usuarios en el inquilino del asociado de Contoso mediante la autenticación multifactor de Microsoft Entra.

  2. Alejandra inicia una nueva sesión del explorador y va a la página de información general del Centro de partners (que no está protegida con MFA). El Centro de partners redirige a Alejandra a Microsoft Entra ID para iniciar sesión.

  3. Debido a la configuración de autenticación multifactor de Microsoft Entra existente por Contoso, Se requiere Alejandra para completar la comprobación de MFA. Tras el inicio de sesión correcto y la comprobación de MFA, Alejandra se redirige de nuevo a la página de información general del Centro de partners.

  4. Alejandra intenta acceder a una de las páginas protegidas por MFA en el Centro de partners. Dado que Alejandra ha completado la comprobación de MFA durante el inicio de sesión anterior, Alejandra puede acceder a la página protegida con MFA sin necesidad de volver a realizar la comprobación de MFA.

Ejemplo 2: El asociado ha implementado MFA que no es de Microsoft mediante la federación de identidades

  1. Prashob trabaja para un CSP denominado Wingtip. Wingtip ha implementado MFA para todos sus usuarios en el inquilino del asociado de Wingtip mediante MFA que no es de Microsoft, que se integra con el identificador de Microsoft Entra a través de la federación de identidades.

  2. Prashob inicia una nueva sesión del explorador y va a la página de información general del Centro de partners (que no está protegida con MFA). El Centro de partners redirige Prashob a Microsoft Entra ID para iniciar sesión.

  3. Dado que Wingtip ha configurado la federación de identidades, Microsoft Entra ID redirige Prashob al proveedor de identidades federado para completar el inicio de sesión y la comprobación de MFA. Una vez que el inicio de sesión y la comprobación de MFA se han realizado correctamente, Prashob se redirige a Microsoft Entra ID y, a continuación, a la página de información general del Centro de partners.

  4. Prashob intenta acceder a una de las páginas protegidas por MFA del Centro de partners. Dado que Prashob ya ha completado la comprobación de MFA durante el inicio de sesión anterior, puede acceder a la página protegida de MFA sin necesidad de volver a realizar la comprobación de MFA.

  5. Prashob va a la página de administración de servicios para agregar usuarios al identificador de Microsoft Entra de Contoso. Dado que Prashob ha usado el proveedor de autenticación compatible con Entra con autenticación segura, puede acceder al inquilino del cliente sin problemas.

La recomendación para Prashob en este ejemplo es usar la solución de autenticación multifactor de Microsoft Entra o un proveedor de autenticación compatible con Entra, para que puedan administrar el inquilino del cliente correctamente.

Ejemplo 3: El asociado no ha implementado MFA

  1. Un asociado de CSP llamado Fabrikam aún no ha implementado MFA. Microsoft recomienda implementar una solución MFA compatible con el identificador de Microsoft Entra.

  2. Jorge trabaja para Fabrikam. Fabrikam no ha implementado MFA para ningún usuario en el inquilino del asociado de Fabrikam.

  3. Juan inicia una nueva sesión del explorador y va a la página de información general del Centro de partners (que no está protegida con MFA). El Centro de partners redirige a John a Microsoft Entra ID para iniciar sesión.

  4. Después de iniciar sesión correctamente, John se redirige a la página de información general del Centro de partners, ya que no ha completado la comprobación de MFA.

  5. Jorge intenta acceder a una de las páginas protegidas por MFA del Centro de partners. Dado que John no ha completado la comprobación de MFA, el Centro de partners redirige a John a Microsoft Entra ID para completar la comprobación de MFA. Dado que esta es la primera vez que Se requiere John para completar MFA, También se solicita a John que se registre para MFA. Tras el registro de MFA correcto y la comprobación de MFA, John puede acceder a la página protegida por MFA.

  6. En otro día, antes de que Fabrikam implemente MFA para cualquier usuario, John inicia una nueva sesión del explorador y va a la página de información general del Centro de partners (que no está protegida con MFA). El Centro de partners redirige a John a Microsoft Entra ID para iniciar sesión sin mensaje de MFA.

  7. Jorge intenta acceder a una de las páginas protegidas por MFA del Centro de partners. Dado que John no ha completado la comprobación de MFA, el Centro de partners redirige a John a Microsoft Entra ID para completar la comprobación de MFA. Dado que John ha registrado MFA, esta vez solo se le pide que complete la comprobación de MFA.

Ejemplo 4: Partner ha implementado MFA que no es compatible con Microsoft Entra

  1. David trabaja para un CSP denominado Wingtip. Wingtip ha implementado MFA para todos sus usuarios en el inquilino del asociado wingtip mediante MFA que no es de Microsoft en su entorno de nube con acceso condicional.

  2. Trent inicia una nueva sesión del explorador y va a la página de información general del Centro de partners (que no está protegida con MFA). El Centro de partners redirige Trent a Microsoft Entra ID para iniciar sesión.

  3. Dado que Wingtip usó una integración de MFA que no es compatible con el identificador de Entra de Microsoft y no tiene una autenticación segura, Trent no podrá acceder a todas las páginas y API protegidas de MFA en el Centro de partners.

Dado que Trent accede a las páginas protegidas de MFA, es necesario presentar la MFA con la autenticación fuerte para obtener acceso a las páginas protegidas de MFA.

Los asociados deben usar un proveedor de autenticación compatible con el identificador de Microsoft Entra que admita la notificación del método de credencial ("notificación amr" en la referencia de notificaciones del token de access: Plataforma de identidad de Microsoft, que refleja el tipo de credencial real proporcionado durante la autenticación.

Recomendamos encarecidamente a los partners de CSP que implementen MFA que sea compatible con el identificador de Entra de Microsoft inmediatamente para aumentar la línea de base de seguridad del inquilino.

API del Centro de partners

La API del Centro de partners admite tanto la autenticación de solo aplicación como la de aplicación y usuario (App+User).

Cuando se usa la autenticación de App+User, el Centro de partners requiere la comprobación de MFA. Más concretamente, cuando una aplicación de asociado envía una solicitud de API al Centro de partners, debe incluir un token de acceso en el encabezado de autorización de la solicitud.

Nota:

El modelo de aplicaciones seguras es un marco de trabajo escalable para autenticar partners de CSP y CPV mediante la arquitectura de MFA de Microsoft Azure al llamar a las API del Centro de partners. Debe implementar este marco al usar MFA en la automatización del servicio.

Cuando el Centro de partners recibe una solicitud de API con un token de acceso obtenido mediante la autenticación de app+user, la API del Centro de partners comprueba la presencia del valor de MFA en la notificación Referencia de método de autenticación (AMR). Puedes usar un descodificador JWT para validar si un token de acceso contiene el valor esperado de referencia de método de autenticación (AMR) o no:

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "23ec45a3-5127-4185-9eff-c8887839e6ab",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "4988e250-5aee-482a-9136-6d269cb755c0",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "df845f1a-7b35-40a2-ba78-6481de91f8ae",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

  • Si el valor está presente, el Centro de partners concluye que se completó la comprobación de MFA y procesa la solicitud de API.

  • Si el valor no está presente, la API del Centro de partners rechaza la solicitud con la siguiente respuesta:

    HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:03ce8ca8-8373-4021-8f25-d5dd45c7b12f
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

Al llamar a las API del Centro de partners, solo se admiten tokens de acceso de solo aplicación para las operaciones que no requieren asignaciones de roles de GDAP en un inquilino del cliente.

Para más información sobre los procedimientos recomendados, consulte Autenticación y autorización de API: información general.

Administración delegada de partner

Los inquilinos de asociados deben usar privilegios de administrador delegados granulares (GDAP) para administrar los recursos de los clientes a través de portales de Microsoft Online Services (portal.azure.com o admin.microsoft.com), la interfaz de línea de comandos (CLI) y las API (mediante la autenticación de app+usuario). Para obtener más información, consulte Opciones de MFA admitidas.

Uso de portales de servicio

Los partners de CSP pueden administrar sus clientes desde el portal del Centro de partners a través de la interfaz de administración de servicios. Los partners pueden navegar al cliente y seleccionar Administración de servicios para poder administrar un servicio específico para el cliente. Los partners deberán seguir las instrucciones del rol de GDAP para obtener el rol de GDAP con privilegios mínimos adecuado para administrar sus clientes.

Al acceder a los portales de Microsoft Online Services mediante privilegios delegados de asociados Administración (Administración-en nombre de) para administrar los recursos del cliente, muchos de estos portales requieren que la cuenta de asociado se autentique de forma interactiva, con el inquilino de Microsoft Entra del cliente establecido como contexto de autenticación. La cuenta de asociado es necesaria para iniciar sesión en el inquilino del cliente.

La autenticación de Id. de Microsoft Entra requiere que un usuario complete la comprobación de MFA si hay una directiva que requiere MFA. Hay dos experiencias de usuario posibles, en función de si la cuenta de partner es una identidad administrada o federada:

  • Si la cuenta de asociado es una identidad administrada , Microsoft Entra ID solicita directamente al usuario que complete la comprobación de MFA. Si la cuenta de asociado no se ha registrado para MFA con microsoft Entra ID antes, se le pedirá al usuario que complete primero el registro de MFA.

  • Si la cuenta de asociado es una identidad federada , la experiencia depende de cómo el administrador del asociado ha configurado la federación en el identificador de Entra de Microsoft. Al configurar la federación en el id. de Microsoft Entra, el administrador del asociado puede indicar a Microsoft Entra ID si el proveedor de identidades federado admite MFA o no.

    • Si es así, Microsoft Entra ID redirige al usuario al proveedor de identidades federado para completar la comprobación de MFA.
    • Si no es así, Microsoft Entra ID solicita directamente al usuario que complete la comprobación de MFA. Si la cuenta de asociado no se ha registrado para MFA con microsoft Entra ID antes, se le pedirá al usuario que complete primero el registro de MFA.

La experiencia general es como el escenario en el que un inquilino del cliente final ha implementado MFA para sus administradores. Por ejemplo, el inquilino del cliente ha habilitado los valores predeterminados de seguridad de Microsoft Entra, que requiere que todas las cuentas con derechos administrativos inicien sesión en el inquilino del cliente con la comprobación de MFA, incluidos los agentes de Administración y los agentes del departamento de soporte técnico.

Con fines de prueba, los partners pueden habilitar los valores predeterminados de seguridad de Microsoft Entra en el inquilino del cliente y, a continuación, intentar usar los privilegios delegados delegados de asociados Administración istration (GDAP) para acceder al inquilino del cliente.

Nota:

No todos los portales de Microsoft Online Service requieren que las cuentas de asociados inicien sesión en el inquilino del cliente al acceder a los recursos del cliente mediante GDAP. En su lugar, algunas solo requieren que las cuentas de asociado inicien sesión en el inquilino del asociado. Un ejemplo es el Centro de administración de Exchange. Con el tiempo, esperamos que estos portales requieran que las cuentas de asociados inicien sesión en el inquilino del cliente al usar GDAP.

Experiencia de registro de MFA

Durante la comprobación de MFA, si la cuenta de asociado no se ha registrado para MFA antes, el identificador de Microsoft Entra pide al usuario que complete primero el registro de MFA.

Revise más información sobre el método Microsoft Authenticator:

Screenshot of the first step in MFA registration.

Después de que el usuario seleccione Siguiente, se le pedirá que elija entre una lista de métodos de comprobación.

Screenshot of the second step in MFA registration.

Después del registro correcto, el usuario debe completar la comprobación de MFA mediante su método de verificación elegido.

Problemas comunes

Revise la lista de problemas comunes notificados por otros asociados para comprender si la solicitud es válida.

Problema 1: El asociado necesita más tiempo para implementar MFA para sus agentes asociados

Un partner no se ha iniciado o todavía está en proceso de implementar MFA para sus agentes de partner que requieren acceso a los portales de Microsoft Online Services con privilegios de administración delegada de partner para administrar los recursos de los clientes. El partner necesita más tiempo para completar la implementación de MFA. ¿Es esto un motivo válido para la excepción técnica?

Respuesta: No. Un asociado debe planear la implementación de MFA para que sus usuarios eviten interrupciones.

Nota:

Aunque un asociado no ha implementado MFA para sus agentes asociados, los agentes asociados todavía pueden acceder a los portales de Microsoft Online Services mediante privilegios de Administración sistration delegado del asociado si pueden completar el registro de MFA y la comprobación de MFA cuando se le solicite durante el inicio de sesión en el inquilino del cliente. Al completar el registro de MFA no se habilita automáticamente el usuario para MFA.

Problema 2: El asociado no ha implementado MFA porque no necesitan acceso para administrar los clientes

Un asociado tiene algunos usuarios en sus inquilinos asociados que no necesitan acceso a los portales de Microsoft Online Services para administrar los recursos de los clientes mediante los privilegios de Administración istration delegados del asociado. El partner está en proceso de implementar MFA para estos usuarios y necesita más tiempo para que se complete. ¿Es esto un motivo válido para la excepción técnica?

Respuesta: No. Dado que estas cuentas de usuario no usan privilegios de Administración istration delegados para administrar los recursos del cliente, no se les pedirá que inicien sesión en el inquilino del cliente. No se verán afectados por el identificador de Entra de Microsoft que requiere la comprobación de MFA durante el inicio de sesión en el inquilino del cliente. Todos los usuarios deben tener MFA accediendo al Centro de partners o a las cargas de trabajo del cliente para administrar los recursos del cliente.

Problema 3: El asociado no ha implementado MFA para las cuentas de servicio de usuario

Un partner tiene algunas cuentas de usuario en sus inquilinos de partner, que los dispositivos usan como cuentas de servicio. Estas cuentas con pocos privilegios no requieren acceso al Centro de partners ni a los portales de Microsoft Online Services para administrar los recursos de los clientes mediante los privilegios delegados de asociados Administración istration. ¿Esta es una razón válida para una excepción técnica?

Respuesta: No. Dado que estas cuentas de usuario no usan privilegios de Administración istration delegados para administrar los recursos de los clientes, no son necesarios para iniciar sesión en el inquilino del cliente. No se verán afectados por el identificador de Entra de Microsoft que requiere la comprobación de MFA durante el inicio de sesión en el inquilino del cliente. Si la API o el portal requieren autenticación de aplicación+usuario, se requiere que todos los usuarios usen MFA para la autenticación.

Problema 4: El asociado no puede implementar MFA mediante la aplicación Microsoft Authenticator

Un asociado tiene una directiva de "escritorio limpio", que no permite a los empleados llevar sus dispositivos móviles personales a su área de trabajo. Sin acceso a sus dispositivos móviles personales, los empleados no pueden instalar la aplicación Microsoft Authenticator, que es la única comprobación de MFA compatible con los valores predeterminados de seguridad de Microsoft Entra. ¿Es esto un motivo válido para la excepción técnica?

Respuesta: No. El asociado debe tener en cuenta la siguiente alternativa para que sus empleados puedan seguir completando la comprobación de MFA al acceder al Centro de partners:

  • El asociado también puede suscribirse a Microsoft Entra ID P1 o P2, o usar soluciones MFA que no son de Microsoft compatibles con el identificador de Microsoft Entra que pueden proporcionar más métodos de verificación. Para más información, consulte Métodos de autenticación admitidos.

Problema 5: El asociado no puede implementar MFA debido al uso de protocolos de autenticación heredados

Un partner tiene algunos agentes de partner que todavía usan protocolos de autenticación heredados, que no son compatibles con MFA. Por ejemplo, los usuarios siguen usando Outlook 2010, que se basa en protocolos de autenticación heredados. Al habilitar MFA para estos agentes de partner se interrumpirá el uso de protocolos de autenticación heredados. ¿Es esto un motivo válido para la excepción técnica?

Respuesta: No. Se recomienda a los asociados que se quiten del uso de protocolos de autenticación heredados debido a posibles implicaciones de seguridad, ya que estos protocolos no se pueden proteger con la comprobación de MFA y son mucho más susceptibles al riesgo de credenciales. Se recomienda dejar de usar cualquier autenticación heredada y usar valores predeterminados de seguridad o acceso condicional. Para prepararse para alejarse de la autenticación heredada, revise los inicios de sesión mediante el libro de autenticación heredado y las instrucciones sobre cómo bloquear la autenticación heredada.

Para comprender el plan más reciente para admitir la autenticación heredada para Outlook, lea la entrada sobre la autenticación básica y Exchange Online y siga el blog del equipo de Exchange para obtener las próximas noticias.

Problema 6: El asociado ha implementado una MFA que no es de Microsoft que no reconoce el identificador de Entra de Microsoft

Un asociado ha implementado MFA para sus usuarios mediante una solución MFA que no sea de Microsoft. Sin embargo, el asociado no puede configurar correctamente la solución MFA que no es de Microsoft para retransmitir al identificador de Microsoft Entra que se ha completado la comprobación de MFA durante la autenticación del usuario. ¿Es esto un motivo válido para la excepción técnica?

Respuesta: No, los partners deben usar un proveedor de autenticación compatible con Entra ID que admita la notificación del método de credencial ("AMR"), referencia de notificaciones de token de acceso: Plataforma de identidad de Microsoft, que refleja el tipo de credencial real proporcionado durante la autenticación.

Le recomendamos encarecidamente que implemente MFA que sea compatible con el identificador de Entra de Microsoft inmediatamente para aumentar la línea de base de seguridad del inquilino.

Pasos siguientes