Registro de dispositivos de autenticação federada

Esta seção fornece um exemplo do protocolo de registro de dispositivo móvel usando a política de autenticação federada. Quando a política de autenticação é definida como Federada, o agente de autenticação da Web é usado pelo cliente de registro para obter um token de segurança. O cliente de registro chama a API do agente de autenticação da Web na mensagem de resposta para iniciar o processo. O servidor deve criar as páginas do agente de autenticação da Web para se ajustarem à tela do dispositivo e devem ser consistentes com a IU de registro existente. O token de segurança opaco que é retornado do agente como uma página final é usado pelo cliente de registro como o segredo de segurança do dispositivo durante a chamada de solicitação de certificado do cliente.

O <AuthenticationServiceURL> elemento que especifica a URL inicial da página do agente de autenticação da Web.

Para obter detalhes sobre o protocolo de registro de dispositivo móvel da Microsoft para Windows, consulte [MS-MDE2]: Protocolo de Registro de Dispositivo Móvel Versão 2.

Observação

Para obter a lista de cenários de registro sem suporte no Windows, consulte Cenários de registro sem suporte.

Serviço de descoberta

O serviço Web de descoberta fornece as informações de configuração necessárias para que um usuário registre um telefone em um serviço de gerenciamento. O serviço é um serviço Web restful sobre HTTPS (somente autenticação de servidor).

Observação

O administrador do serviço de descoberta deve criar um host com o endereço enterpriseenrollment.<domain_name>.com.

O fluxo de descoberta automática do dispositivo usa o nome de domínio do endereço de email que foi enviado para a tela de configurações do Local de trabalho durante a entrada. O sistema de descoberta automática constrói um URI que usa esse nome de host anexando o subdomínio enterpriseenrollment ao domínio do endereço de email e anexando o caminho /EnrollmentServer/Discovery.svc. Por exemplo, se o endereço de email for sample@contoso.com, o URI resultante para a primeira solicitação Get seria: http://enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc.

A primeira solicitação é uma solicitação HTTP GET padrão.

O exemplo a seguir mostra uma solicitação via HTTP GET para o servidor de descoberta fornecido user@contoso.com como o endereço de e-mail.

Request Full Url: http://EnterpriseEnrollment.contoso.com/EnrollmentServer/Discovery.svc
Content Type: unknown
Header Byte Count: 153
Body Byte Count: 0

GET /EnrollmentServer/Discovery.svc HTTP/1.1
User-Agent: Windows Phone 8 Enrollment Client
Host: EnterpriseEnrollment.contoso.com
Pragma: no-cache

Request Full Url: http://EnterpriseEnrollment.contoso.com/EnrollmentServer/Discovery.svc
Content Type: text/html
Header Byte Count: 248
Body Byte Count: 0

HTTP/1.1 200 OK
Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 0

Depois que o dispositivo obtém uma resposta do servidor, ele envia uma solicitação POST para enterpriseenrollment.<domain_name>/EnrollmentServer/Discovery.svc. Depois de obter outra resposta do servidor (que deve informar ao dispositivo onde está o servidor de registro), a próxima mensagem enviada do dispositivo é para enterpriseenrollment.<domain_name> o servidor de registro.

A seguinte lógica é aplicada:

  1. Primeiro, o dispositivo tenta HTTPS. Se o dispositivo não confiar no certificado do servidor, a tentativa de HTTPS falhará.
  2. Se isso falhar, o dispositivo tentará HTTP para ver se ele foi redirecionado:
    • Se o dispositivo não for redirecionado, o usuário será solicitado a fornecer o endereço do servidor.
    • Se o dispositivo for redirecionado, o usuário será solicitado a permitir o redirecionamento.

O exemplo a seguir mostra uma solicitação por meio de um comando HTTP POST para o serviço Web de descoberta fornecido user@contoso.com como o endereço de email

https://EnterpriseEnrollment.Contoso.com/EnrollmentServer/Discovery.svc

