Integração do Azure Active Directory com o MDM

O Azure Active Directory é o maior serviço de gerenciamento de identidade de nuvem corporativa do mundo. Ele é usado por organizações para acessar Office 365 e aplicativos empresariais da Microsoft e fornecedores saaS (software de terceiros como serviço). Muitas das experiências de Windows 10 avançadas 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. Este artigo descreve as etapas envolvidas.

Conecte-se ao Azure AD

Várias maneiras de conectar seus dispositivos:

Para dispositivos de propriedade da empresa:

  • Unir o Windows a um domínio tradicional do Active Directory
  • Ingressar no Windows para Azure AD

Para dispositivos pessoais (BYOD):

  • Adicionar uma conta de trabalho da Microsoft ao Windows

Ingressar no Azure AD

Os dispositivos de propriedade da empresa são tradicionalmente unidos ao domínio Active Directory local da organização. Esses dispositivos podem ser gerenciados usando Política de Grupo ou software de gerenciamento de computadores, como o Microsoft Configuration Manager. Em Windows 10, também é possível gerenciar dispositivos ingressados no domínio com um MDM.

Windows 10 apresenta uma nova maneira de configurar e implantar dispositivos Windows de propriedade da organização. Esse mecanismo é chamado Azure AD Ingressar. Como a junção de domínio tradicional, Azure AD Join permite que os dispositivos se tornem conhecidos e gerenciados por uma organização. No entanto, com Azure AD Ingressar, o Windows autentica para Azure AD em vez de se autenticar em um controlador de domínio.

Azure AD Join também permite que dispositivos de propriedade da empresa sejam registrados automaticamente e gerenciados por um MDM. Além disso, Azure AD Join pode ser executado em um computador comprado na loja, na OOBE (experiência fora de caixa), o que ajuda as organizações a simplificar sua implantação de dispositivo. Um administrador pode exigir que os usuários pertencentes a um ou mais grupos registrem seus dispositivos para gerenciamento com um MDM. Se um usuário estiver configurado para exigir o registro automático durante Azure AD Ingressar, esse registro se tornará uma etapa obrigatória para configurar o Windows. Se o registro de MDM falhar, o dispositivo não será ingressado no Azure AD.

Importante

Cada usuário habilitado para registro automático de MDM com Azure AD Join deve receber uma licença de Azure Active Directory Premium válida.

Cenário BYOD

Windows 10 também introduz uma maneira mais simples de configurar dispositivos pessoais para acessar aplicativos e recursos de trabalho. Os usuários podem adicionar sua conta de trabalho da Microsoft ao Windows e desfrutar de acesso mais simples e seguro aos aplicativos e recursos da organização. Durante esse processo, Azure AD detecta se a organização configurou um MDM. Se esse for o caso, o Windows tentará registrar o dispositivo no MDM como parte do fluxo "adicionar conta". No caso BYOD, os usuários podem rejeitar os Termos de Uso do MDM. O dispositivo não está registrado no MDM e o acesso aos recursos da organização normalmente é restrito.

Registro de MDM integrado e UX

Dois cenários de registro de MDM Azure AD:

  • Ingressar em um dispositivo para Azure AD para dispositivos de propriedade da empresa
  • Adicionar uma conta de trabalho a um dispositivo pessoal (BYOD)

Em ambos os cenários, 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.

Em ambos os cenários, o fluxo de registro oferece uma oportunidade para que o serviço MDM renderize 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 e de propriedade da empresa. 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 cenário fora da caixa, a exibição da Web é 100% tela inteira, o que dá ao fornecedor de MDM a capacidade de pintar uma experiência de borda a ponta. Com grande poder vem grande responsabilidade! É 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 solução #2 em 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 doacesso ao Trabalho 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 de acesso ao trabalho porque o gerenciamento está vinculado à conta de trabalho ou Azure AD.

Pontos de extremidade MDM envolvidos no registro integrado Azure AD

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

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

  2. Registre o dispositivo.

    Essa etapa é um fluxo ativo em que o agente de DM do Windows OMA 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.

Ponto de extremidade Termos de Uso Use esse ponto de extremidade para informar os usuários sobre as maneiras pelas quais seu dispositivo pode ser controlado por sua organização. 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. Essa 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.

fluxo de registro de anúncios do azure.

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.

Adicionar um 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. Aqui um exemplo de código do GitHub que explica como adicionar aplicativos multilocatários ao Azure AD, WepApp-WebAPI-MultiTenant-OpenIdConnect-DotNet.

Observação

