Письма

Вопрос: «Я перешел на Windows 2000, выполнив новую установку. Прописал все полномочия и общие ресурсы. В домене работают AD, SQL Server 2000, Exchange 2000 Server. Все машины, включая рабочие станции и серверы NT 4.0, заработали с новым доменом — замечательно. Через неделю возникла проблема с Exchange 2000, и было решено вернуться к версии 5.5. Я удалил версию 2000 и поставил 5.5 на контроллер Windows 2000. С почтой все нормально, НО...

После этого все системы с NT 4.0, где я менял конфигурацию, перестали регистрироваться в домене с сообщением «Incorrect or missing machine budget in domain or incorrect password». Попытки повторного включения/исключения машин заканчиваются сообщением «Welcome to domain XXX», но после перезагрузки в домен не попасть. Предварительно в AD я выкидывал их учетные записи. Пробовал полную чистую переинсталляцию NT 4.0 с другими именами машин — ничего. Пришлось временно убрать их в рабочую группу с именем домена, и доступ к ресурсам они получают. Но сами понимаете — нужны еще политики, безопасность и пр. Кроме того, мне необходим сервер на NT 4.0 — член домена — а никак! Я понимаю, что Exchange 2000 поменял под себя AD, что версию 5.5 потом ставить не рекомендуется (но и не запрещается, так как у нее свой каталог). Но станции-то здесь причем?»

Андрей Проскурин, pruha@as.silmet.ee

Ответ: Описанные симптомы весьма характерны и однозначно указывают на то, что на контроллере домена Windows 2000 у Вас запрещены так называемые нуль-сессии (null session). Нуль-сессия — это подключение клиента к серверу, установленное с пустым именем пользователя и пустым паролем. Особенности процесса регистрации клиента Windows NT 4.0 в домене NT/2000 таковы, что этот процесс состоит из двух фаз. В первой фазе рабочая станция Windows NT 4.0 выполняет анонимное нуль-подключение к контроллеру домена и производит через него несколько удаленных вызовов процедур (RPC), проверяя наличие учетной записи данного компьютера в домене и ее пароль. Если аутентификация компьютера проходит успешно (т. е. подтверждено, что компьютер является членом домена), то нуль-сессия прерывается, и начинается вторая фаза регистрации: устанавливается новое подключение, но уже с использованием настоящего имени пользователя и его пароля. На данном этапе аутентифицируется уже не компьютер, а пользователь. Таким образом, производится двойная аутентификация.

Становится понятно, что если на контроллере домена Windows 2000 нуль-сессии заблокировать, то получится в точности такая картина, как описана Вами в письме, — блокировка не мешает вводить рабочие станции и серверы в домен (поскольку создание учетной записи компьютера в домене производится от имени администратора и нуль-сессии при этом не используются), но после перезагрузки и попытки регистрации в домене выдается сообщение о некорректности учетной записи компьютера (!) в домене. На самом деле с учетной записью компьютера конечно же все в порядке. Если вы перехватите сетевой трафик программой типа Network Monitor или ей подобной, то увидите троекратную попытку нуль-подключения клиента к ресурсу IPC$ на контроллере домена и троекратный ответ контроллера «Access Denied». После этого пользователю выдается знакомое вам сообщение об ошибке. С технической точки зрения за блокировку нуль-сессий на Windows 2000 отвечает один-единственный параметр реестра: раздел [HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlLsa], параметр RestrictAnonymous. Значение «2» запрещает нуль-сессии, «0» или «1» — разрешает. Кстати, на функционировании рабочих групп и клиентов Windows 2000 блокировка нуль-сессий никак не отражается (что Вы и наблюдаете).

Теперь о том, как вернуть все в рабочее состояние. Менять указанный выше параметр в реестре бесполезно — он контролируется через политику Windows 2000, и если вы измените лишь реестр, то через какое-то время все вернется на круги своя. Вам нужно открыть по очереди следующие политики: Local Security Policy, Domain Security Policy и Domain Controllers Security Policy (на контроллере домена все это можно найти в папке Start->Programs->Administrative Tools), и в каждой из них проверить параметр Security SettingsLocal PoliciesSecurity Options»Additional restrictions for anonymous connections». Везде, где вы найдете его в положении No Access, нужно поставить None. После этого каждый контроллер (!) следует перезагрузить, поскольку соответствующий параметр реестра относится к подсистеме безопасности (LSA), а она отдельно от компьютера не перезагружается.

