Integração do Azure Active Directory com o MDM

Artigo
08/10/2023
Aplica-se a:

✅ Windows 11, ✅ Windows 10

O Azure Active Directory é o maior serviço de gerenciamento de identidade de nuvem corporativa do mundo. Ele é usado por organizações para acessar o Microsoft 365 e aplicativos empresariais da Microsoft e fornecedores saaS (software de terceiros como serviço). Muitas das experiências avançadas do Windows para usuários organizacionais (como acesso à loja ou roaming de estado do sistema operacional) usam Azure AD como a infraestrutura de identidade subjacente. O Windows se integra ao Azure AD, permitindo que os dispositivos sejam registrados em Azure AD e registrados no MDM em um fluxo integrado.

Depois que um dispositivo é registrado no MDM, o MDM:

Pode impor a conformidade com políticas de organização, adicionar ou remover aplicativos e muito mais.
Pode relatar a conformidade de um dispositivo no Azure AD.
Azure AD pode permitir o acesso a recursos da organização ou aplicativos protegidos por Azure AD a dispositivos que estejam em conformidade com as políticas.

Para dar suporte a essas experiências avançadas com seu produto MDM, os fornecedores de MDM podem se integrar ao Azure AD.

Registro de MDM integrado e UX

Há várias maneiras de conectar seus dispositivos a Azure AD:

Em cada cenário, Azure AD autentica o usuário e o dispositivo. Ele fornece um identificador de dispositivo exclusivo verificado que pode ser usado para registro de MDM. O fluxo de registro oferece uma oportunidade para o serviço MDM renderizar sua própria interface do usuário usando uma exibição da Web. Os fornecedores de MDM devem usar a interface do usuário para renderizar os Termos de Uso (TOU), que podem ser diferentes para dispositivos BYOD (propriedade da empresa e traga seu próprio dispositivo). Os fornecedores de MDM também podem usar a exibição da Web para renderizar mais elementos de interface do usuário, como pedir um PIN único.

No Windows 10, a exibição da Web durante o cenário fora da caixa é exibida como tela inteira por padrão, fornecendo aos fornecedores de MDM a capacidade de criar uma experiência de usuário de ponta a ponta. No entanto, em Windows 11 a exibição da Web é renderizada em um iframe. É importante que os fornecedores de MDM que se integram ao Azure AD respeitem as diretrizes de design do Windows. Esta etapa inclui usar um design web responsivo e respeitar as diretrizes de acessibilidade do Windows. Por exemplo, inclua os botões para frente e para trás que estão corretamente conectados à lógica de navegação. Mais detalhes são fornecidos posteriormente neste artigo.

Para que Azure AD registro funcione para uma conta de Azure AD com suporte dos Serviços Federados do Active Directory (AD FS), você deve habilitar a autenticação de senha para a intranet no serviço do ADFS. Para obter mais informações, consulte Configurar o Azure MFA como provedor de autenticação com o AD FS.

Depois que um usuário tiver uma conta Azure AD adicionada ao Windows e registrada no MDM, o registro poderá ser gerenciado por meio dotrabalho ou da escola do Acesso deContas>de Configurações>. O gerenciamento de dispositivos de Azure AD Junção para cenários de organização ou cenários BYOD é semelhante.

Observação

Os usuários não podem remover o registro do dispositivo por meio da interface do usuário do Access ou da escola porque o gerenciamento está vinculado à Azure AD ou à conta de trabalho.

Pontos de extremidade MDM envolvidos em Azure AD registro integrado

Azure AD registro de MDM é um processo de duas etapas:

Exiba os Termos de Uso e colete o consentimento do usuário: esse consentimento é um fluxo passivo em que o usuário é redirecionado em um controle de navegador (webview) para a URL dos Termos de Uso do MDM.
Registrar o dispositivo: esta etapa é um fluxo ativo em que o agente do DM OMA do Windows chama o serviço MDM para registrar o dispositivo.

Para dar suporte a Azure AD registro, os fornecedores de MDM devem hospedar e expor um ponto de extremidade termos de uso e um ponto de extremidade de registro MDM.

Termos de Uso ponto de extremidade: use esse ponto de extremidade para informar os usuários sobre as maneiras pelas quais sua organização pode controlar seu dispositivo. A página Termos de Uso é responsável por coletar o consentimento do usuário antes do início da fase de registro real.

É importante entender que o fluxo termos de uso é uma "caixa opaca" para Windows e Azure AD. Toda a exibição da Web é redirecionada para a URL de Termos de Uso. O usuário deve ser redirecionado novamente após aprovar ou rejeitar os Termos. Esse design permite que o fornecedor de MDM personalize seus Termos de Uso para cenários diferentes. Por exemplo, diferentes níveis de controle são aplicados em dispositivos BYOD vs. de propriedade da organização. Ou implemente o direcionamento baseado em usuário/grupo, como usuários em determinadas geografias podem ter políticas de gerenciamento de dispositivos mais rigorosas.

