Регистрация устройств с помощью федеративной проверки подлинности

Статья
07/08/2024
Применяется к:

✅ Windows 11, ✅ Windows 10

В этом разделе представлен пример протокола регистрации мобильных устройств с использованием политики федеративной проверки подлинности. Если для политики проверки подлинности задано значение Федеративный, клиент регистрации использует брокер веб-проверки подлинности для получения маркера безопасности. Клиент регистрации вызывает API брокера веб-проверки подлинности в ответе, чтобы начать процесс. Сервер должен создавать страницы брокера веб-проверки подлинности в соответствии с экраном устройства и соответствовать существующему пользовательскому интерфейсу регистрации. Непрозрачный маркер безопасности, возвращаемый брокером в качестве конечной страницы, используется клиентом регистрации в качестве секрета безопасности устройства во время вызова запроса сертификата клиента.

Элемент <AuthenticationServiceURL> ответного сообщения обнаружения указывает начальный URL-адрес страницы брокера веб-проверки подлинности.

Дополнительные сведения о протоколе регистрации мобильных устройств Майкрософт для Windows см. в разделе [MS-MDE2]: Протокол регистрации мобильных устройств версии 2.

Примечание.

Список сценариев регистрации, не поддерживаемых в Windows, см. в статье Сценарии регистрации не поддерживаются.

Служба обнаружения

Веб-служба обнаружения предоставляет сведения о конфигурации, необходимые пользователю для регистрации телефона в службе управления. Служба представляет собой беспокойную веб-службу по протоколу HTTPS (только проверка подлинности сервера).

Примечание.

Администратор службы обнаружения должен создать узел с адресом enterpriseenrollment.<domain_name>.com.

Поток автоматического обнаружения устройства использует доменное имя адреса электронной почты, который был отправлен на экран параметров рабочей области во время входа. Система автоматического обнаружения создает универсальный код ресурса (URI), который использует это имя узла, добавляя поддомен enterpriseenrollment в домен адреса электронной почты и добавляя путь /EnrollmentServer/Discovery.svc. Например, если адрес электронной почты — sample@contoso.com, результирующий URI для первого запроса Get будет: http://enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc.

Первый запрос является стандартным HTTP-запросом GET.

В следующем примере показан запрос через HTTP GET к серверу обнаружения, указанному user@contoso.com в качестве адреса электронной почты.

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

После того как устройство получает ответ от сервера, устройство отправляет запрос POST в enterpriseenrollment.<domain_name>/EnrollmentServer/Discovery.svc. После получения другого ответа от сервера (который должен сообщить устройству, где находится сервер регистрации), следующее сообщение, отправленное с устройства, будет отправлено на enterpriseenrollment.<domain_name> сервер регистрации.

Применяется следующая логика:

Устройство сначала пытается использовать ПРОТОКОЛ HTTPS. Если устройство не доверяет сертификату сервера, попытка HTTPS завершается ошибкой.
В случае сбоя устройство пытается проверить, перенаправляется ли оно по протоколу HTTP:
- Если устройство не перенаправляется, пользователю будет предложено ввести адрес сервера.
- Если устройство перенаправляется, пользователю предлагается разрешить перенаправление.

В следующем примере показан запрос через команду HTTP POST к веб-службе обнаружения, указанному user@contoso.com в качестве адреса электронной почты.

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

В следующем примере показан запрос службы обнаружения.

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

Ответ обнаружения имеет формат XML и содержит следующие поля:

URL-адрес службы регистрации (EnrollmentServiceUrl) — указывает URL-адрес конечной точки регистрации, предоставляемой службой управления. Устройство должно вызвать этот URL-адрес после проверки подлинности пользователя. Это поле является обязательным.
Политика проверки подлинности (AuthPolicy) — указывает, какой тип проверки подлинности требуется. Для сервера MDM значение OnPremise является поддерживаемым значением, что означает, что пользователь проходит проверку подлинности при вызове URL-адреса службы управления. Это поле является обязательным.
В Windows значение Federated добавляется в качестве другого поддерживаемого значения. Это добавление позволяет серверу использовать брокер веб-проверки подлинности для выполнения настраиваемой проверки подлинности пользователя и условия принятия использования.

