Вопрос: «На автономном сервере W2000 Server SP3 я попытался с помощью надстроек «Шаблоны безопасности» и «Анализ и настройка безопасности» создать шаблон, политику безопасности на его основе и применить его. За основу я взял шаблон hisecws.inf. Изменил настройки безопасности применительно к некоторым службам, убрал у группы Everyone полный доступ, оставил только возможность перезапуска. Права администраторов и самой системы не трогал. Но после применения политики даже администратор не может управлять этими службами, они стартуют (если в шаблоне был настроен тип запуска «Авто»), но управлять ими нельзя (все кнопки недоступны). Я попытался вернуться назад, используя шаблон defltsv.inf: процесс применения политики проходит до запуска служб, после этого secedit виснет, в журнале тоже последняя запись — первая обработанная secedit служба. Восстановление из резервной копии состояния системы System state не помогло. Все права на c:winnt и реестр у администратора и системы есть. Как исправить режим управления службами и вообще вернуться в исходное состояние?»

Сыров Андрей Георгиевич, Andrey.Syrov@vsk.ru

Ответ: «После изменения разрешений на запуск/остановку служб через политику Windows 2000 доступ к этим службам действительно может быть потерян. Данная проблема описана в Microsoft Knowledge Base, статья Q257247 по адресу: http://support.microsoft.com/default.aspx?scid=kb;EN-US;257247. Связано это с тем, что учетная запись, от имени которой запускается служба (чаще всего — учетная запись LocalSystem, входящая в локальные группы Administrators и System), должна иметь права на запуск/остановку этой службы. Если их отобрать — доступ к службе пропадает полностью, вплоть до того, что становится невозможно даже изменить разрешения обратно на правильные (что и произошло). Решить проблему можно только одним способом — нужно найти в системном реестре параметр, содержащий разрешения на доступ к соответствующей службе, и удалить его полностью. После удаления назначенных Вами разрешений начинают действовать разрешения по умолчанию (кстати, на абсолютное большинство служб действуют только разрешения по умолчанию и ничего более). После этого компьютер нужно перезагрузить, по-другому перезапустить недоступные службы в подобной ситуации невозможно. Что касается разрешений по умолчанию, то они вкратце сводятся к следующей схеме: группа Administrators имеет полный доступ ко всем службам, независимо от их состояния — Auto, Manual или Disabled. Группа Power Users имеет права на запуск и остановку только тех служб, которые находятся в состоянии Manual (на контроллере домена вместо группы Power Users используется группа Server Operators). Обычные пользователи не имеют никаких прав на управление службами Windows 2000.

Теперь о том, как удалить некорректные разрешения. Нужно найти в реестре настройки соответствующей службы, а точнее — открыть раздел HKEY_LOCAL_MACHINESYSTEMCurrentControlSet Services»ИМЯ_СЛУЖБЫ»Security. В этом разделе должен присутствовать единственный параметр, называется он тоже Security, имеет тип REG_BINARY. Его нужно просто удалить. Повторяете процедуру для каждой службы и перезагружаете машину. Microsoft также рекомендует перед перезагрузкой назначить для служб новые разрешения взамен удаляемых (делать это надо через доменную групповую политику, GPO), но реально это требуется только в том случае, если Вас не устраивают разрешения по умолчанию (см. выше). Я бы рекомендовал оставить по умолчанию — у обычных пользователей доступа к службам все равно нет.

Что же касается резервного копирования и восстановления состояния системы (System State) при помощи утилиты ntbackup.exe, то эти операции действительно не восстанавливают предыдущее состояние системных служб. Дело в том, что в состав сохраняемых System State файлов входят не все файлы операционной системы и не все разделы реестра. В частности, раздел HKEY_LOCAL_MACHINESYSTEMCurrentControlSet Services, содержащий настройки всех системных служб, исключен из System State целиком. Полный список исключений можно найти в Knowledge Base, статья Q233427, по адресу: http://support.microsoft.com/default.aspx?scid=kb;EN-US;233427».

Вопрос: «При работе с утилитой командной строки sfc у меня сложилась следующая ситуация. На большую часть машин в нашей организации мы установили Windows XP Pro с компакт-диска, и при запуске sfc «подсовывали» ей «родной» компакт-диск. С выходом SP1 мы решили интегрировать SP1 с оригинальным дистрибутивом Windows XP Pro. В результате получился сетевой каталог с дистрибутивом уже Windows XP SP1 Pro. В реестре нашли параметры (в HKLMSoftwareMicrosoftWindowsCurrentVersionSetup) и прописали указатель на новый каталог. Применили sfc... и столкнулись с отказом читать файлы из каталога. Тогда мы решили создать новый компакт-диск, и... sfc снова отказывается его признавать за свой. Как быть?»

Игорь Коваленко, broker@nht.ru

