Программное средство NoMAS

Сервис Microsoft по поддержке продуктов (Microsoft Product Support Services — PSS) предоставляет Вам полезную программу NoMAS. В этой статье я хочу рассказать, что это за средство и при каких обстоятельствах Вы можете им воспользоваться.

Что такое NoMAS?

Думаю, что те специалисты Exchange, которые увлекаются боксом, могут сказать, что «no mas» (хватит — исп.) — это те слова, которые приписываются Роберто Дюрану, закончившему в восьмом раунде свой поединок с Шугар Рэем Леонардом. Однако, в нашем случае NoMAS значит «нет номера кода идентификатора учетной записи» (no master account SID), и это название программного средства, которое можно взять на сайте Microsoft, и которое поможет решить проблемы, связанные с атрибутом номера кода идентификатора учетной записи msExchMasterAccountSid. В последнее время увеличилось число людей, спрашивающих об этом средстве в различных конференциях и рассылках по Exchange. Прежде чем я расскажу о NoMAS, важно понять, что такое msExchMasterAccountSid и какие здесь могут быть проблемы.

Событие 9548 в журнале событий

Возможно, самый распространенный способ, с помощью которого Вы можете узнать о msExchMasterAccountSid это появление в журнале приложений Вашего Exchange-сервера предупреждения с кодом 9548 (см. рисунок 1).

Событие 9548, показанное выше, говорит Вам в описании, что отключенный пользователь neilh не имеет атрибута msExchMasterAccountSid. Я создал это событие, просто отключив свою учетную запись Windows, а затем делегировав ее права к другому почтовому ящику через Outlook. Однако, я не предпринял шагов для включения атрибута msExchMasterAccountSid, поэтому и появилось предупреждение. И так, что же это за атрибут msExchMasterAccountSid?

При предоставление разрешений к спискам доступа (Access Control Lists — ACLs) Exchange 2000 или Exchange 2003, таких как списки доступа общих папок, существует две возможности для расчета предоставления разрешений, которые зависят от того, является ли учетная запись Active Directory, которой выдаются разрешения, включенной или отключенной. Если учетная запись включена, используются атрибуты objectSID и sIDHistory. Если же запись отключена, используется атрибут msExchMasterAccountSid. Это значит, что включенная запись никогда не должна иметь установленный атрибут msExchMasterAccountSid, и наоборот, на отключенной записи он должен быть установлен. В предупреждении на рисунке сверху хранилище Exchange не может определить правильный идентификатор учетной записи для пользователя, поскольку оно пыталось найти msExchMasterAccountSid для отключенного пользователя, но этот атрибут, как я говорил, не был установлен.

Один из лучших способов объяснения, как используется msExchMasterAccountSid, является описание того, что происходит при миграции с Exchange 5.5 на Exchange 2003. При такой миграции коннектор Active Directory (Active Directory Connector — ADC) используется для синхронизации папок Exchange 5.5 с Active Directory. Если ADC не может найти пользователя в Active Directory с идентификатором учетной записи, которая соответствует идентификатору первичной учетной записи NT для почтового ящика Exchange 5.5, он создает отключенную учетную запись Windows и устанавливает атрибут msExchMasterAccountSid для идентификатора первичной учетной записи NT для почтового ящика Exchange 5.5. Результатом является отключенная учетная запись Windows Active Directory, у которой идентификатором является по существу идентификатор пользователя домена Windows NT4, что в свою очередь значит что пользователь Windows NT4 имеет доступ к почтовому ящику Exchange 2000 или Exchange 2003.

Кроме того, ADC устанавливает права Чтение, Полный Доступ к Почтовому Ящику и Связанная Внешняя Учетная Запись для учетной записи, чей идентификатор имеет установленный атрибут msExchMasterAccountSid. Важно заметить, что учетная записи с правом Связанная Внешняя Учетная Запись должна иметь идентификатор, который хранится в атрибуте msExchMasterAccountSid, и что может быть только одна учетная запись с правом Связанная Внешняя Учетная Запись. Еще одно, что Вы могли заметить, это предоставление права Связанная Внешняя Учетная Запись учетной записи SELF. Обычно это видно, когда ADC синхронизирует почтовые ящики с Active Directory для отключенных учетных записей. Если учетной записи SELF дать права Связанная Внешняя Учетная Запись, то почтовый ящик будет доступен для тех пользователей, которые имеют на него права доступа.

