Назад | Перейти на главную страницу

Тесты безопасности Windows Server 2016 + CIS: «доступ запрещен» для объектов GP, все общие ресурсы заблокированы, в т.ч. SYSVOL

У нас есть домен Active Directory с Windows Server 2016 на контроллере домена и актуальная Windows 10 на всех клиентах. Не так давно я начал развертывание тестов безопасности Center for Internet Security (CIS) Level-1 в домене с помощью групповой политики: Windows 10 в политике домена по умолчанию, с переопределениями на основе документа Windows Server 2012 R2 (там нет еще один на 2016 год) в политике контроллера по умолчанию. Меня и раньше укушало небрежное усиление защиты Windows, поэтому на этот раз я просмотрел все настройки одну за другой, открывая соответствующие документы и проверяя влияние любых незнакомых параметров. Это работало нормально - до сегодняшнего дня, когда мне наконец удалось что-то напортачить. Симптомы следующие

  1. Если щелкнуть левой кнопкой мыши любой объект групповой политики в управлении групповыми политиками, появится сообщение об ошибке «Доступ запрещен». Тем не менее, я все еще могу исследовать свойства объекта и управлять ими, включая изменение статуса GPO;
  2. Открытие одного из указанных объектов GPO для выпуска снова показывает «доступ запрещен», хотя и в другом поле, и при запуске редактора видимые записи дерева отмечаются красным X;
  3. Вернувшись в Управление групповой политикой, если я перейду на вкладку «Подробности» объекта групповой политики, я смогу увидеть только его версию AD. Один в sysvol описан как недоступный;
  4. Наконец, когда я бегу gpupdate / force на любом компьютере домена, включая сам контроллер домена, я получаю такую ​​ошибку:

Ошибка обработки групповой политики. Windows попыталась прочитать файл \ contoso.com \ sysvol \ contoso.com \ Policies {foo} \ gpt.ini с контроллера домена, но безуспешно. Параметры групповой политики не могут применяться, пока это событие не будет разрешено. Эта проблема может быть временной и может быть вызвана одним или несколькими из следующих факторов: a) Разрешение имен / сетевое подключение к текущему контроллеру домена. б) Задержка службы репликации файлов (файл, созданный на другом контроллере домена, не реплицирован на текущий контроллер домена). c) Клиент распределенной файловой системы (DFS) отключен.

К сожалению, я только что понял, что забыл проверить соответствующий код ошибки в журнале событий, однако, учитывая, что если я укажу в Проводнике на \ contoso.com \ sysvol \ (или, если на то пошло, любой поделиться на этом сервере, используя в пути как хост, так и доменное имя). Меня просят ввести учетные данные, но я еще не нашел работающих, я снова делаю ставку на «доступ запрещен». Кстати, доступ к sysvol по локальному пути на DC работает нормально.

Короче говоря, по крайней мере два последних симптома убедительно указывают на то, что мне удалось заблокировать себя из общего ресурса SYSVOL; не знаю, вызваны ли первые два тоже этим или нет. Кстати, после перезагрузки контроллера домена в режим DSRM, а затем обратно в нормальный режим, все работало около 10 минут.

Теперь у меня есть актуальные резервные копии, поэтому я могу просто восстановить последнее рабочее состояние и покончить с этим. Однако мне бы очень хотелось а) понять, какие именно настройки могли вызвать эту проблему (в противном случае я, скорее всего, снова столкнусь с той же проблемой снова), и б) выяснить, как заставить мой домен работать со всем усилением защиты. на месте (контрольные показатели CIS Level-1 исходный уровень, они не должны сильно влиять на функциональность ...). О, и в) если я все еще могу что-нибудь делать с текущей конфигурацией.

Кто-нибудь, имеющий опыт либо повышения безопасности Windows в целом, либо применения тестов CIS в частности, мог бы дать мне толчок в правильном направлении? Если да, то заранее большое спасибо!

Обновление: похоже, мне удалось отключить нарушающие политики, но это не отменило блокировку SYSVOL. Сброс локальной политики безопасности до значений по умолчанию с помощью secedit также не помог, возможно, из-за всех предупреждений «доступ запрещен», выдаваемых процедурой.

Между прочим, я заметил одну интересную вещь: если я запускаю «net share SYSVOL» на контроллере домена из командной строки PowerShell, запущенной с повышенными разрешениями, она действительно возвращает ожидаемую информацию (в отличие от запуска из обычного приглашения, которое дает - как вы уже догадались, ! - "доступ запрещен").

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

  • dcgpofix / target: both (выдал ошибку "доступ запрещен" на SYSVOL)
  • перезагрузитесь в DSRM
  • secedit / configure / cfg% windir% \ inf \ defltbase.inf / db defltbase.sdb / verbose (выдает несколько предупреждений «доступ запрещен», но сбрасывает по крайней мере назначения прав пользователя и параметры безопасности до значений по умолчанию)
  • перезагрузитесь обратно в нормальный режим
  • dcgpofix / target: снова оба (наконец-то проблема решена)
  • восстановить последние известные исправные объекты групповой политики по умолчанию из резервной копии

Надеюсь, это пригодится, если кто-то окажется в таком же затруднительном положении.