O ponto de extremidade Termos de Uso pode implementar mais lógica de negócios, como coletar um PIN único fornecido por TI para controlar o registro do dispositivo. No entanto, os fornecedores de MDM não devem usar o fluxo Termos de Uso para coletar credenciais de usuário, o que pode ser uma experiência degradada do usuário. Não é necessário, pois parte da integração do MDM garante que o serviço MDM possa entender os tokens emitidos pelo Azure AD.
Ponto de extremidade de registro do MDM: depois que os usuários aceitarem os Termos de Uso, o dispositivo será registrado em Azure AD. O registro automático de MDM começa.

O diagrama a seguir ilustra o fluxo de alto nível envolvido no processo de registro real. O dispositivo é registrado pela primeira vez com Azure AD. Esse processo atribui um identificador de dispositivo exclusivo ao dispositivo e apresenta ao dispositivo a capacidade de se autenticar com Azure AD (autenticação do dispositivo). Em seguida, o dispositivo é registrado para gerenciamento com o MDM. Esta etapa chama o ponto de extremidade de registro e solicita o registro para o usuário e o dispositivo. Neste ponto, o usuário foi autenticado e o dispositivo foi registrado e autenticado com Azure AD. Essas informações estão disponíveis para o MDM na forma de declarações em um token de acesso apresentado no ponto de extremidade de registro.

Espera-se que o MDM use essas informações sobre o dispositivo (ID do dispositivo) ao relatar a conformidade do dispositivo de volta ao Azure AD usando o microsoft API do Graph. Um exemplo para a conformidade do dispositivo de relatório é fornecido posteriormente neste artigo.

Tornar o MDM uma parte confiável do Azure AD

Para participar do fluxo de registro integrado descrito na seção anterior, o MDM deve consumir tokens de acesso emitidos pelo Azure AD. Para relatar a conformidade com Azure AD, o MDM deve autenticar-se para Azure AD e obter autorização na forma de um token de acesso que permita invocar o Microsoft API do Graph.

MDM baseado em nuvem

Um MDM baseado em nuvem é um aplicativo SaaS que fornece recursos de gerenciamento de dispositivos na nuvem. É um aplicativo multilocatário. Esse aplicativo é registrado com Azure AD no locatário doméstico do fornecedor MDM. Quando um administrador de TI decide usar essa solução MDM, uma instância desse aplicativo fica visível no locatário do cliente.

O fornecedor MDM deve primeiro registrar o aplicativo em seu locatário doméstico e marcá-lo como um aplicativo multilocatário. Para obter mais informações sobre como adicionar aplicativos multilocatários a Azure AD, consulte Integrar um aplicativo que autentica usuários e chama o Microsoft Graph usando o exemplo de código saaS (padrão de integração de vários locatários) no GitHub.

Observação

Para o provedor MDM, se você não tiver um locatário Azure AD existente com uma assinatura Azure AD que você gerencia, siga estes guias passo a passo:

Início rápido: crie um novo locatário no Azure Active Directory para configurar um locatário.
Associe ou adicione uma assinatura do Azure ao locatário do Azure Active Directory para adicionar uma assinatura e gerenciá-la por meio do Portal do Azure.

O aplicativo MDM usa chaves para solicitar tokens de acesso de Azure AD. Essas chaves são gerenciadas dentro do locatário do provedor de MDM e não visíveis para clientes individuais. A mesma chave é usada pelo aplicativo MDM de vários locatários para se autenticar com Azure AD, no locatário do cliente onde o dispositivo gerenciado pertence.

Observação

Todos os aplicativos MDM devem implementar Azure AD tokens V2 antes de certificarmos que a integração funciona. Devido a alterações na plataforma de aplicativos Azure AD, usar tokens V2 Azure AD é um requisito difícil. Para obter mais informações, consulte plataforma de identidade da Microsoft tokens de acesso.

MDM local

Um aplicativo MDM local é diferente de um MDM de nuvem. É um aplicativo de locatário único que está presente exclusivamente no locatário do cliente. Os clientes devem adicionar o aplicativo diretamente dentro de seu próprio locatário. Além disso, cada instância de um aplicativo MDM local deve ser registrada separadamente e ter uma chave separada para autenticação com Azure AD.

Para adicionar um aplicativo MDM local ao locatário, use o serviço Azure AD, especificamente em Mobilidade (MDM e MAM)>Adicionar aplicativo>Criar seu próprio aplicativo. Os administradores podem configurar as URLs necessárias para registro e Termos de Uso.

