Заметки об Exchange и Active Directory : Tips&Tricks

Управление получателями в многодоменной среде (часть 2)

vladg — Wed, 28 Feb 2007 05:39:00 GMT

Сегодня мы рассмотрим на примерах все параметрых встроенной переменной $AdminSessionADSettings. По умолчанию "видение всего леса" отключено, и область видимости всех командлетов в данном процессе ограничена локальным доменом компьютера. Конфигурационный контроллер домена (ККД) тот же, что ККД, используемый службами Exchange на данном компьютере.

[PS] C:\>$AdminSessionADSettings

ViewEntireForest              : False
DefaultScope                  : asia.company.com
PreferredGlobalCatalog        :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers    : {}

Попробуем найти всех получателей по имени Петр:

[PS] C:\>get-mailbox petr* | fl Identity

Identity : asia.company.com/Users/Petr Petrov
Identity : asia.company.com/Users/Petr Ivanov

Как видите, все они из текущего домена - Asia. Теперь расширим нашу географию и рассмотрим весь лес:

[PS] C:\>$AdminSessionADSettings.ViewEntireForest = $true

[PS] C:\>get-mailbox petr* | fl Identity

Identity : europe.company.com/Users/Petr Pavlov
Identity : asia.company.com/Users/Petr Petrov
Identity : asia.company.com/Users/Petr Ivanov

В список результатов теперь попал еще один Петр из европейского домена. Вот как выглядят наши настройки в данный момент:

[PS] C:\>$AdminSessionADSettings

ViewEntireForest              : True
DefaultScope                  :
PreferredGlobalCatalog        :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers    : {}

Теперь снова сузим наше поле зрения до одного домена, но в этот раз выберем другой домен.

[PS] C:\>$AdminSessionADSettings.ViewEntireForest = $false

[PS] C:\>$AdminSessionADSettings

ViewEntireForest              : False
DefaultScope                  : asia.company.com
PreferredGlobalCatalog        :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers    : {}

[PS] C:\>$AdminSessionADSettings.DefaultScope = "europe.company.com"

Проверим, что теперь мы смотрим только на Европу:

[PS] C:\>$AdminSessionADSettings

ViewEntireForest              : False
DefaultScope                  : europe.company.com
PreferredGlobalCatalog        :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers    : {}

[PS] C:\>get-mailbox petr* | fl Identity

Identity : europe.company.com/Users/Petr Pavlov

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

[PS] C:\>$AdminSessionADSettings.PreferredDomainControllers = "dc01.asia.company.com"
[PS] C:\>$AdminSessionADSettings

ViewEntireForest              : False
DefaultScope                  : europe.company.com
PreferredGlobalCatalog        :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers    : {dc01.asia.company.com}

Аналогично можно установить глобальный каталог:

[PS] C:\>$AdminSessionADSettings.PreferredGlobalCatalog = "dc01.asia.company.com"
[PS] C:\>$AdminSessionADSettings.ViewEntireForest = $true

Эту установку можно проверить, посмотрев на поле OriginatingServer в возвращаемых результатах

[PS] C:\>get-mailbox petr* | fl Identity, originatingserver

Identity : europe.company.com/Users/Petr Pavlov
OriginatingServer : dc01.asia.company.com

Identity : asia.company.com/Users/Petr Petrov
OriginatingServer : dc01.asia.company.com

Identity : aisa.company.com/Users/Petra Ivalov
OriginatingServer : dc01.asia.company.com

И наконец, напоминаю, что с этой встроенной переменной нужно обращаться осторожно, а то можно нечаянно ее уничтожить:

[PS] C:\>$AdminSessionADSettings = $false
[PS] C:\>$AdminSessionADSettings
False

К счастью, с настройками при этом ничего не случилось, и переменную можно вернуть обратно:

[PS] C:\>$AdminSessionADSettings = [Microsoft.Exchange.Data.Directory.AdminSessionADSettings]::Instance
[PS] C:\>$AdminSessionADSettings