Para o provedor MDM, se você não tiver um locatário Azure AD existente com uma assinatura Azure AD gerenciada, siga o guia passo a passo em Adicionar um locatário Azure AD e Azure AD assinatura para configurar um locatário, 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, seja qual for o locatário do cliente que 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.

Use as etapas a seguir para registrar um aplicativo MDM baseado em nuvem com Azure AD. Neste momento, você precisa trabalhar com a equipe de engenharia Azure AD para expor esse aplicativo por meio da galeria de aplicativos Azure AD.

  1. Faça logon no Portal de Gerenciamento do Azure usando uma conta de administrador em seu locatário doméstico.

  2. Na navegação à esquerda, selecione Active Directory.

  3. Selecione o locatário do diretório em que você deseja registrar o aplicativo.

    Verifique se você está conectado ao locatário da casa.

  4. Selecione a guia Aplicativos .

  5. Na gaveta, selecione Adicionar.

  6. Selecione Adicionar um aplicativo que minha organização está desenvolvendo.

  7. Insira um nome amigável para o aplicativo, como ContosoMDM, selecione Aplicativo Web e ou API Web e selecione Avançar.

  8. Insira a URL do logon do serviço MDM.

  9. Para a ID do aplicativo, insira https://<your_tenant_name>/ContosoMDM, em seguida, selecione OK.

  10. Enquanto ainda estiver no portal do Azure, selecione a guia Configurar do aplicativo.

  11. Marque seu aplicativo como multilocatário.

  12. Encontre o valor da ID do cliente e copie-o.

    Você precisará dessa ID mais tarde ao configurar seu aplicativo. Essa ID do cliente é usada ao obter tokens de acesso e adicionar aplicativos à galeria de aplicativos Azure AD.

  13. Gere uma chave para seu aplicativo e copie-a.

    Você precisa dessa chave para chamar o Microsoft API do Graph para relatar a conformidade do dispositivo. Essas informações são abordadas na próxima seção.

Para obter mais informações sobre como registrar um aplicativo de exemplo com Azure AD, confira as etapas para registrar a API Web TodoListService em NativeClient-DotNet.

Adicionar um 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 tem 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. 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 registrar 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 melhores práticas de segurança, consulte Windows Azure Security Essentials.

Você pode rolar as chaves de aplicativo usadas por um serviço de MDM baseado em nuvem sem exigir uma interação do cliente. Há um único conjunto de chaves em todos os locatários de clientes que são 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 devem ser revertidas pelo administrador do cliente. Para melhorar a segurança, forneça diretrizes aos clientes sobre rolagem e proteção das 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.

A imagem a seguir mostra como os aplicativos MDM aparecem na galeria de aplicativos do Azure.

azure ad adicionar um aplicativo para mdm.

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

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 o administrador adicionar 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 de thee e a chave obtêm autorização para acessar o microsoft API do Graph e para 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 registro durante a Azure AD experiência de junção no OOBE, em que todas as páginas são páginas HTML de ponta a ponta. Não tente copiar os modelos porque você nunca obterá o posicionamento do botão direito.

Há três cenários distintos:

  1. Registro de MDM como parte do Azure AD Ingressar no Windows OOBE.
  2. Registro de MDM como parte do Azure AD Ingressar, após o Windows OOBE de Configurações.
  3. 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 cliente do 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 ponto de extremidade Termos de Uso é hospedado pelo servidor MDM. 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 foi emitido por Azure AD e garantir 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 redirecionamento_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 redirecionamento_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 registro de MDM não poderá ser recusado pelo usuário se configurado pelo administrador para a junção do Azure AD.

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 erro e um parâmetro error_description em sua solicitação de redirecionamento de volta para o Windows. A URL deve ser codificada e o conteúdo do erro_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 texto de descrição do erro 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 Status HTTP 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 Windows 10 suporte:
- 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 usuário Azure AD que entra no dispositivo ingressado Azure AD - chame esse tipo de registro de 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 verificar se o token está 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 usuário convidado está 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). Um token JWT válido é apresentado pelo Windows no 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 OMA DM pkg#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#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. A conformidade do dispositivo com políticas configuradas é avaliada pelo MDM e, em seguida, relatada a Azure AD. Esta seção aborda o API do Graph chamada que você pode usar para relatar um status de conformidade do dispositivo para Azure AD.

Para obter um exemplo que ilustra como um MDM pode obter um token de acesso usando o tipo de concessão do OAuth 2.0_credentials, 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 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 o status de conformidade de um dispositivo que está sendo gerenciado por ele.

Observação

Essa API só é aplicável a aplicativos MDM aprovados em 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
}

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 pelo 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 o status de conformidade.
  • 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 .