Возвращение Active Directory Connector

Коннектор Active Directory Connector (ADC) появился одновременно с Exchange 2000 Server. ADC обеспечивает синхронизацию данных службы Exchange Server 5.5 Directory Service (DS) с Active Directory (AD). В результате организации, располагающие как серверами Exchange 5.5, так и Exchange 2000 или Exchange Server 2003, получают единый согласованный глобальный список адресов (Global Address List - GAL) и общий согласованный перечень конфигурационной информации.

За годы существования ADC подверглась значительным усовершенствованиям. Возможности версии, используемой в настоящее время с Exchange 2003, значительно шире, чем у прежних версий. Компания Microsoft незаметно исправила много ошибок в ADC и значительно расширила внутреннюю функциональность - в частности, в Exchange 2003 Service Pack 1 (SP1) появились новые возможности перемещения почтовых ящиков между сайтами. В данной статье рассматриваются несколько слабо документированных и малоизвестных аспектов ADC, которые, тем не менее, очень важны для администраторов Exchange.

Создание и перенос учетной записи ADC

В ходе синхронизации объектов почтовых ящиков, в версии ADC для Exchange 2000 используется набор правил согласования объектов, чтобы обнаружить в AD объект, связанный c внутрипроцессным объектом Exchange 5.5. В соответствии с этими правилами сначала проводится сравнение глобально уникальных идентификаторов (globally unique identifiers - GUID), затем отличительных имен (distinguished name - DN), и наконец, идентификаторов безопасности (security identifier - SID). Если в AD нет подходящих объектов, то ADC генерирует новый объект (обычно объект user) в AD. Новый объект user создается с атрибутом samAccountName (также User logon name), который соответствует псевдониму почтового ящика Exchange 5.5 (Экран 1).

Данная возможность успешно применяется во многих организациях, но проблемы возникают, если ADC генерирует учетные записи прежде, чем будет выполнена любая миграция унаследованных учетных записей Windows NT 4.0 в AD. В таких случаях ADC может создать учетную запись AD с именем neiln (как видно на Экране 1), но если администратор впоследствии использует инструмент ADMT (Active Directory Migration Tool) для миграции соответствующей учетной записи NT 4.0, то возникает конфликт именования. Во многих организациях регистрационные имена NT 4.0 идентичны псевдонимам почтовых ящиков Exchange. В случае конфликта, ADMT обычно присоединяет числовое значение в начале или конце samAccountName вновь созданного объекта. Таким образом, ADC может создать две учетные записи с именами neiln и neiln-1. Обычное решение в такой ситуации - отыскать и объединить совпадающие объекты с помощью инструмента AD Cleanup Tool, но к сожалению, AD Cleanup Tool вставляет объект, созданный ADC, в объект, генерируемый ADMT. Таким образом, имена пользователей изменяются и приобретают такой вид, как neiln-1, или приходится изменить имена учетной записи.

Кроме того, некоторые организации "срезают углы" и используют генерируемый ADC объект в качестве нормальной входной учетной записи. Это может привести к катастрофическим последствиям, так как в отличие от учетной записи, генерируемой ADMT, объект, созданный ADC, не имеет атрибута sIDHistory; поэтому после миграции теряется доступ к таким ресурсам, как принтеры, сетевые диски и группы. Только при использовании ADMT (или другого стороннего инструмента миграции учетных записей) для переноса учетных записей NT 4.0 можно полностью воспроизвести контекст безопасности.

Если пользователи активизируют и работают с генерируемыми ADC учетными записями, как с настоящими, то могут возникнуть другие проблемы, связанные с доступом к Public Folder и делегированием доступа к почтовому ящику. Когда пользователь Exchange пытается обратиться к Exchange Public Folder, процесс Exchange Store использует атрибуты AD, связанные с почтовым ящиком, чтобы выяснить, имеет ли пользователь полномочия для доступа к информации Public Folder. Только ADC может присвоить значение атрибуту ExchMasterAccountSID: учетные записи, созданные в AD с помощью Exchange System Manager (ESM) или ADMT, не имеют значения для атрибута msExchMasterAccountSID. Поэтому, если пользователь продолжает регистрироваться в старой учетной записи NT 4.0 (совершенно отдельной от AD), то его полномочия и возможность обращаться к контенту Pubic Folder или почтовому ящику другого пользователя определяется значением msExchMasterAccountSID - но не SID, связанного с учетной записью, генерируемой ADC.