O exemplo a seguir mostra a solicitação de serviço de descoberta.

<?xml version="1.0"?>
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Header>
        <a:Action s:mustUnderstand="1">
            http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/Discover
        </a:Action>
        <a:MessageID>urn:uuid: 748132ec-a575-4329-b01b-6171a9cf8478</a:MessageID>
        <a:ReplyTo>
            <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
        </a:ReplyTo>
        <a:To s:mustUnderstand="1">
            https://ENROLLTEST.CONTOSO.COM/EnrollmentServer/Discovery.svc
        </a:To>
    </s:Header>
    <s:Body>
        <Discover xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment/">
            <request xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
                <EmailAddress>user@contoso.com</EmailAddress>
                <OSEdition>3</OSEdition>
                <!-- New -->
                <RequestVersion>3.0</RequestVersion>
                <!-- Updated -->
                <DeviceType>WindowsPhone</DeviceType>
                <!-- Updated -->
                <ApplicationVersion>10.0.0.0</ApplicationVersion>
                <AuthPolicies>
                    <AuthPolicy>OnPremise</AuthPolicy>
                    <AuthPolicy>Federated</AuthPolicy>
                </AuthPolicies>
            </request>
        </Discover>
    </s:Body>
</s:Envelope>

A resposta de descoberta está no formato XML e inclui os seguintes campos:

  • URL do serviço de registro (EnrollmentServiceUrl) - Especifica a URL do ponto de extremidade de registro exposto pelo serviço de gerenciamento. O dispositivo deverá chamar essa URL depois que o usuário for autenticado. Este campo é obrigatório.
  • Política de autenticação (AuthPolicy) - Indica que tipo de autenticação é necessária. Para o servidor MDM, local é o valor com suporte, o que significa que o usuário é autenticado ao chamar a URL do serviço de gerenciamento. Este campo é obrigatório.
  • No Windows, Federado é adicionado como outro valor com suporte. Essa adição permite que o servidor use o Agente de Autenticação da Web para executar a autenticação personalizada do usuário e a aceitação do termo de uso.

Observação

A resposta do servidor HTTP não deve definir Transfer-Encoding como Chunked; Ela deve ser enviada como uma mensagem.

Quando a política de autenticação é definida como Federada, o Agente de Autenticação da Web (WAB) é usado pelo cliente de registro para obter um token de segurança. A URL da página inicial do WAB é fornecida pelo serviço de descoberta na mensagem de resposta. O cliente de registro chama a API do WAB na mensagem de resposta para iniciar o processo do WAB. As páginas WAB são páginas da Web hospedadas no servidor. O servidor deve criar essas páginas para se ajustar perfeitamente à tela do dispositivo e ser o mais consistente possível com outras compilações na IU de registro do MDM. O token de segurança opaco retornado do WAB como uma página final é usado pelo cliente de registro como o segredo de segurança do dispositivo durante a chamada de solicitação de registro de certificado do cliente.

Observação

Em vez de depender da cadeia de caracteres do agente do usuário que é passada durante a autenticação para obter informações, como a versão do sistema operacional, use as seguintes diretrizes:

  • Analise a versão do sistema operacional dos dados enviados durante a solicitação de descoberta.
  • Acrescente a versão do sistema operacional como um parâmetro no AuthenticationServiceURL.
  • Analise a versão do sistema operacional do AuthenticiationServiceURL quando o sistema operacional enviar a resposta para autenticação.

Uma nova marca XML, AuthenticationServiceUrl, é introduzida no XML DiscoveryResponse para permitir que o servidor especifique a URL inicial da página WAB. Para autenticação federada, esta marca XML deve existir.

Observação

O cliente de registro é agnóstico em relação aos fluxos de protocolo para autenticar e retornar o token de segurança. Embora o servidor possa solicitar credenciais do usuário diretamente ou entrar em um protocolo de federação com outro servidor e serviço de diretório, o cliente de registro é independente de tudo isso. Para permanecer agnóstico, todos os fluxos de protocolo pertencentes à autenticação que envolvem o cliente de registro são passivos, ou seja, implementados pelo navegador.

