Hints, Tips, Tricks and
Gotchas
of OU Administration
This page is a list of short tips, tricks and workarounds that may be useful to OU administrators as they move more deeply into the AD environment. For some walkthroughs of basic administrative tasks, see this page.
If you have any suggestions for topics that should be covered here, please send email.
Organizational Unit (OU) design and administration
- Putting machines in an OU does NOT automatically change who its administrators are (but see below)
- Some suggestions for organizing your OU.
- Adding a client system to an OU from the command line using NETDOM.EXE
Group Policy Issues
- Finally! An explanation of "Loopback Processing" and why you need to use it at Yale.
- Using Group Policy to control group membership on client systems
- Use GPRESULT to test and track application of group policy
- Enable "user environment debug logging" of group policy application for detailed tracking of Ggroup Policy application.
- Controlling application of Group Policy by "filtering" with ACL's
"Irrational" Client Behavior
Miscellaneous Useful Tidbits
Organizational Unit (OU) Design and Administration
Putting machines in an OU does NOT automatically change who its administrators are.
It makes sense in some ways that if a computer is in an OU and that OU has its administrative authority delegated to a user or group, then the machine should recognize that authority and allow OU Admins to have admin control over the machines.
This is not the case, however, so OU admins must change the membership of the local "Administrators" group on each workstation to reflect who should have authority over that machine.
By default, when a workstation joins the Yale AD, it will have the local "Administrator" user and the "Domain Admins" group from the yu.yale.edu domain placed in its Administrators group. This is the same as with NT 4.
It is recommended that OU administrators create a GLOBAL group within their OU in order to carry admin authority. A suggested name for this group is "<OU name> machine admins".
Once that group is created, place the accounts of people who should have administrative authority over all machines in the OU into that new group and then add that group to the local "Administrators" group on client machines.
It is very important to only add groups to the "Administrators" group for this purpose and NOT individual users because, when the user leaves, they would have to be individually removed from every machine so please use a group even if there is only a single administrator for your machines.
NOTEL: To find out how to fix this with Group Policy, see below.
Some suggestions for organizing your Organizational Unit (OU).
Logical organization of an OU will be increasingly important as more machines are moved into it. While each area is unique, the number of different types of objects that an OU can contain is quite large so here are some suggestions on how to set things up.
Some areas are creating a sub-OU called "Computers" and putting all computers in it. This has the advantage that there isn't a commingling of computers, groups, and other objects at the top level of your OU.
Others are dividing their OU's by sub-group. For instance, a department's OU could have sub-OU's for each functional group that it contains such as administrative and research groups. The machines from each group's users are placed in the appropriate OU so that they are together and can have GPO's applied to them.
Feedback is requested on pros and cons of different ways of organizing OU's so that a "best practices" document can be created to use as a guide for new administrators.
Adding a client system to an OU from the command line using NETDOM.EXE
NETDOM is a powerful tool for automating domain membership activity on client systems. Here is how to create a computer account in a desired OU from the command line. NETDOM.EXE found in the \support\tools\support directory on the Windows 2000 Professional CD, is part of the Windows 2000 resource kit and is also on the W2K support tools disk.
To add a computer account to a specified OU via the command line, use NETDOM with a command line like this.
(The complete command line has been broken at each section to show detail.)
NETDOM ADD <machine>
/Domain:yu.yale.edu
/UserD:<netid>@yu.yale.edu
/PasswordD:*
/OU:OU=<target-ou>,OU=<parent-ou-name>,DC=yu,DC=yale,DC=eduWhere:
- <machine> is the name of the computer object to be created in the domain
- <netid> is the netid of a valid domain user (to authenticate to the DC)
- <target-OU> is the name of the sub-OU the machine is to be created in
- <parent-ou-name> is the name of the OU "above" <target-OU>
In this example, NETDOM will prompt for the password of the user specified.
The line specifying the OU is the most critical. For example:
/OU:OU=Computers,OU=MED,DC=yu,DC=yale,DC=edu
would create a computer object in the OU "Computers" which is under the top-level OU named "MED" in the yu.yale.edu domain.
If your OU name has more than one word in it, specify it in quotation marks like this:
OU="Workstation Support Services"
Documentation on automating the creation of computer accounts in a domain is in Microsoft Knowledge base article Q222525 which is available on the web or as part of Technet.
Knowledge base article Q150493 describes how to use it to join a machine to a domain from the command line.
The combination of these two capabilities of NETDOM means that it's possible to script the entire process of adding a new client to the domain.
[ Kudos to Dorothy Ortale and Adriene Nazaretian at the School of Medicine for this one. ]
Group Policy Issues
Finally! An explanation of "Loopback Processing" and why you need to use it at Yale.
When a Group Policy object is created and applied to an OU at Yale, you will discover that the "user" settings in that GPO aren't applied to people who log on to machines that are covered by that policy. The reason for this is that group policy user settings come from the OU that the user's account is in and computer settings come from the OU that the computer is in.
The net effect of this is that user group policy settings are ignored on client systems at Yale.
To override this behavior, we use "loopback processing" which makes sure that the user-side settings of a GPO are applied to any user who logs onto that machine, whether or not they have user settings from another GPO.
To set this, open the group policy editor and then open "Administrative Templates -> System -> Group Policy". Find the setting labeled "User Group Policy loopback processing mode". It is disabled by default. Enable this setting, and set the mode to "Replace" (the choices are "Replace" or "Merge"). Then save the changes and reboot the client. After the client refreshes the machine group policy settings (either via reboot or the normal GP update cycle), users logging in should see the user-level settings from the GPO take effect.
Using Group Policy to control group membership on client systems
To control the membership of specified groups on client systems, you can use a group policy option called "Restricted Groups". To do this, right-click on "restricted groups" and select "Add Group". Enter the name of the group on the client that you wish to control (like "Administrators"). Once it appears on the right, double-click to get a window where you can specify "Members of this Group" or "This Group is a Member of". You can use the "Add" and "Remove" buttons to set it so that group policy will change the specified group's membership on the client to match the settings you specify. Any entries in the group that are not there will be added, and any "extra" members will be removed. you can make multiple entries to control any number of groups on the client.
Note that the group specified must already exist on the client in order for this to work.
Use GPRESULT to test and track application of group policy
GPRESULT, a tool provided with the Windows 2000 Resource Kit (available as part of Technet), displays information about a user and computer's domain and group memberships as well as itemizing where all group-policy related settings were applied.
This is a very important tool to use when testing a new group policy or attempting to diagnose problems with policies not being applied incorrectly.
To view a sample report from GPRESULT, click here.
Enable "user environment debug logging" of group policy application for detailed tracking of GPO application.
There is a registry key that will enable creation of a log file recording detailed activity during the application of Group Policy on a machine:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
Value: UserEnvDebugLevel
Type : REG_DWORD
Data : 10002 (Hex)The log file will be created as %SystemRoot%\Debug\UserMode\userenv.log.
This registry key is documented in Knowledge Base article Q221833.
Controlling application of Group Policy by "filtering" with ACL's
There are many cases where it's useful to create a Group Policy Object (GPO) that only applies to designated groups of users. For example, a GPO could be created that applies to ordinary users but not to administrators, or one of several different policies could be used depending on the group membership of a user.
In Windows 2000, this "filtering" is done by modifying the ACL on the GPO so that the group(s) that should NOT have the policy applied are listed in the ACL with the "deny" attribute checked next to "Apply Group Policy".
Note that under Windows 2000 (and Windows NT) the presence of a "deny" entry in any ACL will always override any other entry in the ACL that grants access. For example, if you allow "Everyone" to take some action on an object and a person is also a member of a group that has that same access denied by a specific "deny" entry, they will not be allowed to take that action.
In the example below, users in the group "Workstation Support Staff" will not have the listed policy applied to them when they log on.
"Irrational" Client Behavior
Systems will change their DNS suffix when joining a domain
By design, Windows 2000 clients will change their DNS suffix (the part of the fully-qualified DNS name that's after the hostname) to match the name of the domain. For example, when a machine named "space.physics.yale.edu" joins the new AD domain (which is named "yu.yale.edu"), it will change its DNS name to "space.yu.yale.edu".
This behavior is by design and matches up with Microsoft's intent that the DNS and active directory name spaces be one and the same. Yale does not follow this model.
Note that this does not change the name the machine is officially registered with, just what the machine "thinks" its name is.
It is possible to override the DNS suffix via group policy by setting a new DNS suffix. Every machine that is touched by this policy will pick up the new DNS suffix and thus change back to the "correct" one.
Miscellaneous Useful Tidbits
Showing more detail during startup, shutdown, logon and logoff
To give more detail in the small dialog that is shown during startup, shutdown, logon and logoff cycles, enable the group policy setting "Verbose vs normal status messages" under Computer Configuration :: Administrative Templates :: System.
This will display additional information such as the names of GPO's being applied, what logon/off scripts are being executed, etc. This is very useful to see what is going on during long startup/shutdown/logon/logoff sequences.
For even more detail, turn on "User Environment Debug Logging" as documented in Knowledge base article Q221833. This will write a log file recording group policy application and other information.
Recommended Audit Policy Settings
Below is a screen shot of the recommended audit policy settings for Windows 2000 Servers and clients. This is configured via Group Policy.
Note that we don't need to enable everything in order to get a good log. Mainly we want to know about all logon events, and most of the rest is only looking for failures -- we're more interested in a failed attempt to change group membership, for example, than in successful changes because it might indicate someone probing the boundaries of their account.
Resist the temptation to turn all auditing on, especially process tracking. That only produces logs which are too big and/or roll over too rapidly to be useful.
Ken Hoover of ITS Workstation Support has a perl script which summarizes user logon/logoff activity on Windows NT and 2000 machines. Click here to read more about it.
on during long startup/shutdown/logon/logoff sequences.For even more detail, turn on "User Environment Debug Logging" as documented in Knowledge base article Q221833. This will write a log file recording group policy application and other information.
Recommended Audit Policy Settings
Below is a screen shot of the recommended audit policy settings for Windows 2000 Servers and clients. This is configured via Group Policy.
Note that we don't need to enable everything in order to get a good log. Mainly we want to know about all logon events, and most of the rest is only looking for failures -- we're more interested in a failed attempt to change group membership, for example, than in successful changes because it might indicate someone probing the boundaries of their account.
Resist the temptation to turn all auditing on, especially process tracking. That only produces logs which are too big and/or roll over too rapidly to be useful.
Ken Hoover of ITS Workstation Support has a perl script which summarizes user logon/logoff activity on Windows NT and 2000 machines. Click here to read more about it.
