Заметки об Exchange и Active Directory

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

Сегодня я расскажу про права доступа, используемые службами 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 себе дает, не действуеют при считывании объектов из нашего домена с глобального каталога, живущего в другом домене. На самом деле все не так плохо, это касается всего нескольких атрибутов, которые не являются доступными по умолчанию.