Delegated OU Practices

Last updated: January 30, 2023
Audience: IT Staff / Technical

These practices apply to users and administrators of delegated OUs. These practices supplement the Microsoft Infrastructure (MI) Policy.

Obtaining a Delegated OU

The general process for obtaining a delegated OU is as follows:

  1. An employee authorized to make IT decisions for a UW organization should submit a request that includes the following info:
    • Requested delegated OU name
    • Initial OU administrators
    • Requested computer namespace reservation(s) (as described below)
    • Department/organization name
    • The name and contact info for a computing director or equivalent for your department/organization
    • An estimate of the number of computers and GPOs
    • Note that this form may prompt you for UW NetID credentials.
  2. UW-IT reviews the request for reasonableness, checking authority and requested names.
  3. When all is in order, the OU will be created, delegated, and the associated details recorded/published.
  • If the initial OU administrators do not have Admin UW NetIDs, UW-IT will help facilitate obtaining them
  • An email list u_msinf_delou_<ou>_oucontacts that can be used to contact the OU admins will be created
  • UW-IT will provide any orientation assistance needed

Delegated OU Naming

Names for delegated OUs should be chosen carefully.

  • The person determining the name should be a computing director or person in an equivalent role (as assigned by the VP, Dean, Chair, etc. as appropriate to the unit).
  • Names are available on a first-come, first-served basis.
  • Names should be short and without special characters, because other names and technologies used will leverage the delegated OU name.

Delegated OU Administrator Assignment

Valid administrators for the delegated OU will designated by the computing director or person in an equivalent role established for the organization.

  • Each delegated OU MUST have more than one OU admin.
  • UW-IT will validate the selected people (or non-people) ensuring that the appropriate Admin NetID (or Application NetID or gMSA) is delegated permissions. Shared UW NetIDs MUST NOT be OU admins.
  • Permissions to any given delegated OU will be granted to u_msinf_delou_<delegated OU name>_ouadmins.

UW-IT will also:

  • Ensure that the designated OU admins are on the mi_announce email list.
  • Ensure that the mailing list u_msinf_delou_<ou>_oucontacts is on the managedBy attribute for the delegated OU.
  • Ensure proper acclimatization for these OU admins, and provide the right framework for smooth operations and troubleshooting support.

OU admins MAY request that the MI service delegate directory permissions within their OU to UW NetIDs that are not OU admins, e.g. the ability to create computer objects. Depending on the scope of the use case, these UW NetIDs MAY be Personal, Admin, Shared, Application UW NetIDs, or gMSAs. All directory permission requests are at the discretion of the MI service.

Computers in Your Delegated OU

Computer Account Creation

Prior to joining a computer to the NETID domain, Windows administrators SHOULD pre-create a new computer account for that computer (e.g. via Active Directory Users & Computers). Failure to pre-create the computer account when joining a computer to the NETID domain, will result in the Unclaimed Computers OU Group Policy settings which are not pleasant.

Computer Naming

Computer naming is managed for consistency, avoid naming collisions, and ease contention over a variety of things based on computer names. While this section is entitled computer naming, it can affect more than just computer objects–group managed service accounts (gMSAs) and users are potentially also affected. Any object that includes service principal names (SPNs) is also potentially in the scope of this section. Where you see “hostname” or “computer”, SPNs are also intended. In general, computer naming spans a number of attributes that include:

  • dnsHostname
  • samAccountName (on computers and gMSAs, not on users)
  • servicePrincipalName

Computer Naming Rules:

  • New hostnames (and SPNs) that fall under an already accepted computer namespace reservation are considered reserved by the organization with the accepted namespace reservation.
  • Existing computers (and SPNs) MAY be migrated into the NETID domain with whatever name they currently have, as long as it doesn’t violate an existing approved namespace reservation or collide with the hostname (or SPN) of an existing NETID computer
  • New computers and SPNs (i.e. computers not migrated in) MUST have a name that conforms to a reserved computer namespace belonging to the appropriate delegated OU.

A default computer namespace will be given to each OU in the NETID domain, based on the algorithm:

    <delegated OU name>-<variable>

e.g. pot-barkills might be a computer in the pottery delegated OU used by barkills.

