Главная > Lync, SfB > Lync Autodiscover

Lync Autodiscover

О чем это все

В данной статье описан процесс Autodiscover Lync. Почему написал: порой приходится освежать информацию по Lync, и в частности вопрос по процессу автообнаружения, поэтому решил собрать в кучку информацию по этому вопросу из разных источников и практики. Надеюсь куча получилась понятная ))

 

Autodiscover – это служба автообнаружения, необходимая для работы мобильных клиентов, в Lync 2013\S4B также используется клиентами стационарных ПК. Она распознается по обязательным DNS-записям lyncdiscover.<домен> и lyncdiscoverinternal.<домен>. Веб-службы Lync\S4B передают ответ на запрос клиента, в котором указываются компоненты, доступные для клиента, и способы связи с этими компонентами, в формате отклика автообнаружения.

Таблица поддержки режимов автообнаружения клиентами Lync\S4B

LyncDiscover DNS SRV Lookup
Lync 2010 client +
Lync 2013 client + +
S4B client + +
Lync Windows Store App +
Lync Phone Edition +
Lync\S4B Mobile +
Lync Mac +

 

Порядок обнаружения служб клиентами Lync\S4B (пример для домена contoso.com)

Клиент пытается разрешить в DNS записи (порядок в следующей таблице) и получить ответ от служб для последующей регистрации.

DNS запись Примечание
1 lyncdiscoverinternal.contoso.com Запись А для службы автообнаружения, для внутренних подключений, направленных к внутренним веб-службам
2 lyncdiscover.contoso.com запись A для службы автообнаружения, для внешних веб-служб
3 _sipinternaltls._tcp.contoso.com SRV-запись для внутренних подключений TLS
4 _sipinternal._tcp.contoso.com SRV-запись для внутренних подключений TCP
5 _sip._tls.contoso.com SRV-запись для внешних подключений TCP
6 sipinternal.contoso.com запись A, для пула переднего плана
7 sip.contoso.com запись A для пула переднего плана, если клиент во внутренней сети; запись A для пограничного сервера доступа (если клиент внешний и без доступа по VPN)
8 sipexternal.contoso.com запись A для пограничного сервера доступа, если клиент внешний без доступа по VPN

 

Кратко о процессе получения ответа клиенту Lync от Autodiscover (LyncDiscover) на примере подключения мобильного клиента Lync 2013 (sip: user@contoso.com)

  • Разрешить в DNS А-запись lyncdiscoverinternal.contoso.com если невозможно разрешить или подключиться, то lyncdiscover.contoso.com
  • Разрешив запись, клиент пытается туда отправить HTTP (port 80) и HTTPS (port 443) запрос: GET http://lyncdiscover.contoso.com/?sipuri=user@contoso.com
  • Клиент получает файл формата JSON или XML, где указаны url веб-служб Lync\S4B (для подключения и проверки подлинности)
  • Проходит проверку подлинности и получает тикет от службы WebTicket
  • Клиент заново отправляет запрос на получение информации о домашнем пуле предоставив свой веб-тикет.
  • Если для пользователя это не домашний пул, то мы получим ответ перенаправления, где проводятся те же самые шаги для аутентификации на другом сервере.
  • Получить XML от службы Autodiscover где будут указаны url домашнего пула FE, пула Edge связанного с этим пулом FE, и других служб.

 

Далее подробнее о процессе LyncDiscover (Lync 2013 / S4B). Этот раздел – это вольный пересказ части этой статьи

Итак, рассмотрим подробнее процесс lyncdiscover (SRV записи тут рассматривать не будем). Из предыдущей таблицы видим, что клиент должен разрешить по порядку следующие А записи:

  • lyncdiscoverinternal.contoso.com
  • lyncdiscover.contoso.com

Разрешив запись, клиент пытается отправить HTTP (port 80) и HTTPS (port 443) запрос (HTTP GET) в следующем виде:

GET http://lyncdiscover.contoso.com/?sipuri=user@contoso.com

 Далее клиент должен получить ответ в одном из двух поддерживаемых форматах: JSON или XML. Формат по умолчанию — нотация объектов JavaScript (JSON). Второй формат — документ XML. Запрос и ответ предсказуемы, так как документ имеет заданную схему, определяющую формат. Строка, которая указывает используемую схему в документе, — это первая строка в запросе или ответе.

 

