Integración de Azure Active Directory con MDM

Azure Active Directory es el servicio de administración de identidades en la nube empresarial más grande del mundo. Las organizaciones lo usan para acceder a aplicaciones Office 365 y empresariales desde Microsoft y proveedores de software como servicio (SaaS) de terceros. Muchas de las experiencias de Windows 10 enriquecidas para los usuarios de la organización (como el acceso a la tienda o la itinerancia de estado del sistema operativo) usan Azure AD como la infraestructura de identidad subyacente. Windows se integra con Azure AD, lo que permite que los dispositivos se registren en Azure AD y se inscriban en MDM en un flujo integrado.

Una vez que un dispositivo está inscrito en MDM, la MDM:

  • Puede aplicar el cumplimiento con las directivas de la organización, agregar o quitar aplicaciones, etc.
  • Puede notificar el cumplimiento de un dispositivo en Azure AD.
  • Azure AD puede permitir el acceso a los recursos de la organización o a las aplicaciones protegidas por Azure AD a los dispositivos que cumplen las directivas.

Para admitir estas experiencias enriquecidas con su producto MDM, los proveedores de MDM pueden integrarse con Azure AD. En este artículo se describen los pasos implicados.

Conexión a Azure AD

Varias maneras de conectar los dispositivos:

Para dispositivos propiedad de la empresa:

  • Unión de Windows a un dominio de Active Directory tradicional
  • Unión de Windows a Azure AD

Para dispositivos personales (BYOD):

  • Adición de una cuenta profesional de Microsoft a Windows

Unión a Azure AD

Tradicionalmente, los dispositivos propiedad de la empresa se unen al dominio Active Directory local de la organización. Estos dispositivos se pueden administrar mediante directiva de grupo o software de administración de equipos, como Microsoft Endpoint Configuration Manager. En Windows 10, también es posible administrar dispositivos unidos a un dominio con una MDM.

Windows 10 presenta una nueva manera de configurar e implementar dispositivos Windows propiedad de la organización. Este mecanismo se denomina unión a Azure AD. Al igual que la unión a un dominio tradicional, Azure AD Join permite que los dispositivos se conozcan y administren mediante una organización. Sin embargo, con Azure AD Join, Windows se autentica en Azure AD en lugar de autenticarse en un controlador de dominio.

Azure AD Join también permite que los dispositivos propiedad de la empresa se inscriban automáticamente y se administren mediante una MDM. Además, Azure AD Join se puede realizar en un equipo comprado en la tienda, en la experiencia integrada (OOBE), lo que ayuda a las organizaciones a simplificar la implementación de dispositivos. Un administrador puede requerir que los usuarios que pertenecen a uno o varios grupos inscriban sus dispositivos para su administración con una MDM. Si un usuario está configurado para requerir la inscripción automática durante la unión a Azure AD, esta inscripción se convierte en un paso obligatorio para configurar Windows. Si se produce un error en la inscripción de MDM, el dispositivo no se unirá a Azure AD.

Importante

A todos los usuarios habilitados para la inscripción automática de MDM con Azure AD Join se les debe asignar una licencia de Azure Active Directory Premium válida.

Escenario BYOD

Windows 10 también presenta una manera más sencilla de configurar dispositivos personales para acceder a aplicaciones y recursos profesionales. Los usuarios pueden agregar su cuenta profesional de Microsoft a Windows y disfrutar de un acceso más sencillo y seguro a las aplicaciones y recursos de la organización. Durante este proceso, Azure AD detecta si la organización ha configurado una MDM. Si ese es el caso, Windows intenta inscribir el dispositivo en MDM como parte del flujo "agregar cuenta". En el caso de BYOD, los usuarios pueden rechazar los Términos de uso de MDM. El dispositivo no está inscrito en MDM y el acceso a los recursos de la organización suele estar restringido.

Inscripción de MDM integrada y experiencia de usuario

Dos escenarios de inscripción de MDM de Azure AD:

  • Unión de un dispositivo a Azure AD para dispositivos propiedad de la empresa
  • Adición de una cuenta profesional a un dispositivo personal (BYOD)

En ambos escenarios, Azure AD autentica al usuario y al dispositivo. Proporciona un identificador de dispositivo único comprobado que se puede usar para la inscripción de MDM.

En ambos escenarios, el flujo de inscripción proporciona una oportunidad para que el servicio MDM represente su propia interfaz de usuario mediante una vista web. Los proveedores de MDM deben usar la interfaz de usuario para representar los Términos de uso (TOU), que pueden ser diferentes para los dispositivos BYOD y propiedad de la empresa. Los proveedores de MDM también pueden usar la vista web para representar más elementos de la interfaz de usuario, como pedir un PIN de un solo uso.

En el escenario integrado, la vista web es 100 % de pantalla completa, lo que proporciona al proveedor de MDM la capacidad de pintar una experiencia perimetral. ¡Con gran poder viene una gran responsabilidad! Es importante que los proveedores de MDM que se integran con Azure AD respeten las directrices de diseño de Windows. Este paso incluye el uso de un diseño web con capacidad de respuesta y el respeto de las directrices de accesibilidad de Windows. Por ejemplo, incluya los botones de avance y retroceso que están conectados correctamente a la lógica de navegación. Más adelante en este artículo se proporcionan más detalles.

