А что, Microsoft отказалась от попыток создания более гибких лесов Active Directory (AD)? Хотелось бы разобраться в этом вопросе. Я уже рассказывал о Microsoft Identity Integration Server (MIIS), предложении компании Microsoft в области службы интеграции каталогов, и объяснил, что этот инструмент нужен для облегчения жизни системным администраторам в условиях работы приходится с самыми разными производителями программного обеспечения, когда каждый из них предлагает свою службу каталогов. Напоминаю, что существует две версии MIIS: продвинутая версия MIIS, по цене $25,000 на один процессор, и версия Microsoft Identity Integration Feature Pack (IIFP), которая распространяется бесплатно, но ей для работы требуется Windows Server 2003 Enterprise Edition. В основном IIFP решает задачу автоматизации обслуживания учетных записей пользователей в двух и более лесах AD. Но почему вообще этим приходится заниматься?

Первая причина, почему вам может понадобиться обслуживать множественные учетные записи пользователей в двух и более лесах AD, связана с юридическими вопросами. Если вы работаете в инвестиционном банке, скорее всего вам приходится иметь дело с тремя типами сотрудников: брокеры, которые продают клиентам продукты; аналитики, которые проводят профессиональные исследования в интересах клиентов для обоснованного принятия решений последними; и все остальные. Предположим, что из соображений безопасности или принятого в данной стране законодательства вам необходимо иметь два леса: один для исследователей и другой для продавцов. Но некоторым сотрудникам необходимо "жить" и там, и там – например, сотрудникам IT-служб или каким-то "большим начальникам". Поэтому администратор вынужден заводить для них учетные записи и в лесу исследований, и в лесу продаж, со всеми вытекающими отсюда неприятными для обслуживания последствиями. Например, когда такой пользователь меняет свой пароль в одном лесу, то же самое необходимо сделать и в другом лесу; когда сотрудница меняет фамилию – выходит замуж, например, - то везде в AD, где фигурирует ее старая фамилия, надо выполнить соответствующие изменения. С помощью IIFP администратор выполняет необходимые изменения только в одном месте, а все остальное за него выполняет IIFP. Синхронизация пользовательских учетных записей в двух – или трех, или пяти – лесах может показаться сущим пустяком, но поверьте мне, это не так. Наличие такого бесплатного инструмента как IIFP очень кстати.

Мне могут возразить – мол, "я не работаю в брокерском доме, и вопросы законодательства в этот смысле меня не касаются, поэтому мне не нужно заводить множество лесов"? Хорошо, но держу пари, что если вы работаете с AD, вам как минимум нужны два леса: один лес "рабочий" – лес компании, и отдельный лес AD для тестирования. Так что некоторые сотрудники будут иметь учетной записи в обоих лесах и, следовательно, вопрос синхронизации записей возникнет.

Теперь рассмотрим такую ситуацию. Представим себе, что компания United Airlines решила диверсифицировать свой бизнес и прикупила компанию Amtrak. Я не говорю, что это решение правильное, я говорю – "представим себе". В обеих компаниях функционирует AD. После того, как компании оказываются в одной организации, как будет производиться слияние двух лесов?

Вероятно, самый быстрый способ решить проблему слияния – воспользоваться IIFP. С привлечением IIFP ничто не помешает вам использовать оба леса. каждый со своей собственной почтовой организацией Exchange. Можно предположить, что многим в Amtrak вскоре может понадобиться учетная запись в лесу United без прекращения действия старой учетной записи Amtrak, хотя бы просто в силу централизации IT-персонала. И вот здесь IIFP может пригодиться.

Есть кое-что, что следует запланировать на перспективу. Скорее всего, администраторы будут постепенно переносить объекты из леса Amtrak в лес United, поставив цель в конце концов закрыть лес Amtrak. Но в данном случае термин мигрировать (migrate) может ввести в заблуждение, поскольку речь идёт о лесах AD. Миграция в действительности означает "разъединение безопасности обоих доменов, установка доверительных отношений, а затем использование инструмента миграции для копирования объектов из одного леса в другой". Также это означает необходимость "подготовиться к манипуляции над скопированными объектами, решение проблем несовместимости (например, на уровне SID), и пр." Короче, путаница очень даже возможна. Не поймите меня превратно: я не против утилит миграции. Всякий, кто занимался аналогичной задачей, понимает, о чем идёт речь. Я говорю – только в печати лет 6 – что Windows отчаянно нуждается в безболезненной технологии "склеивания" двух лесов, в своего роде программе Forest Wizard. И это не мои персональные фантазии. Впервые я услышал о такого рода задаче от сотрудников Microsoft в конце 90-х годов. Десятки раз я слышал такие высказывания: "Да, мы знаем, что вы не можете перемещать домены из существующего леса и создавать на их основе автономные леса, не можете взять домен из одного леса и вставить его в другой лес, не можете склеить два домена, но это же самая первая версия. Ко времени выхода Blackcomb мы обязательно все поправим".

В то время предполагалось, что время Blackcomb наступит где-то в 2005-2006 году. Я предполагал, что ждать придется не очень долго, около 5 лет. Я даже сейчас не жалуюсь, хотя планы выхода Blackcomb отодвинулись ориентировочно на 2011 год, поскольку считаю, что лучше подождать ещё какое-то время, пока код не созреет до устойчивого состояния, чем выпустить кишащий ошибками код прямо сейчас. Но меня беспокоит то, что сегодня я уже ничего не слышу о давно обещанной функциональности – возможности объединять леса. Создаётся впечатление, что разработчики AD считают, что организациям с огромным числом лесов надо просто продолжать работать, ничего не меняя, и лишь использовать некоторые формы MIIS (например, IIFP) для синхронизации лесов.

Если раньше в Microsoft говорили, что самое крупная структура Windows – лес, то сейчас говорится, что самая крупная структура – это федерация (federation), которая представляет собой группу лесов, соединенных друг с другом некоторым образом, возможно, с помощью утилиты, подобной IIFP. Сегодня разработчики AD работают над созданием группы под названием "Identity and Access Group". Безусловно, это работа заслуживает высокой оценки, но было по-прежнему неверно считать, что речь идёт о коренной переработке AD. Когда спрашивают о прогрессе в отношении объединения лесов или доменов, чаще всего приходится слышать, что о таком проекте в Windows ничего не слышали.

Очень хорошо, что есть службы метакаталогов, подобные IIFP, для поддержания совместной работы большого числа лесов. Тот факт, что IIFP ничего не стоит – тоже прекрасно. Но как поведет себя эта программа с ростом масштаба решаемой задачи? Насколько надежна в работе федерация, в которой будут насчитываться сотни или даже тысячи всевозможных отношений доверия? Я думаю, что ответа на этот вопрос пока не знает никто. Все мы помним истории с развертыванием в организациях Windows NT 4.0 с большим числом доверительных отношений и насколько эти конструкции оказались ненадежными; не случится ли то же самое и с огромными федерациями AD?

Когда организация насчитывает несколько лесов, метакаталоги представляются прекрасным временным решением, достаточным в качестве краткосрочной перспективы. Но при отсутствии утилит, которые бы помогли объединять домены или леса, выходит, что из краткосрочной данная перспектива превращается в долгосрочную головную боль.

Марк Минаси, help@minasi.com