JSON

Клиент отправляет в заголовке HTTP запроса:

Accept: application/json

Ответ сервера выглядит так:

{

  «_links»:{

    «self»:{

      «href»:»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=contoso.com&#187;

    },

    «user»:{

      «href»:»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=contoso.com&#187;

    },

    «xframe»:{

      «href»:»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187;

    }

  }

}

 

Так как используется формат JSON то служба lyncdiscover предполагает, что клиент будет использовать службу UCWA, поэтому предлагает метод OAUTH для получения домашнего пула пользователя. Как можно видеть, формат json возвращает мало информации (меньше чем xml):

  • “self” – это ссылка на веб-службы, сгенерировавшие этот ответ
  • “user” – это URL-адрес службы автообнаружения, использующая аутентификацию OAUTH
  • “xframe” – предназначен для использования веб-приложениями для обхода ограничений AJAX при междоменных запросах.

 

XML

Клиент отправляет в заголовке HTTP запроса:

Accept: application/vnd.microsoft.rtc.autodiscover+xml;v=1

 

Ответ от сервера Lync 2013/S4B

<AutodiscoverResponse xmlns:xsd=»http://www.w3.org/2001/XMLSchema&#187; xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance&#187; AccessLocation=»External»>

  <Root>

    <Link token=»Domain» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/domain?originalDomain=contoso.com&#187; />

    <Link token=»User» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=contoso.com&#187; />

    <Link token=»Self» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=contoso.com&#187; />

    <Link token=»OAuth» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=contoso.com&#187; />

    <Link token=»External/XFrame» href=»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187; />

    <Link token=»Internal/XFrame» href=»https://lyncpool.domain.local/Autodiscover/XFrame/XFrame.html&#187; />

    <Link token=»XFrame» href=»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187; />

  </Root>

</AutodiscoverResponse>

 

Разберем что мы получили в ответе:

  • AccessLocationExternal» в корне AutodiscoverResponse – это место подключения , либо внешнее(external) либо внутреннее (internal), и определяется по порту подключения (4443 или 443 соответственно)
  • «Domain» – для обнаружения FQDN текущего пула. Не требует аутентификации.
  • «User» – для обнаружения домашнего пула пользователя, требует аутентификации.
  • «OAuth» – аналогично “user” при этом для NTLM\Kerberos требуется аутентификация OAuth

Есть два отдельных способа получения информации о домашнем пуле конкретного пользователя и связанных с ним веб-сервисов.

  • WebTicketService доступен на Lync Server 2010 и 2013 и требует поддержки NTLM или Kerberos для получения начального билета, который затем может быть использован для подтверждения личности пользователя с этого момента.
  • OAuth доступен только на Lync Server 2013 и предоставляет простой (и более удобный в Интернете) способ получения токена, который также может использоваться для подтверждения подлинности, на любом Front End Server в топологии, поскольку все они имеют один и тот же сертификат X509(реплицируется через CMS).

 

Autodiscover через WebTicketService

Итак, рассмотрим обнаружение домашнего пула пользователя по методу “user”. Отправляем HTTP GET на “user” URL

GET https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=contoso.com?sipuri=user@contoso.com

И мы получаем ответ HTTP 401 Unauthorized, сообщающий нам, что требуется аутентификация. Но он не принимает какие-либо традиционные методы аутентификации, вы не можете использовать NTLM или Kerberos, так как оба требуют соединения с AD для проверки учетных данных (это увеличило бы зависимость от AD и дало бы дополнительную нагрузку для каждой попытки соединения). Также NTLM через HTTP раздувается, требуя, чтобы каждое соединение полностью аутентифицировалось.

Тогда как в методе получения билета(ticket, «тикет») – нужно один раз подтвердить вашу личность и получить уникальный «тикет», действительный в течении определенного периода. Что позволяет вам просто передавать свой тикет в последующих запросах, делая сам запрос более быстрым и легким и избавляет от необходимости проходить весь повторный процесс аутентификации каждый раз (в отличии от NTLM).

Наряду с ответом «401», сервер возвращает ответ с следующими заголовками:

X-MS-WebTicketURL: https://lyncweb.contoso.com/WebTicket/WebTicketService.svc

X-MS-WebTicketSupported: cwt,saml

X-MS-Server-Fqdn: lync-fe01.contoso.local