Para que la inscripción de Azure AD funcione para una cuenta de Azure AD con respaldo de Active Directory Federated Services (AD FS), debe habilitar la autenticación con contraseña para la intranet en el servicio ADFS. Para obtener más información, consulte la solución #2 en Configuración de Azure MFA como proveedor de autenticación con AD FS.

Una vez que un usuario tiene una cuenta de Azure AD agregada a Windows e inscrita en MDM, la inscripción se puede administrar a través decuentas > de configuración > Acceso al trabajo. La administración de dispositivos de Azure AD Join para escenarios de organización o escenarios BYOD es similar.

Nota

Los usuarios no pueden quitar la inscripción de dispositivos a través de la interfaz de usuario de acceso al trabajo porque la administración está asociada a Azure AD o a la cuenta profesional.

Puntos de conexión MDM implicados en la inscripción integrada de Azure AD

La inscripción de MDM de Azure AD es un proceso de dos pasos:

  1. Muestre los Términos de uso y recopile el consentimiento del usuario.

    Este consentimiento es un flujo pasivo en el que se redirige al usuario en un control de explorador (vista web) a la dirección URL de los Términos de uso de la MDM.

  2. Inscriba el dispositivo.

    Este paso es un flujo activo en el que el agente de Windows OMA DM llama al servicio MDM para inscribir el dispositivo.

Para admitir la inscripción de Azure AD, los proveedores de MDM deben hospedar y exponer un punto de conexión de términos de uso y un punto de conexión de inscripción de MDM.

Punto de conexión de términos de uso Use este punto de conexión para informar a los usuarios de las formas en que su organización puede controlar su dispositivo. La página Términos de uso es responsable de recopilar el consentimiento del usuario antes de que comience la fase de inscripción real.

Es importante comprender que el flujo de términos de uso es un "cuadro opaco" para Windows y Azure AD. Toda la vista web se redirige a la dirección URL de términos de uso. Se debe redirigir al usuario después de aprobar o rechazar los Términos. Este diseño permite al proveedor de MDM personalizar sus Términos de uso para diferentes escenarios. Por ejemplo, se aplican diferentes niveles de control en BYOD frente a dispositivos propiedad de la organización. O bien, implemente la segmentación basada en usuarios o grupos, como los usuarios de determinadas zonas geográficas pueden tener directivas de administración de dispositivos más estrictas.

El punto de conexión de términos de uso puede implementar más lógica empresarial, como recopilar un PIN de un solo uso proporcionado por TI para controlar la inscripción de dispositivos. Sin embargo, los proveedores de MDM no deben usar el flujo de términos de uso para recopilar credenciales de usuario, lo que puede ser una experiencia de usuario degradada. No es necesario, ya que parte de la integración de MDM garantiza que el servicio MDM pueda comprender los tokens emitidos por Azure AD.

Punto de conexión de inscripción de MDM Una vez que los usuarios aceptan los Términos de uso, el dispositivo se registra en Azure AD. Comienza la inscripción automática de MDM.

En el diagrama siguiente se muestra el flujo de alto nivel implicado en el proceso de inscripción real. El dispositivo se registra por primera vez con Azure AD. Este proceso asigna un identificador de dispositivo único al dispositivo y presenta al dispositivo la capacidad de autenticarse con Azure AD (autenticación de dispositivo). A continuación, el dispositivo se inscribe para la administración con MDM. Este paso llama al punto de conexión de inscripción y solicita la inscripción para el usuario y el dispositivo. En este momento, el usuario se ha autenticado y el dispositivo se ha registrado y autenticado con Azure AD. Esta información está disponible para MDM en forma de notificaciones dentro de un token de acceso presentado en el punto de conexión de inscripción.

flujo de inscripción de azure ad.

Se espera que mdm use esta información sobre el dispositivo (id. de dispositivo) al notificar el cumplimiento del dispositivo a Azure AD mediante microsoft Graph API. Más adelante en este artículo se proporciona un ejemplo para notificar el cumplimiento de dispositivos.

Convertir la MDM en una entidad confiable de Azure AD

Para participar en el flujo de inscripción integrado descrito en la sección anterior, la MDM debe consumir tokens de acceso emitidos por Azure AD. Para notificar el cumplimiento con Azure AD, la MDM debe autenticarse en Azure AD y obtener autorización en forma de token de acceso que le permita invocar la Graph API de Microsoft.

Incorporación de una MDM basada en la nube

Una MDM basada en la nube es una aplicación SaaS que proporciona funcionalidades de administración de dispositivos en la nube. Es una aplicación multiinquilino. Esta aplicación se registra con Azure AD en el inquilino principal del proveedor de MDM. Cuando un administrador de TI decide usar esta solución MDM, una instancia de esta aplicación se hace visible en el inquilino del cliente.

El proveedor de MDM primero debe registrar la aplicación en su inquilino principal y marcarla como una aplicación multiinquilino. Aquí se muestra un ejemplo de código de GitHub que explica cómo agregar aplicaciones multiinquilino a Azure AD, WepApp-WebAPI-MultiTenant-OpenIdConnect-DotNet.

Nota

Para el proveedor de MDM, si no tiene un inquilino de Azure AD existente con una suscripción de Azure AD que administre, siga la guía paso a paso de Incorporación de un inquilino de Azure AD y una suscripción de Azure AD para configurar un inquilino, agregar una suscripción y administrarla a través de Azure Portal.