Примечание.

В ответе HTTP-сервера не должно быть задано Transfer-Encoding значение Фрагментировано. Оно должно быть отправлено в виде одного сообщения.

Если для политики проверки подлинности задано значение Федеративная, клиент регистрации использует брокер веб-проверки подлинности (WAB) для получения маркера безопасности. URL-адрес начальной страницы WAB предоставляется службой обнаружения в ответном сообщении. Клиент регистрации вызывает API WAB в ответе, чтобы запустить процесс WAB. WAB-страницы — это веб-страницы, размещенные на сервере. Сервер должен создать эти страницы, чтобы хорошо соответствовать экрану устройства и быть максимально согласованными с другими сборками в пользовательском интерфейсе регистрации MDM. Непрозрачный маркер безопасности, возвращаемый из WAB в качестве конечной страницы, используется клиентом регистрации в качестве секрета безопасности устройства во время вызова запроса на регистрацию сертификата клиента.

Примечание.

Вместо того, чтобы полагаться на строку агента пользователя, передаваемую во время проверки подлинности, для получения сведений, таких как версия ОС, используйте следующие рекомендации:

Анализ версии ОС на основе данных, отправляемых во время запроса на обнаружение.
Добавьте версию ОС в качестве параметра в AuthenticationServiceURL.
Выполните синтаксический анализ версии ОС из AuthenticiationServiceURL, когда ОС отправляет ответ для проверки подлинности.

В xml DiscoveryResponse появился новый XML-тег AuthenticationServiceUrl, позволяющий серверу указать начальный URL-адрес страницы WAB. Для федеративной проверки подлинности этот XML-тег должен существовать.

Примечание.

Клиент регистрации не зависит от потоков протокола для проверки подлинности и возврата маркера безопасности. Хотя сервер может запрашивать учетные данные пользователя напрямую или входить в протокол федерации с другим сервером и службой каталогов, клиент регистрации не зависит от всего этого. Чтобы остаться не зависящими, все потоки протокола, относящиеся к проверке подлинности, в которых участвует клиент регистрации, являются пассивными, то есть реализованы в браузере.

Ниже приведены явные требования к серверу.

Элемент <DiscoveryResponse>``<AuthenticationServiceUrl> должен поддерживать ПРОТОКОЛ HTTPS.
Сервер проверки подлинности должен использовать доверенный корневой сертификат устройства. В противном случае вызов WAP завершается ошибкой.
WP не поддерживает встроенную проверку подлинности Windows (WIA) для ADFS во время проверки подлинности WAB. ADFS 2012 R2, если используется, необходимо настроить, чтобы не пытаться использовать WIA для устройства Windows.

Клиент регистрации отправляет HTTPS-запрос следующим образом:

AuthenticationServiceUrl?appru=<appid>&amp;login_hint=<User Principal Name>

<appid> имеет форму ms-app://string
<User Principal Name> — это имя зарегистрированного пользователя, например user@constoso.com в качестве входных данных пользователя на странице входа в систему. Значение этого атрибута служит подсказкой, используемой сервером проверки подлинности в рамках проверки подлинности.

После завершения проверки подлинности сервер проверки подлинности должен вернуть документ html-формы с действием метода POST appid, определенным в параметре строки запроса.

Примечание.

Чтобы сделать приложение совместимым со строгой политикой безопасности содержимого, обычно необходимо внести некоторые изменения в шаблоны HTML и клиентский код, добавить заголовок политики и проверить, правильно ли все работает после развертывания политики.

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>

Сервер должен отправить POST на URL-адрес перенаправления формы ms-app://string (схема URL-адресов ms-app), как указано в действии метода POST. Значение маркера безопасности — это строка http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary в кодировке Base64, содержащаяся в атрибуте <wsse:BinarySecurityToken> EncodingType. Windows выполняет двоичное кодирование, когда отправляет его обратно на сервер регистрации, в том виде, в который он просто закодирован в ФОРМАТЕ HTML. Эта строка непрозрачна для клиента регистрации; клиент не интерпретирует строку.