X-Content-Type-Options: nosniff

Content-Length: 1293

Cache-Control: no-cache

Content-Type: text/html

Server: Microsoft-IIS/8.0

X-Powered-By: ASP.NET,ARR/2.5

Date: Sat, 09 Jan 2017 21:00:00 GMT

 

Здесь мы видим важную информацию:

  • XMSServerFqdn: Fqdn пула который отвечает на этот запрос

 

  • X-MS-WebTicketURL: url службы WebTicketService. Эта веб-служба SOAP, которая аутентифицирует пользователя через протоколы NTLM или Kerberos(напомню что керберос нужно дополнительно настраивать) и возвращает тикет (часть ответа SOAP-сообщения)

 

Далее мы отправляем по полученному URL новый запрос и получаем опять HTTP 401 Unauthorized, но в этот раз мы видим метод аутентификации в ответе: WWW-Authenticate: NTLM. И в следующем заголовке добавим:

SOAPAction: http://docs.oasisopen.org/wssx/wstrust/200512/RST/Issue

 И присоединим SOAP – сообщение используя метод «Issue» WebTicketService

<s:Envelope xmlns:s=»http://schemas.xmlsoap.org/soap/envelope/»&gt;

   <s:Body>

       <RequestSecurityToken Context=»9deba099-5746-4d41-8e36-6f1977e69d8f» xmlns=»http://docs.oasis-open.org/ws-sx/ws-trust/200512″&gt;

           <TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</TokenType&gt;

           <RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</RequestType&gt;

           <AppliesTo xmlns=»http://schemas.xmlsoap.org/ws/2004/09/policy»&gt;

               <EndpointReference xmlns=»http://www.w3.org/2005/08/addressing»&gt;

                   <Address>https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user?sipuri=user@contoso.com</Address&gt;

               </EndpointReference>

           </AppliesTo>

           <Claims Dialect=»urn:component:Microsoft.Rtc.WebAuthentication.2010:authclaims»>

               <auth:ClaimType Uri=»http://schemas.xmlsoap.org/ws/2005/05/identity/claims/uri&#187; Optional=»false» xmlns:auth=»http://schemas.xmlsoap.org/ws/2006/12/authorization»&gt;

                   <auth:Value>sip:user@contoso.com</auth:Value>

               </auth:ClaimType>

           </Claims>

           <Entropy>

               <BinarySecret Type=»http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce»>OTJhYzRlZjMtYTY1OC00MGQ1LWI2YjQtNzczOGFlZDFmZjVl</BinarySecret&gt;

           </Entropy>

           <KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</KeyType&gt;

       </RequestSecurityToken>

   </s:Body>

</s:Envelope>

 

Этот обмен SOAP-сообщениями использует WS-Trust (расширение WS-Security) и обеспечивает платформу для обмена токенами безопасности и установления доверительных отношений.

Важные моменты в этом сообщении:

  • “EndpointReference” (<Address>) – содержит адрес веб-сервиса, к которому мы хотели бы получить доступ, используя ранее полученный тикет.
  • “Claims” (<auth:value>) – sip адрес пользователя
  • “Entropy”( BinarySecret) – уникальный ключ Base64, используется как «доказательство владения» для предотвращения атак повтора.

Затем мы получаем утверждение SAML, завернутое в сообщение SOAP. В сообщении все содержимое RequestedSecurityToken и есть наш тикет. Теперь у нас есть все чтобы подтвердить идентичность.

Теперь возвращаемся к исходному запросу HTTP GET на “user” URL

GET https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=contoso.com?sipuri=user@contoso.com

 

Но сейчас мы можем аутентифицироваться, добавив в HTTP заголовок наш веб-тикет и получить наш XML от службы Autodiscover.

 

 

Autodiscover через OAuth

OAuth – более легкий способ получения токена, который необходим чтобы доказать нашу идентичность и получить свой XML от службы autodiscover. OAuth — это открытый стандарт, написанный Microsoft и опубликованный IETF как RFC6749. На высоком уровне он обеспечивает те же функциональные возможности, что и WebTicketService, но самое важное отличие заключается в том, что полученный маркер создается с использованием сертификата X509, назначенного на сервере, поэтому разрешает любому серверу с этим сертификатом декодировать и доверять токену без необходимости повторной аутентификации клиента на другом сервере. (Lync 2013\S4B автоматически копирует этот сертификат OAuth на все другие серверы Front End через CMS).

