У меня возникают проблемы с тем, чтобы объект групповой политики не применялся к определенному подразделению.
У меня есть объект групповой политики bitlocker, который использует пароль на уровне домена. (это применимо к каждому подразделению), но я хочу, чтобы он исключил компьютер и пользователей, которые являются частью подразделения безопасности. Потому что я хочу использовать USB с ключом на этих компьютерах.
Я пробовал это решение https://www.faqforge.com/windows-server-2016/exclude-user-computer-group-policy-object/ где вы добавляете компьютеры и пользователей в группу и запрещаете применение gpo уровня домена к группе.
Но я получаю сообщение об ошибке при попытке выполнить битлокировку компьютера в OU. Он говорит, что у меня есть конфликтующие GPO битлокера.
Что делать?
Хотя это уже было сказано, я собираюсь приклеить это сюда, чтобы не скрывать в комментариях. В основном потому, что, судя по тому, что вы сказали, вы только что применили новую политику в корне домена, даже не протестировав ее сначала на суб-OU?
Это невероятно рискованная идея, и вам повезло, что вы не заблокировали свои DC или что-то в этом роде.
Номер один - избавьтесь от политики битлокеров в корне домена. Практически единственные политики, которые у вас должны быть, - это базовые политики безопасности, такие как длина пароля, блокировка учетной записи и все эти фундаментальные вещи.
Во-вторых, начните думать о том, как будут применяться ваши политики. Должны ли они действительно применимы к каждому объекту в домене или должны применяться только к компьютерам или пользователям? Или выбранный пользователи или компьютеры? Это сообщает, как вы собираетесь связать свои политики.
Поместите все объекты вашего компьютера в одно подразделение (или подразделение верхнего уровня, а затем подчиненные подразделения по мере необходимости). Я настоятельно рекомендую вам иметь отдельные подразделения верхнего уровня для рядовых серверов и рядовых рабочих станций. Примените свою политику Bitlocker к OU рабочих станций верхнего уровня и / или OU серверов по мере необходимости.
Если вы хотите исключить политику из ваших компьютеров «безопасности» (такая ирония), создайте для них еще одно подразделение верхнего уровня.
Для общего управления не смешивайте объекты пользователей и объекты компьютеров в одних и тех же подразделениях верхнего уровня. Управлять этим сложно, и запросы LDAP становятся неэффективными по мере увеличения домена. Поместите одни и те же классы объектов (например, «Пользователи», «Компьютеры») в отдельные подразделения, а затем при необходимости создайте дочерние подразделения для этих объектов.
Не попадайтесь в унаследованную ловушку создания подчиненных подразделений для каждого отдела, если у вас буквально нет отдельных команд ИТ-управления для каждого из них - вам нужны только новые подчиненные подразделения, если вам нужно настроить разрешения или политики подразделений. Что касается политик, в наши дни я обычно рекомендую использовать группы AD для объектов пользователей / компьютеров, на которые вы хотите настроить таргетинг, или для компьютерных запросов WMI, чтобы ограничить область применения детализированных политик).
Да, и убедитесь, что вы не оставляете учетные записи пользователей или компьютеров в контейнерах «Пользователи» или «Компьютеры» по умолчанию. Единственное, что должно быть в Users, - это учетные записи и группы по умолчанию, которые создаются в домене (и некоторые из них должны быть перемещены в целях безопасности в свое время - любая учетная запись, созданная впоследствии, должна перейти в соответствующее OU.
И пройдите тренинг по управлению групповой политикой.