Additional computer namespace reservations CAN be requested by delegated OUs. Computer namespace reservations have the following properties:

  • MUST include a wildcard (*), denoting more than one potential computer name
  • the wildcard SHOULD come last in the reservation
  • a hyphen SHOULD precede the wildcard
  • SHOULD be short, as Windows hostnames MUST be fewer than 15 characters

All computer namespace reservation requests follow a process, as follows:

  1. Request is submitted to UW-IT (via initial OU request form or help ticket)
  2. MI vets the request for collisions against:
    • existing NETID computers, gMSAs, and SPNs
    • existing computer namespace reservations
  3. Collisions with existing computers are communicated to the requestor, and the requestor can do one of the following:
    • accept those existing computer collisions as exceptions, or
    • choose a different namespace, or
    • talk with the other delegated OU to work something out
  4. When all is in order, MI records and publishes the computer namespace reservations, along with a date of approval to help eliminate confusion and resolve disputes.

For the purposes of computer name dispute and resolution:

  • Each organization with a delegated OU MAY challenge a computer name, gMSA, or SPN in use in another delegated OU, if it should fail to meet these requirements or cause some other problem.
  • The MI service, in consultation with the service manager, will resolve any such issues.
  • The MI service MAY revoke any computer name.
  • The MI service SHOULD only revoke a name if there is a violation of these computer namespace rules which is not addressed with a mutually agreeable solution in a timely manner.

Hostname Resolution

All computers in the NETID domain CAN use the campus WINS server to ensure that name resolution of down-level services works. All computers in the NETID domain SHOULD use authoritative DNS servers to ensure common DNS name resolution.

Hostname DNS Zone

Servers in the NETID domain SHOULD be placed in whatever DNS zone the system operators currently use.

Workstations MAY also be placed in whatever DNS zone the system operators currently use. MI also provides a DDNS zone/service for workstations, intended for DHCP based clients, which computers in the NETID domain MAY optionally make use of.

All computers in the NETID domain MUST have a valid, resolvable dnsHostname value. Computer in the NETID domain MUST NOT have a dnsHostname value of *.netid.washington.edu. Put another way, any DNS zone is a valid DNS suffix for a computer in the NETID domain, except netid.washington.edu.

UW-IT will NOT set any values on the msDS-allowedDnsSuffixes attribute that restricts what DNS suffixes are valid in the domain.

Service Principal Names

Any delegated OU admin MAY make a request for service principal names (SPNs) that differ from a computer’s hostname or fully qualified DNS name. The MIS service MUST vet these requests against existing computer hostnames and computer namespace reservations prior to assigning the requested non-default SPN.

Group Managed Service Accounts (gMSAs)

OU Admins MAY create and delete gMSAs in their delegated OU.

Delegated OUs MUST name gMSAs using their computer namespace reservation. The DNSHostName and SPNs on gMSAs SHOULD also conform to the computer naming guidelines.

OU Admins SHOULD use a group to specify which computers are allowed to retrieve the managed password.

Unless there is a compelling business reason, OU Admins SHOULD NOT set the password change interval (from the default of 30 days) when creating a gMSA.

OU Admins SHOULD delete unused gMSAs. When a gMSA is no longer used on a computer, OU Admins SHOULD remove that computer from the group allowed to retrieve that gMSA password and also remove the cached gMSA password from that computer.

Group Policy

Group Policy Naming

All group policy objects, WMI filters, IPSec policy names SHOULD begin with the delegated OU name of the organization creating and managing that GPO/WMI filter/IPSec policy, followed by a colon, then whatever verbose name desired. In other words, GPO/WMI filter/IPSec policy names SHOULD follow the form:

<delegated OU name>: *

Group Policy Creation

When using GPMC to create or modify a group policy, be sure that your u_msinf_delou_<delegated OU name>_gpadmins group is granted the “Edit settings, delete, modify security” permissions. To do this, select the “Delegation” tab for the policy object and click the add button. Enter the u_msinf_delou_<delegated OU name>_gpadmins group name and click OK. Then select the permission from the permissions dialog box. This ensures that another delegated OU admin from your organization can manage the policy if the person who created it is unavailable.