Однако, для учетных записей AD, созданных с помощью ESM или ADMT, при определении условий доступа к ресурсу в Store используется контекст безопасности объекта (через objectSID или sIDHistory). Процессу Store известно, какой подход следует использовать, так как предполагается, что активизированный объект (созданный ESM или ADMT) может использовать свой контекст безопасности, но блокированный объект (созданный ADC) должен работать с msExchMasterAccountSID. Поэтому, если пользователь использует для регистрации учетную запись, генерируемую ADC, то может оказаться, что подходящий контекст безопасности отсутствует.

Некоторые сторонние инструменты миграции «NT 4.0 - AD» более аккуратно работают с объектом, созданным ADC, атрибут samAccountName которого совпадает с именем переносимой из NT 4.0 учетной записи. Эти инструменты распознают, что соответствующие значения взаимосвязаны, и объединяет их во время миграции учетной записи NT 4.0. Поэтому в AD не существует дублированных объектов и впоследствии не возникает необходимости использовать AD Cleanup Tool.

Изменения при преобразовании samAccountName

В целях упрощения, компания Microsoft изменила поведение ADC в Exchange 2003. В версии ADC для Exchange 2003 атрибут samAccountName рандомизируется, когда ADC генерирует объект AD для почтового ящика Exchange 5.5. Вместо создания учетной записи AD с именем, совпадающим с псевдонимом почтового ящика Exchange 5.5, ADC генерирует имя учетной записи AD (атрибут samAccountName) с таким значением, как ADC_SNWNIEAEHAIGTRWNV.

У рандомизации значений samAccountName есть два следствия. Во-первых, если ADMT переносит учетную запись NT 4.0 в AD, то верятность конфликта имен мала, так как имя учетной записи NT 4.0 вряд ли будет таким же, как samAccountName объекта, созданного ADC. Поэтому имя учетной записи, генерируемой ADMT, будет идентично имени учетной записи NT 4.0, и когда AD Cleanup Tool объединит две учетные записи, сохранится нужное имя (neiln, а не neiln-1). Во-вторых, фактически устраняется проблема использования учетной записи, подготовленной ADC, в качестве первичной учетной записи при регистрации. Даже самые технически грамотные пользователи вряд ли решатся применять длинное и трудно запоминаемое рандомизированное имя для регистрации.

У нового подхода есть очевидные преимущества, но возникают затруднения при использовании некоторых сторонних инструментов миграции, в которых предполагается идентичность атрибута samAccountName объекта, генерируемого ADC, данным для регистрации учетной записи NT 4.0. По этому полю ведется поиск соответствий в ходе миграции учетной записи NT 4.0. В результате изменений в поведении, эта функциональность более неприменима. Хотя с момента изменений в версии ADC для Exchange 2003 прошло довольно много времени, данная проблема по-прежнему не решена во многих инструментах миграции (например, Microsoft ADMT).

Существует возможность (слабо документированная и малоизвестная) блокировать рандомизацию samAccountName в версии ADC для Exchange 2003. Чтобы отменить рандомизацию и восстановить прежнее поведение для данного соглашения о соединении (connection agreement - CA) ADC необходимо установить разряд 15 атрибута msExchADCOptions для нужного CA. Для этого следует запустить такой инструмент, как ADSI Edit, пройти по иерархической структуре AD к нужному CA, щелкнуть правой кнопкой мыши на CA, выбрать пункт Properties, затем вариант Both из раскрывающегося списка Select which properties to view, и вариант msExchADCOptions из раскрывающегося списка Select a property to view. Чтобы установить разряд 15, следует прибавить к существующему значению (обычно 4) число 32768, затем ввести новое значение в поле Edit Attribute (Экран 2).

После установки атрибута любые новые объекты, создаваемые этим CA в AD не будут иметь рандомизированных атрибутов samAccountName. Существующие объекты AD, уже созданные ADC, останутся без изменений. Для того, чтобы изменения вступили в силу, не нужно перезапускать службу ADC.

Сказанное не значит, что я рекомендую отменить рандомизацию samAccountName. У новой функции рандомизации Exchange 2003 много преимуществ, особенно при использовании стандартных инструментов миграции Microsoft. Однако, в некоторых программах сторонних поставщиков лучше применять старый подход.

Кроме того, даже при стандартном поведении Exchange 2003 ADC, атрибут samAccountName не всегда рандомизируется. Если почтовый ящик Exchange 5.5 идентифицирован как ресурс (установлен параметр NTDS NoMatch в Custom Attribute 10), то атрибут samAccountName созданной ADC учетной записи не рандомизируется, так как предполагается, что миграция соответствующей учетной записи NT 4.0 проводиться не будет. В случаях, когда ADC сопоставляет почтовый ящик Exchange 5.5 с учетной записью, уже созданной в AD, то ADC обновляет эту учетную запись с использованием атрибутов Exchange. Новая учетная запись не создается, и ADC не вносит никаких изменений в существующий атрибут samAccountName.