Ответ: «Утилита sfc.exe (Security File Checker), запускаемая из командной строки, работает совместно с механизмом Windows File Protection (WFP) и служит для проверки системных файлов Windows 2000/XP на предмет наличия несанкционированных изменений (проверяются контрольные суммы и цифровые подписи). В случае обнаружения несоответствий системные файлы заменяются резервными копиями из каталога WINNTSYSTEM32DLLCACHE, а при их отсутствии — оригинальными версиями из дистрибутива операционной системы, который должен быть доступен всем клиентам. Для удобства дистрибутивные файлы можно положить на файловый сервер и интегрировать с любым пакетом обновлений. В принципе, запуск SFC вручную в нормальных условиях обычно не требуется, поскольку механизм Windows File Protection на Windows 2000/XP всегда работает в фоновом режиме, автоматически отслеживая изменения, вносимые в системные файлы и автоматически восстанавливая их при необходимости (можно попробовать, например, стереть notepad.exe — он восстановится через 5-6 с). Но когда операционная система выключена, модификация файлов не отслеживается, и WFP не активизируется. В случае сомнений в целостности файлов можно явно активизировать WFP и запустить сканирование всех системных файлов утилитой sfc.exe из командной строки (наберите, например, «sfc /scannow»).

Работа SFC и WFP в Windows XP и Windows 2000 практически ничем не отличается, но для их корректного функционирования должен выполняться ряд условий.

  1. Пакет обновлений должен быть правильно распакован и интегрирован с дистрибутивными файлами операционной системы. Для распаковки нужно запустить основной исполняемый файл с ключом «/x», т. е., например, «xpsp1.exe /x». В ответ на вопрос о каталоге для распаковки следует указать любой пустой каталог. Для наложения же пакета обновлений на дистрибутив операционной системы требуется запустить из распакованного каталога файл UPDATEupdate.exe с ключом «-s:путь_к_дистрибутиву». Нужно иметь в виду, что реальный путь к дистрибутивным файлам обязательно должен заканчиваться на «I386», например «C:WinXPI386», но при запуске update.exe он указывается БЕЗ завершающего «I386», т. е. в данном примере — «update.exe -s:C:WinXP». Для Windows 2000 и Windows XP процедура интеграции одинакова.
  2. После интеграции пакета обновлений каталог с дистрибутивными файлами должен быть размещен на сервере. Называться он по-прежнему должен «I386».
  3. К дистрибутивным файлам следует открыть общий доступ. Но непосредственно к каталогу «I386» его открывать нельзя: если имя сетевого ресурса будет иметь вид «serverI386», то SFC и WFP работать не будут. Доступ должен открываться на один каталог выше, т. е. если файлы лежат в каталоге «C:WinXPI386», то доступ открывается к WinXP, а полный путь к дистрибутиву выглядит вот так: serverWinXPI386.
  4. На каждой рабочей станции, где будет запускаться SFC, в системном реестре должен быть прописан параметр HKLMSoftwareMicrosoftWindowsCurrentVersion SetupSourcePath (имеет тип REG_SZ). Это сетевой путь к дистрибутивным файлам БЕЗ завершающего «I386», т. е. если реальный сетевой путь имеет вид «serverWinXPI386», то параметр SourcePath должен быть «serverWinXP». После изменения этого параметра рабочую станцию Windows 2000 обязательно следует перезагрузить; Windows XP перезагружать не нужно.
  5. При запуске утилита SFC может потребовать от пользователя выполнить процедуру аутентификации (выдать запрос на имя и пароль). Это означает, что учетная запись, от имени которой запускается SFC, не имеет прав на сетевой ресурс, содержащий дистрибутивные файлы. На Windows 2000 утилита SFC всегда запускается от имени учетной записи LocalSystem, которая может получить доступ к сетевым ресурсам только при условии функционирования протокола аутентификации Kerberos. Это значит, что файловый сервер должен также работать под управлением Windows 2000/2003 и находиться в одном лесу доменов с клиентом. В этом случае учетная запись LocalSystem получает права учетной записи компьютера в домене, а компьютер, в свою очередь, входит в группы Everyone, Authenticated Users и Domain Computers. При отсутствии же домена протокол Kerberos не работает, LocalSystem не получает никаких прав на сетевые ресурсы и SFC на Windows 2000 работает только с локальной копией дистрибутива (с компакт-диска, например). При попытке воспользоваться файловым сервером система запрашивается имя и пароль, но набирать что бы то ни было бесполезно. В Windows XP утилита SFC запускается от имени учетной записи пользователя, который ее запускает, поэтому там такой проблемы обычно не бывает. Аутентификация может потребоваться лишь в том случае, когда сам пользователь, запускающий SFC, не имеет разрешений на доступ к общим ресурсам сервера. Чтобы этого не происходило, проще всего выполнить то же самое условие — клиент и сервер должны входить в один домен/лес доменов. Разрешения на дистрибутив в обоих случаях проще всего предоставить группе Everyone (только на чтение).

Однако существует простой способ сделать так, чтобы при работе SFC аутентификация не требовалась никогда: ни для Windows 2000, ни для Windows XP. Я настоятельно рекомендую им воспользоваться, ибо это сильно упростит использование SFC. Для этого необходимо на файловом сервере, хранящем дистрибутив операционной системы, разрешить нуль-доступ (подключение с пустым именем и паролем) к сетевому ресурсу с дистрибутивными файлами. Нужно найти в реестре сервера параметр HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServiceslanmanserverparametersNullSessionShares (имеет тип REG_MULTI_SZ) и отредактировать его при помощи regedt32.exe (regedit.exe не годится). Это список ресурсов, к которым разрешен нуль-доступ. Нужный ресурс следует добавить в конец списка. Если полное имя ресурса, например, «serverWinXP», то в список добавляется «WinXP». Затем нужно перезапустить службу Server. После этого SFC будет функционировать даже на рабочих станциях Windows 2000/XP, не входящих в домен».

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