XADM: Exchange 2000 ошибка сообщения становятся создано из-за проблемы С Policytest и право SeSecurityPrivilege

Переводы статьи Переводы статьи
Код статьи: 314294 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

Проблема

Не удается подключить базы данных сообщений Exchange 2000, а в. журнале событий приложений регистрируется одно или несколько из следующих сообщений об ошибках.:
Тип события: ошибка
Источник события: MSExchangeDSAccess
Категория события: (3)
КОД события: 2102
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Процесс MAD.EXE (PID = 1088). Все использующиеся серверы контроллеров домена не отвечают::
dc1.company.com
dc2.company.com
dc3.company.com
Тип события: ошибка
Источник события: MSExchangeSA
Категория события: (1)
КОД события: 9004
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Служба обновления метабазы не удалось запустить "," Ошибка "80040a01".
Тип события: ошибка
Источник события: MSExchangeSA
Категория события: (1)
КОД события: 1005
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Непредвиденная ошибка произошла неизвестная ошибка. КОД: 80040a01 произошла системного помощника Microsoft Exchange.
Тип события: ошибка
Источник события: MSExchangeMU
Категория события: (1)
КОД события: 1002
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Ошибка запуска агента Центра обновления метабазы. Код ошибки: 80040a01..
Тип события: ошибка
Источник события: MSExchangeIS
Категория события: (6)
КОД события: 9519
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Ошибка 0x80004005 при запуске базы данных "First Storage
Store(EXCHANGE1) Group\Mailbox "для банка данных Microsoft Exchange. Не удалось настроить MDB.. The Microsoft Exchange Information Store service could not find the specified object.. ID no:c1041722
Тип события: ошибка
Источник события: MSExchangeMU
Категория события: Общие
КОД события: 1029
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Ошибка при репликации дескриптора безопасности в метабазу. Пользователям недоступна возможность чтения или записи данных в метабазу.. Код ошибки: 8000500d..
Тип события: ошибка
Источник события: MSExchangeSA
Категория события: Интерфейс RFR
КОД события: 9074
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Интерфейс ссылок службы каталогов не удалось обработать запрос клиента. RFRI возвращает код ошибки:[0x3f0]..
Тип события: ошибка
Источник события: MSExchangeIS
Категория события: Общие
КОД события: 1121
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Ошибка 0x80004005 подключение к Microsoft Active Directory.
Тип события: ошибка
Источник события: MSExchangeMTA
Категория события: Настройка
КОД события: 125
Дата: 1/1/2002
Время: 12: 00: 00 AM
Пользователь: н/Д
Компьютер: EXCHANGE1
Описание: Произошла неустранимая ошибка при чтении значения из каталога. Имя MTA не найдено.. Обратитесь в службу технической поддержки Microsoft.. [MTA ОСНОВНОЙ БАЗОВЫЙ 1 12] (16)

Причина

Такое поведение наблюдается, если на некоторых или на всех контроллерах домена для локальной доменной группы Exchange Enterprise Servers было удалено право управления записью в журнал безопасности и аудита (SeSecurityPrivilege)..

При установке первого компьютера Exchange в домене или при запуске программы установки Exchange с помощью/ domainprepпереключатель, группа Exchange Enterprise Servers предоставляется право SeSecurityPrivilege.

Если право SeSecurityPrivilege позже отменяется, компьютеры Exchange, которые используют контроллеры в данном домене, на определенном этапе перестают работать.. Проблема проявляется после истечения интервалов обновления безопасности Kerberos или перезапуска служб Exchange на определенном сервере..

Решение

Для устранения проблемы необходимо с помощью программы Policytest.exe проверить состояние права SeSecurityPrivilege на каждом контроллере в определенном домене.. Программа Policytest.exe входит в состав компакт-диска Exchange 2000..

Чтобы проверить наличие у сервера Exchange 2000 Enterprise права SeSecurityPrivilege на контроллере домена, необходимо выполнить следующие действия.:
  1. Войдите на контроллер домена с помощью учетной записи администратора домена и запустите консоль «Политика безопасности контроллера домена». (По умолчанию расположен консоли политика безопасности контроллера доменаSTART ::в менюАдминистрированиеГруппа).
  2. expandПараметры безопасности, а затем разверните узелЛокальные политики. expandНазначение прав пользователя, а затем откройте окно свойствУправление аудитом и журналом безопасности.