Сначала идет запрос GET на URL-адрес «OAuth», полученный из ответа LyncDiscover в формате XML (или «User» URL из ответа JSON).

GET https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=contoso.com?sipuri=user@contoso.com

Мы опять получаем HTTP 401 Unauthorized, но в этот раз со следующим заголовком:

Content-Length: 1293

Cache-Control: no-cache

Content-Type: text/html

Server: Microsoft-IIS/8.0

WWW-Authenticate: Bearer trusted_issuers=»», client_id=»00000004-0000-0ff1-ce00-000000000000″,MsRtcOAuth href=»https://lyncweb.contoso.com/WebTicket/oauthtoken&#187;,grant_type=»urn:microsoft.rtc:windows,urn:microsoft.rtc:anonmeeting,password»

X-MS-Server-Fqdn: lync-fe01.contoso.local

X-Powered-By: ASP.NET,ARR/2.5

X-Content-Type-Options: nosniff

Date: Sun, 9 Jan 2017 20:00:00 GMT

 

На этот раз заголовок WWW-Authenticate дает нам URL-адрес MsRtcOAuth для https://lyncweb.contoso.com/WebTicket/oauthtoken, который принимает несколько разных типов проверки подлинности “grant_type”. Мы можем видеть, что он принимает аутентификацию Windows, проверку подлинности с помощью пароля и тип разрешения, позволяющий анонимно присоединяться к конференциям.

Теперь все, что нам надо, это собрать данные для аутентификации(логин и пароль) и отправим это на URL “OAuth”

grant_type=password&username=user@contoso.com&password=MyPassword!

 

Ответ JSON:

{«access_token»:»cwt=AAEBHAEFAAAAFFAF…Xyrbdfs»,

    «expires_in»:28402,

    «ms_rtc_identityscope»:»local»,

    «token_type«:»Bearer«

}

 

Мы просто используем значение «access_token» таким же образом, как мы использовали тикет от WebTicketService, отправив HTTP GET снова на URL автообнаружения OAuth, как показано ниже:

GET https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=contoso.com?sipuri=user@contoso.com

Authorization: Bearer cwt= AAEBHAEFAAAAFFAF…Xyrbdfs

 

При этом мы получим тот же XML от Autodiscover который мы получили ранее, используя WebTicketService

 

 

Кратко о предыдущих процессах

 Итак, какие этапы у нас пройдены:

  1. Разрешить в DNS А-записи lyncdiscoverinternal.contoso.com или lyncdiscover.contoso.com
  2. Получить файл формата JSON или XML и узнать в них url веб-служб Lync\S4B
  3. Получить тикет от WebTicketService или OAuth токен.
  4. Аутентифицироваться по url autodiscover/“user” или по url autodiscover/oauth

 

Если для пользователя это не домашний пул, то мы получим ответ перенаправления, где проводятся те же самые шаги для аутентификации на другом сервере.

Редирект в формате JSON выгляди так:

{

  «_links»:{

    «redirect»:{

      «href»:»https://lyncweb2.contoso.com/Autodiscover/AutodiscoverService.svc/root&#187;

    }

  }

}

 

Редирект в формате XML выглядит так:

 

<AutodiscoverResponse xmlns:xsd=»http://www.w3.org/2001/XMLSchema&#187; xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance&#187; AccessLocation=»External»>

<User>

   <Link href=»https://lyncweb2.contoso.com/Autodiscover/AutodiscoverService.svc/root&#187; token=»Redirect»/>

</User>

</AutodiscoverResponse>

 Итогом всех этих мучений должен быть ответ от службы autodiscover в формате xml файла

 

Autodiscover XML

XML будет выглядеть примерно так:

 

<AutodiscoverResponse xmlns:xsd=»http://www.w3.org/2001/XMLSchema&#187; xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance&#187; AccessLocation=»External»>

<User>

<SipServerInternalAccess fqdn=»lyncpool01. contoso.local» port=»5061″ />

<SipClientInternalAccess fqdn=»lyncpool01. contoso.local» port=»5061″ />

<SipServerExternalAccess fqdn=»access01.contoso.com» port=»5061″ />

<SipClientExternalAccess fqdn=»access01.contoso.com» port=»443″ />

