Active Directory: how to lock out certain logons on certain machines

Open active directory users and groups as a suitably privileged user and browse to the OU you are going to establish the policy in. All sub-OUs contained within the OU you are applying policy to, will also be affected by this policy.

Create a new group in or around this OU. I do this so I remember that they exist when browsing the directory. You could just as easily place them in some suitable container elsewhere in the directory.
Putting the group in the affected OU makes it easier to delegate the management of the policy and those affected by it to other users.

CREATIVE trusts other domains for authentication so I use a local group for this activity, as it is able to contain references to objects in these trusted domains.
I would normally name the group something obvious that relates back to the scope of the policy I am implementing. Among other things, this will help avoid object naming conflicts.
In a larger organisation something fairly systematic would have to be set up.

Any member of this group will be affected by this policy when interacting with the objects contained in the OU. If the policy is implemented too high up a directory tree (ironically this means closer to the root), the effect may be broader than you plan.
The CREATIVE directory contains OUs for a number of labs or lab-like groupings of computers which have their own no-access groups and policies. This allows us to restrict access to particular resources without affecting a person's access to others.

Once your group has been made, open the properties dialogue for the OU you are using and select the Group Policy tab.

Create a new policy, giving it a suitably easy to remember what you were thinking about type name.

The policy can be switched on and off in the Group Policy tab in the OU properties dialogue. If you want it to take effect, make sure it is switched on.

Note the Block policy inheritance check box at the bottom of this window. This allows you to block the effects of any group policy defined higher up the directory structure.
This could be used as a way of exempting people and computers from the effect of a lockout policy.

You modify the details of the policy by clicking edit.

There is a large number of policy items to choose from -so much power and control! However, I am only going to use one of these -a simple user rights policy called Deny Log on Locally.
This has fairly obvious effects in the context of a person trying to log onto a computer.

To use a polcy, you need to switch it on by affirming your desire to define an instance of the policy. Checking the define this policy box allows you the opportunity to add users and or groups to the list of those who will be denied the ability to log on locally to the computers hosted in the OU to which this policy is applied.

You could insert all the users you want to deny access here, but it would mean that modifying this list would involve editing policy each time you wanted to make a change, and this is not as easy as modifying group memberships. Things like group membership can be managed easily with scripts.

Why would you want to script this sort of thing?:

Click apply or OK to put the policy in place and close the Group Policy editor.