Если выполнены следующие условия, то ADC генерирует рандомизированный атрибут samAccountName для обрабатываемого почтового ящика Exchange 5.5:

• Ассоциированная учетная запись NT 4.0 представляет собой локальную или глобальную группу;
• Ассоциированная учетная запись представляет собой учетную запись NT 4.0 во внешнем домене или учетную запись AD в отдельном лесу;
• В AD уже существует учетная запись, которая соответствует ассоциированной учетной записи NT 4.0 и готова к работе с электронной почтой, но имеет иное имя DN (ассоциирована с каким-то другим почтовым ящиком).

Усовершенствования ADC в Exchange 2003 SP1

Одно из наиболее удачных усовершенствований в Exchange 2003 и ADC - мастер ADC Tools Connection Agreement Wizard. Этот мастер анализирует среду Exchange 5.5 и автоматически генерирует соответствующие соглашения CA для организации. Это ценная возможность, но использовать ее непросто, так как для создания CA мастер использует выбираемые по умолчанию параметры, заданные разработчиками Microsoft, и эти параметры могут не соответствовать конкретным требованиям предприятия. Предположим, что нужно назначить параметры, чтобы указать ADC, следует ли действительно удалить удаляемые объекты Exchange 5.5 или их требуется записать в файл. Или для двустороннего CA требуется сначала выполнить репликацию из Windows, а не Exchange 5.5.

Если соглашения CA созданы вручную, то можно использовать ADC Manager, чтобы назначить упомянутые выше и аналогичные атрибуты, но если используется мастер, то необходимо применить выбираемые по умолчанию параметры. К сожалению, если мастер используется для создания соглашения CA, то их репликация начинается автоматически сразу же после завершения настройки, так как свойство Schedule установлено в значение Always. Компания Microsoft исправила эти небольшие, но досадные изъяны в двух новых файлах - ca_defaults.xml и activate_cas.vbs - которые находятся в каталоге programfilesmsadc в процессе установки версии ADC из состава Exchange 2003 SP1.

С помощью файла ca_defaults.xml можно установить новые стандартные параметры для любых CA, создаваемых мастером. Например, если требуется запретить автоматическую репликацию CA сразу после их создания, то можно изменить строку файла

и заменить значение activationStyle с 2 (Always - всегда) на 0.

Многими другими атрибутами CA можно управлять, устанавливая их значения в данном файле перед запуском мастера. Список управляемых атрибутов CA приведен в статье Microsoft "Description of the changes to ADC Tools in Exchange Server 2003 Service Pack 1" (http://support.microsoft.com/?kbid=867627).

Файл activate_cas.vbs имеет особое назначение. Если присвоить атрибуту activationStyle значение 0, чтобы соединения CA не выполняли автоматического реплицирования, то в конечном итоге их придется активизировать и присвоить этому атрибуту значение, отличное от 0. При небольшом числе CA эту операцию можно выполнить вручную, но задача усложняется, если на предприятии имеются сотни CA. Для этой цели сценарий activate_cas.vbs просто назначает всем CA значение 2 (Always).

Перед запуском сценария следует изменить каталоги на program filesmsadc и выполнить команду

activate_cas NOW

Возможности сценария шире, но перебор CA и назначение атрибутов производится в следующем фрагменте:

while not caSet.EOF
set ca = GetObject(
caSet.fields("adsPath") )
ca.put "activationStyle", 2
ca.setInfo
caSet.moveNext
wend

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

При использовании этих файлов следует помнить, что последующие обновления ADC или процедуры повторной установки перезаписывают существующие варианты файлов. Поэтому файлы, в которые внесены какие-то настройки, следует сохранить перед применением обновлений ADC, а затем заменить вновь созданные файлы сохраненными копиями.

Неизбежное зло

Новая функциональность ADC обеспечивает более гладкую, беспроблемную миграцию с использованием стандартных инструментов Microsoft, таких как ADMT и AD Cleanup Tool. Однако очевидно, что при некоторых обстоятельствах предпочтителен старый вариант ADC, который облегчит процесс миграции. Кроме того, некоторые сложности развертывания CA были устранены благодаря новым возможностям конфигурирования. ADC остается неизбежным злом, но по крайней мере, работать с инструментом стало проще.

Киран Маккорри (kieran.mccorry@hp.com) проживает в Ирландии. Он главный консультант в Advanced Technology Group компании HP и имеет сертификат Microsoft Exchange MVP. Его последняя книга - Microsoft Exchange Server 2003 Deployment and Migration (издательство Digital Press).