Почему так происходит? Exchange, конечно, ни в чем не виноват — ни установка, ни удаление Exchange 2000/5.5 такого эффекта не дают (я даже специально воспроизвел вашу ситуацию, чтобы в этом убедиться). Скорее всего, вы применили к одной из перечисленных выше политик так называемый шаблон безопасности (Security Template) под названием hisecdc.inf (он хранится в папке winntsecurity emplates). Этот шаблон как раз блокирует нуль-сессии и вносит ряд других ужесточений политики безопасности, не совместимых со старыми операционными системами. Применение его запрещается, если в домене Windows 2000 присутствуют клиенты, отличные от Windows 2000/XP, — они после этого работать не будут. Ликвидировать последствия применения hisecdc.inf можно вручную, а можно, например, с помощью другого шаблона: securedc.inf (из той же папки). Он ослабляет настройки безопасности до уровня, приемлемого для клиентов Windows NT 4.0. Другие шаблоны безопасности на нуль-сессии не влияют, и их использование в данном случае бесполезно. Применение шаблонов обеспечивается через редакторы перечисленных мною выше политик функцией Import Policy, доступной в контекстном меню (щелчок правой кнопкой мыши) на объекте Security Settings. Перезагрузка системы нужна в любом случае.

Напоследок я рекомендую все-таки удалить сервер Exchange 5.5 с контроллера домена Windows 2000 (особенно если контроллер одновременно является глобальным каталогом), поскольку эти два продукта конфликтуют по портам TCP (конфликтуют порты, используемые службами LDAP и MAPI). Или стоит хотя бы переназначить порты — подробнее об этом рассказано в опубликованной в Knowledge Base статье Q275127. На клиентов Windows NT 4.0 эти конфликты никак не влияют, но в работе клиентов Windows 2000 (и самого сервера Exchange 5.5) могут возникать проблемы».

Вопрос: «Мы затеяли перевод контроллеров домена на операционную систему Windows 2000 и развертывание Active Directory. Домен станет дочерним по отношению к другому домену, в котором находится сервер корпоративной почты Exchange 2000. Будут установлены соответствующие доверительные отношения. Имя домена изменится. Клиенты — Windows 9x. Почтовый клиент — MS Outlook 98. Вопросы такие.

1. Как осуществить изменение настроек клиентских компьютеров с Windows 9x (а именно клиента для сетей Microsoft, параметр «Входить в домен Windows NT»). Здесь я думаю сделать следующее: изменить реестр клиентских компьютеров, распространив через сценарий регистрации соответствующим образом откорректированные в разделе реестра HKEY_LOCAL_MACHINESystemCurrentControlSet ServicesMSNP32NetworkProvider параметр AuthentificatingAgent и в разделе HKEY_LOCAL_MACHINESecurityProvider параметр Container, присвоив им новое имя домена. Является ли мое решение, на Ваш взгляд, оптимальным в сложившейся ситуации?

2. Как в этом случае централизованно изменить конфигурацию настроек MS Outlook? Зависит ли конфигурация Outlook от настроек сети?

Левитес Сергей Дмитриевич, levitessd@mels.ru

Ответ: «К сожалению, никаких подходящих средств удаленного администрирования при инсталляции Windows 9x по умолчанию не устанавливается, поэтому в любом случае вам придется прибегнуть к выполнению при регистрации каких-то сценариев. Из всех возможных действий, которые можно выполнить при помощи сценария, легче всего изменить параметр реестра. В Windows 9x он всего один: HKEY_LOCAL_MACHINESystemCurrentControlSet ServicesMSNP32NetworkProviderAuthentificatingAgent=»новое имя домена». Второй параметр реестра, приведенный Вами, необязателен, он нужен только в том случае, если Вы захотите предоставлять права на использование сетевых ресурсов Windows 9x (общие папки и принтеры) пользователям домена Windows 2000. Так что с точки зрения простоты перенастройки рабочих станций предложенный Вами метод оптимален.

Однако данный подход порождает другую проблему: чтобы запустился сценарий (Logon Script), пользователь должен зарегистрироваться в существующем домене. После запуска сценария имя домена, прописанное в реестре рабочей станции, изменится, и при следующем входе в систему пользователь попытается зарегистрироваться в другом домене — пока еще не существующем. Локально зарегистрироваться в системе Windows 9x он при этом сможет (получив сообщение о недоступности контроллеров домена), но часть сетевых ресурсов станет ему недоступна, поскольку рабочая станция начнет вести себя как участник рабочей группы. Эффект будет такой: за счет того, что имена и пароли пользователей остались прежними, пользователи смогут получить доступ к тем серверам, на которых существуют соответствующие учетные записи, т. е. к контроллерам старого домена. Но к рядовым серверам — членам домена — доступа больше не будет. Серверы будут проверять пользователей только по локальным спискам учетных записей (SAM), а эти списки наверняка пусты. На контроллеры домена серверы обращаться не будут, поскольку имя домена, в котором находится клиент, не совпадает с именем домена, в котором находится сервер. Картина не изменится до тех пор, пока домен не будет, наконец, переименован. А переименовать его можно будет только после того, как Ваш сценарий запустится на всех без исключения рабочих станциях. Соответственно, получается перерыв в работе сети.

