Requesting an OU Admin package

Use the UD Active Directory OU Request Form to request an Organization Unit (OU) in UD's central Active Directory (AD) structure. The form will open in a separate browser tab or window so that you can refer to this document while completing the form.


Working within an enterprise-level AD as an Organization Unit Administrator (OU Admin) requires special considerations that are unnecessary in smaller AD environments. The following is a list of considerations and suggested procedures to operate as an OU Admin in an Enterprise AD.

Naming conventions

Naming conventions are necessary to preserve namespace and avoid naming collisions. In an organization as large as the University, each instance of the above object types provides a possible conflict. Of equal importance is keeping user, group, and object names as short as possible.

Within UD's centralized Active Directory, Built-in Groups, Built-in user accounts, and Domain user accounts synchronized from central LDAP will not adhere to naming conventions: they will match LDAP entries. Other object types will adhere to different naming conventions as specified below.

  • Created Users must start with your prefix.
  • Created Groups must start with your prefix.
  • Strongly recommend computers and servers start with your prefix.
    • NSS reserves the right to take a computer name from you if there is a more appropriate group to use it. However, we will not do this without first trying to arbitrate the conflict.
    • No name squatting allowed--play nice please.
  • NSS will create GPOs, which will be named with your prefix.
  • SubOUs can be named as you wish.

Unit code

When you request an OU, you should also specify a 2-4 character prefix code. (You can select multiple.) These prefixes should be used on all your OU items.

Using Windows Server 2008, and logging in with their username@domain (userPrincipalName), usernames can be up to 256 characters.

  • Security and Distribution Groups: 64 Characters
  • Organization Units: 64 Characters
  • Fully Qualified Domain Names: 64 Characters
  • Group Policy Objects: 256 Characters

Testing/development domain

We will also maintain a second "development" or "testing" domain. Its purpose is for both OU Admins and enterprise admins to test various features before implementing them. This domain is also a good place to try various settings particularly on group policy.

What we need from you

To request an OU in the WIN domain, you will need to submit the following:
  • 2-4 letter prefix(es) for your OU.
  • A list of Users to be granted OU admin rights.
  • Single contact email for beginning of authority. Any requests for new people to have OU admin rights will require that person's approval.
  • OU name.
  • Name of initial computers.

What you get

  • OU named as requested if available (first come, first served).
  • A group that is named OU_Admin that has full control of the OU. NSS retains control of this group.
  • Requested users get a second account (UDLogonAdmin) that has membership in OU_Admin group.
  • Initial computer accounts created.
  • Email to each user with a link to their passwords and documentation.
  • A copy of all of that in the WIN-DEV domain.
  • An initial blank group policy linked to that OU with permissions granted to the OU_Admin group. Subsequent group policies can be requested.

How to join a computer in the domain

  1. In your OU, create a computer record.
  2. On the computer, attempt to join the domain using your OU admin account.
  3. Reboot.

Restricted groups

By default, any client machine that joins the domain will automatically add the “DOMAIN\Domain Users” group to the Local Users group on that client machine.In our domain, this means that unless you change this setting, any faculty member, staff member, or student at UD can log in to any client machine, which could bypass security measures.

Also by default, your Domain OUAdmin account will not have any administrative rights over client machines in your OU. You would need to log in as the local administrator. As many units have multiple staff members, and some employ students, sharing this local admin password is undesirable.

It's possible to solve both problems using the Restricted Groups setting in a group policy object applied to your client machines. To create a Restricted Group, you need to go into edit mode for a GPO, then access the Restricted Groups node by navigating to Computer Configuration ⇒ Windows Settings ⇒ Security Settings ⇒ Restricted Groups.

After you specify a group to restrict, two ways to control the membership of groups. The first setting controls the membership of a specified group; the second setting control which groups the specified group has membership within. This is an important distinction. 

First, you can use the Members of this group setting, which allows you to control the members of the group that you specify for the policy. The members can include both user and group accounts. When you configure the members of a group, it will overwrite the existing membership of the client machine’s group and replace the members with those specified within the GPO. You might use this setting in the following way: 

  1. In the Group Policy Editor, right-click Restricted Groups.
  2. Click Add Group.
  3. Click Administrators.
  4. Under Members of this group, add the following two members:

    • Administrator
      (i.e., the local administrator of the client computer or server.)

    • DOMAIN\XXXX-Machine Admins
      (We recommend creating a group for this setting even if there’s only one administrator because that person may be unavailable at times.)

  5. Click OK to exit.

Using these settings, the administrator group for any machine within your OU will only include the machine’s local administrator account and the domain group you specified.


If you were to configure this setting and leave the members blank, the local machine’s group would not have any members after the GPO applied to the computer.

The second setting you can use is This group is a member of. This setting allows you to control which other groups the specified group has membership in.

All groups that you configure in this interface must meet the approved group nesting rules. Therefore, you can’t configure a local group to have membership in another group because local groups can’t be placed in Active Directory groups, nor can they be placed in other local groups.

If the list of groups in this section is left blank, it will not remove the specified group from any existing groups—it will just not place it in additional groups. For example, if you create a group called XXXX-Student IT Workers, you would follow these steps to add that group to the restricted groups setting as follows:

Under This group is a member of, add Power Users. Now anyone who has membership in the XXXX-Student IT Workers group will have Power User privileges on any client machine in your OU (enabling them to install software, for example).

Note that using the first setting (i.e., Members of this group) will override anything on the local machine. Using the second setting (i.e., This group is a member of) will keep local group membership as is and simply add the additional groups you specify.