Limit AD user to only login to computer in a specific OU

Joel Coel

12/7/23, 9:19 PM

We have an AD domain (still on-premise) that supports a library, among other things. This library has a number of public computers, and these public computers are in their own OU in Active Directory. We also have a generic public guest login our librarians can use to give outside guests access to the machines.

I want to limit this account — and only this account — so it can only access computers in the PublicComputers OU.

We have many other users who should also still be able to login to these computers and others.

I am aware of the Log On To... button on a User object in AD, but this is a poor fit as these computers come and go. The OU membership is maintained for other reasons, but if we need to use that button every time a computer moves around it will quickly end up out of date.

The relevant parts of our AD hierarchy look like this:

Domain Root > InstitutionComputers > Library > PublicComputers
            > ServiceAccounts > public
            > Users (group) > {ManyOtherUsers}
            > OtherOU > {ManyOtherUsers}

How can I do this?

I've tried a setting a Deny Logon policy at the domain level to include the public account, and then another Deny Logon policy at the more-specific OU level that does not include the account.

In testing this works on some machines, but others will block the public user from logging in. If I look in Local Security Policy from a machine that is not working I see it has the full policy from the domain level, rather than the OU level, but I have confirmed the machine is a member of the correct OU. Additionally, gpresult shows both policies. (I'm adding this info to the question, also), so I know the more-specific policy is matching these computers. This continues to happen even after running gpupdate /force and restarting the computer.

It turns out I had a misconception of how "enforced" works in Group Policy, where it's more like css !important vs enabled/disabled. Unmarking "enforced" allowed the documented precedence rules to work, while still applying all the policies.

2184

1 + 0

permissions

active-directory

group-policy

Score:2

Server

Jevgenij Martynenko

12/10/23, 11:06 AM

Create 2 GPOs:

Domain level GPO. Add public user to Deny Log On Locally security policy
OU level GPO (the OU which has computer objects). Configure Deny Log On Locally as empty (or whatever you need it to be, in case you have other users you need to block)

For more information, check Microsoft docs: https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/deny-log-on-locally

Enforcement precedence work in reversal comparing to usual apply order:

If there are conflicting settings in GPOs that are enforced at two levels of the hierarchy, the setting enforced furthest from the client prevails. This is a reversal of the usual rule, in which the setting from the nearest-linked GPO would prevail.

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

+ 5

Joel Coel

12/12/23, 5:53 PM

I've been testing this. It works on some machines, but others will block the public user from logging in. If I look in Local Security Policy on the machine itself I see it has the full policy from the domain level, rather than the OU level, but I have confirmed the machine is a member of the correct OU. Additionally, gpresult shows both policies. (I'm adding this info to the question, also).

Jevgenij Martynenko

12/12/23, 6:00 PM

Run rsop.msc or gpresult.exe on problematic machines. It should provide you some insights. There can be more than one reason why some machines do not receive policies and it is a completly different issue

Joel Coel

12/12/23, 8:18 PM

I think I figured this out. I had a misconception of what "enforced" means, where I thought it was more like "Enabled" vs "Disabled" but in reality it's more like !important in css, where you use it to override the normal inheritance structure. Still a little more testing to do.

Joel Coel

12/13/23, 3:14 PM

... Okay, I think this is working. I will update the question so it's clearer what was really going on, and then mark this as the answer. One thing still bugs me, though: if both items were marked as "enforced", I'd still expect AD to respect the more-specific policy. I'd like to know what was actually going on there.

Jevgenij Martynenko

12/13/23, 7:07 PM

Enforcement precedence work in reversal comparing to usual apply order: `If there are conflicting settings in GPOs that are enforced at two levels of the hierarchy, the setting enforced furthest from the client prevails. This is a reversal of the usual rule, in which the setting from the nearest-linked GPO would prevail.` https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc758377(v=ws.10)?redirectedfrom=MSDN

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Limit AD user to only login to computer in a specific OU

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.