Подробное рассмотрение подготовки Active Directory к Exchange 2007 (часть 2)

Если вы хотите почитать предыдущую часть этой серии статей, перейдите по ссылке: Подробное рассмотрение подготовки Active Directory к Exchange 2007 (часть 1).

Введение

В первой части этого цикла статей мы начали наше рассмотрение с четырех шагов, необходимых для подготовки Active Directory к получению Exchange 2007. Первым шагом была подготовка наследственных Exchange разрешений в ситуациях, когда в вашей организации новая версия сосуществует с более старыми версиями Exchange, такими как Exchange 2000 или Exchange 2003. В первой части мы лишь запустили команду setup /pl, чтобы познакомится с некоторыми проблемами, нуждающимися в решении до того, как процесс будет продолжен. Эти проблемы были представлены нам в окне командной строки, однако, как вы вскоре увидите, существуют другие способы просмотра того, что произошло во время выполнения этих подготовительных команд.

Установка файлов логов

Как и в случае с прочими подготовительными процессами, которые мы рассмотрим в этой статье, будут создаваться файлы журналов регистрации событий, которые можно просматривать по завершении процесса на предмет возникновения ошибок. Нужный нам файл – это ExchangeSetup.log, созданный в папке C:\ExchangeSetupLogs, как показано на рисунке 3.

Рисунок 3: Лог Exchange Setup

Если открыть файл ExchangeSetup.log в блокноте у вас появятся те же ошибки и предупреждения в виде текстового файла, которые вы видели в окне командной строки первой части этой серии статей. Эти ошибки выделены на рисунке 4:

Рисунок 4: Открытый лог Exchange Setup

Вы должны заметить, что некоторые ошибки «скрывают» другие ошибки, которые могут наличествовать в вашей наследственной организации Exchange. Например, когда я добавил учетную запись, которую использовал для группы Enterprise Admins и переключил наследственную организацию Exchange в собственный режим, повторный запуск команды setup /pl произвел новую ошибку, показанную на рисунке 5. Здесь говорится, что на один или более серверов Exchange 2003 в наследственной среде не установлен Exchange 2003 Service Pack 2. Мораль сего рассказа заключается в том, что необходимо убедиться, что вы полностью задокументировали свою наследственную среду Exchange и исправили все проблемы, которые могут препятствовать подготовке наследственных разрешений, до выполнения этой команды. Если этого не сделать, то вам придется выполнять эту команду много раз, пока все необходимые моменты не будут выполнены.

Рисунок 5: Ошибка отсутствия Exchange 2003 SP2

В конце концов, процесс выполнения команды setup /pl должен завершиться успешно, как показано на рисунке 6, однако в этом конкретном случае следует обратить внимание, что предупреждение относительно .NET Framework 2.0 SP1 все еще присутствует, что в очередной раз подтверждает тот факт, что предупреждения на самом деле не препятствуют продолжению процесса.

Рисунок 6: Успешное завершение процесса подготовки наследственных разрешений

Осмотр списка разрешений

Так как же убедиться в том, что подготовка наследственных разрешений завершилась успешно? Во-первых, нужно помнить, что журналы регистрации событий являются здесь вашими друзьями, как уже отмечалось в первой части. Сначала нужно просмотреть файл ExchangeSetup.log и убедиться, что процесс был завершен без ошибок.

Далее, обратите внимание, что в документации Microsoft приведена подробная информация о записях контроля доступа (Access Control Entries – ACEs), которые генерируются этим процессом. Остается вопрос о том, как определить, были ли добавлены эти ACEs. Давайте более подробно рассмотрим файл ExchangeSetup.log, созданный во время установки наследственных разрешений Exchange. На рисунке 7 приведен отрывок. Обратите внимание, что я установил в блокноте опцию переноса по словам Word Wrap, чтобы все записи журнала были видны полностью.

Рисунок 7: Записи ACE в ExchangeSetup.log

На рисунке 7 показаны различные ACEs, которые были применены. Если рассматривать первую запись в списке, то видно, что WriteProperty ACE была добавлена к самому домену (DC=neilhobson,DC=com). Также интересным является Globally Unique Identifier (GUID), который показан в конце записи. Этот GUID имеет следующее значение 1f298a89-de98-47b8-b5cd-572ad53d267e. Если вы посмотрите ниже в журнале регистрации, то увидите, что ReadProperty и WriteProperty ACE были применены к объекту AdminSDHolder.

Компания Microsoft подробно описывала в различных статьях способы подтверждения того, что эти ACEs существуют, поэтому для полноты статьи я опишу этот процесс здесь, чтобы продемонстрировать на примере моей тестовой среды, что делать. Вы можете воспользоваться инструментом LDP, который идет как часть Windows Support Tools для проверки ACEs, которые были добавлены процессом подготовки наследственных разрешений. Я не буду рассматривать все ACEs, которые были добавлены, я сконцентрируюсь на двух из них, о которых я упоминал в предыдущем абзаце, а именно WriteProperty в объекте домена и WriteProperty/ReadProperty в объекте AdminSDHolder. Давайте начнем с ACE, добавленной к объекту домена:

1. Выполняем LDP.EXE.
2. В главном окне LDP нажимаем Подключение, а затем ПодключитьпїЅ
3. В окне Подключить вводим имя корневого контроллера домена и нажимаем OK. Это окно показано на рисунке 8.

   

   Рисунок 8: Окно подключения LDP

1. Обратно в главном окне LDP жмем Подключения, а затем Привязать (Bind)
2. В окне Привязать вводим имя пользователя, пароль и учетную запись пользователя домена, которая имеет такие разрешения, как учетная запись администратора корневого домена. Это окно показано на рисунке 9 ниже.

   

   Рисунок 9: Окно привязки LDP Bind

1. Правая панель теперь должна информировать вас о том, что вы аутентифицировались. Нажмите Вид, затем Дерево и в окне Вид дерева просто оставьте поле BaseDN пустым и нажмите OK.
2. В главном окне LDP вы должны увидеть свой корневой домен, записанный сверху в левой панели, как показано на рисунке 10.

   

   Рисунок 10: Вид дерева LDP

1. Прежде чем двигаться далее, очистите содержимое правой панели путем нажатия Подключение, а затем Новое. Это просто значительно облегчает чтение информации в следующем шаге.
2. Правой клавишей нажмите на домене вверху левой панели и выберите Дополнительно, затем Идентификатор безопасности (Security Descriptor) из контекстного меню, показанного на рисунке 11.

   

   Рисунок 11: Опции меню идентификатора безопасности

1. В появившемся окне Идентификатор безопасности оставьте поле Dn без изменений и выберите OK.
2. Теперь в правой панели появится много информации, подробно описывающей ACEs. В моей тестовой среде в общей сложности было обнаружено 40 ACEs. Ваш экран должен выглядеть подобно тому, что показан на рисунке 12.

   

   Рисунок 12: Отображение ACEs

1. Если вы пролистаете список ACEs, то найдете запись для набора WriteProperty ACE в объекте домена, как показано на рисунке 13. Здесь вы можете убедиться в том, что это WriteProperty ACE (из строки ACTRL_DS_WRITE_PROP) и что идентификатором безопасности для этой записи будет группа Exchange Enterprise Servers. Также обратите внимание, что GUID упомянутый выше также присутствует.

   

   Рисунок 13: Доменная ACE для группы Exchange Enterprise Servers

Теперь давайте проверим, сможем ли мы увидеть ACE в объекте AdminSDHolder. Оставляем LDP открытой там, где она была, и выполняем следующие шаги:

1. Жмем на Подключение, затем Новое, чтобы очистить правую панель.
2. В левой панели разворачиваем объект домена и дважды жмем на объекте Система. Прямо в объекте Система вы увидите объект AdminSDHolder.
3. Нажимаем Подключение, затем Новое, чтобы еще раз очистить правую панель.
4. Теперь правой клавишей нажимаем на объекте AdminSDHolder и выбираем Дополнительно, а затем Идентификатор безопасности, точно так же, как делали это только что для объекта домена.
5. В появившемся окне Идентификатор безопасности оставляем поле Dn без изменений и нажимаем OK.
6. И снова у нас появится много информации ACE в правой панели. Теперь можно пролистать список записей и найти ту, которая задает ReadProperty и WriteProperty для Exchange Enterprise Servers группы, как показано на рисунке 14.

   

   Рисунок 14: AdminSDHolder ACE для группы Exchange Enterprise Servers

На этом мы завершим рассмотрение установки наследственных разрешений Exchange. Я знаю, что уделил много места подготовке наследственных разрешений, но надеюсь, это дало вам много полезной информации о том, как проверять, были ли ACEs применены или нет.

Как станет ясно из последующих частей, на самом деле лучше дождаться, пока репликация Active Directory начнет работать, прежде чем переходить к следующим компонентам установки, а также будут представлены способы проверки наличия репликации. Я подробно опишу этот процесс после следующего шага, подготовки схемы, поскольку некоторые читатели, возможно, пропустили эту статью и первую часть, если в их организации отсутствует более старая версия Exchange.

Заключение

Здесь во второй части этой серии статей мы завершили рассмотрение процесса подготовки наследственных Exchange разрешений, уделяя внимание тому, как убедиться в успешности этого процесса после его завершения. В третьей части мы рассмотрим шаги, необходимые для подготовки схемы Active Directory, а также проверки успешности завершения этого процесса, наряду с проверкой репликации Active Directory.

Источник  http://www.msexchange.org

• Пользовательские политики
• Маршрутизация Windows 2008
• Управление папками в Windows vista
• Sip сервер Windows
• Политика безопасности контроллера домена

Tags: bind, Exchange