Создание единой адресной книги Exchange для двух и более лесов Active Directory

Маленькое предисловие.
Почтовая организация Exchange существует только в пределах леса AD. Адресные списки, которые видит пользователь, тоже строятся только в пределах того леса, в котором инсталлирован Exchange. В случае поглощения компании или, наоборот, расщепления возникают случаи, когда люди из некогда разных организаций и лесов очень сильно хотят видеть друг друга в своих адресных списках, да не подключаемых через скрипты и запрашиваемые по LDAP.
Удивлён, что на Хабре ничего нет про Forefront Identity Management(FIM 2010).
Вот, как построить единый адресный список, состоящий из пользователей двух разных лесов AD с использованием FIM 2010, я постараюсь рассказать ниже.

Думаю, многие системные администраторы Windows окружения в многолесовой архитектуре знают, что получить легко и просто общую адресную книгу не просто.
Существуют самописные скрипты, которые решают эту же задачу. Есть продукты сторонних производителей. Ну и, конечно же, есть бесплатные инструменты от MS. В некоторых случаях можно подключить внешнюю адресную книгу через LDAP, но это решение сложно поддерживать, т.к. настройка происходит на стороне пользователя и имеет кучу других недостатков.

Мне бы хотелось рассказать про решение Enterprise уровня, которое умеет намного больше, чем просто синхронизировать контакты между лесами, но и объединять разные источники данных о пользователях в одном месте, наделять пользователей полномочиями, управлять членством в группах и куча всего другого. Сегодня остановимся просто на синхронизации контактов.

Прежде всего немного о самом продукте — Forefront Identity Management 2010.
Данный продукт уже неоднократно переименовывался. В районе 2003 года был продукт Microsoft Identity Integration Server (MIIS). Далее его переименовали в Identity Lifecycle Manager (ILM), кажется, в 2007 году, и вот сейчас это всё выродилось в Forefront Identity Management. Функционал продукта возрастал и улучшался.

Как говорилось выше, в нашем кейсе есть два леса AD, в каждом из которых существует своя почтовая организация Exchange 2010.
Буду заурядным и назову свои компании fabrikam.com и всеми любимый contoso.com.
Сам продукт поставлю на отдельный сервер в лес fabrikam.com. Для установки понадобится дистрибутив с официального сайта, MS SQL Server 2008 и выше, установленный на этой же машине или на другом сервере. Я поставил SQL 2008 R2 на эту же машину. Стандартным требованием является установка .NET Framework 3.5.

Создам в настройках DNS сервера обоих лесов перекрёстные Conditional Forwarding записи. И сразу же проверим, что адреса обоих лесов разрешаются с сервера, на котором установлен FIM. Можно, конечно, обойтись и без этого и просто прописать в hosts файле сервера, на котором установлен FIM необходимые записи.

Создам служебную учётную запись в обоих лесах fimacc, как на рисунке:

Дополнительно к имеющимся правам дадим право Replicating Directory Changes командой dsacls dc=contoso,dc=com" /G contoso\fimacc:CA;"Replicating Directory Changes". Это же действие можно сделать и через adsiedit, но займет значительно больше времени.
Создадим иерахию OU в Active Directory обоих доменов. Под корнем каждого домена будет OU — GAL, а под ней Contacts.


На этом подготовительные мероприятия свернём и приступим к настройке Management Agent в интерфейсе FIM.
Вот так выглядит главное окно, где и будем трудиться:
Откроем оснастку Synchronization Service Manager и в разделе Management Agents перейдём к созданию Management Agent.
Укажем имя — Contoso GAL и выберем тип синхронизации — Active Directory global address list (GAL)


На следующем шаге вводим учётные данные пользователя того домена, к которому планируем подключаться, т.е. fimacc из contoso.com.


Если на прошлом шаге подключения не произошло, то надо убедиться в том, что адрес домена разрешается корректно, учётная запись создана и ей делегированы все нужные права.
Далее выберем в верхней части окна наш домен, в нижней части окна через кнопку Containers вызовём диалог выбора нужного контейнера GAL. Необходимо снять выделение с корня домена и выделить GAL, не снимая выделения с дочерних OU.


Следующим шагом станет выбор контейнера, где будут размещаться будущие контакты(Target OU). Я выбрал contoso.com\GAL\AnotherOrg


В этом же шаге добавим SMTP адрес того домена, к которому подключаемся, т.е. contoso.com


И теперь самая простая часть — нажимаем Next,Next,Next до шага Configure Extensions. Тут необходимо указать имя сервера Exchange с ролью CAS. У меня это — W2012T3.contoso.com/PowerShell.


Следует сразу после создания Management Agent его испытать и выполнить Run-Full Import(Stage Only)


Результат подключения к серверу должен быть success. Количество объектов в строчке Adds не равно нулю.


Проделать всё тоже самое для второй организации fabrikam.com
В этот раз укажу учётную запись fimacc из домена fabrikam.com, домен fabrikam.com. Выберу все те же самые OU только в другом домене. Отличий еще два от предыдущей организации: имя сервера, на котором доступен PowerShell, и электронные адреса — @fabrikam.com.
Сделаем Run-Full Import(Stage Only) и получим не нулевой результат.
После успешного завершения предыдущего шага каждый Management Agent необходимо запустить Run-Full Synchronization.


И вновь получить не нулевой результат


Ну и заключительным шагом станет экспорт контактов в целевые леса. Run-Export.


Ну и самое приятное — проверка результата.


Эта заметка иллюстрирует простоту и функциональность данного продукта.
P.S. Мой первый пост, могут быть ошибки форматирования.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 5

    0
    У нас FIM очень активно используется. Весь Identity Lifecycle Management на нем.
      0
      Какой конкретно функционал используете?
        0
        создание и блокировка AD, Notes, VPN аккаунтов. других систем.
        создание, изменение, удаление групп безопасности и групп рассылки
        периодические ресертификации
        много всего
          +1
          Пишите об этом! Тема то очень интересная.
            0
            я просто Advanced пользователь. Система внедрена на всю компанию американским ИТ отделом (Fortune TOP 100).

            в основе идеологии системы (помимо глубокого использования AD, конечно), что мне очень нравится — UPI (Unique Person Identifier). Я видел подобное решение даже не во всех крупных международных компаниях, и это то, что, по моему мнению, должно быть внедрено везде.

            человек получает уникальный номер при приеме на работу в штат, контрактором, или при создании для него аккаунта (даже если сотрудник внешней компании), и сохраняет этот номер неизменным всегда. Он может увольняться и возвращаться, менять статус на контрактора или, наоборот, штатного сотрудника, уйти к партнеру, поменять фамилию, юрлицо. табельный номер, AD аккаунт и т.д. — но номер останется.

            к этому номеру (идентификатору) привязываются AD аккаунты и другие (зависимые) бизнес-системы.

            кроме того, этот номер используется в общении между разными функциями (например, между HR и административным отделом неудобно использовать табельный или ФИО, а вот UPI — очень удобно).

            даже не представляю, как бы мы работали без него (точнее помню, как работали без такого ID в предыдущей компании, и это был ужас)

    Only users with full accounts can post comments. Log in, please.