IT-блог компании "ЛанКей"

Как известно, Office Communications Server 2007 R2 всю свою информацию хранит в Active Directory, и при развертывании он изменяет лес AD – расширяет схему, создает новые атрибуты пользователей. Бывают случаи, когда изменение схемы Active Directory основного леса нежелательно – а тем не менее, развернуть и использовать OCS надо, и хочется использовать все прелести объединенных коммуникаций.

Для решения такой задачи существует специальное развертывание Office Communications Server, называемое развертыванием в ресурсном лесу (resource forest). Это значит, что параллельно с существующим у нас основным лесом и доменом мы можем развернуть совершенно отдельный лес, в котором и будет располагаться OCS. Это решение поддерживается Microsoft и описано в паре англоязычных документов, ну а чтобы не отсылать читателя к ним, мы расскажем по-русски, как это сделать.

Пусть у нас есть некий основной домен с пользователями, называющийся например mycompany.ru. Соответственно, пользователи имеют e-mail-адреса логин@mycompany.ru, пользуются Outlook’ом, Exchange (неважно каким, но лучше конечно 2007/2010 ).

Развертывание OCS в ресурсном лесу будет состоять из следующих шагов:

1. Развертывание отдельного леса, с именем например myocs.local
2. Установка доверия между доменами
3. Развертывание OCS в лесу myocs.local
4. Создание в этом лесу учетных записей-заглушек для пользователей основного домена
5. Наслаждение работой с объединенными коммуникациями Microsoft

Шаг 1 – развертывание отдельного леса

Для отдельного леса нам понадобится один компьютер, который будет служить контроллером домена этого леса. Конечно, в идеале их должно быть как минимум два, но поскольку мы рассматриваем тестовый вариант – можно ограничиться одним компьютером. И, конечно, для удобства это будет виртуальная машина, запущенная под управлением Hyper-V на Windows Server 2008 R2.

Структура лесов будет выглядеть следующим образом:

Итак, мы установим компьютер операционной системой Windows Server 2008 R2, назовем его dcrf, и промотируем его до домен-контроллера. При создании домена укажем, что это новый домен нового леса. А домен назовем myocs.local.

Уровень домена/леса должен быть не ниже 2003 – так требует OCS. Поскольку ресурсный лес будет обслуживаться только этим контроллером – смело ставим уровень леса в Windows Server 2008 R2.

Я использую для контроллера именно Windows Server 2008 R2, потому что в нем есть встроенные коммандлеты для управления Active Directory, что очень поможет нам на шаге 4, при создании пользователей-заглушек с информацией из основного домена.

Так как нам необходимо, чтобы между доменами было доверие – то контроллеры доменов dc.mycompany.ru и dcrf.myocs.local должны находить друг друга. Поэтому следующим шагом будет соответствующая настройка DNS – создадим на DNS-сервере dcrf.myocs.local форвардинг на IP-адрес контроллера dc.mycompany.ru, а на DNS-сервере dc.mycompany.ru – conditional forwarding для домена myocs.local на IP-адрес dcrf.myocs.local.

На этом же сервере развертывается Enterprise Root Certification Authority, который будет использован для выдачи сертификатов для серверов OCS.

Шаг 2 – настройка доверия между доменами

После того, как мы добьемся, что оба домена друг друга увидят – разрешат имена серверов, можно настраивать доверие.

Достаточно создать 1-way trust от ресурсного домена к основному – то есть, ресурсный домен доверяет логиниться к себе пользователям из основного. Открываем AD Domains and Trusts на dcrf.myocs.local, и создаем External Trust, 1-way outgoing, до домена mycompany.ru. И, соответственно, на контроллере dc.mycompany.ru создаем External Trust, 1-way incoming.

Итог – мы создали ресурсный лес, и установили доверие с основным рабочим доменом.

Шаг 3 – развертывание OCS в ресурсном лесу

Далее, совершенно обычным образом развертываем Office Communications Server 2007 R2 на серверах в ресурсном лесу. Я назвал такие сервера ocsse.myocs.local и ocsmed.myocs.local, на которых будут развернуты Standard Edition и Mediation Server соответственно. Edge-сервер нам не потребуется – все пользователи будут авторизоваться посредством доверия между доменами, с помощью обычных своих учетных данных.

Установим мы серверы на для удобства тоже на виртуальных машинах – но уже само виртуальные машины будут содержать Windows Server 2008. Поскольку Office Communications Server 2007 R2 не очень хорошо работает на Windows Server 2008 R2, придется использовать предыдущую версию операционной системы.

При установке OCS крайне важно указать следующее – в качестве домена для установки мы выбираем домен myocs.local. А в качестве SIP-домена мы указываем домен mycompany.ru. Это необходимо, поскольку мы хотим, чтобы SIP-адреса пользователей совпадали с их email-адресами, то есть, относились бы к домену mycompany.ru.

Я не буду расписывать подробно установку OCS, настройку и связь с VoIP-шлюзом - это можно найти в соответствующих статьях на этом же блоге.

Главное, что нужно изменить после инсталляции OCS – указать в параметрах Front-End сервера Standard Edition тип авторизации пользователя - только NTLM.

