Integração do Microsoft Entra com o MDM

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

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

• Pode impor conformidade com as políticas da organização, adicionar ou remover aplicativos e muito mais.
• Pode relatar a conformidade de um dispositivo no Microsoft Entra ID.
• Pode permitir o acesso a recursos da organização ou aplicativos protegidos pelo Microsoft Entra ID para dispositivos que estão 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 Microsoft Entra ID.

Registro de MDM integrado e experiência do usuário

Há várias maneiras de conectar seus dispositivos ao Microsoft Entra ID:

• Ingressar dispositivo no Microsoft Entra ID
• Ingressar o dispositivo no AD local e no Microsoft Entra ID
• Adicionar uma conta corporativa da Microsoft ao Windows

Em cada cenário, o Microsoft Entra autentica o usuário e o dispositivo. Ele fornece um identificador de dispositivo exclusivo e verificado que pode ser usado para o registro no MDM. O fluxo de registro fornece uma oportunidade para o serviço MDM renderizar sua própria interface do usuário, usando um modo de 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 (traga seu próprio dispositivo) e de propriedade da empresa. Os fornecedores de MDM também podem usar o modo de exibição da Web para renderizar mais elementos da interface do usuário, como solicitar um PIN único.

No Windows 10, o modo de exibição da Web durante o cenário pronto para uso é exibido em tela inteira por padrão, fornecendo aos fornecedores de MDM a capacidade de criar uma experiência de usuário perfeita de ponta a ponta. No entanto, no Windows 11, o modo de exibição da Web é renderizado em um iframe. É importante que os fornecedores de MDM que se integram ao Microsoft Entra ID respeitem as diretrizes de design do Windows. Essa etapa inclui o uso de um design da Web responsivo e o respeito às diretrizes de acessibilidade do Windows. Por exemplo, inclua os botões avançar e voltar que estão corretamente conectados à lógica de navegação. Mais detalhes são fornecidos posteriormente neste artigo.

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

Quando um usuário tiver uma conta do Microsoft Entra adicionada ao Windows e registrada no MDM, o registro poderá ser gerenciado por meio de Configurações>Contas>Acesso corporativo ou de estudante. O gerenciamento de dispositivos do ingresso no Microsoft Entra para cenários de organização ou cenários BYOD é semelhante.

Pontos de extremidade MDM envolvidos no registro integrado do Microsoft Entra

O registro no MDM do Microsoft Entra é um processo de duas etapas:

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

Para dar suporte ao registro no Microsoft Entra, os fornecedores de MDM devem hospedar e expor um ponto de extremidade de Termos de Uso e um ponto de extremidade de registro deMDM.

• Ponto de extremidade dos Termos de Uso: use esse ponto de extremidade para informar os usuários sobre as maneiras pelas quais sua organização pode controlar o 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 dos Termos de Uso é uma "caixa opaca" para o Windows e o Microsoft Entra ID. Toda a exibição da Web é redirecionada para a URL dos Termos de Uso. O usuário deve ser redirecionado de volta após aprovar ou rejeitar os Termos. Esse design permite que o fornecedor do MDM personalize seus Termos de Uso para cenários diferentes. Por exemplo, diferentes níveis de controle são aplicados em dispositivos BYOD versus dispositivos de propriedade da organização. Ou implemente o direcionamento baseado em usuário/grupo, como usuários em determinadas regiões geográficas podem ter políticas de gerenciamento de dispositivo mais rígidas.

  O ponto de extremidade dos Termos de Uso pode implementar mais lógica de negócios, como coletar um PIN único fornecido pela TI para controlar o registro do dispositivo. No entanto, os fornecedores de MDM não devem usar o fluxo de Termos de Uso para coletar credenciais de usuário, o que pode ser uma experiência de usuário prejudicada. Não é necessário, pois parte da integração do MDM garante que o serviço MDM possa entender os tokens emitidos pelo Microsoft Entra ID.