Seu produto MDM local deve expor uma experiência de configuração em que os administradores podem fornecer a ID do cliente, a ID do aplicativo e a chave configurada em seu diretório para esse aplicativo MDM. Você pode usar essa ID do cliente e a chave para solicitar tokens de Azure AD ao relatar a conformidade do dispositivo.

Para obter mais informações sobre como registrar aplicativos com Azure AD, consulte Noções básicas de registro de um aplicativo no Azure AD.

Principais diretrizes de gerenciamento e segurança

As chaves de aplicativo usadas pelo serviço MDM são um recurso confidencial. Eles devem ser protegidos e revertidos periodicamente para maior segurança. Os tokens de acesso obtidos pelo serviço MDM para chamar o Microsoft API do Graph são tokens de portador e devem ser protegidos para evitar a divulgação não autorizada.

Para obter práticas recomendadas de segurança, consulte Microsoft Azure Security Essentials.

Para MDM baseado em nuvem, você pode rolar as chaves do aplicativo sem exigir uma interação do cliente. Há um único conjunto de chaves em todos os locatários de clientes gerenciados pelo fornecedor MDM em seu locatário Azure AD.

Para o MDM local, as chaves de autenticação Azure AD estão dentro do locatário do cliente e o administrador do cliente deve rolar as chaves. Para melhorar a segurança, forneça diretrizes aos clientes sobre como rolar e proteger as chaves.

Publicar seu aplicativo MDM para Azure AD galeria de aplicativos

Os administradores de TI usam a galeria de aplicativos Azure AD para adicionar um MDM para sua organização usar. A galeria de aplicativos é uma loja rica com mais de 2400 aplicativos SaaS integrados ao Azure AD.

Adicionar MDM baseado em nuvem à galeria de aplicativos

Observação

Você deve trabalhar com a equipe de engenharia Azure AD se seu aplicativo MDM for baseado em nuvem e precisar ser habilitado como um aplicativo MDM multilocatário

Para publicar seu aplicativo, envie uma solicitação para publicar seu aplicativo na galeria de aplicativos do Azure Active Directory

A tabela a seguir mostra as informações necessárias para criar uma entrada na galeria de aplicativos Azure AD.

Item	Descrição
ID do aplicativo	A ID do cliente do aplicativo MDM configurada no locatário. Essa ID é o identificador exclusivo do aplicativo multilocatário.
Editor	Uma cadeia de caracteres que identifica o editor do aplicativo.
URL do aplicativo	Uma URL para a página de destino do aplicativo em que seus administradores podem obter mais informações sobre o aplicativo MDM e contém um link para a página de destino do seu aplicativo. Essa URL não é usada para o registro real.
Descrição	Uma breve descrição do aplicativo MDM, que deve ter menos de 255 caracteres.
Ícones	Um conjunto de ícones de logotipo para o aplicativo MDM. Dimensões: 45 X 45, 150 X 122, 214 X 215

Adicionar MDM local à galeria de aplicativos

Não há requisitos especiais para adicionar MDM local à galeria de aplicativos. Há uma entrada genérica para os administradores adicionarem um aplicativo ao locatário.

No entanto, o gerenciamento de chaves é diferente para o MDM local. Você deve obter a ID do cliente (ID do aplicativo) e a chave atribuída ao aplicativo MDM dentro do locatário do cliente. A ID e a chave obtêm autorização para acessar o microsoft API do Graph e relatar a conformidade do dispositivo.

Temas

As páginas renderizadas pelo MDM no processo de registro integrado devem usar modelos do Windows (Baixar os modelos do Windows e arquivos CSS (1.1.4)). Esses modelos são importantes para o registro durante a experiência de junção Azure AD no OOBE, onde todas as páginas são páginas HTML de ponta a ponta. Evite copiar os modelos porque é difícil acertar o posicionamento do botão.

Há três cenários distintos:

Registro de MDM como parte do Azure AD Ingressar no Windows OOBE.
Registro de MDM como parte do Azure AD Ingressar, após o Windows OOBE de Configurações.
Registro de MDM como parte da adição de uma conta de trabalho da Microsoft em um dispositivo pessoal (BYOD).

Esses cenários dão suporte ao Windows Pro, Enterprise e Education.

Os arquivos CSS fornecidos pela Microsoft contêm informações de versão e recomendamos que você use a versão mais recente. Há arquivos CSS separados para dispositivos cliente Windows, OOBE e experiências pós-OOBE. Baixe os modelos do Windows e os arquivos CSS (1.1.4).

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

Usando temas

