Delegated OU Practices


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.

Delegated OU Naming

Names for delegated OUs should be chosen carefully.

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. UW-IT will also: 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: Computer Naming Rules: 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: 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:

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:

Security

System Security

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").