A seguir estão os requisitos explícitos para o servidor.

  • O <DiscoveryResponse>``<AuthenticationServiceUrl> elemento deve dar suporte a HTTPS.
  • O servidor de autenticação deve usar um certificado raiz confiável do dispositivo. Caso contrário, a chamada WAP falhará.
  • O WP não dá suporte à WIA (Autenticação Integrada do Windows) para ADFS durante a autenticação WAB. O ADFS 2012 R2, se usado, precisa ser configurado para não tentar o WIA para o dispositivo Windows.

O cliente de registro emite uma solicitação HTTPS da seguinte maneira:

AuthenticationServiceUrl?appru=<appid>&amp;login_hint=<User Principal Name>
  • <appid> está no formato ms-app://string
  • <User Principal Name> é o nome do usuário inscrito, por exemplo, user@constoso.com como entrada pelo usuário em uma página de entrada de registro. O valor desse atributo serve como uma dica usada pelo servidor de autenticação como parte da autenticação.

Após a conclusão da autenticação, o servidor de autenticação deve retornar um documento de formulário HTML com uma ação de método POST de appid identificada no parâmetro de cadeia de caracteres de consulta.

Observação

Para tornar um aplicativo compatível com uma Política de segurança de conteúdo estrita, geralmente é necessário fazer algumas alterações nos modelos HTML e no código do lado do cliente, adicionar o cabeçalho da política e testar se tudo funciona corretamente depois que a política é implantada.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Content-Length: 556

<!DOCTYPE>
<html>
   <head>
      <title>Working...</title>
      <script>
         function formSubmit() {
            document.forms[0].submit();
         }
           window.onload=formSubmit;
      </script>
   </head>
   <body>
    <!-- appid below in post command must be same as appid in previous client https request. -->
      <form method="post" action="ms-app://appid">
         <p><input type="hidden" name="wresult" value="token value"/></p>
         <input type="submit"/>
      </form>
   </body>
</html>

O servidor deve enviar um POST para uma URL de redirecionamento do formulário ms-app://string (o esquema de URL é ms-app), conforme indicado na ação do método POST. O valor do token de segurança é a cadeia de caracteres http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary codificada em base64 contida no <wsse:BinarySecurityToken> atributo EncodingType. O Windows faz a codificação binária quando o envia de volta ao servidor de registro, na forma em que é apenas codificado em HTML. Essa cadeia de caracteres é opaca para o cliente de registro; O cliente não interpreta a cadeia de caracteres.

O exemplo a seguir mostra uma resposta recebida do serviço Web de descoberta que requer autenticação via WAB.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing">
    <s:Header>
        <a:Action s:mustUnderstand="1">
            http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/DiscoverResponse
        </a:Action>
        <ActivityId>
            d9eb2fdd-e38a-46ee-bd93-aea9dc86a3b8
        </ActivityId>
        <a:RelatesTo>urn:uuid: 748132ec-a575-4329-b01b-6171a9cf8478</a:RelatesTo>
    </s:Header>
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <DiscoverResponse xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment">
            <DiscoverResult>
                <AuthPolicy>Federated</AuthPolicy>
                <EnrollmentVersion>3.0</EnrollmentVersion>
                <EnrollmentPolicyServiceUrl>
                    https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
                </EnrollmentPolicyServiceUrl>
                <EnrollmentServiceUrl>
                    https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
                </EnrollmentServiceUrl>
                <AuthenticationServiceUrl>
                    https://portal.manage.contoso.com/LoginRedirect.aspx
                </AuthenticationServiceUrl>
            </DiscoverResult>
        </DiscoverResponse>
    </s:Body>
</s:Envelope>

Serviço Web de política de registro

O serviço de política é opcional. Por padrão, se nenhuma política for especificada, o comprimento mínimo da chave será 2k e o algoritmo de hash será SHA-1.