Вот как все должно работать. Однако, что же вызывает появление события 9548? Рассмотрим сценарий, когда кто-нибудь уходит из организации, и служба поддержки отключает эту учетную запись Windows и оставляет включенным почтовый ящик. У Вас появится отключенный пользователь с неустановленным атрибутом msExchMasterAccountSid. Или же служба поддержки правильно установила свойство msExchMasterAccountSid, но что случится, если пользователь вернется, и служба поддержки включит его учетную запись? Вспомнят ли они о msExchMasterAccountSid? Не трудно видеть, как мы может попасть в такую ситуацию и как эти проблемы могут закрыть для пользователя доступ к желаемым ресурсам сети. В последнее время я просмотрел множество журналов событий, где было зафиксировано событие с кодом 9548. Также интересно, что установка атрибута msExchMasterAccountSid не устанавливается принудительно в таких приложениях как оснастка Active Directory Users and Computers (Пользователи и компьютеры Active Directory).

Наконец, еще одна проблема. Стоит заметить, что при отключении учетной записи пользователя Windows с оставлением включенного почтового ящика и не установки атрибута msExchMasterAccountSid, данный почтовый ящик больше не сможет принимать новые сообщения, т.к. Exchange-сервер не может определить правильный идентификатор учетной записи пользователя. Поэтому, все новые сообщения, посланные этому пользователю, будут получать отчеты о недоставке до тех пор, пока вы не примете надлежащих мер.

Исправление

Ну, хватит грусти и печали. Исправить эту проблему очень просто, и в основном я уже описал ее решение. Если Вы отключили учетную запись Windows и оставили включенным почтовый ящик, все что нужно сделать, это дать записи SELF права Связанная Внешняя Учетная Запись и Полный Доступ к Почтовому Ящику для этого почтового ящика. Это делается с помощью оснастки Active Directory Users and Computers (Пользователи и компьютеры Active Directory), где Вы выбираете нужного пользователя, заходите в его свойства, выбираете закладку Exchange Advanced (Расширенные свойства Exchange) и нажимате кнопку Mailbox Rights (права на почтовый ящик). Все это полностью задокументировано в статье 278966 базе знаний Microsoft.

Но для одной-двух учетных записей это не слишком сложно. А что будет, если у Вас много таких учетных записей? Или, что более важно, как найти проблемную учетную запись? В статье из базы знаний Microsoft, упомянутой мной выше, есть удобный способ для поиска таких записей с помощью LDIFDE. Однако, есть лучшее решение — программное средство NoMAS.

Использование NoMAS

Вы можете использовать NoMAS для большого количества изменений при решении данной проблемы. Эта программа написана Алексом Зиглером из Microsoft, хотя Алекс говорит, что теперь она принадлежит и поддерживается Дейвом Голдманом. Для получения копии программы следует связаться с сервисом Microsoft по поддержке продуктов (PSS). При написании этой статьи я использовал версию 2.2004.05.03. Вы можете проверить, вышла ли более поздняя версия. Сама по себе программа представляет из себя исполняемый файл nomas.exe, который я просто скопировал на свой сервер Exchange в папку c:\program files\exchsrvr\bin, хотя Вы можете установить ее где угодно. Запуск программы вызывает окно, показанное на рисунке 2:

Обратите внимание, что по умолчанию файл журнала автоматически называется nomas.log и располагается в той же папке, где и программа. Далее Вам следует выбрать домен или контейнер, с которым Вы собираетесь работать, с помощью кнопки Browse… (Просмотр) справа. Из рисунка 3 Вы видите, что я собираюсь проверить контейнер Users (Пользователи). Также на главном окне видны две опции: Mode selection (выбор режима) и User selection (выбор пользователя). В моем примере, я собираюсь сделать проверку (режим Check) отключенных пользователей (Disabled users).