<Link token=»Internal/Autodiscover» href=»https://lyncpool01.contoso.local/Autodiscover/AutodiscoverService.svc/root&#187; />

<Link token=»Internal/AuthBroker» href=»https://lyncpool01.contoso.local/Reach/sip.svc&#187; />

<Link token=»Internal/WebScheduler» href=»https://lyncpool01.contoso.local/Scheduler&#187; />

<Link token=»Internal/CertProvisioning» href=»https://lyncpool01.contoso.local/CertProv/CertProvisioningService.svc&#187; />

<Link token=»External/Autodiscover» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root&#187; />

<Link token=»External/AuthBroker» href=»https://lyncweb.contoso.com/Reach/sip.svc&#187; />

<Link token=»External/WebScheduler» href=»https://lyncweb.contoso.com/Scheduler&#187; />

<Link token=»External/CertProvisioning» href=»https://lyncweb.contoso.com/CertProv/CertProvisioningService.svc&#187; />

<Link token=»Internal/Mcx» href=»https://lyncweb.contoso.com/Mcx/McxService.svc&#187; />

<Link token=»External/Mcx» href=»https://lyncweb.contoso.com/Mcx/McxService.svc&#187; />

<Link token=»Ucwa» href=»https://lyncweb.contoso.com/ucwa/oauth/v1/applications&#187; />

<Link token=»Internal/Ucwa» href=»https://lyncpool01.contoso.local/ucwa/oauth/v1/applications&#187; />

<Link token=»External/Ucwa» href=»https://lyncweb.contoso.com/ucwa/oauth/v1/applications&#187; />

<Link token=»External/XFrame» href=»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187; />

<Link token=»Internal/XFrame» href=»https://lyncpool01.contoso.local/Autodiscover/XFrame/XFrame.html&#187; />

<Link token=»XFrame» href=»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187; />

<Link token=»Self» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user&#187; />

</User>

</AutodiscoverResponse>

 

Что же мы видим в данном ответе для нашего пользователя:

  • SipServerInternalAccess fqdn – внутреннее имя (fqdn) и порт домашнего пула Front End.
  • SipClientInternalAccess fqdn – внешнее имя (fqdn) и порт домашнего пула Front End.
  • SipServerExternalAccess fqdn – внешнее имя (fqdn) и порт Edge пула связанного с домашним пулом для федеративного подключения и подключения к общедоступным службам обмена мгновенными сообщениями с помощью SIP.
  • SipClientExternalAccess fqdn — внешнее имя (fqdn) и порт Edge пула связанного с домашним пулом для клиентских подключений.
  • AutodiscoverURL службы autodiscover
  • AuthBroker – URL службы Authentication Broker (проверки подлинности (доступа))
  • WebScheduler – URL службы Web Scheduler (планировщик собраний)
  • CertProvisioning — URL службы для получения клиентских сертификатов
  • MCX – URL веб службы для обеспечения совместимости с моб. клиентами Lync 2010
  • UCWA – URL веб службы для подключения моб.клиентов и сторонних приложений
  • XFrame — предназначен для использования веб-приложениями для обхода ограничений AJAX при междоменных запросах
  • Self – URL веб службы вернувшей этот ответ

Вот собственно и все! Информация, полученная от Autodiscover, позволит подключится клиенту и начать работать.

Реклама
Рубрики:Lync, SfB
  1. Станислав Б.
    22.03.2017 в 14:51

    Спасибо за материал!
    Для удобства, в таблице ДНС записей хорошо бы добавить колонку с признаком зоны внешняя / внутренняя, или другим способом визуально разделить.

    • MRN
      22.03.2017 в 15:09

      Станислав, приветствую! Признак конечно можно добавить, но он не будет однозначно подходить всем, например кто-то использует отдельный DNS в DMZ для мобильных клиентов подключающихся к сети по wifi, тогда нужно еще комментировать и этот случай 🙂 Лучше оставим этот вопрос архитекторам проектирующим свою топологию, тем более в описании есть информация для чего нужна каждая из записей.

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Заметки ИТ инженера

Мои заметки, связанные с профессиональной деятельностью в сфере Информационных Технологий

IT in realworld

о технологиях Microsoft, или кратко обо всем. Active Directory and other stuff.

%d такие блоггеры, как: