Each delegated OU has a set of role groups which provide a consistent set of permissions within that delegated OU. This page describes those OU role groups.
|On This Page||Related to This Page|
The following table provides a high-level overview of the role groups associated with a given delegated OU. More detail about each role group is provided in a dedicated section for each.
|OU Admins||u_msinf_delou_<delegatedOU>_ouadmins||Administrators of this delegated OU|
|Group Policy Admins||u_msinf_delou_<delegatedOU>_gpadmins||Can create GPOs. Should be used to delegate management of GPOs created. OU admin is required to link any GPO.|
|Computer Joiners||u_msinf_delou_<delegatedOU>_computerjoiners||Can join a computer to the domain. Can create a computer object in this delegated OU.|
|OU Contacts||u_msinf_delou_<delegatedOU>_oucontacts||Individuals who should be contacted regarding this delegated OU. Not admin accounts.|
|DFS Admins||u_msinf_delou_<delegatedOU>_dfsadmins||Administrators of the DFS namespace associated with this delegated OU. Optional–only created when a DFS namespace is requested.|
|Computer Managers||u_msinf_delou_<delegatedOU>_computermanagers||Manage all computers in this delegated OU. Full permissions to AD computer objects.
Note: This is not intended to grant local admin–this is about the AD permissions.
|LAPS Readers||u_msinf_delou_<delegatedOU>_lapsreaders||Can access the local admin password stored in AD for computers in this delegated OU, for those computers which have LAPS enabled.|
|Bitlocker Readers||u_msinf_delou_<delegatedOU>_bitlockerreaders||Can access the Bitlocker recovery key stored in AD for computers in this delegated OU, for those computers which have Bitlocker enabled.|
The default set of AD permissions granted for a delegated OU are documented at /tools-services-support/it-systems-infrastructure/msinf/design/ou-perms/. These specific permissions for the role groups documented here are detailed there, so it is worth reviewing.
OU Admins have the broadest set of permissions within their delegated OU. This generally equates to full AD permissions without a few permissions for objects which are not permitted due to delegated OU design.
An OU Admins role holder must be a sadm Admin UW NetID or be granted an exception. There must be more than one OU Admins.
OU Admins are responsible to resolve issues for objects in their delegated OU, especially for issues related to computers. OU Admins are responsible for reporting compromised systems within a delegated OU to the UW CISO (security AT_ uw.edu) & MI service team (help AT_ uw.edu WITH subject ‘MI NETID domain compromised system’).
OU Admins may make requests to the Microsoft Infrastructure service for custom permissions within their delegated OU or make other requests.
GP Admins have the ability to create a group policy object in the NETID domain.
A GP Admins role holder must be a sadm Admin UW NetID or be granted an exception. There should be more than one GP Admins.
There is no other permission granted by default. This means that an account with only GP Admins can not link a GPO to an OU. It also means that by default an account with only GP Admins can not edit a GPO previously created by someone else which is used within your delegated OU.
Delegated OU customers are strongly encouraged to use the following practices to address this permission gap:
- Pair an OU admin with a GP admin to deploy new group policies. This might either be the same individual with both roles or two individuals.
- ALWAYS add an additional ACE (permission) on every group policy created which grants the edit permission to your GP Admins role group. This allows other GP Admins from your OU to change or fix your group policies. Without this practice you will have to open a request to the Microsoft Infrastructure service team to bail you out.
Additionally, GP Admins should also follow the other documented practices:
- Group Policy naming
- IPSec & WMI filters
- Group Policy Management tools
- Don’t reuse other’s GPOs
- Backup your GPO before editing
- Don’t create a Group Policy Central Store
Computer joiners can join a computer to the domain and create a computer object in this delegated OU.
This role group is appropriate for people or processes which are only on-boarding new computers to your delegated OU. It is not appropriate for fixing problems with on-boarding; Computer Managers or OU Admins are needed for that.
OU Contacts have no AD permissions. When you need to request that Microsoft Infrastructure make a change to the membership of your other delegated OU role groups, we’ll generally only accept requests that come from holders of this role.
OU Contacts are only personal UW NetIDs for the individuals considered authoritative for your delegated OU.
When Microsoft Infrastructure or another delegated OU needs to contact someone regarding issues related to your delegated OU, they will use this role group.
DFS Admins is an optional role group which is only created and granted permissions when NETID DFS Namespace services are requested.
DFS Admins can manage the DFS namespace created for them. Permissions granted are documented in detail at /tools-services-support/it-systems-infrastructure/msinf/ous/dfs/, with additional permissions available to support DFS-R based replication.
DFS Admins must be sadm Admin UW NetIDs, there are no known reasons for exceptions.
Computer Managers have full permissions for all computers in your delegated OU. The permissions granted do *not* include the ‘All Extended Rights’ permission, which means members of this role group can not access the bitlocker recovery key or the LAPS based local admin password. To get those permissions you must also have membership in the appropriate role groups for those.
A Computer Managers role holder must be a sadm Admin UW NetID or be granted an exception.
Computer Managers are useful for fixing computer naming issues, as well as several other tasks associated with AD computer object management.
LAPS Readers can access the local admin password stored in AD for computers in this delegated OU, for those computers which have LAPS enabled. The local admin password for all computers in your delegated OU is sensitive data which deserves a separate role group.
LAPS Readers must be an Admin UW NetID.
Bitlocker Readers can access the Bitlocker recovery key stored in AD for computers in this delegated OU, for those computers which have Bitlocker enabled.
Bitlocker Readers must be an Admin UW NetID.