Ограничить доступ пользователей AD только к компьютеру в определенном OU

Ограничить доступ пользователей AD только к компьютеру в определенном OU

У нас есть домен 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 объекта групповой политики:

  1. GPO уровня домена. Добавить publicпользователя в политику безопасности Deny Log On Locally
  2. 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.

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc758377(v=ws.10)?redirectedfrom=MSDN

Связанный контент