У нас есть домен AD (все еще локальный), который поддерживает библиотеку, среди прочего. В этой библиотеке есть несколько общедоступных компьютеров, и эти общедоступные компьютеры находятся в своих собственных OU в Active Directory. У нас также есть общий public
гостевой вход, который наши библиотекари могут использовать, чтобы предоставить внешним гостям доступ к машинам.
Я хочу ограничить эту учетную запись — и только ее — так, чтобы она могла получать доступ только к компьютерам в PublicComputers
организационном подразделении.
У нас есть много других пользователей, которые также должны иметь возможность входить в систему на этих и других компьютерах.
Я знаю о Log On To...
кнопке на объекте User в AD, но это плохо подходит, так как эти компьютеры приходят и уходят. Членство в OU сохраняется по другим причинам, но если нам нужно использовать эту кнопку каждый раз, когда компьютер перемещается, она быстро устареет.
Соответствующие части нашей иерархии AD выглядят следующим образом:
Domain Root > InstitutionComputers > Library > PublicComputers
> ServiceAccounts > public
> Users (group) > {ManyOtherUsers}
> OtherOU > {ManyOtherUsers}
Как я могу это сделать?
Я попробовал настроить политику Deny Logon на уровне домена, чтобы включить публичную учетную запись, а затем еще одну политику Deny Logon на более конкретном уровне OU, которая не включает учетную запись.
При тестировании это работает на некоторых машинах, но другие блокируют вход публичного пользователя. Если я смотрю в Local Security Policy с машины, которая не работает, я вижу, что у нее полная политика с уровня домена, а не с уровня OU, но я подтвердил, что машина является членом правильного OU. Кроме того, gpresult
показывает обе политики. (Я также добавляю эту информацию в вопрос), поэтому я знаю, что более конкретная политика соответствует этим компьютерам. Это продолжает происходить даже после запуска gpupdate /force
и перезапуска компьютера.
Оказывается, у меня было неправильное представление о том, как работает "enforced" в групповой политике, где это больше похоже на css !important против enabled/disabled. Снятие отметки "enforced" позволило работать задокументированным правилам приоритета, при этом все политики продолжали применяться.
решение1
Создайте 2 объекта групповой политики:
- GPO уровня домена. Добавить
public
пользователя в политику безопасности Deny Log On Locally - GPO уровня OU (OU, в котором есть объекты-компьютеры). Настройте Deny Log On Locally как пустое (или как вам нужно, на случай, если у вас есть другие пользователи, которых нужно заблокировать)
Более подробную информацию можно найти в документах Microsoft:https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/deny-log-on-locally
Порядок применения очередности действует в обратном порядке по сравнению с обычным порядком применения:
Если в GPO, которые применяются на двух уровнях иерархии, есть конфликтующие настройки, то преобладает настройка, применяемая дальше всего от клиента. Это обратный вариант обычного правила, в котором преобладает настройка из ближайшего связанного GPO.