Uma página MDM deve aderir a um tema predefinido dependendo do cenário exibido. Por exemplo, se o cabeçalho CXH-HOSTHTTP for FRX, que é o cenário OOBE, a página deverá dar suporte a um tema escuro com cor de fundo azul, que usa o arquivo WinJS Ui-dark.css ver 4.0 e oobe-desktop.css ver 1.0.4.

CXH-HOST (CABEÇALHO HTTP)	Cenário	Tema em segundo plano	WinJS	Cenário CSS
FRX	OOBE	Tema escuro + cor de fundo azul	Nome do arquivo: Ui-dark.css	Nome do arquivo: oobe-dekstop.css
MOSET	Configurações/Post OOBE	Tema claro	Nome do arquivo: Ui-light.css	Nome do arquivo: settings-desktop.css

Termos de uso semântica de protocolo

O servidor MDM hospeda o ponto de extremidade Termos de Uso . Durante o fluxo de protocolo de Junção Azure AD, o Windows faz um redirecionamento de página inteira para este ponto de extremidade. Esse redirecionamento permite que o MDM exiba os termos e condições que se aplicam. Ele permite que o usuário aceite ou rejeite os termos associados ao registro. Depois que o usuário aceita os termos, o MDM redireciona de volta ao Windows para que o processo de registro continue.

Redirecionar para o ponto de extremidade Termos de Uso

Esse redirecionamento é um redirecionamento de página inteira para o ponto de extremidade Termos de Usuário hospedados pelo MDM. Aqui está uma URL de exemplo, https://fabrikam.contosomdm.com/TermsOfUse.

Os seguintes parâmetros são passados na cadeia de caracteres de consulta:

Item	Descrição
redirect_uri	Depois que o usuário aceita ou rejeita os Termos de Uso, o usuário é redirecionado para essa URL.
client-request-id	Um GUID que é usado para correlacionar logs para fins de diagnóstico e depuração. Use esse parâmetro para registrar ou rastrear o estado da solicitação de registro para ajudar a encontrar a causa raiz das falhas.
api-version	Especifica a versão do protocolo solicitado pelo cliente. Esse valor fornece um mecanismo para dar suporte a revisões de versão do protocolo.
modo	Especifica que o dispositivo é propriedade da organização quando mode=azureadjoin. Esse parâmetro não está presente para dispositivos BYOD.

Token de acesso

Azure AD emite um token de acesso do portador. O token é passado no cabeçalho de autorização da solicitação HTTP. Aqui está um formato típico:

Autorização: Portador CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw...

As seguintes declarações são esperadas no token de acesso passado pelo Windows para o ponto de extremidade Termos de Uso:

Item	Descrição
ID do objeto	Identificador do objeto de usuário correspondente ao usuário autenticado.
UPN	Uma declaração que contém o UPN (nome da entidade de usuário) do usuário autenticado.
TID	Uma declaração que representa a ID do locatário. No exemplo acima, é Fabrikam.
Recurso	Uma URL higienizada que representa o aplicativo MDM. Exemplo: `https://fabrikam.contosomdm.com`

Observação

Não há nenhuma declaração de ID do dispositivo no token de acesso porque o dispositivo ainda pode não estar registrado no momento.

Para recuperar a lista de associações de grupo para o usuário, você pode usar o Microsoft API do Graph.

Aqui está uma URL de exemplo:

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

Espera-se que o MDM valide a assinatura do token de acesso para garantir que ele seja emitido por Azure AD e que o destinatário seja apropriado.

Termos de uso de conteúdo

O MDM pode fazer outros redirecionamentos conforme necessário antes de exibir o conteúdo termos de uso para o usuário. O conteúdo apropriado dos Termos de Uso deve ser retornado ao chamador (Windows) para que ele possa ser exibido para o usuário final no controle do navegador.

O conteúdo dos Termos de Uso deve conter os seguintes botões:

Aceite – o usuário aceita os Termos de Uso e prossegue com o registro.
Declinar – o usuário recusa e interrompe o processo de registro.

O conteúdo termos de uso deve ser consistente com o tema usado para as outras páginas renderizadas durante esse processo.

Termos de uso da lógica de processamento de ponto de extremidade

Neste ponto, o usuário está na página Termos de Uso mostrada durante o OOBE ou nas experiências de Configuração. O usuário tem as seguintes opções na página:

