Доступ к Lync Mobility из внутренних сетей WiFi
2012-03-29, 16:45 / ArgonВ предыдущей заметке я описал способ подключения мобильных клиентов Lync к веб-службам, использующим SSL-сертификат, к которому устройство изначально не имеет доверия.
Однако действия по установке сертификата корневого CA на каждое устройство могут быть не удобны в масштабах большого предприятия. Выход из ситуации один: веб-службы Lync должны использовать публичный SSL сертификат, выпущенный CA из списка рекомендованных.
Задача осложняется тем, что Lync использует как внутренние пути к веб службам (на front end), так и внешние (на reverse proxy). Естественно, устанавливать публичный сертификат на внутренние веб-службы только для обеспечения совместимости с Lync Mobility не очень хочется.
Напрашивается логичный вывод: пусть все мобильные клиенты всегда обращаются к внешним веб-службам Lync, которые используют публичные сертификаты.
Часть работы за нас уже сделали разработчики: служба автообнаружения Lync Mobility спроектирована использовать DNS-записи:
- lyncdiscoverinternal.lab.argon.pro для нахождения веб-служб Lync из внутренней сети
- lyncdiscover.lab.argon.pro — для внешней
В обоих случаях Lync Discover выдаёт клиентам редирект на адрес внешних веб-служб Lync.
Однако если для внешних и внутренних служб используется одно DNS-имя типа lsweb.lab.argon.pro (Split-Brain DNS, внутреннее имя домена AD совпадает с публичным именем в интернете), мы имеем серьезную проблему… В такой конфигурации внутренние мобильные клиенты не будут иметь способа подключиться к внешним службам, а всегда будет попадать на внутренние службы с внутренним SSL-сертификатом.
Следовательно, чтобы избежать такой ситуации нужно использовать разные имена для внутренних и внешних веб-служб Lync.
Следующий важный момент — на какой IP-адрес указывает DNS-запись для внешних веб-служб при разрешении из внутренней сети. Может показаться удобным направить DNS-имя для внешних веб-служб Lync на внутренний IP-адрес reverse proxy, через который осуществляется публикация. Но если подумать о такой особенности работы мобильных устройств, как частое переключение между WiFi и мобильным интернетом, то эта идея не подходит из-за проблем с кешированием DNS-записей:
- Устройство через WiFi разрешает внутренний IP-адрес reverse proxy
- Переключается на мобильный интернет
- Находит в кэше DNS для имени внешних веб-служб Lync тот же внутренний IP адрес
- Не может подключиться, пока не истечет срок жизни кэша DNS
Чтобы избежать этой проблемы, адрес внешних веб-сервисов должен разрешаться на один и тот же публичный IP-адрес reverse proxy как из внутренней сети, так и снаружи.
Заключение
Для беспроблемной работы Lync Mobility из внутренней сети (WiFi) должны быть обеспечены следующие условия:
- Внешние веб-службы Lync должны использовать публичный SSL-сертификат, выданный рекомендованными поставщиками
- Запись DNS типа lyncdiscover.lab.argon.pro должна вести на публичный IP-адрес reverse proxy
- Запись DNS типа lyncdiscoverinternal.lab.argon.pro не требуется
- Адрес DNS для внешних веб-служб Lync должен отличаться от адреса внутренних веб-служб и разрешаться на один и тот же на публичный IP-адрес reverse proxy как из внутренней сети, так и снаружи
Источники вдохновения
| Рубрика | Unified Communications |
|---|---|
| Метки | lync server, office communications server, ocs, pki, public key infrastructure, active directory certificate services, службы сертификатов, совместимость |
| Опубликовано | 2012-03-29, 16:45; обновлено 2012-03-29, 22:18 |
| Комментарии | 11 комментариев » | Лента комментариев RSS |
| Ссылки | Постоянная ссылка | Обратная ссылка |
11 комментариев
«В обоих случаях Lync Discover выдаёт клиентам редирект на адрес внешних веб-служб Lync.»
Разве это так?
Насколько помню для внутреннего клиента, выдаётся внутренняя ссылка https://lyncint.domaint.int/autodiscover/autodiscoverservice.svc/root/domain
а, потом сходя по ней выдаёт полный набор с вгутренними и внешними сервисами, а сам клиент уже использует только внешние, а внутриние не использует. Или я заблуждаюсь?
Беглая проверка браузером показала, что так оно и есть на портах 80 и 443.
Для lyncdiscoverinternal будет следующая цепочка редиректов:
lyncdiscoverinternal > lync-web-services-internal > lync-web-services-external
Как видишь, в середине присутствуют внутренние веб-службы с их неугодным SSL-сертификатом. Именно поэтому я написал, что DNS-запись lyncdiscoverinternal не нужна.
Более подробно процесс редиректов разобран в последней ссылке в «источниках вдохновения» ;)
А чтобы мобилкам всегда возвращались внутренние веб-сервисы, нужно использовать Set-CsMcxConfiguration с ключем ExposedWebURL.
Дык, об этом и была речь, если бы в обоих случаях первый этап выдавал ссылку сразу на внешние веб-сервисы, то и не было бы и проблемы. Я это имел в виду.
А, так в большенстве случаев для доступа к корпоративному WiFi используется EAP-TLS следовательно корни корпоративного ЦС уже есть на мобильном устройстве, поэтому на серверах линка можно оставлять сертификат выпущенный внутренним ЦС, а вот для публикации edge нужны внешние ибо федерация и пуш-нотификации.
Internal\Mcx указывает на внешние веб-сервисы для того, чтобы при роуменге между WiFi/сотовыми сетями не было проблем с разрешением имён. Чтобы реконет происходил гладко. Можно как в статье играть с TTL, но это надо тестировать, кто его знает как на самом деле мобильные клиенты коннектятся.
Теперь мы одинаково друг друга понимаем… Как будет время, допилю заметку с акцентом на процесс редиректа.
По поводу сертификатов для WiFi. Пока у нас в MS были Win Mobile 6.5, то для коннекта действительно требовалось поставить сертификат. На WP 7.5 для подключения к той же сети достаточно учетных данных в домене. Еще не разбирался, почему так.
Беда WP7 в том, что она не умеет (по факту просто интерфейс не допилен) аутентификацию в рамках EAP-TLS делать. Для меня это самая ожидаемая фича.
дважды прочитал…
не понятно в чём проблема дать разные имена внешней и внутренней службе?!
внутри будет обращаться по одному имени извне по другому.
Правда у меня внутри почему-то обращается по внешнему, хотя внутреннее имя доступно, пробовал и по внутреннему имени через браузер и по имени пула, и по дискаверинтернал — всё доступно, но в упор не хочет обращаться на внутренний сайт. вернее наверное обращается, но ошибка.
Где я ошибся?
Дать имена разные — никакой проблемы нет, написал я это для того, чтобы предупредить заранее. Так как есть соблазн использовать для веб-служб одинаковые имена.
Обращения всегда идут на внешний, даже изнутри, это такое умолчание, о чем я написал в статье (и более подробно описано по ссылкам). Если хочется использовать внутренний адрес, то смотри команду
Set-CsMcxConfiguration –ExposedWebUrl
понял. А если хочется использовать внутри внутренний, а снаружи внешний, как собственно я и думал єто работает)))
так можно?))
В этом случае надо мучаться с одним адресом веб-служб, что внутри сети, так и снаружи, но разрешаемым в разные IP-адреса.
[…] #CU4 Quick Deployment Tool (EN, html, ps1) — Deploying the Lync 2010 Mobility Service (EN, html) — Доступ к Lync Mobility из внутренних сетей WiFi (RU, html) — Reverse Proxy на базе IIS. Блог Станислава Булдакова (RU, […]