В следующем примере показан ответ, полученный от веб-службы обнаружения, который требует проверки подлинности через 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>

Веб-служба политики регистрации

Служба политик необязательна. По умолчанию, если политики не указаны, минимальная длина ключа составляет 2 кб, а хэш-алгоритм — SHA-1.

Эта веб-служба реализует спецификацию протокола политики регистрации сертификатов X.509 (MS-XCEP), которая позволяет настраивать регистрацию сертификатов в соответствии с различными требованиями к безопасности предприятий в разное время (гибкость шифрования). Служба обрабатывает сообщение GetPolicies от клиента, проверяет подлинность клиента и возвращает соответствующие политики регистрации в сообщении GetPoliciesResponse.

Для политики федеративной проверки подлинности учетные данные маркера безопасности предоставляются в сообщении <wsse:BinarySecurityToken> запроса с помощью элемента [WSS]. Маркер безопасности извлекается, как описано в разделе ответ обнаружения. Ниже приведены сведения о проверке подлинности.

wsse:Security: клиент регистрации реализует элемент, определенный <wsse:Security> в разделе [WSS] 5. Элемент <wsse:Security> должен быть дочерним элементом <s:Header> элемента .
wsse:BinarySecurityToken: клиент регистрации реализует элемент, определенный <wsse:BinarySecurityToken> в разделе [WSS] 6.3. Элемент <wsse:BinarySecurityToken> должен быть включен в качестве дочернего <wsse:Security> элемента в заголовке SOAP.

Как описано в разделе ответа на обнаружение, включение <wsse:BinarySecurityToken> элемента непрозрачно для клиента регистрации, и клиент не интерпретирует строку, а включение элемента согласовывается сервером проверки подлинности маркеров безопасности (как определено в <AuthenticationServiceUrl> элементе <DiscoveryResponse> и корпоративном сервере).

Элемент <wsse:BinarySecurityToken> содержит строку в кодировке base64. Клиент регистрации использует маркер безопасности, полученный от сервера проверки подлинности, и base64-кодирует маркер для заполнения <wsse:BinarySecurityToken> элемента .

wsse:BinarySecurityToken/attributes/ValueType: <wsse:BinarySecurityToken> атрибут ValueType должен иметь значение http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken.
wsse:BinarySecurityToken/attributes/EncodingType: <wsse:BinarySecurityToken> атрибут EncodingType должен иметь значение http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary.

В следующем примере показан запрос политики регистрации с полученным маркером безопасности в качестве учетных данных клиента.

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

После проверки подлинности пользователя веб-служба получает шаблон сертификата, с помощью которого пользователь должен зарегистрировать, и создает политики регистрации на основе свойств шаблона сертификата. Пример ответа можно найти на сайте MSDN.

MS-XCEP поддерживает гибкие политики регистрации с использованием различных сложных типов и атрибутов. Для устройства Windows сначала мы будем поддерживать minimalKeyLength, политики hashAlgorithmOIDReference и CryptoProviders. HashAlgorithmOIDReference имеет связанные OID и OIDReferenceID и policySchema в GetPolicesResponse. PolicySchema ссылается на версию шаблона сертификата. Версия 3 MS-XCEP поддерживает алгоритмы хэширования.

Примечание.

В следующем фрагменте кода показан ответ веб-службы политики.

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

Веб-служба регистрации

Эта веб-служба реализует протокол MS-WSTEP. Он обрабатывает сообщение RequestSecurityToken (RST) от клиента, проверяет подлинность клиента, запрашивает сертификат из ЦС и возвращает его клиенту в requestSecurityTokenResponse (RSTR). Помимо выданного сертификата, ответ также содержит конфигурации, необходимые для подготовки DMClient.

RequestSecurityToken (RST) должен иметь учетные данные пользователя и запрос сертификата. Учетные данные пользователя в конверте RST SOAP такие же, как в GetPolicies, и могут отличаться в зависимости от того, является ли политика проверки подлинности OnPremise или Federated. BinarySecurityToken в тексте RST SOAP содержит запрос сертификата PKCS#10 в кодировке Base64, который создается клиентом на основе политики регистрации. Клиент мог запросить политику регистрации с помощью MS-XCEP, прежде чем запрашивать сертификат с помощью MS-WSTEP. Если запрос на сертификат PKCS#10 принят центром сертификации (ЦС) (длина ключа, алгоритм хэширования и т. д. соответствуют шаблону сертификата), клиент может успешно зарегистрировать.