O usuário clica no botão Aceitar – o MDM deve redirecionar para o URI especificado pelo parâmetro redirect_uri na solicitação de entrada. Os seguintes parâmetros de cadeia de caracteres de consulta são esperados:
- IsAccepted – Esse valor booliano é necessário e deve ser definido como true.
- OpacoBlob – Parâmetro obrigatório se o usuário aceitar. O MDM pode usar esse blob para disponibilizar algumas informações para o ponto de extremidade de registro. O valor persistente aqui é disponibilizado inalterado no ponto de extremidade de registro. O MDM pode usar esse parâmetro para fins de correlação.
- Aqui está um redirecionamento de exemplo - ms-appx-web://MyApp1/ToUResponse?OpaqueBlob=value&IsAccepted=true
O usuário clica no botão Recusar – o MDM deve redirecionar para o URI especificado em redirect_uri na solicitação de entrada. Os seguintes parâmetros de cadeia de caracteres de consulta são esperados:
- IsAccepted – Esse valor booliano é necessário e deve ser definido como false. Essa opção também se aplica se o usuário ignorou os Termos de Uso.
- OpacoBlob – Não é esperado que esse parâmetro seja usado. O registro é interrompido com uma mensagem de erro mostrada ao usuário.

Os usuários ignoram os Termos de Uso quando estão adicionando uma conta de trabalho da Microsoft ao dispositivo. No entanto, eles não podem ignorá-lo durante o processo de Junção Azure AD. Não mostre o botão recusar no processo de junção Azure AD. O usuário não poderá recusar o registro de MDM se configurado pelo administrador do Azure AD Join.

Recomendamos que você envie os parâmetros client-request-id na cadeia de caracteres de consulta como parte dessa resposta de redirecionamento.

Termos de tratamento de erro de uso

Se ocorrer um erro durante os termos de processamento de uso, o MDM poderá retornar dois parâmetros - um e error_description um error parâmetro em sua solicitação de redirecionamento de volta para o Windows. A URL deve ser codificada e o conteúdo do error_description deve estar em texto simples em inglês. Este texto não está visível para o usuário final. Portanto, a localização do error_description texto não é uma preocupação.

Aqui está o formato de 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

A tabela a seguir mostra os códigos de erro.

Causa	HTTP status	Erro	Descrição
api-version	302	invalid_request	versão sem suporte
Os dados do locatário ou do usuário estão ausentes ou outros pré-requisitos necessários para o registro do dispositivo não são atendidos	302	unauthorized_client	usuário ou locatário não autorizado
falha na validação do token Azure AD	302	unauthorized_client	unauthorized_client
erro de serviço interno	302	server_error	erro de serviço interno

Protocolo de registro com Azure AD

Com o registro de MDM integrado do Azure, não há fase de descoberta e a URL de descoberta é diretamente passada para o sistema do Azure. A tabela a seguir mostra a comparação entre os registros tradicionais e do Azure.

Detalhe	Registro de MDM tradicional	Azure AD Ingressar (dispositivo de propriedade da organização)	Azure AD adiciona uma conta de trabalho (dispositivo de propriedade do usuário)
Descoberta automática do MDM usando endereço de email para recuperar URL de descoberta de MDM	Inscrição	Não aplicável URL de descoberta provisionada no Azure
Usa a URL de descoberta de MDM	Inscrição Renovação de registro ROBO	Inscrição Renovação de registro ROBO	Inscrição Renovação de registro ROBO
O registro de MDM é necessário?	Sim	Sim	Não O usuário pode recusar.
Tipo de autenticação	OnPremise Federado Certificado	Federado	Federado
EnrollmentPolicyServiceURL	Opcional (todos os auth)	Opcional (todos os auth)	Opcional (todos os auth)
EnrollmentServiceURL	Obrigatório (todos os auth)	Usado (todos os auth)	Usado (todos os auth)
EnrollmentServiceURL inclui versão do sistema operacional, plataforma do sistema operacional e outros atributos fornecidos pela URL de descoberta do MDM	Altamente recomendado	Altamente recomendado	Altamente recomendado
AuthenticationServiceURL usado	Usado (auth federado)	Ignorada	Ignorada
BinarySecurityToken	Personalizado por MDM	token emitido Azure AD	token emitido Azure AD
EnrollmentType	Completo	Dispositivo	Completo
Tipo de certificado registrado	Certificado de usuário	Certificado de dispositivo	Certificado de usuário
Repositório de certificados registrado	Meu/Usuário	My/System	Meu/Usuário
Nome da entidade CSR	UPN	ID do dispositivo	UPN
EnrollmentData Terms of Use binary blob as AdditionalContext for EnrollmentServiceURL	Sem suporte	Com suporte	Com suporte
CSPs acessíveis durante o registro	Suporte ao Windows 10: - DMClient -Certificatestore - RootCATrustedCertificates - ClientCertificateInstall - EnterpriseModernAppManagement – PassportForWork -Política – w7 APPLICATION

Protocolo de gerenciamento com Azure AD

Há dois tipos diferentes de registro de MDM que se integram ao Azure AD e usam Azure AD identidades de usuário e dispositivo. Dependendo do tipo de registro, o serviço MDM pode precisar gerenciar um único usuário ou vários usuários.

