У меня есть контроллер домена (WS2012-R2) и набор (WS2012-R2) серверов, которые являются членами домена. Я случайно добавил группу, в которую входят все администраторы, к групповой политике «Запретить вход в систему локально», «Запретить вход в систему как сервис», «Запретить удаленный доступ» и «Запретить доступ к сети». Это привело к тому, что я и все другие администраторы (даже встроенная учетная запись) были заблокированы из контроллера домена.
Есть ли способ восстановить доступ к серверу, удалив объект групповой политики или удалив учетную запись администратора из группы, в которой было отказано?
Ответы:
На ум приходят две мысли.
Можно предположить, что вы можете использовать загрузочный компакт-диск для доступа к контроллеру домена, пока он находится в автономном режиме, и вручную отредактировать или удалить вызывающий беспокойство объект групповой политики - объекты групповой политики домена существуют в
SYSVOL
папке в файловой системе на контроллерах домена и применяются как параметры реестра, оба из которые доступны с загрузочного компакт-диска - однако это либо отменит репликацией, либо вызовет ошибки репликации домена, как только контроллер домена, на котором вы это сделали, подключится к другому контроллеру (ам) домена в домене. (Я предполагаю, что у вас в домене более одного контроллера домена, как и должно быть ... если у вас есть только один, это не будет плохим подходом).Другой подход, который приходит на ум, - войти в режим восстановления служб каталогов и выполнить принудительное восстановление из резервной копии, предшествующей этому объекту групповой политики. (И это также зависит от предположения, что вы делаете то, что должны делать, и у вас есть резервные копии для восстановления.)
источник
Я на самом деле не пробовал это. (Извините.) Я также предполагаю, что RSAT не будет работать из-за «запрета удаленного / сетевого доступа». (Если вы еще не пробовали, стоит попробовать, но я не оптимистичен.)
Возможно, вы могли бы создать новую учетную запись администратора с загрузочным CD Hiren и использовать эту учетную запись для редактирования политики.
источник
Где применяется групповая политика? Только для контроллеров домена или для всего домена?
Если он применяется только к контроллерам домена, то вы все равно можете войти на другой членский компьютер, используя учетную запись администратора домена; затем вы можете включить консоль управления групповой политикой и / или все другие инструменты администрирования AD, если вы находитесь на серверной ОС, или установить RSAT и сделать то же самое, если это рабочая станция; с помощью этих инструментов вы сможете редактировать вызывающий беспокойство объект групповой политики или, по крайней мере, пользователей и группы (консоль ADUC использует запросы LDAP, поэтому она не подлежит ограничениям на вход в систему).
Если вместо этого политика применяется ко всему домену, и вы не можете войти нигде, используя учетную запись администратора домена, то возможный обходной путь может заключаться в использовании модуля PowerShell Active Directory : почти все командлеты имеют
-credential
параметр, который позволяет указывать учетные данные использовать для запуска команды, даже если PowerShell фактически выполняется под другой учетной записью пользователя ; это включает в себя Remove-ADGroupMember . Таким образом, возможное решение будет:Import-Module ActiveDirectory
$admincreds = Get-Credential
(открывается окно, в котором необходимо ввести учетные данные для учетной записи администратора домена)Remove-ADGroupMember <GroupName> <UserName> -Credentials $admincreds
Если это работает,
<UserName>
будет удалено из<GroupName>
, и, таким образом, нарушающая политика больше не будет его блокировать.источник
Deny network access
распространяется на доступ через RSAT (и PowerShell)? Не то чтобы я собирался протестировать или у меня есть опыт блокировки себя из моих DC, чтобы вернуться к нему, но я считаю, что по этой причине это не сработает.Загрузите контроллер домена в режиме восстановления активного каталога с учетной записью, которую вы настроили при создании домена. (Это просто локальная учетная запись администратора на
Administrator
контроллере домена , названная , и пароль был установлен в dcpromo.)Оттуда удалите все разрешения NTFS на
SYSVOL
томе в папке идентификатора объекта групповой политики. (Проверьте последнюю измененную папку, чтобы найти последний измененный объект групповой политики).В этом режиме база данных Active Directory не загружается, но у вас есть доступ к файловой системе.
Если ничего не работает, в этом режиме вы можете попробовать
gpofix
команду, но имейте в виду, что она удалит ВСЕ объекты групповой политики.источник
Когда домен был изначально создан, была создана учетная запись «бога». Узнайте, что это было, его пароль, и вы сможете войти в DC, где размещен глобальный каталог. Оттуда вы должны быть в состоянии отменить то, что вы сделали, и дать ему время для распространения.
Если это не помогает, есть несколько хакерских техник, которые вы можете использовать, но для меня было бы неуместно передавать это здесь. Обратитесь к местному специалисту по безопасности, поскольку он обычно знаком с хакерскими методами и может помочь вам восстановить домен.
Конечно, если это всего лишь несколько серверов, и это не критично, вы можете просто стереть и начать все сначала.
источник
Сначала отключите все контроллеры домена. Это позволит избежать странных проблем с репликацией.
Первый шаг - удалить неверный параметр групповой политики. Назначения привилегий хранятся в
GptTmpl.inf
файле вMACHINE\Microsoft\Windows NT\SecEdit
каждой папке политики. Вы будете знать , что есть правильную политику , когда этот.inf
файл содержит строку дляSeDenyNetworkLogonRight
,SeDenyInteractiveLogonRight
и так далее. Удалить всеSeDeny...Right
строки из него.Windows не будет применять новые параметры, если не увидит, что объект групповой политики изменился, что определяется путем обращения к
versionNumber
атрибуту объекта Active Directory. Давайте не будем пытаться редактировать AD в автономном режиме. Вместо этого мы удалим неверные настройки из реестра вручную.Смонтируйте
\Windows\System32\config\SECURITY
куст контроллера домена в реестр другой системы Windows с помощьюreg load
. Откройте редактор реестра и перейдите кPolicy\Accounts
монтированному кусту. (Для этого может потребоваться запуск вregedit
качестве SYSTEM. PsExec может сделать это.) Каждый подраздел этого соответствует пользователю или группе, аActSysAc
подключ каждого из них содержит «права». (Все «привилегии» находятся вPrivilgs
подразделе.) Найдите тот соActSysAc
значениемC0 03 00 00
, которое соответствует четырем правам, которым вы отказали. УдалитеActSysAc
или измените его значение на00 00 00 00
. Закройте редактор реестра и размонтируйте улейreg unload
.Загрузите контроллер домена, который вы изменили. Вы должны быть в состоянии войти в систему сейчас. Используйте консоль управления групповыми политиками для внесения любых изменений (независимо от того, насколько это тривиально) в локальные политики соответствующего объекта групповой политики. Это увеличит номер версии объекта групповой политики.
Загрузите другие контроллеры домена и дайте изменениям повторить изменения.
источник
Вы можете попробовать открыть в проводнике \\ domain.controler \ c $ \ windows \ sysvol \ sysvol \ domain.local \ polices (у вас все еще есть доступ)
Там вы найдете все политики. Переместите этот каталог в какое-то временное место и попробуйте перезагрузить компьютер. Это поможет.
источник
\\domainname\sysvol\
и получить доступ к политикам таким образом, но мои надежды не оправдаются. Изменение sysvol требует привилегий администратора домена, и если вы заблокировали всех администраторов домена, вы не сможете получить к нему необходимые привилегии для этого.