La aplicación MDM usa claves para solicitar tokens de acceso desde Azure AD. Estas claves se administran dentro del inquilino del proveedor de MDM y no son visibles para clientes individuales. La aplicación MDM multiinquilino usa la misma clave para autenticarse con Azure AD, sea cual sea el inquilino del cliente al que pertenece el dispositivo administrado.

Nota

Todas las aplicaciones MDM deben implementar tokens de Azure AD V2 antes de certificar que la integración funciona. Debido a los cambios en la plataforma de aplicaciones de Azure AD, el uso de tokens de Azure AD V2 es un requisito difícil. Para obtener más información, consulte Plataforma de identidad de Microsoft tokens de acceso.

Siga estos pasos para registrar una aplicación MDM basada en la nube con Azure AD. En este momento, debe trabajar con el equipo de ingeniería de Azure AD para exponer esta aplicación a través de la galería de aplicaciones de Azure AD.

  1. Inicie sesión en el Portal de administración de Azure mediante una cuenta de administrador en el inquilino principal.

  2. En el panel de navegación izquierdo, seleccione Active Directory.

  3. Seleccione el inquilino del directorio donde desea registrar la aplicación.

    Asegúrese de que ha iniciado sesión en el inquilino principal.

  4. Seleccione la pestaña Aplicaciones .

  5. En el cajón, seleccione Agregar.

  6. Seleccione Agregar una aplicación que mi organización está desarrollando.

  7. Escriba un nombre descriptivo para la aplicación, como ContosoMDM, seleccione Aplicación web o API web y, a continuación, seleccione Siguiente.

  8. Escriba la dirección URL de inicio de sesión del servicio MDM.

  9. En Id. de aplicación, escriba https://<your_tenant_name>/ContosoMDMy seleccione Aceptar.

  10. Mientras sigue en la Azure Portal, seleccione la pestaña Configurar de la aplicación.

  11. Marque la aplicación como multiinquilino.

  12. Busque el valor del identificador de cliente y cópielo.

    Necesitará este identificador más adelante al configurar la aplicación. Este identificador de cliente se usa al obtener tokens de acceso y agregar aplicaciones a la galería de aplicaciones de Azure AD.

  13. Genere una clave para la aplicación y cópiela.

    Necesita esta clave para llamar a microsoft Graph API para notificar el cumplimiento del dispositivo. Esta información se describe en la sección siguiente.

Para obtener más información sobre cómo registrar una aplicación de ejemplo con Azure AD, consulte los pasos para registrar la API web TodoListService en NativeClient-DotNet.

Adición de una MDM local

Una aplicación MDM local es diferente de una MDM en la nube. Se trata de una aplicación de inquilino único que está presente de forma única dentro del inquilino del cliente. Los clientes deben agregar la aplicación directamente dentro de su propio inquilino. Además, cada instancia de una aplicación MDM local debe registrarse por separado y tiene una clave independiente para la autenticación con Azure AD.

Para agregar una aplicación MDM local al inquilino, use el servicio Azure AD, específicamente en Movilidad (MDM y MAM) > Agregar aplicación. Los administradores pueden configurar las direcciones URL necesarias para la inscripción y los Términos de uso.

El producto MDM local debe exponer una experiencia de configuración en la que los administradores puedan proporcionar el identificador de cliente, el identificador de la aplicación y la clave configurada en su directorio para esa aplicación MDM. Puede usar este identificador de cliente y esta clave para solicitar tokens de Azure AD al notificar el cumplimiento del dispositivo.

Para obtener más información sobre el registro de aplicaciones con Azure AD, consulte Conceptos básicos del registro de una aplicación en Azure AD.

Directrices de administración y seguridad de claves

Las claves de aplicación que usa el servicio MDM son un recurso confidencial. Deben protegerse y revertirse periódicamente para una mayor seguridad. Los tokens de acceso obtenidos por el servicio MDM para llamar a microsoft Graph API son tokens de portador y deben protegerse para evitar la divulgación no autorizada.

Para conocer los procedimientos recomendados de seguridad, consulte Windows Azure Security Essentials.

Puede revertir las claves de aplicación que usa un servicio MDM basado en la nube sin necesidad de una interacción del cliente. Hay un único conjunto de claves en todos los inquilinos de clientes administrados por el proveedor de MDM en su inquilino de Azure AD.

En el caso de MDM local, las claves de autenticación de Azure AD están dentro del inquilino del cliente y el administrador del cliente debe revertirlas. Para mejorar la seguridad, proporcione orientación a los clientes sobre cómo revertir y proteger las claves.

Los administradores de TI usan la galería de aplicaciones de Azure AD para agregar una MDM para que su organización la use. La galería de aplicaciones es una tienda enriquecida con más de 2400 aplicaciones SaaS integradas con Azure AD.

En la imagen siguiente se muestra cómo se muestran las aplicaciones MDM en la galería de aplicaciones de Azure.

azure ad agrega una aplicación para mdm.

Nota

Debe trabajar con el equipo de ingeniería de Azure AD si la aplicación MDM está basada en la nube y necesita habilitarse como una aplicación MDM multiinquilino.

En la tabla siguiente se muestra la información necesaria para crear una entrada en la galería de aplicaciones de Azure AD.