Gerenciamento de vários usuários para dispositivos ingressados em Azure AD

Nesse cenário, o registro de MDM se aplica a cada Azure AD usuário que entra no dispositivo ingressado Azure AD - chame esse tipo de registro de registro um registro de dispositivo ou um registro de vários usuários. O servidor de gerenciamento pode determinar a identidade do usuário, determinar quais políticas são direcionadas para esse usuário e enviar políticas correspondentes para o dispositivo. Para permitir que o servidor de gerenciamento identifique o usuário atual conectado ao dispositivo, o cliente OMA DM usa os tokens de usuário Azure AD. Cada sessão de gerenciamento contém um cabeçalho HTTP extra que contém um token de usuário Azure AD. Essas informações são fornecidas no pacote DM enviado ao servidor de gerenciamento. No entanto, em algumas circunstâncias, Azure AD token de usuário não é enviado para o servidor de gerenciamento. Um desses cenários acontece imediatamente após a conclusão dos registros de MDM durante Azure AD processo de junção. Até que Azure AD processo de junção seja concluído e Azure AD usuário entre no computador, Azure AD token de usuário não esteja disponível para o processo OMA-DM. Normalmente, o registro de MDM é concluído antes de Azure AD usuário entrar no computador e a sessão de gerenciamento inicial não contém um token de usuário Azure AD. O servidor de gerenciamento deve marcar se o token estiver ausente e enviar apenas políticas de dispositivo nesse caso. Outro motivo possível para um token de Azure AD ausente na carga OMA-DM é quando um convidado é conectado ao dispositivo.
Adicionar uma conta de trabalho e registro de MDM a um dispositivo:

Nesse cenário, o registro de MDM se aplica a um único usuário que inicialmente adicionou sua conta de trabalho e registrou o dispositivo. Nesse tipo de registro, o servidor de gerenciamento pode ignorar Azure AD tokens que podem ser enviados durante a sessão de gerenciamento. Se Azure AD token estiver presente ou ausente, o servidor de gerenciamento envia políticas de usuário e dispositivo para o dispositivo.
Avaliando Azure AD tokens de usuário:

O token Azure AD está no cabeçalho de Autorização HTTP no seguinte formato:
```
Authorization:Bearer <Azure AD User Token Inserted here>
```
Mais declarações podem estar presentes no token Azure AD, como:
- Usuário – usuário conectado no momento
- Conformidade do dispositivo – valor definir o serviço MDM no Azure
- ID do dispositivo – identifica o dispositivo que está fazendo check-in
- ID do locatário
Os tokens de acesso emitidos por Azure AD são JWTs (tokens Web JSON). O Windows apresenta um token JWT válido para o ponto de extremidade de registro do MDM para iniciar o processo de registro. Há algumas opções para avaliar os tokens:
- Use a extensão JWT Token Handler para WIF para validar o conteúdo do token de acesso e extrair declarações necessárias para uso. Para obter mais informações, consulte Classe JwtSecurityTokenHandler.
- Consulte os exemplos de código de autenticação Azure AD para obter um exemplo para trabalhar com tokens de acesso. Para obter um exemplo, consulte NativeClient-DotNet.

Alerta de Dispositivo 1224 para Azure AD token de usuário

Um alerta é enviado quando a sessão DM é iniciada e há um Azure AD usuário conectado. O alerta é enviado no pacote OMA DM nº 1. Veja um exemplo:

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 quando um usuário está conectado por meio de sondagem

Um alerta é enviado para o servidor MDM no pacote DM nº 1.

Tipo de alerta – com.microsoft/MDM/LoginStatus
Formato de alerta – chr
Dados de alerta – forneça informações de status de entrada para o usuário atual conectado ativo.
- Usuário conectado que tem uma conta Azure AD – texto predefinido: usuário.
- Usuário conectado sem uma conta Azure AD texto predefinido: outros.
- Nenhum usuário ativo – texto predefinido:nenhum

Veja um exemplo.

<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>

Relatar a conformidade do dispositivo ao Azure AD

Depois que um dispositivo é registrado com o MDM para gerenciamento, as políticas de organização configuradas pelo administrador de TI são impostas no dispositivo. O MDM avalia a conformidade do dispositivo com as políticas configuradas e, em seguida, relata-a para Azure AD. Esta seção aborda o API do Graph chamada que você pode usar para relatar uma status de conformidade do dispositivo para Azure AD.

Para obter um exemplo que ilustra como um MDM pode obter um token de acesso usando OAuth 2.0 client_credentials tipo de concessão, consulte Daemon_CertificateCredential-DotNet.

