Для решения такой задачи существует специальное развертывание 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, и работать!

Для тех, кто по каким-то причинам не смог посетить семинар, мы решили выложить видеозаписи докладов:

Доклад по  Windows Server 2008 R2:

Доклад по Exchange Server 2010:

Доклад по Office Communications Server 2007 R2:

Доклад по GFI:

Также, вы можете отдельно скачать сами презентации:

Презентация Windows Server 2008 R2

Презентация Exchange Server 2010

Презентация Office Communications Server 2007 R2

Презентация  GFI: Часть 1, Часть 2.

Внимание! Все материалы презентаций являются собственностью компаний LanKey, Microsoft и GFI. Без письменного разрешения владельцев запрещается частичное или полное копирование и публикация любых материалов данных презентаций.

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

RemoteFX – это обновление к Remote Desktop для Windows Server 2008 R2, входящее также и в клиент Remote Desktop для Windows 7. Предполагается, что RemoteFX позволит значительно ускорить отображение сложного контента, такого, как Silverlight, Flash, в терминальных сессиях.

А также – появилось важное обновление для виртуализации XP Mode в Windows 7. Теперь XP Mode не требует для запуска поддержку виртуализации на процессоре – так что он станет доступнее для клиентов.

DPM 2010 RC интересен (кроме того, что его выход означает – релиз уже близко!) тем, что он поддерживает бэкап виртуальных машин кластера Hyper-V 2 с Cluster Shared Volumes. Чисто случайно как раз такой кластер оказался под рукой, поэтому было принято решение – устанавливать

Развертывание DPM 2010 RC открыло несколько любопытных вещей, которыми я и хочу поделиться:

DPM 2010 Release Candidate поддерживает простой апгрейд с DPM 2010 Beta. Я тестировал его на двух системах – одна инсталляция была выполнена на Windows Server 2008 R2, вторая – на Windows Server 2008 x64.

Beta-версия DPM 2010, кстати, нормально апгрейдится с DPM 2007 SP1 - устанавливает новый SQL-сервер, и апгрейдит старую базу DPMDB. Все параметры и бэкапы при этом сохранились. Как работает апгрейд с DPM 2007 на DPM 2010 RC – сказать пока не могу, не пробовал.

Апгрейд DPM 2010 Beta, стоящего на R2, прошел без проблем и вопросов. А вот для апгрейда той Betы, которая стоит на Windows Server 2008, инсталлятор попросил меня скачать и установить два патча – с номерами 975759 и 962975. Причем, эти патчи недоступны через Windows Update и выдаются по запросу на сайте – нужно только ввести свой e-mail.

После инсталляции вышеуказанных патчей апгрейд DPM прошел на ура. Кстати интересно - RC использует другой instance своего SQL-сервера, и если для Beta он назывался MSDPMV3BETA1EVAL, то для версии RC дополнительно ставится SQL instance с названием MSDPM2010RCEVAL. Базу данных инсталлятор переносит и обновляет сам – но не забудьте перед апгрейдом все-таки сделать ее резервную копию , а также удостовериться, что на диске хватит места под еще один экземпляр SQL Server 2008 и базу данных MSDPM.

Итак, после установки Release Candidate версия DPM станет 3.0.7558.0, вместо версии 3.0.7336.0 у Beta.

После апгрейда самого сервера нужно сапгрейдить и агенты DPM – для этого открываем консоль DPM, заходим в Management -> Agents, и нажимаем на ссылку Update Available рядом с каждым сервером.

Кстати говоря, на некоторые серверы через DPM агент по неясным причинам обновляться отказался – так и оставался в состоянии Needs Updating. Пришлось запускать на сервере установку агента вручную – из папки Agents дистрибутива DPM. После установки агента вручную достаточно нажать Refresh на странице консоли DPM.

Больше ничего с существующими Protection Group делать не надо – все предыдущие настройки и бэкапы сохраняются и подключаются нормально.

А вот при попытке добавить в Protection Group виртуальную машину с кластера Hyper-V, DPM выдал любопытное сообщение:

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

• Для Windows Server 2008 – 948465 (это просто Service Pack 2), и 971394.
• Для Windows Server 2008 R2 – 975921 и 975354.

Эти обновления опять-таки необходимо загружать с Microsoft по запросу, указывая свой e-mail, на который и придет ссылка для скачивания файлов, вместе с паролем.

Вот такие любопытные нововведения продолжаем исследовать RC, и ждем релиз.

Компоненты интеграции предназначены для обоих версий платформы Hyper-V – как для первой версии, входящей в состав Windows Server 2008, так и для второй, входящей в состав Windows Server 2008 R2. Эти компоненты включают в себя:

• драйвер синтетической сетевой карты
• драйвер синтетического адаптера SCSI
• драйвер блочного устройства VSC – поддержка синтетического адаптера IDE для увеличения быстродействия при загрузке

Драйвер мыши для графической оболочки Linux в комплект не входит.

Обращаем внимание, что для большинства виртуальных машин Linux доступно использование только одного виртуального процессора. Полноценная поддержка Hyper-V в ядре начинается с ядра версии 2.6.32.

Журналисты цитируют следующее заявление Дмитрия Сумина, президента Passware: «Полное шифрование диска представляет собой серьезную проблему для следователей. Мы смогли предоставить полиции, правоохранительным органам и частным детективам инструмент, который позволяет обойти BitLocker шифрование.»