Я заметил, что кнопка Start (Пуск) недоступна до тех пор, пока Вы не выберете опцию из поля User selection (Выбор пользователя). Если Вы пренебрежете указанием домена в соответствующем поле и нажмете Start (пуск), высветится окно ошибки с напоминанием, что следует указать домен. Также следует выбрать правильный файл журнала. Однако, данные ограничения не относятся к полю выбора контейнера, и вы можете оставить его пустым. Если это поле пустое, NoMAS производит поиск по домену.

Посмотрим, что делают различные режимы.

Режимы

При выполнении проверки (Check), как в моем случае, NoMAS просто опрашивает Active Directory на предмет включенных пользователей с установлены атрибутом msExchMasterAccountSid, отключенных пользователей с неустановленным атрибутом msExchMasterAccountSid, или же всех, в зависимости от выбора, который сделан в поле User selection (выбор пользователя). Изменений в Active Directory не производится, поскольку это только проверка. Во время проверки NoMAS информирует Вас о том, что происходит:

После окончания работы NoMAS создает файл журнала там, где указано в установках, показанных на рисунке 3. Конечный файл журнала показан на рисунке 5. Обратите внимание, что строка с фразой ‘is missing msExchMasterAccountSid' (отсутствующий атрибут msExchMasterAccountSid), была выделена вручную для удобства чтения.

Из результатов ясно видно, что у нас существует отключенный пользователь без установленного атрибута msExchMasterAccountSid. Если теперь запустить программу в режиме Fix (исправить), NoMAS произведет такой же запрос, но теперь он установит для учетной записи SELF права Связанная Внешняя Учетная Запись. После запуска программы в режиме Fix (исправить), результатом будет файл журнала, показанный на рисунке 6.

Мы можем убедиться, что NoMAS все сделал правильно путем открытия окна Mailbox Rights (Права на почтовый ящик) для нужного пользователя. Как видно из рисунка 7, учетная запись SELF теперь обладает всеми нужными правами.

Режим Resynchronize (ресинхронизировать) интересен тем, что в нем программа опрашивает все включенные почтовые ящики учетных записей и синхронизирует права Связанная Внешняя Учетная Запись и msExchMasterAccountSid, поскольку они и должны быть синхронизированы. Затем автоматически запускается режим Fix (исправить) для включенных и отключенных учетных записей, чтобы убедиться, что все учетные записи правильно сконфигурированы.

Программа NoMAS поставляется с написанным Алексом документом в формате Word, который более детально описывает атрибут msExchMasterAccountSid, использование NoMAS, а так же содержит описание трех LDAP-запросов, которые NoMAS делает в Active Directory. Также Вам может быть интересно знать, что существует сценарий на VBScript программы NoMAS, который работает так же, как и C++-версия программы, описанная выше, хотя и не так быстро и не со всеми возможностями. Вы можете запускать этот сценарий с регулярными интервалами, используя команду-планировщик AT.

Производительность

Хотя получение предупреждений с кодом 9548 в журнале приложений может Вас раздражать, есть и еще одна причина для использования NoMAS при решении проблем с атрибутом msExchMasterAccountSid. Как утверждает сервис Microsoft по поддержке продуктов (Microsoft Product Support Services — PSS), были случаи, когда на больших серверах иногда страдала производительность Exchange-серверов из-за большого количества событий 9548. Это происходит из-за подвисания информационного хранилище при проверке ACL с содержащимися в них отключенных учетных записей без установленного атрибута msExchMasterAccountSid.

Резюме

NoMAS — действительно простое программное средство для решения проблем, связанных с появлением события 9548 в журнале приложений Вашего Exchange-сервера. Проверьте журналы событий на предмет нахождения там события 9548, если Вы найдете их, воспользуйтесь NoMAS для этих проблем. Это стоит сделать хотя бы потому, что я редко видел, чтобы диспетчеры программы Microsoft Operations Manager (MOM) били тревогу при интенсивном росте количества предупреждений 9548.