![]() |
MMC оснастка RRaS - отказано в доступе
Всем доброго времени суток!
После суток гугления, проб и ошибок, обращаюсь за советом к коллективному разуму. Ситуация: Windows Server 2003 R2 SP2 - контролер домена Сервер вынуждено торчит в интернет, потому приходится постоянно следить за обновлениями системы и регулярно их ставить (сколько горя уже было...), после появления сообщений о доступных обновлениях я выжидаю где-то недельку, периодически почитывая гуголь по запросу "w2k3 проблемы после обновления". Так было и на этот раз, где-то 05-06 января сервак затянул несколько обновлений а именно: Код:
Обновление для системы безопасности Windows Server 2003 (KB2893294) (все нижеописанное проявляется при работе как под встроенным локальным администратором, так и при логине под любым пользователем входящим в группу "Администраторы" и "Администраторы домена") Проблема: Первое) Ряду служб, таких как "Служба времени" и т.д. установлен запуск от имени NT AUTHORITY \ LocalService с заполненным полем "пароль". После перезагрузки (которую вежливо попросили обновы) эти службы встали - первоначально решено добавлением NT AUTHORITY \ LocalService в группу "Админитсраторы" (потом Process Explorer помог определить какие службы бегут не "От имени системы", и данное недоразумение поправлено ручками) Второе) 1) Не запускается MMC-оснастка управления RRaS, с ошибкой "Отказано в доступе", причем весьма странно, интерфейс оснастки таки открывается, в нем видно дерево серверов в частности локальный компьютер, но этот узел не разворачивается, но над самим узлом через его свойства можно совершать все доступные манипуляции - перезапустить, остановить и т.д. Сама же RRaS отлично работает, и без проблем управляется через netsh, ни в каком доступе ему не отказано :) ![]() ![]() 2) Средство сбора информации о системе выдает "ужасное" ![]() 3) Результирующая политика не работает вот так ![]() Гугленя и собственные домыслы - возможно сбиты права на реестр, возможно права на некоторые каталоги ФС, но корень зла - RPC и настройки безопасности COM Что было предпринято: 1) Востановление заведомо работоспособных прав на реестр Код:
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=Администраторы=f /grant=system=f Код:
secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose ![]() ![]() Все вышеописанные действия - проблему не решили. Более того, на данном сервере идет ежедневная архивация штатными средствами - "System State" Откат на System State (до обновления), сбрил обновления т.е. их снова предлагается скачать и установить но проблема - осталась. PS: Все службы сервера функционируют нормально, других связанных проблем не проявляется, я уже и не знаю что делать господа. Уж очень хочется вернуть к жизни RRaS оснастку, частенько приходится реконструировать сеть - netsh конечно скажите вы, и я отвечу - да. Но это "какая-то нездоровая х@#$я", да и "спортивный интерес" :) PPS: Я проф.программист, админство - по совместительству и временной необходимости да и то преимущественно Unix-like, а тут сами понимаете - винда, еще и "старая" :( хнык,хнык |
RUVATA, сделайте лог Process Monitor следующим образом:
|
https://drive.google.com/file/d/0B0w...it?usp=sharing
В фильтр добавлен фокус по Process name "mmc.exe" мониторинг включен до вызова оснастки и отключен после закрытия сообщения об ошибке. |
Цитата:
|
ОК :) I'am sorry, инициатива как говорится - е@#$т инициатора
https://drive.google.com/file/d/0B0w...it?usp=sharing Мониторинг активирован за несколько секунд до открытия оснастки и остановлен сразу после закрытия сообщения об ошибке. (ни каких фильтров, только дифолтовые) |
RUVATA, попробуйте удалить параметр DefaultAccessPermission (по умолчанию его нет) в ветке
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole и перезагрузиться. Перед удалением сохраните копию. Выложите содержимое (в Regedit -> меню Файл -> Экспорт). |
Экспорт ветки
Код:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole Параметр удален, система перезагружена - безрезультатно. |
RUVATA, к сожалению, у меня нет под рукой Server 2003, поэтому сами сравните остальные параметры в этой ветке с рабочим сервером.
|
Удалось найти эталонную конфигурацию узла реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
(Рабочий сервер, подобных проблем не наблюдается, несмотря на установку последних обновлений) Вот результат сравнения, имеются несущественные различия ![]() Стоит ли произвести слияние с эталоном ? PS: собственно эталон https://drive.google.com/file/d/0B0w...it?usp=sharing |
Слияние не приносит результата, а вот удаление узла HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
и последующий импорт "эталона" с последующей перезагрузкой - полностью решает проблему. PS: по скольку файлы на гуглодрайве - явление возможно непостоянное, выкладываю здесь содержание reg-файла эталонной конфигурации узла, надеюсь вновь столкнувшимся это сильно упростит жизнь :) Код:
Windows Registry Editor Version 5.00 |
Цитата:
|
Цитата:
Хорошо, что таки решился спросить :) а то бы ковырял и ковырял еще долго, "спортивный интерес" такая штука :) PS: Интересно только как OLE влияет на WMI (там вроде как чистые интерфейсы, а не COM-компонента/ты), так как проблема ощущалась на оба фронта, а решение вроде как касается только OLE/DCOM/COM security... вот |
Время: 13:04. |
Время: 13:04.
© OSzone.net 2001-