В настоящее время мой контроллер домена заблокирован, и я не могу войти на компьютеры домена с учетными записями, которые являются членами группы администраторов домена из-за неправильного применения объекта групповой политики на верхнем уровне. В домене нет других контроллеров домена. Я попытался удалить GPO с помощью RSAT на одной из рабочих станций, но он также отключен этим GPO. Как я могу удалить этот объект групповой политики и восстановить контроль над своим доменом? У меня есть доступ к DC через DSRM, но я не уверен, как я могу это использовать, поскольку AD и групповая политика, кажется, отключены при загрузке в DSRM. К сожалению, у нас нет последней резервной копии AD, которую я мог бы восстановить, поскольку мы недавно перешли на новый DC.
Мы очень ценим любые идеи, так как в настоящее время я ночу на работе, пока не решу эту проблему. Спасибо всем.
Спустя много часов мне удалось восстановить доступ к DC. В итоге у меня сработало следующее. Имейте в виду, что у меня был доступ к логину DSRM на DC и базовым командам PowerShell в доменной сети.
Были некоторые затяжные эффекты GPO, которые нужно было устранить с помощью контр-GPO. Например, WID потерял возможность входа в систему в качестве службы, потому что это право было определено, но пусто в проблемном GPO. Когда я обнаружил эти эффекты, я написал одноразовые объекты групповой политики, чтобы исправить их, и протолкнул их по всему домену.
Надеюсь, это кому-то поможет, и спасибо за все предложения.
Я не знаю, сработает ли это для вас, но я подумал, что стоит опубликовать его как «возможный ответ».
Некоторое время назад, читая в Интернете, я наткнулся на http://www.nobodix.org/seb/win2003_adminpass.html . Согласно этой статье, находясь в «режиме восстановления служб каталогов», вы можете настроить «службу» для выполнения команды. Затем после перезагрузки в нормальный режим служба запустится и выполнит вашу команду как «системный» пользователь.
Я не знаю, будет ли этот метод работать в более современных версиях Windows, и я не знаю, будет ли он работать с нужными вам командами (которые кажутся более сложными, чем простой сброс пароля), но, возможно, стоит попробовать .
Я бы сказал, что вы здесь по-королевски облажались. Моей единственной крупной ошибкой в моей технической карьере было нечто похожее - я случайно отключил все учетные записи в домене, включая все учетные записи администратора (включая мою собственную). К счастью, в качестве дочернего домена я смог попросить кого-нибудь с учетной записью Enterprise Admin включить мою учетную запись, после чего я смог отменить то, что я сделал.
Если у вас нет этой опции, вам нужно будет использовать DSRM для восстановления вашей учетной записи администратора. Вы упомянули, что мигрировали с другого контроллера домена. Если это так, а контроллер домена все еще находится в домене и все еще является контроллером домена, убедитесь, что вы понимаете разницу между принудительным и неавторизованным восстановлением.
Восстановление вашей собственной учетной записи администратора (или любых других учетных записей администратора в резервных копиях, к которым у вас есть доступ) позволит вам отменить все, что было сделано.
Другой пользователь имеет похожую тему на serverfault: Как удалить групповую политику без доступа к домену (контроллеру)?
Спрашивающий никогда не выбирал выигрышный ответ, но предлагаемые методы включают (в произвольном порядке):
\\example.com\SYSVOL\Policies или C:\Windows\SYSVOL\sysvol\example.com\Policies) Сортировка по дате изменения и удаление нового.Удачи, надеюсь, один из этих способов сработает для вас!
Загрузитесь в режиме восстановления, также известном как DSRM, на DC. Этот вход должен быть выполнен с учетной записью с именем «Администратор» и паролем режима восстановления, который вы указали при добавлении роли DC. Выполните следующую команду:
dsquery * -filter (objectClass=groupPolicyContainer) -attr displayName distinguishedName
Просмотрите список нарушающих GPO. Замените различающееся имя в приведенной ниже команде на отличительное имя из нарушившего объект групповой политики. «RM» в этой команде означает «Удалить», а не «Режим восстановления».
dsrm "CN={11111111-AAAA-2222-BBBB-333333333333},CN=Policies,CN=System,DC=acme,DC=com" /subtree
gpupdate /force
Перезагрузите ДЦ в нормальный режим. Перезагрузите другие серверы / рабочие станции. Надеюсь, тогда вы сможете войти.
Я ненароком сделал то же самое вчера. Я внедрял новые STIG для Server 2008R2 и 2012R2. Сделал связку на прошлой неделе, и все выглядело хорошо. По-прежнему оставалось исправить еще 15 на основе сканирования Nessus, поэтому я посмотрел на них и понял, что некоторые из них я уже исправил (или думал, что исправил). Большинство из них требовало от вас запретить администраторам домена, администраторам предприятия и гостям иметь доступ для входа / удаленного / пакетного / служебного доступа.
Некоторые комментаторы хотели знать, какие объекты групповой политики вызвали проблему, поэтому вот что я сделал; Конфигурация компьютера-> Политики-> Настройки Win-> Настройки Sec-> Локальные политики-> Назначение прав пользователей. Есть Запретить вход в пакетное задание, Запретить вход в систему локально (будьте осторожны), Запретить вход в систему через службы удаленного рабочего стола (будьте осторожны) и Запретить доступ к этому компьютеру из сети (этот меня сделал). Существуют также настройки, позволяющие разрешить некоторые из этих прав, но если вы их откажете, разрешение не перезапишется.
Я добавил администраторов домена в объект групповой политики, в котором уже были группы «Гости» и «Администраторы предприятия». Этот объект групповой политики был применен ко всем серверам (включая контроллеры домена). Я не решался сделать это, но мне нужно было проверить, что произойдет. В течение 60 секунд после закрытия окна редактирования GPO все сломалось. Нет 90 минут ожидания обновления групповой политики. Для реализации политики компьютера перезагрузка не требуется. Все просто сломалось, быстро.
Я попытался сделать загрузочный компакт-диск или USB для редактирования учетной записи администратора DSRM, но безрезультатно. Итак, я использовал то, что Уилсон упомянул выше, отредактировал политику и изменил номер редакции. Работает отлично после загрузки с установочного диска Server 2012R2 и выбора восстановления. Затем выберите «Дополнительные инструменты» и «Командная строка». Нашел файлы, отредактировал и сохранил. Перезагрузился, но по-прежнему не мог войти в систему, но смог выполнить удаленный доступ с рабочей станции. Отключил плохой GPO и перезагрузил сервер. Все вернулось в норму.
Самая большая проблема заключалась в том, что все наши админы были в администраторах домена, я знаю, что сейчас это плохая практика, но некоторые люди не решаются менять. Очевидно, мы будем создавать новые группы и распределять людей только по тем группам, которые им нужны. Затем используйте GPO, чтобы предоставить этим конкретным группам доступ к тому, что им нужно, чтобы мы все еще могли реализовать STIG.
Надеюсь это поможет!