Вы можете предоставить право SeSecurityPrivilege непосредственно к серверам Exchange 2000 Enterprise или запустить программу установки Exchange 2000 с/ domainprepключ для предоставления автоматически право SeSecurityPrivilege.

При запуске программы Setup.exe с/ domainprepпараметр, можно не прерывать службы на существующих серверах Exchange. Кроме того, при этом восстанавливаются остальные используемые по умолчанию права и членства в группах (в случае, если они были изменены)..

Предоставление группе Exchange Enterprise Servers права SeSecurityPrivilege вступает в силу только после обновления политики безопасности на контроллере домена.. Время, необходимое для обновления политики безопасности, зависит от топологии и конфигурации домена.. По умолчанию пять минут необходимо для репликации политики на другие контроллеры домена и еще пять минут — на применение измененной политики..

Даже если определенный домен не содержит все компьютеры Exchange, компьютеры Exchange в других доменах, могут использовать контроллеры этого домена. Чтобы компьютер Exchange 2000 мог выполнять просмотр глобального каталога и изменять контейнер конфигурации, когда компьютер Exchange использует данные контроллеры домена, необходимо выполнить следующие действия.:
  1. Компакт-диск установки Exchange 2000, запустите программу установки с помощью/ domainprepпереключатель (/ domainprep Setup.exe). Благодаря этому будут настроены соответствующие группы и права для междоменной связи компьютеров Exchange..
  2. С помощью программы Exchange System Administrator создайте для домена службу Recipient Update Service.. На каждом домене эта служба отвечает за наполнение локальной доменной группы Exchange Enterprise Servers глобальными группами Exchange Domain Servers из других доменов.. Помимо этого служба Recipient Update Service выполняет и другие задачи..

Дополнительная информация

The Exchange Enterprise Servers group is a domain local group. This group supports necessary cross-domain communication between Exchange computers and between Exchange and Active Directory. The membership of the Exchange Enterprise Servers group must include the Exchange Domain Servers global groups from each domain in which Exchange computers exist.

The SeSecurityPrivilege right is required to support various Exchange security functions, including the ability to report which Windows accounts are being used to gain access to mailboxes.

By default, after a domain is installed, the only account with SeSecurityPrivilege rights is the built-in Administrators group for each domain. If you reapply the Security.inf template to the domain, the SeSecurityPrivilege right is reset to its default. This is not the only way that the Exchange Enterprise Servers group might have its rights removed. Other security auditing and configuration tools may reset the policy. Active Directory administrators who are following general security recommendations may also remove the Exchange Enterprise Servers group.

If the SeSecurityPrivilege right is being reset repeatedly, and you cannot determine why this occurs, you can audit changes to domain controller security policy:
  1. On each domain controller, change the size and rollover settings for the Security log as much as necessary to support increased amounts of logging information.

    Предупреждение: If you turn on theнемедленное отключение системы, если невозможно внести в журнал записи об аудите безопасностипараметр вПараметры безопасностираздел политики контроллера домена по умолчанию, контроллер домена завершает работу сразу после заполнения журнала безопасности.
  2. Запустите консоль «Политика безопасности контроллера домена»..
  3. expandЛокальные политикиexpandПолитика аудита, а затем включитеУспех:АудитДоступ К каталогу и изменения политики.
После выполнения этих действий внесение изменений в политику контроллера домена приводит к регистрации события с кодом 608 (учетная запись добавлена) и 609 (учетная запись удалена).. Каждое из этих событий имеет категорию «Изменение политики».. Источник события — «Безопасность».. Событие с кодом 608 выглядит следующим образом.:
Тип события: Аудит успехов
Источник события: безопасность
Категория события: Изменение политики
КОД события: 608
Дата: 12/12/2001
Время: 4:32:20 по
Пользователя: NT AUTHORITY\SYSTEM
Компьютер: DC1
Описание: Пользователь справа исполнителя:
Право пользователя: SeSecurityPrivilege
Назначенные В: DOMAIN\USER
Исполнитель::
Имя пользователя: DC1 $
Домен: домен
Код входа: (0x0, 0x3E7)
СОВЕТ: В окне просмотра событий, щелкните правой кнопкой мышиЖурнал безопасностиОбъект. затем –Представление:, а затем выполните поиск слова «SeSecurityPrivilege» (без кавычек) вНайти«Свойства системы»..

Поскольку система сама редактирует политику, невозможно с помощью протоколирования политики определить учетную запись пользователя, который вносил изменение.. Но эта учетная запись регистрируется при протоколировании доступа к службе каталогов..

