Иногда развертывание Microsoft Lync 2013 требует наличие ресурсного домена. Ресурсный домен — это такое место, где живет только непосредственно сам сервер Lync 2013. Пользователи живут в другом домене – пользовательском. Как их подружить между собой, будет рассказано ниже. Кому интересно, добро пожаловать под кат. Будет интересно (и много всяких картинок).
Как обычно, первый вопрос перед любым проектным решением «А зачем это все надо?». Это решение также не стало исключением. Зачем городить огород, если и так все ставится-настраивается и работает?
Первая причина психологическая: установка MS Lync 2013 требует внесения определенных изменений (расширение) в схему Active Directory. Когда у вас один лес с одним доменом на 100 машин это одно, но когда у вас здоровая инфраструктура с кучей доменов и критичных сервисов, расширение схемы как потенциально опасное может стать камнем преткновения при общении с Заказчиком. Работает – не трогай тут как нельзя лучше проявляет себя. И любые ваши уговоры на счет того, что все пройдет нормально воздействия иметь не будут.
Вторая причина обычно возникает на пилотном проекте. Не всегда Заказчик готов с радостью менять свою инфраструктуру чтобы ознакомиться с продуктом и понять, подходит он ему или нет. Тут идет перекликание с причиной номер один: зачем мне в системе всякие новые объекты, если еще не понятно, будет ли внедрен продукт? Т.к. я сам долго проработал системным администратором, то на собственном опыте могу со всей ответственностью заявить – не любят админы вторжения в свою вотчину. А их нелюбовь в полной мере разделяется их руководителями.
Могут быть и другие причины. Например, безопасники имеют свой взгляд на системы коммуникаций и не хотят зависеть от админов в таком вопросе. Или еще что-нибудь.
И остается только одно – поднять отдельную инфраструктуру для MS Lync, где он может делать все что хочет и это не будет оказывать никакого эффекта на существующую инфраструктуру.
В моем примере я буду все выполнять в тестовой среде, которая схематично изображена ниже:
В моей лабе подняты два леса с одним доменом в каждом. Домен contoso.internal подразумевает под собой существующую инфраструктуру заказчика, где все давно налажено. Домен lync.internal подразумевает под собой ресурсный домен, где будет развернут сервер Lync. Между доменами поднято одностороннее доверие, в котором домен lync.internal доверяет домену contoso.internal. Обратное неверно. Одностороннее доверие обусловлено взглядами на безопасность. Но в большинстве случаев можно смело поднимать двухсторонний траст, который ощутимо проще в траблшутинге.
Для воплощения вышеописанной схемы в виртуальной среде была развернута следующая структура подсетей:
Домен contoso.internal развернут в сети 192.168.1.0/24, домен lync.internal развернут в сети 192.168.2.0/24. При этом домен contoso поднят на базе Windows 2008, а домен lync на базе Windows 2003 в силу специфики Заказчика (чтобы у читающего не было вопросов на счет скриншотов). В качестве шлюза был поднят софтовый роутер на базе Vyatta.
Т.к. статья посвящена решению строго определенной задачи, я не буду рассматривать следующие моменты:
Тем не менее, перед установкой Lync я обращу внимание на настройку службы PKI. Она будет удобной для дальнейшей работы.
Вводная часть окончена. Приступаем.
У нас должна быть развернута и настроена сетевая среда. Обязательно проверьте маршрутизацию и прохождение трафика. Отключите firewall на всех машинах. Все же это лаба, а не боевое внедрение.
У нас должны быть развернуты два леса с доменом в каждом. Обязательно поднимите уровень домена и леса в ресурсном лесе до 2003, а то Lync не установится.
У нас должны быть развернуты клиентские машины (например, на Windows 7) с установленными клиентами Lync (например, из комплекта MS Office 2013).
Для работы MS Lync 2013 требуются служба сертификатов. Конечно, можно генерить сертификаты где-то и импортировать в систему. Но мы не для того поднимаем ресурсный домен, чтобы иметь какие-либо ограничения.
Итак, прежде чем разворачивать непосредственно сам Lync нам требуется работающая служба сертификатов. Давайте ее установим и прежде чем она начнет выдавать сертификаты, немного изменим ее настройки.
Зайдем в свойства нашего СА и перейдем на вкладку Extensions. Там мы увидим следующее:
Из всего этого безобразия нам надо оставить только верхную строчку, ведующую к локальному хранению CRL. Остальное смело удаляйте. Далее следует добавить строчку для публикации листа отозванных сертификатов через протокол http в самом простом варианте. Это будет удобно для пользователей юзерского домена. В моем примере я добавил строчку http (не надо выделываться и колдовать с https. Это совершенно лишнее) следующего содержания http://crl.lync.internal/root.crl.
Все выпущенные этим СА сертификаты будут указывать, что проверить список отозванных сертификатов можно по вышеуказанному пути. В рамках данной статьи не рассматривается установка и настройка IIS (или любого другого веб-сервера) для поддержки данного способа публикации и механизм копирования файла. Читателю предлагается выполнить это самостоятельно.
После этого можно смело ставить Lync 2013 в обычном порядке. Не забудьте, что в Lync будет два SIP домена: lync.internal и contoso.internal. Поэтому при развертывании Lync обязательно укажите дополнительный SIP домен.
Если по какой-либо причине Lync у вас уже был развернут ранее, то в Topology Builder добавьте второй домен и проведите необходимые процедуры по изменению конфигурации (публикация и получение новых сертификатов).
Построение доверия процедура достаточно простая. Сначала надо в каждом домене в службе DNS разрешить передачу своей зоны на другой сервер. Можете разрешить для лабы передавать всем или сразу указать, что передавать только строго указанному DNS.
После этого в домене contoso.internal создайте Secondary зону для Lync.internal, а в lync.internal создайте Secondary зону для Contoso.internal. Убедитесь, что данный среплицировались.
После этого можно переходить к поднятию одностороннего доверия между доменами.
Для домена Lync.internal доверие к Contoso.internal будет Outgoing trust, для домена Contoso.internal доверие к Lync.internal наоборот incoming trust.
После создания доверия ОБЯЗАТЕЛЬНО проверьте кнопочкой Validate в свойствах доверия, что оно исправно. Очень много проблем с работой в такой схеме завязано на неправильное функционирование трастов.
Для правильной работы клиентов Lync из пользовательского домена contoso.internal в DNS этого домена следует добавить две записи типа А:
Обе записи должны указывать на IP Lync сервера в домене lync.internal:
В каждом домене заведите для удобства OU Lync Users. В этом OU в домене contoso.internal обычным способом создайте учетную запись. В моем примере это две учетные записи LyncTest и LyncTest2.
В домене lync.internal в аналогичной OU создайте аналогичных пользователей. Пароли значения не имеют. После создания переведите состояние этих учетных записей в положение Disable.
Запустите панель управления (Control panel) Lync 2013 и последовательно добавьте созданные и отключенные учетные записи в систему Lync:
При добавлении записи дайте ей следующие свойства
Т.е. укажите ее sip адресом адрес из домена contoso.internal.
Повторите данную процедуру для каждой добавляемой учетной записи.
В домене Contoso.internal открыть оснастку AD U&C и перевести режим отображения в расширенный:
Для каждой учетной записи, что будет использоваться в Lync выполнить следующее: перейти в свойства учетной записи, открыт вкладку редактора атрибутов и выгрузить на дискетку-флешку значение параметра ObjectSID:
Не забудьте, что каждое значение должно совпадать с учеткой в домене lync. Internal.
Кстати, чтобы клиент Lync не просил ввести имя пользователя в клиенте при первом запуске очень удобно прописать sip-адрес в поле атрибута ProxyAddress. Адрес должен иметь вид sip: имя@домен. Т.е. в нашем случае это будет для пользователя LyncTest2 sip:lynctest2@contoso.internal:
После этого переходим в домен Lync.internal. Т.к. тут у нас 2003 сервер, то для редактирования атрибутов необходима оснастка ADSIedit. Она входит в комплект Support Tools, находящийся на диске с дистрибутивом. Если этой оснастки у вас нет, разверните данные утилиты.
Запускаем ADSIedit и находим наши учетные записи-дублеры в домене lync.internal:
Находим у них атрибут msRTCSIP-OriginatorSid и прописываем сохраненные ранее значения из ObjectSid для каждой учетки соответственно.
Заодно выгружаем корневой сертификат нашего СА и сохраняем на сменный носитель. Он нам пригодится.
В домене contoso.internal заходим на рабочую машину под пользователем, подготовленным для работы с Lync (в нашем примере или LyncTest или LyncTest2).
Запускаем клиент Lync 2013 и…
Получаем ошибку сертификата:
Вот тут нам и пригодится выгруженный ранее сертификат СА. Тем или иным способом распространяем его на машины, которые будут работать с Lync (например, через групповые политики или даже вручную) чтобы данный сертификат оказался в контейнере Trusted Root Certification Authorities.
И после обновления политик снова запускаем клиент Lync 2013. Клиент выведет запрос на пароль. Просто нажмите ОК. Через некоторое время произойдет подключение.
Все.
Не забудьте о CRL. Лист отозванных сертификатов должен быть доступен клиентам Lync. В ином случае через 10 дней клиенты при входе не смогут проверить отозванные сертификаты, и процедура входа будет занимать 5-7 или даже более минут. Пользователей это бесит.
Разумеется, через настройку групповых политик вы можете увеличить валидность уже полученного CRL до бесконечности. Но это уже совсем другая история. Удачи.
Зачем все это может потребоваться?
Как обычно, первый вопрос перед любым проектным решением «А зачем это все надо?». Это решение также не стало исключением. Зачем городить огород, если и так все ставится-настраивается и работает?
Первая причина психологическая: установка MS Lync 2013 требует внесения определенных изменений (расширение) в схему Active Directory. Когда у вас один лес с одним доменом на 100 машин это одно, но когда у вас здоровая инфраструктура с кучей доменов и критичных сервисов, расширение схемы как потенциально опасное может стать камнем преткновения при общении с Заказчиком. Работает – не трогай тут как нельзя лучше проявляет себя. И любые ваши уговоры на счет того, что все пройдет нормально воздействия иметь не будут.
Вторая причина обычно возникает на пилотном проекте. Не всегда Заказчик готов с радостью менять свою инфраструктуру чтобы ознакомиться с продуктом и понять, подходит он ему или нет. Тут идет перекликание с причиной номер один: зачем мне в системе всякие новые объекты, если еще не понятно, будет ли внедрен продукт? Т.к. я сам долго проработал системным администратором, то на собственном опыте могу со всей ответственностью заявить – не любят админы вторжения в свою вотчину. А их нелюбовь в полной мере разделяется их руководителями.
Могут быть и другие причины. Например, безопасники имеют свой взгляд на системы коммуникаций и не хотят зависеть от админов в таком вопросе. Или еще что-нибудь.
И остается только одно – поднять отдельную инфраструктуру для MS Lync, где он может делать все что хочет и это не будет оказывать никакого эффекта на существующую инфраструктуру.
Как это выглядит
В моем примере я буду все выполнять в тестовой среде, которая схематично изображена ниже:
В моей лабе подняты два леса с одним доменом в каждом. Домен contoso.internal подразумевает под собой существующую инфраструктуру заказчика, где все давно налажено. Домен lync.internal подразумевает под собой ресурсный домен, где будет развернут сервер Lync. Между доменами поднято одностороннее доверие, в котором домен lync.internal доверяет домену contoso.internal. Обратное неверно. Одностороннее доверие обусловлено взглядами на безопасность. Но в большинстве случаев можно смело поднимать двухсторонний траст, который ощутимо проще в траблшутинге.
Для воплощения вышеописанной схемы в виртуальной среде была развернута следующая структура подсетей:
Домен contoso.internal развернут в сети 192.168.1.0/24, домен lync.internal развернут в сети 192.168.2.0/24. При этом домен contoso поднят на базе Windows 2008, а домен lync на базе Windows 2003 в силу специфики Заказчика (чтобы у читающего не было вопросов на счет скриншотов). В качестве шлюза был поднят софтовый роутер на базе Vyatta.
Что не будет рассмотрено в данной статье
Т.к. статья посвящена решению строго определенной задачи, я не буду рассматривать следующие моменты:
- настройка виртуальной среды и виртуальных машин;
- развертывание лесов-доменов;
- установка Lync и его клиентов на целевых ПК;
- автоматизацию синхронизации пользователей между доменами.
Тем не менее, перед установкой Lync я обращу внимание на настройку службы PKI. Она будет удобной для дальнейшей работы.
Вводная часть окончена. Приступаем.
Что нам надо для успешного старта
У нас должна быть развернута и настроена сетевая среда. Обязательно проверьте маршрутизацию и прохождение трафика. Отключите firewall на всех машинах. Все же это лаба, а не боевое внедрение.
У нас должны быть развернуты два леса с доменом в каждом. Обязательно поднимите уровень домена и леса в ресурсном лесе до 2003, а то Lync не установится.
У нас должны быть развернуты клиентские машины (например, на Windows 7) с установленными клиентами Lync (например, из комплекта MS Office 2013).
Настройка службы PKI
Для работы MS Lync 2013 требуются служба сертификатов. Конечно, можно генерить сертификаты где-то и импортировать в систему. Но мы не для того поднимаем ресурсный домен, чтобы иметь какие-либо ограничения.
Итак, прежде чем разворачивать непосредственно сам Lync нам требуется работающая служба сертификатов. Давайте ее установим и прежде чем она начнет выдавать сертификаты, немного изменим ее настройки.
Зайдем в свойства нашего СА и перейдем на вкладку Extensions. Там мы увидим следующее:
Из всего этого безобразия нам надо оставить только верхную строчку, ведующую к локальному хранению CRL. Остальное смело удаляйте. Далее следует добавить строчку для публикации листа отозванных сертификатов через протокол http в самом простом варианте. Это будет удобно для пользователей юзерского домена. В моем примере я добавил строчку http (не надо выделываться и колдовать с https. Это совершенно лишнее) следующего содержания http://crl.lync.internal/root.crl.
Все выпущенные этим СА сертификаты будут указывать, что проверить список отозванных сертификатов можно по вышеуказанному пути. В рамках данной статьи не рассматривается установка и настройка IIS (или любого другого веб-сервера) для поддержки данного способа публикации и механизм копирования файла. Читателю предлагается выполнить это самостоятельно.
После этого можно смело ставить Lync 2013 в обычном порядке. Не забудьте, что в Lync будет два SIP домена: lync.internal и contoso.internal. Поэтому при развертывании Lync обязательно укажите дополнительный SIP домен.
Если по какой-либо причине Lync у вас уже был развернут ранее, то в Topology Builder добавьте второй домен и проведите необходимые процедуры по изменению конфигурации (публикация и получение новых сертификатов).
Построение доверия между доменами
Построение доверия процедура достаточно простая. Сначала надо в каждом домене в службе DNS разрешить передачу своей зоны на другой сервер. Можете разрешить для лабы передавать всем или сразу указать, что передавать только строго указанному DNS.
После этого в домене contoso.internal создайте Secondary зону для Lync.internal, а в lync.internal создайте Secondary зону для Contoso.internal. Убедитесь, что данный среплицировались.
После этого можно переходить к поднятию одностороннего доверия между доменами.
Для домена Lync.internal доверие к Contoso.internal будет Outgoing trust, для домена Contoso.internal доверие к Lync.internal наоборот incoming trust.
После создания доверия ОБЯЗАТЕЛЬНО проверьте кнопочкой Validate в свойствах доверия, что оно исправно. Очень много проблем с работой в такой схеме завязано на неправильное функционирование трастов.
Настройка DNS
Для правильной работы клиентов Lync из пользовательского домена contoso.internal в DNS этого домена следует добавить две записи типа А:
- Meet.contoso.internal
- Sip.contoso.internal
Обе записи должны указывать на IP Lync сервера в домене lync.internal:
Настройка пользовательских параметров
В каждом домене заведите для удобства OU Lync Users. В этом OU в домене contoso.internal обычным способом создайте учетную запись. В моем примере это две учетные записи LyncTest и LyncTest2.
В домене lync.internal в аналогичной OU создайте аналогичных пользователей. Пароли значения не имеют. После создания переведите состояние этих учетных записей в положение Disable.
Запустите панель управления (Control panel) Lync 2013 и последовательно добавьте созданные и отключенные учетные записи в систему Lync:
При добавлении записи дайте ей следующие свойства
Т.е. укажите ее sip адресом адрес из домена contoso.internal.
Повторите данную процедуру для каждой добавляемой учетной записи.
Настройка SID
В домене Contoso.internal открыть оснастку AD U&C и перевести режим отображения в расширенный:
Для каждой учетной записи, что будет использоваться в Lync выполнить следующее: перейти в свойства учетной записи, открыт вкладку редактора атрибутов и выгрузить на дискетку-флешку значение параметра ObjectSID:
Не забудьте, что каждое значение должно совпадать с учеткой в домене lync. Internal.
Кстати, чтобы клиент Lync не просил ввести имя пользователя в клиенте при первом запуске очень удобно прописать sip-адрес в поле атрибута ProxyAddress. Адрес должен иметь вид sip: имя@домен. Т.е. в нашем случае это будет для пользователя LyncTest2 sip:lynctest2@contoso.internal:
После этого переходим в домен Lync.internal. Т.к. тут у нас 2003 сервер, то для редактирования атрибутов необходима оснастка ADSIedit. Она входит в комплект Support Tools, находящийся на диске с дистрибутивом. Если этой оснастки у вас нет, разверните данные утилиты.
Запускаем ADSIedit и находим наши учетные записи-дублеры в домене lync.internal:
Находим у них атрибут msRTCSIP-OriginatorSid и прописываем сохраненные ранее значения из ObjectSid для каждой учетки соответственно.
Заодно выгружаем корневой сертификат нашего СА и сохраняем на сменный носитель. Он нам пригодится.
Запуск клиента
В домене contoso.internal заходим на рабочую машину под пользователем, подготовленным для работы с Lync (в нашем примере или LyncTest или LyncTest2).
Запускаем клиент Lync 2013 и…
Получаем ошибку сертификата:
Вот тут нам и пригодится выгруженный ранее сертификат СА. Тем или иным способом распространяем его на машины, которые будут работать с Lync (например, через групповые политики или даже вручную) чтобы данный сертификат оказался в контейнере Trusted Root Certification Authorities.
И после обновления политик снова запускаем клиент Lync 2013. Клиент выведет запрос на пароль. Просто нажмите ОК. Через некоторое время произойдет подключение.
Все.
Не забудьте о CRL. Лист отозванных сертификатов должен быть доступен клиентам Lync. В ином случае через 10 дней клиенты при входе не смогут проверить отозванные сертификаты, и процедура входа будет занимать 5-7 или даже более минут. Пользователей это бесит.
Разумеется, через настройку групповых политик вы можете увеличить валидность уже полученного CRL до бесконечности. Но это уже совсем другая история. Удачи.