Elemento Descripción
Id. de aplicación El identificador de cliente de la aplicación MDM que está configurado dentro del inquilino. Este identificador es el identificador único de la aplicación multiinquilino.
Publicador Cadena que identifica el publicador de la aplicación.
Dirección URL de la aplicación Dirección URL a la página de aterrizaje de la aplicación donde los administradores pueden obtener más información sobre la aplicación MDM y contiene un vínculo a la página de aterrizaje de la aplicación. Esta dirección URL no se usa para la inscripción real.
Descripción Una breve descripción de la aplicación MDM, que debe tener menos de 255 caracteres.
Iconos Un conjunto de iconos de logotipo para la aplicación MDM. Dimensiones: 45 X 45, 150 X 122, 214 X 215

No hay requisitos especiales para agregar MDM local a la galería de aplicaciones. Hay una entrada genérica para que el administrador agregue una aplicación a su inquilino.

Sin embargo, la administración de claves es diferente para MDM local. Debe obtener el identificador de cliente (id. de aplicación) y la clave asignadas a la aplicación MDM dentro del inquilino del cliente. El identificador y la clave obtienen autorización para acceder al Graph API de Microsoft y para notificar el cumplimiento del dispositivo.

Temas

Las páginas representadas por MDM en el proceso de inscripción integrada deben usar plantillas de Windows (descargue las plantillas de Windows y los archivos CSS (1.1.4)). Estas plantillas son importantes para la inscripción durante la experiencia de unión a Azure AD en OOBE, donde todas las páginas son páginas HTML perimetrales. No intente copiar las plantillas porque nunca obtendrá la posición correcta del botón.

Hay tres escenarios distintos:

  1. Inscripción de MDM como parte de La unión a Azure AD en Windows OOBE.
  2. Inscripción de MDM como parte de La unión a Azure AD, después de Windows OOBE desde Configuración.
  3. Inscripción de MDM como parte de la adición de una cuenta profesional de Microsoft en un dispositivo personal (BYOD).

Estos escenarios admiten el cliente de Windows Pro, Enterprise y Education.

Los archivos CSS proporcionados por Microsoft contienen información de versión y se recomienda usar la versión más reciente. Hay archivos CSS independientes para dispositivos cliente Windows, OOBE y experiencias posteriores a OOBE. Descargue las plantillas de Windows y los archivos CSS (1.1.4).

  • Para Windows 10, use oobe-desktop.css.
  • Para Windows 11, use oobe-light.css.

Uso de temas

Una página MDM debe cumplir un tema predefinido en función del escenario que se muestre. Por ejemplo, si el encabezado CXH-HOSTHTTP es FRX, que es el escenario OOBE, la página debe admitir un tema oscuro con color de fondo azul, que usa el archivo WinJS Ui-dark.css ver 4.0 y oobe-desktop.css ver 1.0.4.

CXH-HOST (ENCABEZADO HTTP) Escenario Tema de fondo WinJS Escenario CSS
Frx OOBE Tema oscuro + color de fondo azul Nombre de archivo: Ui-dark.css Nombre de archivo: oobe-dekstop.css
MOSET Configuración o publicación de OOBE Tema claro Nombre de archivo: Ui-light.css Nombre de archivo: settings-desktop.css

Semántica del protocolo de términos de uso

El punto de conexión de términos de uso está hospedado por el servidor MDM. Durante el flujo del protocolo de unión a Azure AD, Windows realiza una redirección de página completa a este punto de conexión. Esta redirección permite que la MDM muestre los términos y condiciones que se aplican. Permite al usuario aceptar o rechazar los términos asociados a la inscripción. Una vez que el usuario acepta los términos, la MDM vuelve a redirigir a Windows para que continúe el proceso de inscripción.

Redirección al punto de conexión de términos de uso

Esta redirección es una redirección de página completa al punto de conexión de términos de usuario hospedado por mdm. Esta es una dirección URL de ejemplo, https://fabrikam.contosomdm.com/TermsOfUse.

Los parámetros siguientes se pasan en la cadena de consulta:

Elemento Descripción
redirect_uri Después de que el usuario acepte o rechace los Términos de uso, se le redirigirá a esta dirección URL.
client-request-id GUID que se usa para correlacionar los registros con fines de diagnóstico y depuración. Use este parámetro para registrar o realizar un seguimiento del estado de la solicitud de inscripción para ayudar a encontrar la causa principal de los errores.
api-version Especifica la versión del protocolo solicitado por el cliente. Este valor proporciona un mecanismo para admitir revisiones de versiones del protocolo.
mode Especifica que el dispositivo es propiedad de la organización cuando mode=azureadjoin. Este parámetro no está presente para dispositivos BYOD.

Token de acceso

Azure AD emite un token de acceso de portador. El token se pasa en el encabezado de autorización de la solicitud HTTP. Este es un formato típico:

Autorización: Portador CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw...

Se esperan las siguientes notificaciones en el token de acceso pasado por Windows al punto de conexión de términos de uso:

Elemento Descripción
Id. de objeto Identificador del objeto de usuario correspondiente al usuario autenticado.
Upn Notificación que contiene el nombre principal de usuario (UPN) del usuario autenticado.
Tid Una notificación que representa el identificador de inquilino del inquilino. En el ejemplo anterior, es Fabrikam.
Recurso Dirección URL saneada que representa la aplicación MDM. Por ejemplo: https://fabrikam.contosomdm.com

Nota

No hay ninguna notificación de id. de dispositivo en el token de acceso porque es posible que el dispositivo aún no esté inscrito en este momento.