MDM baseado em nuvem – Se seu produto for um serviço MDM multilocatário baseado em nuvem, você terá uma única chave configurada para seu serviço no locatário. Para obter autorização, use essa chave para autenticar o serviço MDM com Azure AD.
MDM local – Se seu produto for um MDM local, os clientes devem configurar seu produto com a chave usada para autenticar com Azure AD. Essa configuração de chave ocorre porque cada instância local do produto MDM tem uma chave específica do locatário diferente. Portanto, talvez seja necessário expor uma experiência de configuração em seu produto MDM que permita que os administradores especifiquem a chave a ser usada para se autenticar com Azure AD.

Usar o Microsoft API do Graph

A chamada de API REST de exemplo a seguir ilustra como um MDM pode usar o Microsoft API do Graph para relatar a conformidade status de um dispositivo gerenciado.

Observação

Essa API só é aplicável a aplicativos MDM aprovados em dispositivos Windows.

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
}

Onde:

contoso.com - Esse valor é o nome do locatário Azure AD para cujo diretório o dispositivo foi ingressado.
db7ab579-3759-4492-a03f-655ca7f52aae1 - Esse valor é o identificador do dispositivo cujas informações de conformidade estão sendo relatadas ao Azure AD.
eyJ0eXAiO......... – Esse valor é o token de acesso do portador emitido por Azure AD ao MDM que autoriza o MDM a chamar o Microsoft API do Graph. O token de acesso é colocado no cabeçalho de autorização HTTP da solicitação.
isManaged and isCompliant – Esses atributos boolianos indicam conformidade status.
api-version – use esse parâmetro para especificar qual versão da API do grafo está sendo solicitada.

Resposta:

Êxito – HTTP 204 sem conteúdo.
Falha/erro – HTTP 404 não encontrado. Esse erro poderá ser retornado se o dispositivo ou locatário especificado não puder ser encontrado.

Perda de dados durante o cancelamento da inscrição do Azure Active Directory Join

Quando um usuário é registrado no MDM por meio do Azure Active Directory Join e desconecta o registro, não há nenhum aviso de que o usuário perderá dados do Windows Proteção de Informações (WIP). A mensagem de desconexão não indica a perda de dados WIP.

aadj unenrollment.

Códigos de erro