Вот лишь некоторые примеры:

http://news.softodrom.ru/ap/b5920.shtml

http://www.inattack.ru/news/3291.html

http://www.xakep.ru/post/50347/

Меня задолбали сообщения в аську от друзей и знакомых, которые увидев подобные новости, спешили проинформировать меня и позлорадствовать «типа поломали твой Microsoft».

Мне эта чушь надоела, и я решил написать статью на блог.

И так, BitLocker – это средство шифрования дисков, которое присутствует в Windows 7 и Vista, Windows Server 2008 и 2008 R2. А весь шум гам  возник, после выхода продукта Passware Kit 9.5, который, по заявлению производителя, теперь умеет взламывать BitLocker.

Давайте разберёмся, как же работает сие чудо. Для так называемого взлома зашифрованного тома программе требуется предоставить собственно дамп зашифрованного тома и (внимание!) дамп физической памяти компьютера! Мало того, дамп должен быть сделан, после того, как вы ввели правильный пароль и разблокировали зашифрованный диск!

Товарищи, о чём мы говорим? Где здесь взлом?

Естественно, что в процессе работы с зашифрованным томом, в оперативной памяти находятся ключи шифрования. Но как только вы компьютер выключили, память очищается! Даже если вдруг, к злоумышленнику попадёт включенный компьютер, но залоченный, всё равно шансы извлечь ключи из памяти практически равны нулю.  (не надо мне только про жидкий азот). Ещё один способ получить дамп памяти – это использовать файл hiberfil.sys. Но вопервых этот файл создаётся только, когда используется режим гибернации, а во вторых он располагается на системном томе, который по идее тоже должен быть зашифрован.

Сами разработчики, так вообще предлагают сделать дамп памяти при помощи утилиты MDD от компании ManTech, которая для работы требует администраторские права, пытается установить неподписанный драйвер, что естественно блокируется системой. Но даже после всего этого у меня на Windows 7 x64 утилита, так и не смогла сделать дамп.

Так, что мне вообще не понятен практический смысл возможности «взлома» BitLocker, предлагаемый Passware. М.б. кто-то объяснит?

PS.

Кстати, Passware Kit включает в себя достаточно много средств взлома. Но на своём опыте могу сказать, что и они не отличаются особой эффективностью. Так например, уже достаточно давно Passware предлагает нам средства взлома EFS. Кто-нибудь его взломал? Нет? А почему? Да потому, что предлагается почти тоже самое, для взлома нужно предоставить сертификат с закрытым ключом, которым всё шифровалось, да и ещё кажется и пароль. – ну это же бред! С паролем и сертификатом и сам Windows может всё открыть.

По моему ничего эффективнее ректотермального криптоанализа ещё не изобрели.

Само железо было оттестировано различными мемтестами – ничего не показало. Да и очень вряд ли в брендовых серверах что-то не так с компонентами

В журнале производительности записывается ошибка:

The computer was rebooted from a bugcheck. The bugcheck was: 0x00000101 (0x000000000000000d, 0x0000000000000000, 0xfffff880022e2180, 0x000000000000000c).


Причина оказалась очень интересной. Дело в том, что в серверах стоят новые процессоры Intel Xeon E5520, с архитектурой Nehalem. И, оказывается, в этих процессорах есть ошибка – что-то не так с прерываниями. Intel выпустила описание ошибки, и соответственно, Microsoft сформировала knowledge base и опубликовала патч – http://support.microsoft.com/kb/975530. И проявляется эта ошибка именно под управлением операционной системы Windows Server 2008 R2 и ролью Hyper-V. Причем, так как проблема проявляется только на строго определенных процессорах – данный патч недоступен через Windows Update, и его надо качать вручную.

Решение: установка патча с сайта Microsoft, взятого по адресу http://support.microsoft.com/kb/975530. После установки – перезагрузить сервер.

Ждем патча от Intel в виде паяльника и набора радиокомпонентов «Сделай сам»

Проблема в обновлении KB974571 – «MS09-056: Vulnerabilities in CryptoAPI could allow spoofing». После установки этого обновления службы Front-End, Access Edge не запустятся.

Например, для Office Communications Server 2007 R2 в журнале событий появляются записи:

Event Type: Error
Event Source: OCS Server
Task Category: (1000)
Event ID: 12290
Description:
The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.



Event Type: Error
Event Source: OCS Server
Task Category: (1000)
Event ID: 12299
Description:
The service is shutting down due to an internal error.
Error Code: C3E93C23 (SIPPROXY_E_INVALID_INSTALLATION_DATA)
Resolution:
Check the previous event log entries and resolve them. Restart the server. If the problem persists contact product support.


Решение: если вы еще не разворачивали обновления – не устанавливайте обновление KB974571. Если уже установили – деинсталлируйте это обновление.

Поскольку данное обновление имеет статус «Критическое» – его установка в дальнейшем крайне желательна. Ожидаем разрешения проблемы и свежего обновления от Microsoft.

Компания «ЛанКей» участвует в акции компании Microsoft «Время, вперед с Windows Server 2008 R2″. Зайдите по этому адресу, заполните форму – и мы приедем к вам, бесплатно расскажем о новом продукте Windows Server 2008 R2, и ответим на ваши вопросы.