Para recuperar la lista de pertenencias a grupos para el usuario, puede usar microsoft Graph API.

Esta es una dirección URL de ejemplo.

https://fabrikam.contosomdm.com/TermsOfUse?redirect_uri=ms-appx-web://ContosoMdm/ToUResponse&client-request-id=34be581c-6ebd-49d6-a4e1-150eff4b7213&api-version=1.0
Authorization: Bearer eyJ0eXAiOi

Se espera que mdm valide la firma del token de acceso para asegurarse de que azure AD lo emitió y asegurarse de que el destinatario es adecuado.

Contenido de términos de uso

La MDM puede realizar otras redirecciones según sea necesario antes de mostrar el contenido de los Términos de uso al usuario. El contenido de los Términos de uso adecuados debe devolverse al autor de la llamada (Windows) para que se pueda mostrar al usuario final en el control del explorador.

El contenido de los Términos de uso debe contener los siguientes botones:

  • Aceptar : el usuario acepta los Términos de uso y continúa con la inscripción.
  • Rechazar : el usuario rechaza y detiene el proceso de inscripción.

El contenido de los Términos de uso debe ser coherente con el tema usado para las demás páginas representadas durante este proceso.

Lógica de procesamiento de puntos de conexión de términos de uso

En este momento, el usuario se encuentra en la página Términos de uso que se muestra durante la OOBE o en las experiencias de configuración. El usuario tiene las siguientes opciones en la página:

  • El usuario hace clic en el botón Aceptar : la MDM debe redirigir al URI especificado por el parámetro redirect_uri en la solicitud entrante. Se esperan los siguientes parámetros de cadena de consulta:
    • IsAccepted : este valor booleano es necesario y debe establecerse en true.
    • OpaqueBlob : parámetro obligatorio si el usuario acepta. La MDM puede usar este blob para que cierta información esté disponible para el punto de conexión de inscripción. El valor que se conserva aquí está disponible sin cambios en el punto de conexión de inscripción. La MDM puede usar este parámetro con fines de correlación.
    • Este es un redireccionamiento de ejemplo: ms-appx-web://MyApp1/ToUResponse?OpaqueBlob=value&IsAccepted=true
  • El usuario hace clic en el botón Rechazar : la MDM debe redirigir al URI especificado en redirect_uri en la solicitud entrante. Se esperan los siguientes parámetros de cadena de consulta:
    • IsAccepted : este valor booleano es obligatorio y debe establecerse en false. Esta opción también se aplica si el usuario omitió los Términos de uso.
    • OpaqueBlob : no se espera que se use este parámetro. La inscripción se detiene con un mensaje de error que se muestra al usuario.

Los usuarios omiten los Términos de uso al agregar una cuenta profesional de Microsoft a su dispositivo. Sin embargo, no pueden omitirlo durante el proceso de unión a Azure AD. No muestre el botón rechazar en el proceso de unión a Azure AD. El usuario no puede rechazar la inscripción de MDM si lo configura el administrador para la unión a Azure AD.

Se recomienda enviar los parámetros client-request-id en la cadena de consulta como parte de esta respuesta de redireccionamiento.

Control de errores de los términos de uso

Si se produce un error durante el procesamiento de los términos de uso, la MDM puede devolver dos parámetros: un error y un parámetro error_description en su solicitud de redirección a Windows. La dirección URL debe codificarse y el contenido del error_description debe estar en texto sin formato en inglés. Este texto no es visible para el usuario final. Por lo tanto, la localización del texto de la descripción del error no es un problema.

Este es el formato de dirección URL:

HTTP/1.1 302
Location:
<redirect_uri>?error=access_denied&error_description=Access%20is%20denied%2E

Example:
HTTP/1.1 302
Location: ms-appx-web://App1/ToUResponse?error=access_denied&error_description=Access%20is%20denied%2E

En la tabla siguiente se muestran los códigos de error.

Causa Estado HTTP Error Descripción
api-version 302 invalid_request versión no admitida
Faltan datos de inquilino o usuario u otros requisitos previos necesarios para la inscripción de dispositivos 302 unauthorized_client usuario o inquilino no autorizado
Error en la validación del token de Azure AD 302 unauthorized_client unauthorized_client
Error interno del servicio 302 server_error Error interno del servicio

Protocolo de inscripción con Azure AD

Con la inscripción de MDM integrada de Azure, no hay ninguna fase de detección y la dirección URL de detección se pasa directamente al sistema desde Azure. En la tabla siguiente se muestra la comparación entre las inscripciones tradicionales y las inscripciones de Azure.