ViewEntireForest              : True
DefaultScope                  :
PreferredGlobalCatalog        :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers    : {}

Вот и все. Если есть вопросы пишите или оставляйте комментарии.

Управление получателями в многодоменной среде (часть 1)

vladg — Sat, 24 Feb 2007 05:33:00 GMT

В Exchange 2000 и 2003 управление получателями осуществлялось с помощью оснастки "Active Directory - пользователи и компьютеры" (ADUC). По умолчанию она подключалась к произвольному контроллеру текущего домена, но можно было также переключиться на любой другой домен, или весь лес (путем подключения к глобальному каталогу). Кроме того, для преодоления эффектов репликации можно было указать конкретный контроллер домена или глобальный каталог. В Exchange 2007 управление получателями убрано из оснастки и интегрировано с другими функциями управления Exchange - как в графической оболочке, так и в командной строке. Естественно, мы хотели сохранить все возможности, описанные выше, и даже расширили их. Сейчас я расскажу, каким образом они реализованы в среде Powershell.

По умолчанию новый экземпляр Powershell так же, как и ADUC, "видит" только получателей текущего домена (контроллер домена выбирается произвольно). Это можно видеть в заголовке окна Powershell - там указано имя текущего компьютера и облать действия (локальный домен). Кстати, при этом имеется в виду локальный домен компьютера, а не пользователя (потому что такущий администратор может быть из другого леса, а управлять мы все же хотим получателями Exchange в этом лесу). Другой, более универсальный способ, состоит в использовании встроенной переменной $AdminSessionADSettings. Рассмотрим ее поподробнее:

[PS] C:\>$AdminSessionADSettings

ViewEntireForest              : False                               [Видеть весь лес - значит использовать Глобальный каталог]
DefaultScope                  : asia.company.com           [Текущая область действия - в данной случае локальный домен]
PreferredGlobalCatalog        :                                    [Предпочитаемый глобальный каталог]
ConfigurationDomainController : dc16.asia.company.com [Конфигурационный контроллер домена - вся информация, не относящаяся к получателям идет туда/оттуда]
PreferredDomainControllers    : {}                              [Список предпочитаемых контроллеров домена, не более одного на домен]

Именно путем изменения полей этой переменной администратор и может добиться практически неограниченной гибкости в плане использования серверов Active Directory. Как видите, можно переключаться между режимами "весь лес" и "домен", устанавливать текущий домен, задавать предпочитаемые контроллеры домена и глобальный каталог. Все задачи (командлеты) Exchange будут использовать эти установки (если, конечно, в параметрах самой задачи не будет указано иначе). Эти установки действуют в рамках одного процесса Powershell. Все они доступны и в графической оболочке EMC.
Как результат, по умолчанию - даже без настроек специфических контроллеров домена - администратор может практически позабыть о репликации при выполнении последовательности действий - например, он может создать нового получателя и тут же изменить настройки или удалить его. Если действие происходит в том же процессе Powershell или EMC, будет автоматически выбран тот же контроллер домена, что был использован при создании объекта.
В следующем сообщении я поподробнее рассмотрю функциональность всех полей на примерах.

Механизм "известных объектов" ("well-known objects") для надежного нахождения важных записей в Active Directory

vladg — Fri, 16 Feb 2007 00:43:00 GMT

Как известно, любую запись в Active Directory можно найти по ее различающемуся имени (DN) или уникальному GUIDу.Существует немалое количество популярных записей, часто используемых приложениями - например, контейнер CN=Computers,DC=BQSNLF-dom,DC=com. Часто при написании приложений люди "строят" такие адреса путем конкатенации различающегося имени домена и фиксированной строки типа "CN=Computers," + <domain DN>. Этот способ работает почит всегда. Но Active Directory позволяет переименовывать или переносить некоторые из этих контейнеров, и тогда приложение перестает работать.

Для того, чтобы приложение могло по-прежнему находить перенесенный контейнер, в Active Directory существует механизм специальных указателей, так называемых "известных объектов" (well-known objects). Эти указатели "живут" в атрибутах wellKnownObjects и otherWellKnownObjects на фиксированных объектах (типа домена или конфигурационного контейнера), и представляют собой комбинацию из GUID и различающегося имени. Вот, например, как выглядит такой указатель на контейнер Computers:

Dn: DC=BQSNLF-dom,DC=com
1> wellKnownObjects: B:32:AA312825768811D1ADED00C04FD8D5CD:CN=Computers,DC=BQSNLF-dom,DC=com;

Для того, чтобы гарантированно найти этот контейнер, нужно выполнить следующий запрос в Active Directory: <WKGUID=AA312825768811D1ADED00C04FD8D5CD,DC=BQSNLF-dom,DC=com>.

Как видите, это не совсем стандартное различающееся имя. Префикс WKGUID говорит о том, что необходимо заглянуть в специальные атрибуты-указатели; далее идет значение GUID, соответствующее контейнеру Computers (этот GUID был выбран разработчиками этого контейнера), а далее идет различающееся имя объекта, на котором эти атрибуты-указатели хранятся.

При этом если контейнер будет переименован или перемещен, то этот "указатель" автоматически обновится и WKGUID-запрос его легко найдет.

Данный механизм используется в Exchаnge 2007 для нахождения Универсальных групп, существующих в единственном экземпляре. По умолчанию эти группы создаются на этапе подготовки леса в корневом домене. Но поскольку некоторые администраторы Exchange стремятся держать корневой домен "в чистоте" (а некоторые вообще блокируют к нему доступ), то мы поддерживаем перемещение этих групп в другой домен. Указатели на эти группы зранятся в атрибуте otherWellKnownObjects на контейнере Microsoft Exchange:

Dn: CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=BQSNLF-dom,DC=com
5> otherWellKnownObjects:
B:32:9C5B963F67F14A4B936CB8EFB19C4784:CN=ExchangeLegacyInterop,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
B:32:DC1301662F547445B9C490A52961F8FC:CN=Exchange View-Only Administrators,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
B:32:0BD898D939081042B77BF4A555E07FA1:CN=Exchange Recipient Administrators,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
B:32:354B603D92D95541AAFD8C0AE688EA0F:CN=Exchange Organization Administrators,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
B:32:A7D2016C83F003458132789EEB127B84:CN=Exchange Servers,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;

Соответственно, для того, чтобы гарантированно найти, скажем, группу Exchange Organization Administrators, необходимо выполнить такой запрос (GUID этот одинаков для всех инсталляций Exchange):

<WKGUID=354B603D92D95541AAFD8C0AE688EA0F,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=BQSNLF-dom,DC=com>

Так и поступают все компоненты Exchange 2007. Я рекомендую использовать этот способ при написании приложений, которые должны надежно работать с Exchange 2007 (или просто приложений для Active Directory).

Exchange 2007 и статическая конфигурация контроллеров домена

vladg — Tue, 13 Feb 2007 22:12:00 GMT

Сегодня получил такое письмо и решил заодно опубликовать свой ответ:

Здравствуйте.
Вы как разработчик Exchange надеюсь сможете мне помочь.
У меня возникла следующая проблема.
При добавлении/удалении ролей, а также при запуске setup.exe c любыми из ключей /PrepareAD /PrepareLegacyExchangePermissions /PrepareSchema возникает ошибка:
Setup cannot use domain controller 's-dc1.xxxxxxxx.RU' because an override is set in the registry. Run Setup again, and specify '/DomainController:'.
Ничего не могу сделать с Exchange, ни удалить, ни переустановить.
Где отыскать это переопределение (override in the registry)?

В Exchange можно задать статический список контроллеров домена/глобальных каталогов. Он хранится в регистратуре, но имеется и нормальный "человеческий" доступ к этим данным. Вот как их можно посмотреть:

[PS] D:\>get-exchangeserver -status | fl Name, Static*

Name                            : 4367R9-A15
StaticDomainControllers         : {}
StaticGlobalCatalogs            : {}
StaticConfigDomainController    :
StaticExcludedDomainControllers : {}

В данном случае у меня нет никаких статических серверов. Вот как их можно установить:

[PS] D:\>Set-ExchangeServer 4367R9-a15 -StaticDomainControllers hp643453.JXNLDW-dom.com

Посмотрим, что получилось:

[PS] D:\>get-exchangeserver -status | fl Name, Static*

Name                            : 4367R9-A15
StaticDomainControllers         : {hp643453.JXNLDW-dom.com}
StaticGlobalCatalogs            : {}
StaticConfigDomainController    :
StaticExcludedDomainControllers : {}

Теперь уберем статическую конфигурацию и разрешим Exchange самому выбирать контроллеры домена и глобальные каталоги:

[PS] D:\>Set-ExchangeServer 4367R9-a15 -StaticDomainControllers $null

Проверим, что все чисто:

Перед запуском программы установки Exchange для удаления или модификации ролей необходимо очистить всю статическую конфигурацию. Это нужно для того, чтобы программа установки могла выбирать контроллеры домена по своему усмотрению (например, schema master если указан ключ /PrepareSchema).

Статические списки серверов имеет смысл использовать только для выяснения причин неполадок или чтобы временно избежать использования перегруженных или неисправных серверов. Я не рекомендую иметь эти списки на постоянной основе, так как они уменьшают живучесть Exchange в случае, если сервера из этого списка вдруг станут недоступны. А если у вас в реестре прописан конфигурационный контроллер домена (StaticConfigDomainController), то если по каким-то причинам пропадет связь с ним, Exchange перестанет функционировать. (В обычных условиях, когда ничего нигде не прописано, будет случайно выбран другой работающий контроллер домена и ничего страшного не произойдет).

Кстати, эти настройки существуют начиная с Exchange 2000.

P.S. Оказалось что установка всех статических серверов в $null проблемы не решила. Дело в том, что при этом ключ в реестре не удаляется (а только очищается его значение). ExBPA этого не понимает и считает, что ститческий сервер по-прежнему там. Это уже исправлено в первом Сервис Паке к Exchange 2007. В краткосрочной перспективе можно просто удалить значение HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Instance0\ConfigDCHostName из реестра (чтобы его вообще не было, даже пустого). То, что значение пустое, видно, кстати, из сообщения об ошибке, упомянутого выше: '/DomainController:'. Если бы в реестре был "настоящий" контроллер домена, то ошибка бы содержала это имя: '/DomainController:dcname.corp.com', и тогда запуск программы установки с таким ключом прошел бы успешно.

права доступа служб Exchange 2000 и 2003

vladg — Wed, 11 Oct 2006 13:03:00 GMT

Сегодня я расскажу про права доступа, используемые службами Exchange 2000 и 2003, почему они такие и к каким последствиям это приводит (а в следующий раз – про то, чем в этом плане отличается Exchange 2007).

Все службы Exchange 2000 и 2003 используют учетную запись компьютера, на котором они запущены (“local system”). Альтернативой этому мог бы быть какой-нибудь специально созданный пользователь (такую схему использует, например, Live Communication Server), но у пользователя есть существенный минус – ему нужен пароль, который периодически надо обновлять. Если забыть это сделать, все службы перестанут работать. Администраторы не любят этого, поэтому Exchange использует учетную запись local system, которая не требует поддержки.

Дизайн прав доступа был прост: все сервера в лесу Active Directory равноправны, они будут членами одной группы, и программа установки Exchange даст этой группе права на все необходимые ресурсы. Так, в общем, и сделали.

Главной проблемой такого дизайна был тот факт, что Exchange 2000 должен был работать в «смешанном режиме» (mixed mode) в лесу, содержащем Windows NT4. В такой конфигурации Универсальные группы, которые идеально подходили под решение этой задачи, недоступны (нужен «основной режим» (native mode) Windows 2000). В смешанном режиме есть два варианта:
- Локальные группы (domain local): они могут иметь членов из разных доменов, но все эти члены видимы только внутри данного домена
- Глобальные группы (global): они могут иметь членов только из своего домена, зато все они видимы из любого домена.

Естественно, ни одна из этих групп не подходит для решения данной задачи. В результате Exchange 2000/2003 создает две группы в каждом домене (куда устанавливается Exchange):
- глобальная группа Exchange Domain Servers (EDS), членами которой являются все сервера Exchange данного домена.
- локальная группа Exchange Enterprise Servers (EES), членами которой являются все группы EDS из всех доменов.

Все доменные ресурсы в Active Directory (учетные записи пользователей, групп и т.д.) разрешают доступ группе EES – таким образом, это достаточно сделать всего один раз, при установке первого сервера Exchange 2000/2003.
Все конфигурационные ресурсы (все, что находится под CN=Configuration,DC=domain,DC=com) разрешают доступ каждой группе EDS по отдельности - таким образом, это делается один раз на домен. Но это не так и плохо, поскольку копия конфигурационного контекста именования (naming context) имеется на каждом контроллере домена и программа установки делает это легко. Членство групп EES в других доменах поддерживает служба обновления пользователей (Recipient Update Service - RUS).

Когда служба старует, она имеет в своем токене SID обеих групп из своего домена: EDS и EES. Когда сервер попытается считать объект в контексте домена, контроллер домена или глобальный каталог сравнит ACL на этом объекте с токеном службы, найдет ACE для группы EES, а также соответствующий SID в токене, и доступ будет разрешен.

Эта схема работает также и для нескольких доменов. Представим себе, что у нас есть два домена: P (Parent - родительский) и C (child – дочерний). Там будут существовать следующие группы:

Родительский домен (P):

Exchange Domain Servers (EDS-P), включающая сервера Exchange из родительского домена

Exchange Enterprise Servers (EES-P), включающая EDS-P и EDS-C, чтобы сервера Exchange из дочернего домена имели доступ к ресурсам родительского домена

Дочерний домен (С):

Exchange Domain Servers (EDS-C), включающая сервера Exchange из дочернего домена

Exchange Enterprise Servers (EES-C), включающая EDS-P и EDS-C, чтобы сервера Exchange из родительского домена имели доступ к ресурсам дочернего домена

Теперь если сервер Exchange из родительского домена попытается считать объект с глобального каталога в дочернем домене, то он сможет это сделать, поскольку на объекте будет ACE с группой EES-С, и глобальный каталог знает, что эта группа включает в себя EDS-P, которая и есть у нас в токене.

Но есть одно «но». J Представим себе, что служба Exchange 2000 пытается прочитать объект с глобального каталога, находящегося в другом домене. Но объект, который мы хотим прочитать, живет в нашем домене (мы вполне можем это сделать, глобальный каталог имеет копии объектов со всего леса). Посмотрим, что произойдет в этом случае.

Следует заметить, что при «разговоре» с ГК из другого домена из нашего токена исчезнет локальная группа EES-P (в силу своей локальности). В нашем токене останется только SID группы EDS-P. Теперь ГК прочитает ACE, обнаружит там группу EES-P, но, в отличие от предыдущего случая, он не сможет узнать, что она содержит EDS-P, поскольку она живет в другом домене. Результат: все дополнительные права, которые Exchange себе дает, не действуеют при считывании объектов из нашего домена с глобального каталога, живущего в другом домене. На самом деле все не так плохо, это касается всего нескольких атрибутов, которые не являются доступными по умолчанию.

Чтобы обойти это ограничение, группы EDS являются членами пред-Windows2000 группы (pre-windows2000 compatibility group), которой даются права на чтение всех атрибутов.