Esse serviço Web implementa a especificação M.XCEP (X.509 Certificate Enrollment Policy Protocol) que permite personalizar o registro de certificado para atender às diferentes necessidades de segurança das empresas em momentos diferentes (agilidade criptográfica). O serviço processa a mensagem GetPolicies do cliente, autentica o cliente e retorna políticas de registro correspondentes na mensagem GetPoliciesResponse.

Para a política de autenticação federada, a credencial de token de segurança é fornecida em uma mensagem de solicitação usando o <wsse:BinarySecurityToken> elemento [WSS]. O token de segurança é recuperado conforme descrito na seção de resposta de descoberta. As informações de autenticação são as seguintes:

  • wsse:Security: o cliente de registro implementa o <wsse:Security> elemento definido na seção 5 do [WSS]. O <wsse:Security> elemento deve ser um filho do <s:Header> elemento.
  • wsse:BinarySecurityToken: o cliente de registro implementa o <wsse:BinarySecurityToken> elemento definido na seção 6.3 do [WSS]. O <wsse:BinarySecurityToken> elemento deve ser incluído como um filho do <wsse:Security> elemento no cabeçalho SOAP.

Conforme descrito na seção de resposta de descoberta, a inclusão do elemento é opaca para o cliente de <wsse:BinarySecurityToken> registro, e o cliente não interpreta a cadeia de caracteres, e a inclusão do elemento é acordada pelo servidor de autenticação de token de segurança (conforme identificado no <AuthenticationServiceUrl> elemento de <DiscoveryResponse> e o servidor corporativo.

O <wsse:BinarySecurityToken> elemento contém uma cadeia de caracteres codificada em base64. O cliente de registro usa o token de segurança recebido do servidor de autenticação e codifica em base64 o token para preencher o <wsse:BinarySecurityToken> elemento.

  • wsse:BinarySecurityToken/attributes/ValueType: O <wsse:BinarySecurityToken> atributo ValueType deve ser http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken.

  • wsse:BinarySecurityToken/attributes/EncodingType: O <wsse:BinarySecurityToken> atributo EncodingType deve ser http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary.

O exemplo a seguir é uma solicitação de política de registro com um token de segurança recebido como credencial de cliente.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
    xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
    <s:Header>
        <a:Action s:mustUnderstand="1">
            http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy/IPolicy/GetPolicies
        </a:Action>
        <a:MessageID>urn:uuid:72048B64-0F19-448F-8C2E-B4C661860AA0</a:MessageID>
        <a:ReplyTo>
            <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
        </a:ReplyTo>
        <a:To s:mustUnderstand="1">
             https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
        </a:To>
        <wsse:Security s:mustUnderstand="1">
            <wsse:BinarySecurityToken ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary"
                xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                B64EncodedSampleBinarySecurityToken
            </wsse:BinarySecurityToken>
        </wsse:Security>
    </s:Header>
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <GetPolicies xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy">
            <client>
                <lastUpdate xsi:nil="true"/>
                <preferredLanguage xsi:nil="true"/>
            </client>
            <requestFilter xsi:nil="true"/>
        </GetPolicies>
    </s:Body>
</s:Envelope>

Depois que o usuário é autenticado, o serviço Web recupera o modelo de certificado com o qual o usuário deve se registrar e cria políticas de registro com base nas propriedades do modelo de certificado. Um exemplo da resposta pode ser encontrado no MSDN.

O MS-XCEP oferece suporte a políticas de registro flexíveis usando vários tipos e atributos complexos. Para o dispositivo Windows, primeiro daremos suporte ao minimalKeyLength, às políticas de hashAlgorithmOIDReference e aos CryptoProviders. O hashAlgorithmOIDReference relacionou OID e OIDReferenceID e policySchema no GetPolicesResponse. O policySchema refere-se à versão do modelo de certificado. A versão 3 do MS-XCEP oferece suporte a algoritmos de hash.

Observação

A resposta do servidor HTTP não deve definir Transfer-Encoding como Chunked; Ela deve ser enviada como uma mensagem.

O trecho a seguir mostra a resposta do serviço Web de política.

<s:Envelope
   xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
   xmlns:s="http://www.w3.org/2003/05/soap-envelope"
   xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy/IPolicy/GetPoliciesResponse
    </a:Action>
    <a:RelatesTo>urn:uuid: 69960163-adad-4a72-82d2-bb0e5cff5598</a:RelatesTo>
  </s:Header>
  <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <GetPoliciesResponse
       xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy">
      <response>
      <policyID />
        <policyFriendlyName xsi:nil="true"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
        <nextUpdateHours xsi:nil="true"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
        <policiesNotChanged xsi:nil="true"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
        <policies>
          <policy>
            <policyOIDReference>0</policyOIDReference>
            <cAs xsi:nil="true" />
            <attributes>
              <commonName>CEPUnitTest</commonName>
              <policySchema>3</policySchema>
              <certificateValidity>
                <validityPeriodSeconds>1209600</validityPeriodSeconds>
                <renewalPeriodSeconds>172800</renewalPeriodSeconds>
              </certificateValidity>
              <permission>
                <enroll>true</enroll>
                <autoEnroll>false</autoEnroll>
              </permission>
              <privateKeyAttributes>
                <minimalKeyLength>2048</minimalKeyLength>
                <keySpec xsi:nil="true" />
                <keyUsageProperty xsi:nil="true" />
                <permissions xsi:nil="true" />
                <algorithmOIDReference xsi:nil="true" />
                <cryptoProviders xsi:nil="true" />
              </privateKeyAttributes>
              <revision>
                <majorRevision>101</majorRevision>
                <minorRevision>0</minorRevision>
              </revision>
              <supersededPolicies xsi:nil="true" />
              <privateKeyFlags xsi:nil="true" />
              <subjectNameFlags xsi:nil="true" />
              <enrollmentFlags xsi:nil="true" />
              <generalFlags xsi:nil="true" />
              <hashAlgorithmOIDReference>0</hashAlgorithmOIDReference>
              <rARequirements xsi:nil="true" />
              <keyArchivalAttributes xsi:nil="true" />
              <extensions xsi:nil="true" />
            </attributes>
          </policy>
        </policies>
      </response>
      <cAs xsi:nil="true" />
      <oIDs>
        <oID>
          <value>1.3.14.3.2.29</value>
          <group>1</group>
          <oIDReferenceID>0</oIDReferenceID>
          <defaultName>szOID_OIWSEC_sha1RSASign</defaultName>
        </oID>
      </oIDs>
    </GetPoliciesResponse>
  </s:Body>
</s:Envelope>

Serviço Web de registro

Este serviço Web implementa o protocolo MS-WSTEP. Ele processa a mensagem RST (RequestSecurityToken) do cliente, autentica o cliente, solicita o certificado da autoridade de certificação e o retorna em RSTR (RequestSecurityTokenResponse) para o cliente. Além do certificado emitido, a resposta também contém as configurações necessárias para provisionar o DMClient.

O RST (RequestSecurityToken) deve ter a credencial de usuário e uma solicitação de certificado. A credencial do usuário em um envelope RST SOAP é a mesma que em GetPolicies e pode variar dependendo se a política de autenticação é local ou federada. O BinarySecurityToken em um corpo RST SOAP contém uma solicitação de certificado PKCS #10 codificada em Base64, que é gerada pelo cliente com base na política de registro. O cliente poderia ter solicitado uma política de registro usando o MS-XCEP antes de solicitar um certificado usando o MS-WSTEP. Se a solicitação de certificado PKCS #10 for aceita pela AC (autoridade de certificação) (o comprimento da chave, o algoritmo de hash e assim por diante corresponderem ao modelo de certificado), o cliente poderá se registrar com êxito.

O RequestSecurityToken usa um TokenType personalizado (http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken), pois nosso token de registro é mais do que um certificado X.509 v3. Para obter mais informações, consulte a seção Resposta.

O RST também pode especificar muitos itens AdditionalContext, como DeviceType e Version. Com base nesses valores, por exemplo, o serviço Web pode retornar uma configuração de DM específica do dispositivo e da versão.

Observação

O serviço de política e o serviço de registro devem estar no mesmo servidor; ou seja, eles devem ter o mesmo nome de host.

O exemplo a seguir mostra a solicitação do serviço Web de registro para autenticação federada.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
   xmlns:a="http://www.w3.org/2005/08/addressing"
   xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
   xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
   xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
   xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RST/wstep
    </a:Action>
    <a:MessageID>urn:uuid:0d5a1441-5891-453b-becf-a2e5f6ea3749</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
    <a:To s:mustUnderstand="1">
      https://enrolltest.contoso.com:443/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
    </a:To>
    <wsse:Security s:mustUnderstand="1">
      <wsse:BinarySecurityToken
         wsse:ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken"
         wsse:EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">
      B64EncodedSampleBinarySecurityToken
      </wsse:BinarySecurityToken>
    </wsse:Security>
  </s:Header>
  <s:Body>
    <wst:RequestSecurityToken>
      <wst:TokenType>
        http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
      </wst:TokenType>
      <wst:RequestType>
        http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
      </wst:RequestType>
      <wsse:BinarySecurityToken
         ValueType="http://schemas.microsoft.com/windows/pki/2009/01/enrollment#PKCS10"
         EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">
        DER format PKCS#10 certificate request in Base64 encoding Insterted Here
      </wsse:BinarySecurityToken>
      <ac:AdditionalContext xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization">
           <ac:ContextItem Name="OSEdition">
               <ac:Value> 4</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="OSVersion">
               <ac:Value>10.0.9999.0</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="DeviceName">
               <ac:Value>MY_WINDOWS_DEVICE</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="MAC">
               <ac:Value>FF:FF:FF:FF:FF:FF</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="MAC">
               <ac:Value>CC:CC:CC:CC:CC:CC</ac:Value>
            <ac:ContextItem Name="IMEI">
               <ac:Value>49015420323756</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="IMEI">
               <ac:Value>30215420323756</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="EnrollmentType">
               <ac:Value>Full</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="DeviceType">
               <ac:Value>CIMClient_Windows</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="ApplicationVersion">
               <ac:Value>10.0.9999.0</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="DeviceID">
               <ac:Value>7BA748C8-703E-4DF2-A74A-92984117346A</ac:Value>
            </ac:ContextItem>
            <ac:ContextItem Name="TargetedUserLoggedIn">
               <ac:Value>True</ac:Value>
            </ac:ContextItem>
         </ac:AdditionalContext>
    </wst:RequestSecurityToken>
  </s:Body>
</s:Envelope>

Depois de validar a solicitação, o serviço Web procura o modelo de certificado atribuído para o cliente, atualiza-o se necessário, envia as solicitações PKCS#10 para a CA, processa a resposta da CA, constrói um formato OMA Client Provisioning XML e o retorna no RSTR (RequestSecurityTokenResponse).

Observação

A resposta do servidor HTTP não deve definir Transfer-Encoding como Chunked; Ela deve ser enviada como uma mensagem.

Semelhante ao TokenType no RST, o RSTR usa um ValueType personalizado no BinarySecurityToken (http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc), porque o token é mais do que um certificado X.509 v3.

O XML de provisionamento contém:

  • Os certificados solicitados (obrigatório)
  • A configuração do DMClient (obrigatório)

O cliente instala o certificado do cliente, o certificado raiz corporativo e o certificado de AC intermediário, se houver um. A configuração do DM inclui o nome e o endereço do servidor DM, qual certificado de cliente usar e agendar quando o DMClient chama de volta para o servidor.

O XML de provisionamento de registro deve conter no máximo um certificado raiz e um certificado de autoridade de certificação intermediário que é necessário para encadear o certificado do cliente MDM. Mais certificados de autoridade de certificação raiz e intermediários podem ser provisionados durante uma sessão do OMA DM.

Quando certificados de autoridade de certificação raiz e intermediários estão sendo provisionados, o caminho do nó de CSP com suporte é: CertificateStore/Root/System para provisionamento de certificado raiz, CertificateStore/My/User para provisionamento de certificado de autoridade de certificação intermediária.

Aqui está um exemplo de mensagem RSTR e um exemplo de XML de provisionamento do cliente OMA no RSTR. Para obter mais informações sobre os CSPs (provedores de serviço de configuração) usados no provisionamento de XML, consulte a seção Configurações, políticas e gerenciamento de aplicativos da empresa.

O exemplo a seguir mostra a resposta do serviço Web de registro.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:a="http://www.w3.org/2005/08/addressing"
   xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <s:Header>
      <a:Action s:mustUnderstand="1" >
         http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RSTRC/wstep
      </a:Action>
      <a:RelatesTo>urn:uuid:81a5419a-496b-474f-a627-5cdd33eed8ab</a:RelatesTo>
      <o:Security s:mustUnderstand="1" xmlns:o=
         "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <u:Timestamp u:Id="_0">
            <u:Created>2012-08-02T00:32:59.420Z</u:Created>
            <u:Expires>2012-08-02T00:37:59.420Z</u:Expires>
         </u:Timestamp>
      </o:Security>
   </s:Header>
   <s:Body>
      <RequestSecurityTokenResponseCollection
         xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
         <RequestSecurityTokenResponse>
            <TokenType>
                http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
            </TokenType>
             <DispositionMessage xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment"/>
             <RequestedSecurityToken>
               <BinarySecurityToken
                  ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc"
                  EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary"
                  xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                  B64EncodedSampleBinarySecurityToken
               </BinarySecurityToken>
            </RequestedSecurityToken>
            <RequestID xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment">0</RequestID>
         </RequestSecurityTokenResponse>
      </RequestSecurityTokenResponseCollection>
   </s:Body>
</s:Envelope>

O código a seguir mostra um exemplo de XML de provisionamento (apresentado no pacote anterior como um token de segurança):

<wap-provisioningdoc version="1.1">
   <characteristic type="CertificateStore">
      <characteristic type="Root">
         <characteristic type="System">
            <characteristic type="Encoded Root Cert Hash Inserted Here">
               <parm name="EncodedCertificate" value="B64 encoded cert insert here" />
            </characteristic>
         </characteristic>
      </characteristic>
   </characteristic>
   <characteristic type="CertificateStore">
      <characteristic type="My" >
         <characteristic type="User">
            <characteristic type="Encoded Root Cert Hash Inserted Here">
               <parm name="EncodedCertificate" value="B64EncodedCertInsertedHere" />
            </characteristic>
            <characteristic type="PrivateKeyContainer"/>
            <!-- This tag must be present for XML syntax correctness. -->
         </characteristic>
         <characteristic type="WSTEP">
            <characteristic type="Renew">
               <!-If the datatype for ROBOSupport, RenewPeriod, and RetryInterval tags exist, they must be set explicitly. -->
               <parm name="ROBOSupport" value="true" datatype="boolean"/>
               <parm name="RenewPeriod" value="60" datatype="integer"/>
               <parm name="RetryInterval" value="4" datatype="integer"/>
            </characteristic>
         </characteristic>
      </characteristic>
   </characteristic>
   <characteristic type="APPLICATION">
      <parm name="APPID" value="w7"/>
      <parm name="PROVIDER-ID" value="TestMDMServer"/>
      <parm name="NAME" value="Microsoft"/>
      <parm name="ADDR" value="https://DM.contoso.com:443/omadm/Windows.ashx"/>
      <parm name="CONNRETRYFREQ" value="6" />
      <parm name="INITIALBACKOFFTIME" value="30000" />
      <parm name="MAXBACKOFFTIME" value="120000" />
      <parm name="BACKCOMPATRETRYDISABLED" />
      <parm name="DEFAULTENCODING" value="application/vnd.syncml.dm+wbxml" />
      <parm name="SSLCLIENTCERTSEARCHCRITERIA" value="Subject=DC%3dcom%2cDC%3dmicrosoft%2cCN%3dUsers%2cCN%3dAdministrator&amp;amp;Stores=My%5CUser"/>
      <characteristic type="APPAUTH">
         <parm name="AAUTHLEVEL" value="CLIENT"/>
         <parm name="AAUTHTYPE" value="DIGEST"/>
         <parm name="AAUTHSECRET" value="password1"/>
         <parm name="AAUTHDATA" value="B64encodedBinaryNonceInsertedHere"/>
      </characteristic>
      <characteristic type="APPAUTH">
         <parm name="AAUTHLEVEL" value="APPSRV"/>
         <parm name="AAUTHTYPE" value="BASIC"/>
         <parm name="AAUTHNAME" value="testclient"/>
         <parm name="AAUTHSECRET" value="password2"/>
      </characteristic>
   </characteristic>
   <characteristic type="DMClient"> <!-- In Windows 10, an enrollment server should use DMClient CSP XML to configure DM polling schedules. -->
      <characteristic type="Provider">
        <!-- ProviderID in DMClient CSP must match to PROVIDER-ID in w7 APPLICATION characteristics -->
        <characteristic type="TestMDMServer">
            <parm name="UPN" value="UserPrincipalName@contoso.com" datatype="string" />
            <parm name="EntDeviceName" value="Administrator_Windows" datatype="string" />
            <characteristic type="Poll">
                <parm name="NumberOfFirstRetries" value="8" datatype="integer" />
                <parm name="IntervalForFirstSetOfRetries" value="15" datatype="integer" />
                <parm name="NumberOfSecondRetries" value="5" datatype="integer" />
                <parm name="IntervalForSecondSetOfRetries" value="3" datatype="integer" />
                <parm name="NumberOfRemainingScheduledRetries" value="0" datatype="integer" />
                <!-- Windows 10 supports MDM push for real-time communication. The DM client long term polling schedule's retry waiting interval should be more than 24 hours (1440) to reduce the impact to data consumption and battery life. Refer to the DMClient Configuration Service Provider section for information about polling schedule parameters.-->
                <parm name="IntervalForRemainingScheduledRetries" value="1560" datatype="integer" />
                <parm name="PollOnLogin" value="true" datatype="boolean" />
            </characteristic>
        </characteristic>
      </characteristic>
   </characteristic>
   <!-- For Windows 10, we removed EnterpriseAppManagement from the enrollment protocol. -->
</wap-provisioningdoc>

Observação

  • <Parm name> e <characteristic type=> elementos no xml do CSP APPLICATION CSP w7 diferenciam maiúsculas de minúsculas e devem estar todos em maiúsculas.

  • Na característica w7 APPLICATION, as credenciais CLIENT e APPSRV devem ser fornecidas em XML.

  • Descrições detalhadas dessas configurações estão localizadas na seção Configurações corporativas, políticas e gerenciamento de aplicativos deste documento.

  • A característica PrivateKeyContainer é necessária e deve estar presente no XML de provisionamento de registro pelo registro. Outras configurações importantes são os elementos de parâmetro PROVIDER-ID, NAME e ADDR, que precisam conter a ID exclusiva e o NOME do seu provedor de DM e o endereço onde o dispositivo pode se conectar para provisionamento de configuração. A ID e o NAME podem ser valores arbitrários, mas devem ser exclusivos.

  • Também importante é SSLCLIENTCERTSEARCHCRITERIA, usado para selecionar o certificado a ser usado para autenticação do cliente. A pesquisa é baseada no atributo subject do certificado de usuário assinado.

  • CertificateStore/WSTEP permite a renovação do certificado. Se o servidor não for compatível, não o defina.

  • Last updated on