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