Purpose
This proposal establishes a naming policy for top-level Delegated OUs in the NETID domain (i.e. MI). This proposal should address what are acceptable names for Delegated OUs. Such a proposal is necessary prior to allowing multiple organizations to join this domain. This proposal addresses C19 on the MI Roadmap Feature list, https://sharepoint.washington.edu/windows/Lists/MI%20Roadmap%20Features/byPriorityUndone.aspx.
Additionally, this proposal establishes how the assignment of delegated permissions to a Delegated OU happens. This proposal should address who are acceptable OU administrators, how authority to select OU admins will be vetted, and describe the mechanism used to assign the permissions to manage a Delegated OU. This proposal address C18 on the MI Roadmap Feature list, https://sharepoint.washington.edu/windows/Lists/MI%20Roadmap%20Features/byPriorityUndone.aspx.
Assumptions
Multiple organizations will need delegated OUs in the NETID domain. We expect the number of organizations wanting this to be about 30-40.
We expect there to be some nominal charge for a delegated OU.
Delegated OU names will be re-used as a component in other MI naming policies, so brevity is a good feature.
OU names are not highly visible to clients.
Only the top-level OU is subject to this policy, i.e. only those OUs that are direct children of OU=Delegated,DC=netid,DC=washington,DC=edu. Sub OUs under the top-level OU have no naming restrictions.
Only people who are qualified to manage Windows and Active Directory resources should be granted permissions to an organization’s Delegated OU. Only admin NetIDs (and application NetIDs for non-people) should be granted this level of permission given the risk segmentation profile.
Design Considerations
LDAP protocol character restrictions are relevant. Some special characters may require escaping to be handled properly, so their use is often avoided.
Only one OU can have any given name. But as long as the names are not very short abbreviations this should not be a significant design constraint.
Must be less than 64 characters, per AD schema requirements.
Some organizations will need to hard-code their OU name into tools to provide services. This means that a rename at a later point is undesirable, but not unsurmountable.
Some group names, such as the one used to grant delegation permissions, will be derived from the OU name, so the name should not violate the Group Service guidelines for naming components (see #3 of https://wiki.cac.washington.edu/display/groups/UW+Group+Naming+Plan).
Someone in authority within the organization represented by a given Delegated OU should suggest and authorize all accounts given delegation permission over that Delegated OU. Additionally, MI Engineering should verify the other pre-requisites, and ensure that other MI relevant notification and support processes include all people granted permissions to a Delegated OU.
Discussion
The lack of an centrally managed UW organization naming registry means this type of problem must be solved by each service that deals with organizational names. The future emergence of a UW Org Registry could impact the solution chosen here, and could result in some amount of churn as OUs are renamed to match. At present, there is no project on the books to create a UW Org Registry, but the need for such a resource is apparent, and will eventually be realized.
One option would be to allow any name on a first-come first-served basis, given the above constraints and considerations. This would allow a great deal of flexibility, but could lead to some conflicts if abbreviations are used. This option would probably need to provide a vetting process to ensure the requestor is authorized to represent the name chosen.
Another option would be to leverage the DNS zone architecture, naming OUs by the significant portion of the DNS zone granted to the requesting organization. This option would still need to address whether the requestor is authorized to represent that organization. One significant issue with this option is that many organizations do not have a DNS zone, and do not want arbitrarily request one to meet this requirement.
Another option would be to leverage the Groups Service’s uw stem home group vetting process, where a given organization’s Delegated OU name would be the same as their UW stem home group. This would eliminate the need for another service vetting names and authorities, and would have neatly meet the group naming design constraint. A side-effect would be that some organizations which don’t currently have uw stem home groups would need to request them prior to getting a MI Delegated OU, but this is a positive side-effect from the MI service perspective. One problem with this is that some organizations don’t manage just their organization’s IT services, but manage more than their organization. For example, UW Technology’s Nebula service manages many organization’s IT services. This may introduce some confusion, but the Group Service is flexible enough to address this. At present, Nebula is eligible for a top level UW stem, and it would not make sense to use the UW Technology stem or the stems for the many other organization which Nebula manages which is also eligible. This problem might be addressed by exceptions in the Group Service or in the MI policy. One possible advantage this option has is that UW stem home groups have some chance of being significant in a future UW Org Registry, so there’s a possibility that future impacts might be less significant.
A final option would be to leverage a process like the Groups Service’s uw stem home group vetting process, where if the organization has been through that process, that work could be re-used, but wouldn’t have to be, and if they haven’t, then that organization would be taken through a similar process, but it wouldn’t have to result in a UW stem home group, nor have any implications for the Groups Service. This option doesn’t lock organizations into the name chosen for the uw stem process, and also doesn’t arbitrarily limit the delegated OU naming process by requirements within the Groups Service. In other words, a computing director or equivalent would be recognized as authorized to define the OU name, and designate the OU admins. Some discussion about the name and possible alternatives might happen, but ultimately the choice would be left to the computing director, and names would be available on a first-come, first-served basis.
The assumptions and design considerations for who are acceptable OU administrators and how authority will be vetted, suggest that the mechanism used to assign the permissions and authorization to manage a Delegated OU be managed by MI Engineering, based upon recommendation by the recognized authorities for a given organization. That is to say, a recognized authority for a given organization will suggest/authorize individuals to MI. MI Engineering will validate their status, and add the appropriate admin NetID to the appropriate group, and assign that group permissions to the delegated OU. Should the individual not currently have an admin NetID, then MI Engineering will guide them through the process of getting one. MI Engineering manages the group, and takes future change suggestions through the same process.
Proposed Policy and Process
All Delegated OU names should go through a vetting process where a computing director or person in an equivalent role (as assigned by the VP, Dean, Chair, etc. as appropriate to the unit) are recognized as authorized to determine the appropriate name, where names are available on a first-come, first-served basis.
Permissions to any given Delegated OU will be granted to u_windowsinfrastructure_<chosen OU name>_ouadmins. The permissions granted are documented at http://www.netid.washington.edu/documentation/delegPerms.aspx.
The computing director or person in an equivalent role established for an organization’s delegated OU will designate valid administrators for the delegated OU. MI Engineering will validate the selected people (or non-people) ensuring that the appropriate admin NetID (or application NetID) is put in the group designated above.
Additionally, MI Engineering will ensure that the designated OU admins are on the MI_announce email list, and will work to make sure that an appropriate “contact” (i.e. with email address) is on the managedBy attribute for the delegated OU. At this time, MI Engineering will also take other steps with the designated OU administrators to ensure proper acclimatization within MI, and provide the right framework for smooth operations and troubleshooting support.
Example Use Cases
The College of Pottery asks for a delegated OU. Mr. Clay Vase is the computing director for the College of Pottery, and he decides he’s like to use copott for the name. This name is not previously taken, so it is accepted. Clay designates Ms. Glass Shard, UW NetID of glasshard as the OU administrator. MI Engineering creates a delegated OU with a name of copott at OU=copott,OU=Delegated,DC=netid,DC=washington,DC=edu. MI Engineering verifies that Glass meets all requirements, and adds sadm_glasshard to a newly created group u_windowsinfrastructure_copott_ouadmins. u_windowsinfrastructure_copott_ouadmins is granted the correct permissions to the copott delegated OU.
Outcome
This proposal was implemented with the release of Delegated OUs