Detalle Inscripción de MDM tradicional Unión a Azure AD (dispositivo propiedad de la organización) Azure AD agrega una cuenta profesional (dispositivo propiedad del usuario)
Detección automática de MDM mediante la dirección de correo electrónico para recuperar la dirección URL de detección de MDM Inscripción No aplicable
Dirección URL de detección aprovisionada en Azure
Usa la dirección URL de detección de MDM Inscripción
Renovación de la inscripción
ROBO
Inscripción
Renovación de la inscripción
ROBO
Inscripción
Renovación de la inscripción
ROBO
¿Se requiere la inscripción de MDM? No
El usuario puede rechazarlo.
Tipo de autenticación OnPremise
Federados
Certificado
Federados Federados
EnrollmentPolicyServiceURL Opcional (toda la autenticación) Opcional (toda la autenticación) Opcional (toda la autenticación)
EnrollmentServiceURL Obligatorio (toda la autenticación) Se usa (toda la autenticación) Se usa (toda la autenticación)
EnrollmentServiceURL incluye la versión del sistema operativo, la plataforma del sistema operativo y otros atributos proporcionados por la dirección URL de detección de MDM. Altamente recomendado Altamente recomendado Altamente recomendado
AuthenticationServiceURL usado Usado (autenticación federada) Saltamos Saltamos
BinarySecurityToken Personalizado por MDM Token emitido por Azure AD Token emitido por Azure AD
EnrollmentType Completo Dispositivo Completo
Tipo de certificado inscrito Certificado de usuario Certificado de dispositivo Certificado de usuario
Almacén de certificados inscrito Mi/Usuario Mi/Sistema Mi/Usuario
Nombre del firmante de CSR Nombre principal del usuario Id. de dispositivo Nombre principal del usuario
EnrollmentData Términos de uso de blob binario como AdditionalContext para EnrollmentServiceURL No se admite Se admite Se admite
Csp accesibles durante la inscripción Windows 10 soporte técnico:
- DMClient
- CertificateStore
- RootCATrustedCertificates
- ClientCertificateInstall
- EnterpriseModernAppManagement
- PassportForWork
- Directiva
- w7 APPLICATION

Protocolo de administración con Azure AD

Hay dos tipos de inscripción de MDM diferentes que se integran con Azure AD y usan identidades de usuario y dispositivo de Azure AD. En función del tipo de inscripción, es posible que el servicio MDM tenga que administrar un único usuario o varios usuarios.

Administración de varios usuarios para dispositivos unidos a Azure AD En este escenario, la inscripción de MDM se aplica a todos los usuarios de Azure AD que inician sesión en el dispositivo unido a Azure AD: llame a este tipo de inscripción una inscripción de dispositivo o una inscripción de varios usuarios. El servidor de administración puede determinar la identidad del usuario, determinar qué directivas tienen como destino este usuario y enviar las directivas correspondientes al dispositivo. Para permitir que el servidor de administración identifique al usuario actual que ha iniciado sesión en el dispositivo, el cliente de OMA DM usa los tokens de usuario de Azure AD. Cada sesión de administración contiene un encabezado HTTP adicional que contiene un token de usuario de Azure AD. Esta información se proporciona en el paquete DM enviado al servidor de administración. Sin embargo, en algunas circunstancias, el token de usuario de Azure AD no se envía al servidor de administración. Uno de estos escenarios se produce inmediatamente después de que se completen las inscripciones de MDM durante el proceso de unión a Azure AD. Hasta que finalice el proceso de unión a Azure AD y el usuario de Azure AD inicie sesión en la máquina, el token de usuario de Azure AD no estará disponible para el proceso OMA-DM. Normalmente, la inscripción de MDM se completa antes de que el usuario de Azure AD inicie sesión en la máquina y la sesión de administración inicial no contenga un token de usuario de Azure AD. El servidor de administración debe comprobar si falta el token y solo enviar directivas de dispositivo en tal caso. Otra posible razón para que falte un token de Azure AD en la carga de OMA-DM es cuando un usuario invitado inicia sesión en el dispositivo.

Adición de una cuenta profesional e inscripción de MDM a un dispositivo En este escenario, la inscripción de MDM se aplica a un único usuario que inicialmente agregó su cuenta profesional e inscribió el dispositivo. En este tipo de inscripción, el servidor de administración puede omitir los tokens de Azure AD que se pueden enviar durante la sesión de administración. Tanto si el token de Azure AD está presente como si falta, el servidor de administración envía directivas de usuario y dispositivo al dispositivo.

Evaluación de tokens de usuario de Azure AD El token de Azure AD está en el encabezado de autorización HTTP en el formato siguiente:

Authorization:Bearer <Azure AD User Token Inserted here>

Puede haber más notificaciones en el token de Azure AD, como:

  • Usuario: usuario que ha iniciado sesión actualmente
  • Cumplimiento de dispositivos: valor que establece el servicio MDM en Azure
  • Id. de dispositivo: identifica el dispositivo que está comprobando
  • ID. del espacio empresarial

Los tokens de acceso emitidos por Azure AD son tokens web JSON (JWT). Windows presenta un token JWT válido en el punto de conexión de inscripción de MDM para iniciar el proceso de inscripción. Hay un par de opciones para evaluar los tokens:

  • Use la extensión Controlador de tokens JWT para WIF para validar el contenido del token de acceso y extraer las notificaciones necesarias para su uso. Para obtener más información, vea JwtSecurityTokenHandler (Clase).
  • Consulte los ejemplos de código de autenticación de Azure AD para obtener un ejemplo para trabajar con tokens de acceso. Para obtener un ejemplo, vea NativeClient-DotNet.

Alerta de dispositivo 1224 para el token de usuario de Azure AD

Se envía una alerta cuando se inicia la sesión de DM y hay un usuario de Azure AD que ha iniciado sesión. La alerta se envía en OMA DM pkg#1. A continuación te mostramos un ejemplo:

Alert Type: com.microsoft/MDM/AADUserToken