Поэтому если Вы хотите, чтобы сеть работала корректно и переход пользователей в новый домен совершился плавно, Вы должны будете создать и некоторое время поддерживать оба домена: и старый, и новый — с разными названиями, но одинаковыми наборами учетных записей. Это означает, что вместо модернизации (upgrade) домена придется делать реструктуризацию — создание нового домена Windows 2000 параллельно с существующим и клонирование учетных записей из старого домена в новый. Делается это с помощью утилиты Active Directory Migration Tool (ADMT), которую можно бесплатно загрузить с Web-сайта Microsoft. При клонировании устанавливаются доверительные отношения (trusts) между старым и новым доменами, за счет чего пользователи после клонирования могут получить доступ к серверам независимо от того, в каком домене стоит сервер и в каком домене регистрируется пользователь. Переносить пользователей и сервер в новый домен в этом случае можно в любом порядке и в любое время. Подробную информацию об использовании ADMT можно найти по адресу: http://www.microsoft.com/windows2000/techinfo/ howitworks/activedirectory/admt.asp, там же опубликованы ссылки на саму утилиту ADMT и документ под названием «Domain Migration Cookbook», описание различных сценариев миграции домена Windows NT 4.0 до Windows 2000, как методом модернизации, так и методом реструктуризации. Другой источник информации на эту тему — двухдневный учебный курс Microsoft «#2010: Designing a Microsoft Windows 2000 Migration Strategy».

Если Вы откажетесь от клонирования (это процесс весьма сложный) и пойдете по пути модернизации контроллеров домена Windows NT 4.0 до Windows 2000, то имейте в виду: в процессе модернизации имя домена (имя NetBIOS, которое используют клиенты Windows 9x/NT), изменить нельзя! И после тоже — домены Windows 2000 не переименовываются. Переименовать домен можно только до модернизации, пока он еще является доменом Windows NT 4.0.

По поводу второго вопроса. Настройки подключения Microsoft Outlook к серверу Exchange лежат в так называемом почтовом профиле (доступен через Control Panel -> Mail). Этот профиль хранится в реестре, и в нем содержится лишь имя организации Exchange, имя почтового сервера и имя почтового ящика, к которому Вы подключаетесь (Mailbox Alias). Имя пользователя и имя домена там не фигурируют. Из Вашего письма не совсем понятно, что произойдет с вашей почтовой системой во время миграции, но в принципе если изменяется только имя домена, а почтовый сервер, с которым до миграции работали пользователи, остается прежним, то перенастраивать Outlook не придется. При модернизации сервера Exchange 5.5 до Exchange 2000 проблем с клиентами тоже не будет, так как имя почтового сервера сохраняется. Аналогично, если Вы сделаете параллельную установку Exchange 2000 в существующую организацию Exchange 5.5 и аккуратно перенесете почтовые ящики со старого сервера на новый, все клиенты при очередном запуске Outlook автоматически перенастроятся на новый сервер (при условии, что Вы не будете удалять старый сервер, пока процесс перенастройки не закончится!). Миграция c Exchange 5.5 на Exchange 2000 подробно описана, например, в Knowledge Base, статьи Q327928 (общие принципы), Q316886 (сценарий параллельной установки с переносом почтовых ящиков) и Q324318 (сценарий модернизации). Все сценарии миграции при их корректном выполнении являются для клиентов MS Outlook прозрачными.

Если же в процессе миграции будет построена абсолютно новая почтовая система (т. е. миграции как таковой не будет), то придется заново подключить всех клиентов к новому серверу Exchange. Для этого нужно создать на каждой рабочей станции новый почтовый профиль. Старый можно удалить, хотя это и необязательно. Помочь в автоматизации данного процесса может утилита PROFGEN (Profile Generator), входящая в состав Exchange 5.5/2000 Resource Kit. Она позволяет автоматически создавать новые почтовые профили на всех рабочих станциях, назначая их при этом профилями по умолчанию, и должна запускаться через Logon Script. Имя почтового сервера должно быть заранее указано в соответствующем конфигурационном файле, а в качестве имени почтового ящика используется имя, под которым пользователь вошел в систему. Более подробное описание утилиты можно найти в документации, входящей в состав Exchange Resource Kit.

Сергей Мороз — преподаватель Учебного центра информационных технологий Академии народного хозяйства при Правительстве РФ. Имеет сертификаты MCSE, MCT. С ним можно связаться по адресу: SergeyM@ane.ru.