• Ponto de extremidade de registro no MDM: depois que os usuários aceitarem os Termos de Uso, o dispositivo será registrado no Microsoft Entra ID. O registro automático no MDM é iniciado.

  O diagrama a seguir ilustra o fluxo de alto nível envolvido no processo de registro real. O dispositivo é registrado pela primeira vez com o Microsoft Entra ID. Esse processo atribui um identificador de dispositivo exclusivo ao dispositivo e apresenta ao dispositivo a capacidade de se autenticar com o Microsoft Entra ID (autenticação de 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 o Microsoft Entra ID. 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 do registro.

  

  Espera-se que o MDM use essas informações sobre o dispositivo (ID do Dispositivo) ao relatar a conformidade do dispositivo para o Microsoft Entra ID usando a API do Graph. Um exemplo para relatar a conformidade do dispositivo é fornecido mais adiante neste artigo.

Torne o MDM uma parte confiável do Microsoft Entra ID

Para participar do fluxo de registro integrado descrito na seção anterior, o MDM deve consumir tokens de acesso emitidos pelo Microsoft Entra ID. Para relatar a conformidade com o Microsoft Entra ID, o MDM deve autenticar-se no Microsoft Entra ID e obter autorização na forma de um token de acesso que permita invocar a 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. Este aplicativo está registrado com o Microsoft Entra ID no locatário inicial do fornecedor de MDM. Quando um administrador de TI decide usar essa solução MDM, uma instância desse aplicativo se torna visível no locatário do cliente.

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

O aplicativo MDM usa chaves para solicitar tokens de acesso do Microsoft Entra ID. Essas chaves são gerenciadas dentro do locatário do provedor MDM e não são visíveis para clientes individuais. A mesma chave é usada pelo aplicativo MDM multilocatário para autenticar-se com o Microsoft Entra ID, no locatário do cliente ao qual o dispositivo gerenciado pertence.

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 em 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 o Microsoft Entra ID.

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

Seu produto MDM local deve expor uma experiência de configuração em que os administradores possam fornecer a ID do cliente (também conhecida como ID do aplicativo) e a chave configurada em seu diretório para esse aplicativo MDM. Você pode usar essa ID de cliente e chave para solicitar tokens do Microsoft Entra ID ao relatar a conformidade do dispositivo.

Para obter mais informações sobre como registrar aplicativos com o Microsoft Entra ID, consulte Noções básicas de como registrar um aplicativo no Microsoft Entra ID.

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 rolados periodicamente para maior segurança. Os tokens de acesso obtidos pelo serviço MDM para chamar a API do Graph Microsoft são tokens de portador e devem ser protegidos para evitar a divulgação não autorizada.

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

Para o MDM baseado em nuvem, você pode sobrepor as chaves do aplicativo sem a necessidade de uma interação com o cliente. Há um único conjunto de chaves em todos os locatários do cliente gerenciados pelo fornecedor do MDM em seu locatário do Microsoft Entra.

Para o MDM local, as chaves de autenticação do Microsoft Entra estão dentro do locatário do cliente e o administrador do cliente deve transferir as chaves. Para melhorar a segurança, forneça orientações aos clientes sobre a transferência e a proteção das chaves.

Publicar seu aplicativo MDM na galeria de aplicativos do Microsoft Entra

Os administradores de TI usam a galeria de aplicativos do Microsoft Entra para adicionar um MDM para sua organização usar. A galeria de aplicativos é uma loja avançada com mais de 2.400 aplicativos SaaS integrados ao Microsoft Entra ID.

Adicionar o MDM baseado em nuvem à galeria de aplicativos

Para publicar seu aplicativo, envie uma solicitação para publicar seu aplicativo na galeria de aplicativos do Microsoft Entra

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

Adicionar o MDM local à galeria de aplicativos

Não há requisitos especiais para adicionar o 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 no locatário do cliente. A ID e a chave obtêm autorização para acessar a 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 (baixe os modelos do Windows e arquivos CSS (1.1.4)). Esses modelos são importantes para o registro durante a experiência de ingresso do Microsoft Entra no OOBE, onde todas as páginas são páginas HTML de ponta a ponta. Evite copiar os modelos, pois é difícil acertar o posicionamento do botão.

Há três cenários distintos:

1. Registro no MDM como parte do ingresso no Microsoft Entra no Windows OOBE.
2. Registro no MDM como parte do ingresso no Microsoft Entra, após o Windows OOBE nas Configurações.
3. Registro no MDM como parte da adição de uma conta corporativa da Microsoft em um BYOD (dispositivo pessoal).

Esses cenários são compatíveis com 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.

Termos de Uso semântica do protocolo

O servidor MDM hospeda o ponto de extremidade dos Termos de Uso . Durante o fluxo do protocolo de ingresso do Microsoft Entra, o Windows faz um redirecionamento de página inteira para esse ponto de extremidade. Esse redirecionamento permite que o MDM exiba os termos e condições aplicáveis. Ele permite que o usuário aceite ou rejeite os termos associados ao registro. Depois que o usuário aceitar os termos, o MDM será redirecionado de volta ao Windows para que o processo de registro continue.

Redirecionamento para o ponto de extremidade dos Termos de Uso

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

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

Token de acesso

O Microsoft Entra ID emite um token de acesso de 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 dos Termos de Uso:

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

Aqui está um exemplo de URL:

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 pelo Microsoft Entra ID e que o destinatário seja apropriado.

Conteúdo dos Termos de Uso

O MDM pode fazer outros redirecionamentos adicionais conforme necessário antes de exibir o conteúdo dos Termos de Uso para o usuário. O conteúdo apropriado dos Termos de Uso deve ser retornado ao chamador (Windows) para que 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:

• Aceitar - o usuário aceita os Termos de Uso e prossegue com a inscrição.
• Recusar - o usuário recusa e interrompe o processo de inscrição.

O conteúdo dos Termos de Uso deve ser consistente com o tema utilizado para as demais páginas renderizadas durante este processo.

Termos de Uso 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.
  • OpaqueBlob - Parâmetro necessá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 mantido aqui é disponibilizado inalterado no ponto de extremidade de registro. O MDM pode usar esse parâmetro para fins de correlação.
  • Aqui está um exemplo de redirecionamento - 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 no redirect_uri na solicitação de entrada. Os seguintes parâmetros de cadeia de caracteres de consulta são esperados:
  • IsAccepted - Este 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.
  • OpaqueBlob – não se espera que esse parâmetro seja usado. O registro é interrompido com uma mensagem de erro mostrada para o usuário.

Os usuários ignoram os Termos de Uso ao adicionar uma conta corporativa da Microsoft ao dispositivo. No entanto, eles não podem ignorá-lo durante o processo de ingresso no Microsoft Entra. Não mostrar o botão de recusar no processo de ingresso do Microsoft Entra. O usuário não poderá recusar o registro no MDM se configurado pelo administrador para o ingresso do Microsoft Entra.

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

Termos de Uso Tratamento de erros

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

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

Protocolo de registro com o Microsoft Entra ID

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

Protocolo de gerenciamento com o Microsoft Entra ID

Há dois tipos diferentes de registro no MDM que se integram ao Microsoft Entra ID e usam identidades de usuário e dispositivo do Microsoft Entra. 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 no Microsoft Entra

  Nesse cenário, o registro no MDM se aplica a todos os usuários do Microsoft Entra que entrar no dispositivo ingressado no Microsoft Entra – chame esse tipo de registro de dispositivo ou registro multiusuário. 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 ao dispositivo. Para permitir que o servidor de gerenciamento identifique o usuário atual conectado ao dispositivo, o OMA DMClient usa os tokens de usuário do Microsoft Entra. Cada sessão de gerenciamento contém um cabeçalho HTTP extra que contém um token de usuário do Microsoft Entra. Essas informações são fornecidas no pacote DM enviado ao servidor de gerenciamento. No entanto, em algumas circunstâncias, o token de usuário do Microsoft Entra não é enviado para o servidor de gerenciamento. Um desses cenários ocorre imediatamente após o término dos registros no MDM durante o processo de ingresso no Microsoft Entra. Até que o processo de ingresso no Microsoft Entra seja concluído e o usuário do Microsoft Entra entre no computador, o token de usuário do Microsoft Entra não estará disponível para o processo OMA-DM. Normalmente, o registro no MDM é concluído antes que o usuário do Microsoft Entra entre no computador e a sessão de gerenciamento inicial não contenha um token de usuário do Microsoft Entra. O servidor de gerenciamento deve marcar se o token está ausente e enviar políticas de dispositivo apenas nesse caso. Outro possível motivo para a falta de um token do Microsoft Entra no conteúdo do OMA-DM é quando um convidado está conectado ao dispositivo.

• Adicionando uma conta corporativa e um registro no MDM a um dispositivo:

  Nesse cenário, o registro no MDM se aplica a um único usuário que inicialmente adicionou sua conta corporativa e registrou o dispositivo. Nesse tipo de registro, o servidor de gerenciamento pode ignorar os tokens do Microsoft Entra que podem ser enviados durante a sessão de gerenciamento. Se o token do Microsoft Entra estiver presente ou ausente, o servidor de gerenciamento enviará políticas de usuário e de dispositivo para o dispositivo.

• Avaliando tokens de usuário do Microsoft Entra:

  O token do Microsoft Entra 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 do Microsoft Entra, como:

  • Usuário - usuário conectado no momento
  • Conformidade do dispositivo - valor: defina 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 pelo Microsoft Entra ID são tokens Web JSON (JWTs). O Windows apresenta um token JWT válido ao ponto de extremidade de registro no MDM para iniciar o processo de registro. Há algumas opções para avaliar os tokens:

  • Use a extensão do manipulador de token JWT para WIF para validar o conteúdo do token de acesso e extrair as declarações necessárias para uso. Para obter mais informações, consulte Classe JwtSecurityTokenHandler.
  • Consulte os exemplos de código de autenticação do Microsoft Entra para obter um exemplo para trabalhar com tokens de acesso. Para obter um exemplo, consulte NativeClient-DotNet.

Alerta de dispositivo 1224 para token de usuário do Microsoft Entra

Um alerta é enviado quando a sessão DM é iniciada e há um usuário do Microsoft Entra conectado. O alerta é enviado no pacote OMA DM #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 ao servidor MDM no pacote DM #1.

• Tipo de alerta – com.microsoft/MDM/LoginStatus
• Formato do alerta – chr
• Dados de alerta - fornece informações de status de entrada para o usuário conectado ativo no momento.
  • Usuário conectado que tem uma conta do Microsoft Entra – texto predefinido: usuário.
  • Usuário conectado sem uma conta do Microsoft Entra- 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 conformidade do dispositivo ao Microsoft Entra ID

Depois que um dispositivo é registrado no MDM para gerenciamento, as políticas da 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 a informa ao Microsoft Entra ID. Esta seção aborda a chamada à API do Graph que você pode usar para relatar um status de conformidade do dispositivo ao Microsoft Entra ID.

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

• MDM baseado em nuvem – se o seu produto for um serviço MDM multilocatário baseado em nuvem, você terá uma única chave configurada para seu serviço em seu locatário. Para obter autorização, use essa chave para autenticar o serviço MDM com o Microsoft Entra ID.
• MDM local – se o seu produto for um MDM local, os clientes deverão configurar seu produto com a chave usada para autenticar com o Microsoft Entra ID. Essa configuração de chave ocorre porque cada instância local do seu 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 autenticar com o Microsoft Entra ID.

Usar a API do Graph

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

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 Microsoft Entra em cujo diretório o dispositivo foi ingressado.
• db7ab579-3759-4492-a03f-655ca7f52ae1 - Esse valor é o identificador do dispositivo cujas informações de conformidade estão sendo relatadas ao Microsoft Entra ID.
• eyJ0eXAiO......... - esse valor é o token de acesso de portador emitido pelo Microsoft Entra ID para o 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 e isCompliant - esses atributos boolianos indicam o status de conformidade.
• api-version – Use esse parâmetro para especificar qual versão da API do graph 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 do registro do ingresso no Microsoft Entra

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

Códigos de erro