Group Policy Delegation

Group policy administration privileges will be delegated as follows:

  1. The GP administrators for a given organization WILL initially be the delegated OU administrators.
  2. UW-IT WILL validate any potential GP administrator’s UW employee status.
  3. The MI service will delegate group policy privileges by:
    1. Creating a GP admin group for the OU named:

      u_msinf_delou_<delegated OU name>_gpadmins

    2. Ensuring that the appropriate Admin NetID(s) are members of the OU’s GP admin group, i.e. the MI service will manage membership of the OU’s GP admin group.
    3. Placing the OU’s GP admin group into the ‘NETID\Group Policy Creator Owners’ group, allowing members to create group policy objects, and manage those group policy objects they have created, delegating management of those GPOs as appropriate.
  4. Existing delegated OU administrators CAN submit requests to the MI service (via help ticket) for additional employees that should be granted GP administrator privileges for their organization.

Group Policy Management

GP administrators are encouraged to follow these practices:

  • With respect to IPSec policy and WMI filter delegated management, given the associated delegation constraints and implications (see http://technet.microsoft.com/en-us/library/cc755942(WS.10).aspx and http://support.microsoft.com/kb/329194), delegated OU administrators SHOULD submit requests that MI create and modify any IPSec filters and WMI filters needed.
    • In cases where a high volume of changes are needed, the MI service SHOULD delegate individual objects.
    • GP administrators are encouraged to use computer local IPSec filters or the Windows Firewall, instead of group policy based IPSec filters.
  • All GP administrators MUST use the latest group policy management tools released from Microsoft. GP administrators who don’t follow this policy MAY lose their GP administrator privileges.
  • All GP administrators SHOULD back up a GPO prior to any edit.
    • If a GP administrator requires the MI service provide assistance in restoring a GPO, at no charge we can provide a copy from the 1st or 15th of the month. Recovery effort beyond that WILL be charged on a time and materials basis.
  • GP administrators SHOULD NOT link to a GPO, WMI filter, or IPSec policy created and owned by another organization.
    • If you do re-use another organization’s GPO, WMI filter, or IPSec policy, you MUST make sure both organization’s GP administrators know about this and plan to follow some mutually agreeable change management process.
  • GP administrators MAY copy settings from a GPO, WMI filter, or IPSec policy owned by another organization.
  • Do not create a Group Policy Central Store. A GP central store is not appropriate for a shared AD environment such as the NETID domain. Instead, copy any needed administrative templates to a delegated-OU-joined computer, placing them into the %windir%\PolicyDefinitions folder. Note that some ADMX installers copy the files into subfolders. If this occurs you will need to copy the ADMX files to the PolicyDefinitions folder and the ADML files to the en-US folder.

Security

System Security

  • All systems using delegated OU services MUST meet the UW Information Security Standards (see 2.4, 2.5, and 2.6). All other relevant university IT policy and security standards MUST be met.
  • All systems joined to the NETID domain MUST be running a current anti-virus product.
    • The system owner MUST monitor alerts from the product and react to each one in a timely fashion. Outbreaks of more than 15 computers in a 24 hour period of a particular virus or other malware SHOULD be handled as described under Compromised Systems below.
  • Where practical, a central patching mechanism, such as Microsoft WSUS, SHOULD be used to ensure that systems joined to the NETID domain and applications on those systems stay current on security updates.
    • When this isn’t practical or desirable, alternate mechanisms MUST be in place to mitigate the risk of a system being compromised due to a security vulnerability.
  • System owners SHOULD avoid using the groups “Domain Users” or “Authenticated Users” on an ACL unless they really mean all 600,000+ accounts in the NETID domain. OU admins SHOULD use a different group to represent all the users in their equivalent space and encourage system owners to use that group.

Compromised Systems

Should a system or systems joined to the NETID domain become compromised, the OU admin for those systems MUST assume responsibility for ensuring the systems are properly remediated and, depending on the nature and extent of the compromise, SHOULD notify others of the incident, including the UW Chief Information Security Officer (via UW Security Operations, security@uw.edu) and the MI service team (via UW-IT Help, help@uw.edu, subject: “MI NETID domain compromised system”).