Alert sample:
<SyncBody>
 <Alert>
  <CmdID>1</CmdID>
  <Data>1224</Data>
  <Item>
   <Meta>
    <Type xmlns=”syncml:metinf”>com.microsoft/MDM/AADUserToken</Type>
   </Meta>
   <Data>UserToken inserted here</Data>
  </Item>
 </Alert>
 … other XML tags …
</SyncBody>

Determinar cuándo un usuario ha iniciado sesión a través del sondeo

Se envía una alerta al servidor MDM en el paquete DM#1.

  • Tipo de alerta: com.microsoft/MDM/LoginStatus
  • Formato de alerta: chr
  • Datos de alerta: proporcione información de estado de inicio de sesión para el usuario activo actual que ha iniciado sesión.
    • Usuario que ha iniciado sesión que tiene una cuenta de Azure AD: texto predefinido: usuario.
    • Usuario que ha iniciado sesión sin una cuenta de Azure AD: texto predefinido: otros.
    • No hay ningún usuario activo: texto predefinido:none

A continuación te mostramos un ejemplo.

<SyncBody>
 <Alert>
  <CmdID>1</CmdID>
  <Data>1224</Data>
  <Item>
   <Meta>
    <Type xmlns=”syncml:metinf”>com.microsoft/MDM/LoginStatus</Type>
   </Meta>
   <Data>user</Data>
  </Item>
 </Alert>
 … other XML tags …
</SyncBody>

Notificar el cumplimiento de dispositivos a Azure AD

Una vez que un dispositivo está inscrito con MDM para la administración, las directivas de organización configuradas por el administrador de TI se aplican en el dispositivo. Mdm evalúa el cumplimiento del dispositivo con las directivas configuradas y, a continuación, se notifica a Azure AD. En esta sección se describe la llamada Graph API que puede usar para notificar el estado de cumplimiento de un dispositivo a Azure AD.

Para obtener un ejemplo que muestra cómo una MDM puede obtener un token de acceso mediante el tipo de concesión client_credentials de OAuth 2.0, consulte Daemon_CertificateCredential-DotNet.

  • MDM basado en la nube : si el producto es un servicio MDM multiinquilino basado en la nube, tiene una sola clave configurada para el servicio dentro del inquilino. Para obtener autorización, use esta clave para autenticar el servicio MDM con Azure AD.
  • MDM local : si el producto es una MDM local, los clientes deben configurar el producto con la clave que se usa para autenticarse con Azure AD. Esta configuración de clave se debe a que cada instancia local del producto MDM tiene una clave específica del inquilino diferente. Por lo tanto, es posible que tenga que exponer una experiencia de configuración en el producto MDM que permita a los administradores especificar la clave que se usará para autenticarse con Azure AD.

Uso de Microsoft Graph API

En la siguiente llamada de API REST de ejemplo se muestra cómo una MDM puede usar microsoft Graph API para notificar el estado de cumplimiento de un dispositivo administrado por él.

Nota

Esta API solo es aplicable para aplicaciones MDM aprobadas en dispositivos Windows 10.

Sample Graph API Request:

PATCH https://graph.windows.net/contoso.com/devices/db7ab579-3759-4492-a03f-655ca7f52ae1?api-version=beta HTTP/1.1
Authorization: Bearer eyJ0eXAiO………
Accept: application/json
Content-Type: application/json
{  "isManaged":true,
   "isCompliant":true
}

Donde:

  • contoso.com : este valor es el nombre del inquilino de Azure AD a cuyo directorio se ha unido el dispositivo.
  • db7ab579-3759-4492-a03f-655ca7f52ae1 : este valor es el identificador de dispositivo del dispositivo cuya información de cumplimiento se notifica a Azure AD.
  • eyJ0eXAiO......... : este valor es el token de acceso de portador emitido por Azure AD a la MDM que autoriza a MDM a llamar a Microsoft Graph API. El token de acceso se coloca en el encabezado de autorización HTTP de la solicitud.
  • isManaged y isCompliant : estos atributos booleanos indican el estado de cumplimiento.
  • api-version : use este parámetro para especificar qué versión de graph API se solicita.

Respuesta:

  • Correcto: HTTP 204 sin contenido.
  • Error o error: HTTP 404 no encontrado. Este error se puede devolver si no se encuentra el dispositivo o inquilino especificado.

Pérdida de datos durante la anulación de la inscripción de Azure Active Directory Join

Cuando un usuario se inscribe en MDM a través de Azure Active Directory Join y, a continuación, desconecta la inscripción, no hay ninguna advertencia de que el usuario perderá los datos de Windows Information Protection (WIP). El mensaje de desconexión no indica la pérdida de datos WIP.

aadj unenrollment.

Códigos de error