Código	ID	Mensagem de erro
0x80180001	"idErrorServerConnectivity", // MENROLL_E_DEVICE_MESSAGE_FORMAT_ERROR	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x80180002	"idErrorAuthenticationFailure", // MENROLL_E_DEVICE_AUTHENTICATION_ERROR	Houve um problema ao autenticar sua conta ou dispositivo. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180003	"idErrorAuthorizationFailure", // MENROLL_E_DEVICE_AUTHORIZATION_ERROR	Esse usuário não está autorizado a se registrar. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180004	"idErrorMDMCertificateError", // MENROLL_E_DEVICE_CERTIFCATEREQUEST_ERROR	Houve um erro de certificado. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180005	"idErrorServerConnectivity", // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x80180006	"idErrorServerConnectivity", // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x80180007	"idErrorAuthenticationFailure", // MENROLL_E_DEVICE_INVALIDSECURITY_ERROR	Houve um problema ao autenticar sua conta ou dispositivo. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180008	"idErrorServerConnectivity", // MENROLL_E_DEVICE_UNKNOWN_ERROR	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x80180009	"idErrorAlreadyInProgress", // MENROLL_E_ENROLLMENT_IN_PROGRESS	Outro registro está em andamento. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x8018000A	"idErrorMDMAlreadyEnrolled", // MENROLL_E_DEVICE_ALREADY_ENROLLED	Esse dispositivo já está registrado. Você pode entrar em contato com o administrador do sistema com o código de {0}erro .
0x8018000D	"idErrorMDMCertificateError", // MENROLL_E_DISCOVERY_SEC_CERT_DATE_INVALID	Houve um erro de certificado. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x8018000E	"idErrorAuthenticationFailure", // MENROLL_E_PASSWORD_NEEDED	Houve um problema ao autenticar sua conta ou dispositivo. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x8018000F	"idErrorAuthenticationFailure", // MENROLL_E_WAB_ERROR	Houve um problema ao autenticar sua conta ou dispositivo. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180010	"idErrorServerConnectivity", // MENROLL_E_CONNECTIVITY	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x80180012	"idErrorMDMCertificateError", // MENROLL_E_INVALIDSSLCERT	Houve um erro de certificado. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180013	"idErrorDeviceLimit", // MENROLL_E_DEVICECAPREACHED	Parece que há muitos dispositivos ou usuários para essa conta. Contate o administrador do sistema com o código de {0}erro .
0x80180014	"idErrorMDMNotSupported", // MENROLL_E_DEVICENOTSUPPORTED	Esse recurso não tem suporte. Contate o administrador do sistema com o código de {0}erro .
0x80180015	"idErrorMDMNotSupported", // MENROLL_E_NOTSUPPORTED	Esse recurso não tem suporte. Contate o administrador do sistema com o código de {0}erro .
0x80180016	"idErrorMDMRenewalRejected", // MENROLL_E_NOTELIGIBLETORENEW	O servidor não aceitou a solicitação. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180017	"idErrorMDMAccountMaintenance", // MENROLL_E_INMAINTENANCE	O serviço está em manutenção. Você pode tentar fazer isso novamente mais tarde ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180018	"idErrorMDMLicenseError", // MENROLL_E_USERLICENSE	Houve um erro com sua licença. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x80180019	"idErrorInvalidServerConfig", // MENROLL_E_ENROLLMENTDATAINVALID	Parece que o servidor não está configurado corretamente. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
"rejectedTermsOfUse"	"idErrorRejectedTermsOfUse"	Sua organização exige que você concorde com os Termos de Uso. Tente novamente ou peça mais informações à sua pessoa de suporte.
0x801c0001	"idErrorServerConnectivity", // DSREG_E_DEVICE_MESSAGE_FORMAT_ERROR	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x801c0002	"idErrorAuthenticationFailure", // DSREG_E_DEVICE_AUTHENTICATION_ERROR	Houve um problema ao autenticar sua conta ou dispositivo. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x801c0003	"idErrorAuthorizationFailure", // DSREG_E_DEVICE_AUTHORIZATION_ERROR	Esse usuário não está autorizado a se registrar. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x801c0006	"idErrorServerConnectivity", // DSREG_E_DEVICE_INTERNALSERVICE_ERROR	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x801c000B	"idErrorUntrustedServer", // DSREG_E_DISCOVERY_REDIRECTION_NOT_TRUSTED	O servidor que está sendo contatado não é confiável. Contate o administrador do sistema com o código de {0}erro .
0x801c000C	"idErrorServerConnectivity", // DSREG_E_DISCOVERY_FAILED	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x801c000E	"idErrorDeviceLimit", // DSREG_E_DEVICE_REGISTRATION_QUOTA_EXCCEEDED	Parece que há muitos dispositivos ou usuários para essa conta. Contate o administrador do sistema com o código de {0}erro .
0x801c000F	"idErrorDeviceRequiresReboot", // DSREG_E_DEVICE_REQUIRES_REBOOT	Uma reinicialização é necessária para concluir o registro do dispositivo.
0x801c0010	"idErrorInvalidCertificate", // DSREG_E_DEVICE_AIK_VALIDATION_ERROR	Parece que você tem um certificado inválido. Contate o administrador do sistema com o código de {0}erro .
0x801c0011	"idErrorAuthenticationFailure", // DSREG_E_DEVICE_ATTESTATION_ERROR	Houve um problema ao autenticar sua conta ou dispositivo. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x801c0012	"idErrorServerConnectivity", // DSREG_E_DISCOVERY_BAD_MESSAGE_ERROR	Houve um erro de comunicação com o servidor. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de erro {0}
0x801c0013	"idErrorAuthenticationFailure", // DSREG_E_TENANTID_NOT_FOUND	Houve um problema ao autenticar sua conta ou dispositivo. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .
0x801c0014	"idErrorAuthenticationFailure", // DSREG_E_USERSID_NOT_FOUND	Houve um problema ao autenticar sua conta ou dispositivo. Você pode tentar fazer isso novamente ou entrar em contato com o administrador do sistema com o código de {0}erro .

Integração do Azure Active Directory com o MDM

Registro de MDM integrado e UX

Pontos de extremidade MDM envolvidos em Azure AD registro integrado

Tornar o MDM uma parte confiável do Azure AD

MDM baseado em nuvem

MDM local

Principais diretrizes de gerenciamento e segurança

Publicar seu aplicativo MDM para Azure AD galeria de aplicativos

Adicionar MDM baseado em nuvem à galeria de aplicativos

Adicionar MDM local à galeria de aplicativos

Temas

Usando temas

Termos de uso semântica de protocolo

Redirecionar para o ponto de extremidade Termos de Uso

Token de acesso

Termos de uso de conteúdo

Termos de uso da lógica de processamento de ponto de extremidade

Termos de tratamento de erro de uso

Protocolo de registro com Azure AD

Protocolo de gerenciamento com Azure AD

Alerta de Dispositivo 1224 para Azure AD token de usuário

Determinar quando um usuário está conectado por meio de sondagem

Relatar a conformidade do dispositivo ao Azure AD

Usar o Microsoft API do Graph

Perda de dados durante o cancelamento da inscrição do Azure Active Directory Join

Códigos de erro

Recursos adicionais

Recursos adicionais