Administrating a delegated OU is a little different than administrating your own departmental Windows domain. In specific, some of the tools you use to get administrative work done are different. And you may also need to adapt some of your practices.
This document provides an overview of how an OU administrator would complete common tasks and the tools needed to do them.
A Tool-Centric View
Within a Delegated OU, you’d use the following tools for these tasks.
- Active Directory Users & Computers (ADUC)
- create/manage/move computers
- create/rename/move OUs
- Group Policy Management Console (GPMC)
- create/manage group policy objects (GPOs)
- link GPOs to your OUs
- Groups Web Service
- create/manage groups
- UW NetID Support Tool
- manage NETID user properties
- view NETID user properties
The Chicken and the Egg & Changing How You Do Admin Business
The most common question asked after getting a delegated OU is “how do I add the first computer?” I can’t run ADUC against netid.washington.edu without a computer already in the domain, but to get a computer in, I need one already in. Sounds kinda like the age-old chicken and egg problem, huh?
The resolution to this conundrum is highly relevant to another important topic, which is adapting how you go about making use of the common Windows admin tools listed above. Assuming your departmental Windows domain has a trust with netid.washington.edu, and you’ve granted your netid\sadm_<netid> account permissions on your departmental computer, you can run ADUC and GPMC using your netid\sadm_<netid> account. To do that, you’ll need to become familiar with the RunAs capability. If you are on a computer that is Vista or newer, you may also need to do a little dance with the UAC elevation protections so the tool is running in an elevated/local administrator context.
If you don’t have a trust to netid.washington.edu, no worries. Just send in a help ticket to help@uw.edu, and we’ll create that first computer account for you.
Becoming familiar with RunAs is an important skill as you work within a Delegated OU, and begin using your Admin UW NetID for OU administration tasks, but your personal UW NetID for other tasks.
Other Adaptations
GPMC:
If you do run GPMC against netid.washington.edu from a computer that isn’t in netid.washington.edu there are a few things that won’t be accurate. For example, the list of IPSec rules will correspond to the IPSec rules in the domain of your computer, not the IPSec rules in netid.washington.edu. For this reason, you may want to limit your GPMC use to computers in the netid.washington.edu domain.
ADUC:
Many Windows admins are used to using ADUC for groups, users, and computer management. And for OUs. And if you’re really behind with Windows Server OSes, you might still be using ADUC for group policy management. That changes within a Delegated OU, where you only use ADUC for computer and OU management.
GWS & UW NetID Support Tool:
As web-based tools, you will not use your Admin UW NetID to login to these. Instead, you’ll use your personal UW NetID. If you make use of a function within these tools that requires a higher level of assurance, you’ll be re-challenged for 2-factor authentication. Only your personal UW NetID is associated with the Entrust token, so it is used with these tools. The common risks that Admin UW NetIDs are designed to mitigate are not likely to be present with these tools.
Bulk changes:
Within your departmental domain, you have the ability to script changes to multiple users or groups. This ability is partially lost when moving to a delegated OU. There are some bulk modification capabilities in the Groups Web Service UI (rename & move), and you can write code that does bulk group changes against the GWS programmatic API. However, there currently isn’t any ability to do bulk changes to your NETID users via the UW NetID Support Tool. If this is a significant problem for you, then please don’t hesitate to let us know. By speaking up, you help to inform priorities and it’s possible we’ll be able to help you meet a short-term task.
Skipping manual recreation of your existing domain groups:
There are ways to bulk import your existing domain groups into the UW Groups Service (and therefore into the netid.washington.edu domain). Send a request to help@uw.edu and ask for help from the Groups Service.
Replacing Domain Computers and Domain Users with departmentally appropriate groups:
In your departmental Windows domain, Domain Computers and Domain Users are much smaller groups limited to your department. Within a Delegated OU, these groups include a lot more computers and users respectively. But you probably find the departmentally-scoped meaning of these groups very useful. So there is a solution for both:
- See Delegated OU Computer Groups for the departmental computer solution.
- The UW Groups Service has the ability to create groups whose membership is based on institutional data, which is automatically updated as institutional data changes. Several departments have piloted department employee user groups leveraging appointing department funding source definitions within the data warehouse. We expect that there will soon be a self-delegated solution so that anyone can create these groups, but in the meantime, you can find out more about this provisional solution and how to proceed here.
Service Principal Names (SPNs) and setspn.exe:
There are some SPNs that customers can set and others that you will need to ask the UW Windows Infrastructure service to set for you. For more information about this, see Delegated Service Principal Name values.
If you need our help, submit a request ticket via help@uw.edu with “NETID domain SPN request” in the subject line. UW-IT will vet the request against existing hostnames and reservations and then set the value. If you have a frequent need to do this, we’d love to talk to you about how to expedite this.
Applying a password policy:
See /tools-services-support/it-systems-infrastructure/msinf/other-help/faq/ou-guidance/#passwordPolicy.
Recovering local admin privs without Domain Admin:
See /tools-services-support/it-systems-infrastructure/msinf/other-help/faq/ou-guidance/#recoverLocalAdmin.
Applying Group Policy to your users:
You’ll need to leverage loopback group policy mode. This applies the User section of a GPO as you want, and to apply it, you link it to the OU of the computer the user is logging into. See /tools-services-support/it-systems-infrastructure/msinf/design/arch/users/workarounds/#loopback for details. You’ll see solutions for login scripts, home directories, and roaming profiles there too that leverage loopback. Note that you can directly assign home directory and profile path via the UW NetID Support Tool.