Código ID Mensaje de error
0x80180001 "idErrorServerConnectivity", // MENROLL_E_DEVICE_MESSAGE_FORMAT_ERROR Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x80180002 "idErrorAuthenticationFailure", // MENROLL_E_DEVICE_AUTHENTICATION_ERROR Se produjo un problema al autenticar su cuenta o dispositivo. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180003 "idErrorAuthorizationFailure", // MENROLL_E_DEVICE_AUTHORIZATION_ERROR Este usuario no está autorizado para inscribirse. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180004 "idErrorMDMCertificateError", // MENROLL_E_DEVICE_CERTIFCATEREQUEST_ERROR Se produjo un error de certificado. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180005 "idErrorServerConnectivity", // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x80180006 "idErrorServerConnectivity", // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x80180007 "idErrorAuthenticationFailure", // MENROLL_E_DEVICE_INVALIDSECURITY_ERROR Se produjo un problema al autenticar su cuenta o dispositivo. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180008 "idErrorServerConnectivity", // MENROLL_E_DEVICE_UNKNOWN_ERROR Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x80180009 "idErrorAlreadyInProgress", // MENROLL_E_ENROLLMENT_IN_PROGRESS Hay otra inscripción en curso. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x8018000A "idErrorMDMAlreadyEnrolled", // MENROLL_E_DEVICE_ALREADY_ENROLLED Este dispositivo ya está inscrito. Puede ponerse en contacto con el administrador del sistema con el código {0}de error .
0x8018000D "idErrorMDMCertificateError", // MENROLL_E_DISCOVERY_SEC_CERT_DATE_INVALID Se produjo un error de certificado. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x8018000E "idErrorAuthenticationFailure", // MENROLL_E_PASSWORD_NEEDED Se produjo un problema al autenticar su cuenta o dispositivo. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x8018000F "idErrorAuthenticationFailure", // MENROLL_E_WAB_ERROR Se produjo un problema al autenticar su cuenta o dispositivo. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180010 "idErrorServerConnectivity", // MENROLL_E_CONNECTIVITY Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x80180012 "idErrorMDMCertificateError", // MENROLL_E_INVALIDSSLCERT Se produjo un error de certificado. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180013 "idErrorDeviceLimit", // MENROLL_E_DEVICECAPREACHED Parece que hay demasiados dispositivos o usuarios para esta cuenta. Póngase en contacto con el administrador del sistema con el código {0}de error .
0x80180014 "idErrorMDMNotSupported", // MENROLL_E_DEVICENOTSUPPORTED Esta característica no se admite. Póngase en contacto con el administrador del sistema con el código {0}de error .
0x80180015 "idErrorMDMNotSupported", // MENROLL_E_NOTSUPPORTED Esta característica no se admite. Póngase en contacto con el administrador del sistema con el código {0}de error .
0x80180016 "idErrorMDMRenewalRejected", // MENROLL_E_NOTELIGIBLETORENEW El servidor no aceptó la solicitud. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180017 "idErrorMDMAccountMaintenance", // MENROLL_E_INMAINTENANCE El servicio está en mantenimiento. Puede intentar hacerlo de nuevo más adelante o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180018 "idErrorMDMLicenseError", // MENROLL_E_USERLICENSE Se produjo un error con la licencia. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x80180019 "idErrorInvalidServerConfig", // MENROLL_E_ENROLLMENTDATAINVALID Parece que el servidor no está configurado correctamente. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
"rejectedTermsOfUse" "idErrorRejectedTermsOfUse" Su organización requiere que acepte los Términos de uso. Inténtelo de nuevo o pida más información a su persona de soporte técnico.
0x801c0001 "idErrorServerConnectivity", // DSREG_E_DEVICE_MESSAGE_FORMAT_ERROR Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x801c0002 "idErrorAuthenticationFailure", // DSREG_E_DEVICE_AUTHENTICATION_ERROR Se produjo un problema al autenticar su cuenta o dispositivo. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x801c0003 "idErrorAuthorizationFailure", // DSREG_E_DEVICE_AUTHORIZATION_ERROR Este usuario no está autorizado para inscribirse. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x801c0006 "idErrorServerConnectivity", // DSREG_E_DEVICE_INTERNALSERVICE_ERROR Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x801c000B "idErrorUntrustedServer", // DSREG_E_DISCOVERY_REDIRECTION_NOT_TRUSTED El servidor con el que se está contactando no es de confianza. Póngase en contacto con el administrador del sistema con el código {0}de error .
0x801c000C "idErrorServerConnectivity", // DSREG_E_DISCOVERY_FAILED Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x801c000E "idErrorDeviceLimit", // DSREG_E_DEVICE_REGISTRATION_QUOTA_EXCCEEDED Parece que hay demasiados dispositivos o usuarios para esta cuenta. Póngase en contacto con el administrador del sistema con el código {0}de error .
0x801c000F "idErrorDeviceRequiresReboot", // DSREG_E_DEVICE_REQUIRES_REBOOT Se requiere un reinicio para completar el registro del dispositivo.
0x801c0010 "idErrorInvalidCertificate", // DSREG_E_DEVICE_AIK_VALIDATION_ERROR Parece que tiene un certificado no válido. Póngase en contacto con el administrador del sistema con el código {0}de error .
0x801c0011 "idErrorAuthenticationFailure", // DSREG_E_DEVICE_ATTESTATION_ERROR Se produjo un problema al autenticar su cuenta o dispositivo. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x801c0012 "idErrorServerConnectivity", // DSREG_E_DISCOVERY_BAD_MESSAGE_ERROR Se produjo un error al comunicarse con el servidor. Puede intentar hacerlo de nuevo o ponerse en contacto con el administrador del sistema con el código de error. {0}
0x801c0013 "idErrorAuthenticationFailure", // DSREG_E_TENANTID_NOT_FOUND Se produjo un problema al autenticar su cuenta o dispositivo. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .
0x801c0014 "idErrorAuthenticationFailure", // DSREG_E_USERSID_NOT_FOUND Se produjo un problema al autenticar su cuenta o dispositivo. Puede intentar volver a hacerlo o ponerse en contacto con el administrador del sistema con el código {0}de error .