Как правило, изменение политики контролера домена приводит к немедленной регистрации на нем события «Доступ к каталогу» и, несколько минут спустя, — события «Изменение политики».. Второе событие происходит при обновлении и применении политики на контроллере домена.. В процессе репликации по прошествии нескольких минут политика обновляется и применяется на других контроллеры домена, что приводит к регистрации на них события «Изменение политики»..

В случае обнаружения изменений параметра SeSecurityPrivilege найдите в журнале безопасности события «Доступ к каталогу», в которых поле «Пользователь» имеет значение отличное от SYSTEM и SERVERNAME$. Например::
Тип события: Аудит успехов
Источник события: безопасность
Категория события: Доступ К службе каталога
КОД события: 565
Дата: 12/12/2001
Время: 5:52:53 по
Пользователь: DOMAIN\adam
Компьютер: DC1
Описание: Открытие объекта:
Объект сервера: службы Каталогов
Тип объекта: groupPolicyContainer
Имя объекта: CN {6AC1786C-016F-11 D 2-945F-00C04fB984F9}, CN = = политики, CN = System, DC = domain, DC = com
Новый код дескриптора: 0
Код операции: {0,63067624}
Идентификатор процесса: 280
Основного имени пользователя: $ DC1
Основной домен: домен
Основной код входа: (0x0, 0x3E7)
Имя пользователя клиента: adam
Домен клиента: домен
Код входа клиента: (0x0, 0x3C255DB)
Доступ к Записи свойств
Права-
Свойства:
Запись свойства %{00000000-0000-0000-0000-000000000000}
VersionNumber
В этом сообщении учетная запись пользователя, который внес изменения, указана в поле «Имя клиента».. Поле «Имя объекта» содержит название измененной политики..

В приведенном примере политика имеет в Active Directory имя:
CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=domain,DC=com
Чтобы снять с данного каталога атрибут «Только чтение», можно воспользоваться командойldifdeкоманда для разрешения имен политику на более понятное форму, таким образом, чтобы можно быть уверенным, что событие действительно связана с политики, для которого контроль изменений:
-F LDIFDE POLICIES.LDF -D "CN ПОЛИТИК, CN = СИСТЕМА, DC = ДОМЕНА, DC = = COM" КРАТКОЕ ИМЯ -L -R (КЛАСС_ОБЪЕКТА = GROUPPOLICYCONTAINER)
Файл Policies.ldf определяет все политики и его понятное имя в формате, который похож на:
dn: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=com
changetype: add
displayName: Default Domain Policy

dn: CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=domain,DC=com
changetype: add
displayName: Default Domain Controllers Policy
					
Чтобы предотвратить непреднамеренное удаление права SeSecurityPrivilege для серверов Exchange 2000 Enterprise, можно создать для контроллеров домена специальную политику, которая предусматривает предоставление права SeSecurityPrivilege.:
  1. Запустите консоль управления «Active Directory — пользователи и компьютеры» из состава ММС..
  2. Откройте окно свойствКонтроллеры доменаКонтейнер.
  3. Перейдите на вкладкуГрупповая политика:вкладки и нажмите кнопкуСОЗДАТЬ.. Укажите имя новой политики (например, имя_домена Auditing Rights)..
  4. Это действие можно пропустить.. Его выполнение приводит к ускорению загрузки политики.. Щелкните правой кнопкой мыши новую политику, нажмите кнопкуСвойства, а затем отключитеКонфигурация пользователя.
  5. Новая политика и нажмите кнопкуВ файле. expandКонфигурация компьютераexpandКонфигурация Windows, а затем разверните узелПараметры безопасности. expandЛокальные политикиexpandНазначение прав пользователя, а затем настройте все учетные записи, необходимо право SeSecurityPrivilege.

    Существенный:: Все параметры, которые настраиваются в этой политике заменять значения в других политиках, вместо их объединения. Для неназначенных параметров используются принятые в других политиках значения..
  6. Установите для новой политики более высокий приоритет, чем у политики контроллера домена по умолчанию.. В противном случае будут использованы значения параметров из политики контроллера домена по умолчанию..

Свойства

Код статьи: 314294 - Последний отзыв: 23 ноября 2010 г. - Revision: 2.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft Exchange 2000 Server Standard Edition
Ключевые слова: 
kberrmsg kbprb kbmt KB314294 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:314294

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com