Это важно, поскольку стоящая по умолчанию настройка – Kerberos and NTLM – не позволит авторизоваться пользователям основного домена.

В результате мы получаем два сервера Office Communications Server 2007 R2 в ресурсном лесу, и следующим нашим шагом будет создание пользователей-заглушек.

Шаг 4 – создание и синхронизация информации о пользователях

Поскольку пользовательские учетные записи располагаются в основном домене, а OCS-у требуется, чтобы у него были свои учетные записи, со списком контактов и соответствующими параметрами – необходимо создать отключенные пользовательские аккаунты в домене myocs.local, для которых будут храниться настройки Office Communications Server. А для того, чтобы не приходилось дублировать и синхронизировать пароли – необходимо обеспечить взаимосвязь между действующим аккаунтом пользователя в основном домене, и отключенным аккаунтом пользователя в ресурсном лесу.

Известно, что основным идентификатором пользователя в домене является его SID – Security Identifier. После установки OCS (и соответствующего расширения схемы AD) в ресурсном лесу у объекта пользователя присутствует специальное поле msRTCSIP-OriginatorSID – нам необходимо записать в него SID пользователя из основного домена. Таким образом, в ресурсном лесу у пользователя будет два SID-а – один обычный, относящийся к ресурсному лесу, и второй, который мы занесем вручную – SID пользователя из основного рабочего домена.

Ну и конечно, для того, чтобы в контакт-листе Communicator отображалась полноценная информация о пользователе – необходимо указать имя и фамилию пользователя, его телефон, должность, и e-mail.

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

Создавать объекты и переносить атрибуты, конечно, можно и вручную – но это неинтересно и долго. Как я уже упомянул, в Windows Server 2008 R2 есть коммандлеты PowerShell, которыми я и воспользуюсь.

Вот простейший скрипт, от которого можно отталкиваться в собственных случаях:

$srcdc = "dc.mycompany.ru" # исходный домен
$srcbase = "OU=Domain users,DC=mycompany,DC=ru" # OU, который сканируем на предмет пользователей
$dstdc = "dcrf.myocs.local" # ресурсный домен
$dstbase = "OU=OCS Users,DC=myocs,DC=local" # OU, в котором будут созданы объекты-заглушки.
New-PSDrive -Name DstAD -Root "" -Server $dstdc -PSProvider ActiveDirectory -Cred MYOCS\Administrator # подключаемся к ресурсному домену с правами администратора, который может создавать объекты.
New-PSDrive -Name srcAD -Root "" -Server $srcdc -Cred MYCOMPANY\user -PSProvider ActiveDirectory # подключаемся к исходному домену с правами просто пользователя, который может хотя бы читать данные из исходного AD.
cd srcAD:
$usrs = get-ADUser -SearchBase $srcbase -Filter * -Properties mail # выбираем всех пользователей в указанном OU.
cd dstAD:
foreach ($u in $usrs) {
   echo $u.name
   New-ADUser -Path $dstbase -DisplayName $u.Name -Name $u.name -GivenName $u.GivenName -Surname $u.Surname -SamAccountName $u.samAccountName -OtherAttributes @{'mail'=$u.mail;'msRTCSIP-OriginatorSid'=$u.SID} # создаем пользователя, указывая для него необходимые аттрибуты. Пользователь создается отключенным - Disabled.
}
cd c:
remove-psdrive srcad
remove-psdrive dstad

Этот скрипт не совсем полный – он не переносит должности, название компании, город и офис. Мне это было не нужно - но это всегда можно дописать самостоятельно

Можно заметить, что в ресурсном домене мы создаем пользователей, не указывая для них пароли. Это действительно неважно – так как пользователи будут авторизоваться по своим собственным учетным данным в основном домене, а затем уже просто сопоставляться с отключенными аккаунтами в ресурсном лесу.

После создания пользователей-заглушек мы обычным образом включаем их – Enable for Office Communications Server, и настраиваем – Configure for Office Communications Server.

В основном домене необходимо будет сделать лишь одно изменение – добавить в атрибут proxyAddresses пользователей адрес вида sip:логин@mycompany.ru. Это необходимо для того, чтобы при запуске Communicator пользователю не приходилось бы вручную указывать свой SIP-адрес для входа. Сделать это можно с помощью ADSI Edit, с помощью Email Address Policy в Microsoft Exchange, или написать свой скрипт – как угодно.

Шаг 5 – запускаем и работаем

Все! теперь можно смело ставить на клиентские компьютеры Office Communicator. Также необходимо импортировать на клиентские компьютеры сертификат того корневого центра сертификации, который использовался при создании сертификатов для серверов OCS. В нашем случае это сертификат с центра сертификации dcrf.myocs.local. Импортировать этот сертификат нужно в раздел «Доверенные корневые центры сертификации».

Конечно, необходимо добавить в DNS-зону mycompany.ru записи sip.mycompany.ru и _sipinternaltls._tcp.mycompany.ru – подробнее смотрите в статье по установке и настройке Office Communications Server 2007 R2.

После этого можно смело запускать Office Communicator, и работать!