RequestSecurityToken использует пользовательский TokenType (http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken), так как маркер регистрации больше, чем сертификат X.509 версии 3. Дополнительные сведения см. в разделе Ответ.

В RST также может быть указано множество элементов AdditionalContext, таких как DeviceType и Version. Например, на основе этих значений веб-служба может возвращать конфигурацию dm для конкретного устройства и версии.

Примечание.

Служба политики и служба регистрации должны находиться на одном сервере; то есть они должны иметь одно и то же имя узла.

В следующем примере показан запрос веб-службы регистрации для федеративной проверки подлинности.

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

После проверки запроса веб-служба ищет назначенный шаблон сертификата для клиента, при необходимости обновит его, отправляет запросы PKCS#10 в ЦС, обрабатывает ответ от ЦС, создает XML-формат подготовки клиента OMA и возвращает его в requestSecurityTokenResponse (RSTR).

Примечание.

Как и в tokenType в RST, RSTR использует пользовательский ValueType в BinarySecurityToken (http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc), так как токен больше, чем сертификат X.509 версии 3.

XML-код подготовки содержит:

Запрошенные сертификаты (обязательные)
Конфигурация DMClient (обязательно)

Клиент устанавливает сертификат клиента, корневой сертификат предприятия и промежуточный сертификат ЦС, если он есть. Конфигурация dm включает имя и адрес сервера DM, какой сертификат клиента следует использовать, а также расписание обратного вызова DMClient на сервер.

XML-код подготовки регистрации должен содержать не более одного корневого сертификата и одного промежуточного сертификата ЦС, необходимых для связывания сертификата клиента MDM. Во время сеанса OMA DM можно подготовить больше корневых и промежуточных сертификатов ЦС.

При подготовке корневых и промежуточных сертификатов ЦС поддерживаемый путь к узлу CSP: CertificateStore/Root/System для подготовки корневого сертификата, CertificateStore/My/User для подготовки промежуточных сертификатов ЦС.

Ниже приведен пример сообщения RSTR и пример XML-кода подготовки клиента OMA в RSTR. Дополнительные сведения о поставщиках служб конфигурации (CSP), используемых при подготовке XML, см. в разделе Корпоративные параметры, политики и управление приложениями.

В следующем примере показан ответ веб-службы регистрации.

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

В следующем коде показан пример XML-кода подготовки (представленный в предыдущем пакете в виде маркера безопасности):

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

Примечание.

<Parm name> Элементы и <characteristic type=> в XML-файле W7 APPLICATION CSP чувствительны к регистру и должны быть прописными.
В характеристике приложения w7 учетные данные CLIENT и APPSRV должны быть предоставлены в формате XML.
Подробные описания этих параметров см. в разделе Параметры предприятия, политики и управление приложениями этого документа.
Характеристика PrivateKeyContainer является обязательной и должна присутствовать в XML-коде подготовки регистрации при регистрации. Другие важные параметры — это элементы параметров PROVIDER-ID, NAME и ADDR , которые должны содержать уникальный идентификатор и ИМЯ поставщика dm и адрес, по которому устройство может подключиться для подготовки конфигурации. Идентификатор и ИМЯ могут быть произвольными значениями, но они должны быть уникальными.
Кроме того, важно значение SSLCLIENTCERTSEARCHCRITERIA, которое используется для выбора сертификата, который будет использоваться для проверки подлинности клиента. Поиск основан на атрибуте subject подписанного сертификата пользователя.
CertificateStore/WSTEP включает продление сертификата. Если сервер не поддерживает его, не устанавливайте его.

Поделиться через

Регистрация устройств с помощью федеративной проверки подлинности

Служба обнаружения

Веб-служба политики регистрации

Веб-служба регистрации

Обратная связь

Дополнительные ресурсы