Purpose
This proposal establishes a naming policy for group policy objects (GPOs) in the NETID domain (i.e. MI). This proposal should address what are acceptable names for group policy objects. Such a proposal is necessary prior to allowing multiple organizations to join this domain. This proposal addresses C17 on the MI Roadmap Feature list, https://sharepoint.washington.edu/windows/Lists/MI%20Roadmap%20Features/byPriorityUndone.aspx.
Additionally, this proposal establishes how group policy objects will be delegated in the NETID domain (i.e. MI) and any requirements regarding how they are managed. This proposal should address who can create new group policy objects, and change management processes specific to group policy in MI. Such a proposal is necessary prior to allowing multiple organizations to join this domain. This proposal is related to O01 on the MI Roadmap Feature list, https://sharepoint.washington.edu/windows/Lists/MI%20Roadmap%20Features/byPriorityUndone.aspx, but does not necessarily satisfy O01.
Assumptions
Multiple organizations will need group policies in the NETID domain.
In many cases, multiple people from the same organization will be working with group policies, and these people may not be the same as the people who are the delegated OU admins.
Only people who are recognized as a UW employee should have permissions on group policy objects in MI.
Only admin NetIDs should be granted this level of permission, given the potential scope of impact, i.e. risk.
Group policies may be re-used (i.e. linked to) with multiple OUs, and in some cases, may be re-used across organizations. In such cases, extreme care with regard to change management processes is needed.
Restoring a group policy object that has been deleted is very costly, and is not generally cost effective.
All group policies, except built-in group policies, are subject to this proposal. All WMI filters are subject to this proposal. All IPSec policies are subject to this proposal.
Design Considerations
Group Policy names can be longer than 256 characters, so length is likely not a significant factor.
Only one group policy in a Windows domain can have any given name.
Group policy objects can be linked to no OUs, one OU, or more than one OU. When they are linked to no OUs, they are are not in use at all. When they are linked to more than one OU, changes to the group policy object affect all OUs they are linked to.
The Group Policy Management Console has the capability to back up and restore individual GPOs in a cost-effective manner.
The tool used to create and modify group policy objects is *very* important. If a downlevel tool, that is to say a tool from a Windows operating system older than the latest release, is used then problems can be introduced on any group policy object that downlevel tool is used to modify.
Group policy objects contain a set of settings that are applied to either computer or user objects. Applying user settings within MI is only possible via a special group policy mechanism called loopback, where the user settings to apply are derived from the computer object where the user is logging in from.
Group policy objects can be enabled or disabled. Additionally, the computer and user sections of the GPO can separately be disabled.
Group policy objects have a security filter associated with them which determines whether objects are allowed to apply the settings within the GPO. By default, Authenticated Users can apply all settings within a GPO. This security filter comes from the security ACL (mentioned next).
Group policy objects have a security ACL, sometimes called delegation permissions, applied to them. This ACL determines which objects can read, delete, edit, or modify the security settings for the GPO.
Group policy objects can optionally have a WMI filter associated with them. The WMI filter provides also filtering capability on which objects should apply the GPO, but the degree of functionality is incredibly greater–limited only by the functional limits of WMI. Like group policy objects, WMI filters also reside at a domain level, and are re-usable by anyone in the domain.
Group policy objects can have one specific setting used, IPSec. The IPSec setting references an IPSec policy, which also reside at a domain-level, and are re-usable by anyone in the domain.
By default, only Domain Admins can create or modify IPSec policies.
Discussion
Group Policy management is a complex topic, but with amazing potential, which represents one of the most significant reasons to use a Windows domain. So while there is great complexity, this complexity is worth some degree of pain.
Group policy object name collisions can easily be avoided via a simple scheme. Since there are very few people who will see GPO names, an elegant scheme is not necessary. Given the ability to have an extremely long name, more verbose names should be encouraged to aid recognition in troubleshooting scenarios. Likewise, WMI filter and IPSec policy name collisions can easily be avoided via a simple naming scheme. A naming scheme should incorporate the delegated OU name to aid recognition of administrator ownership in determining the correct support path to follow, otherwise, a GPO named “some settings” can not easily be associated with the College of Pottery that it belongs to.
People outside those delegated OU Administrator privileges for their organization will need to be able to administrate group policies. Toward this end, those with OU Administrator privileges are in the best place to suggest/authorize who should be given this level of privilege for their organization. So a process similar to what is adopted for determining the OU Administrator for a given organization should be used to establish an organization’s Group Policy Administrators. A group managed by MI Engineering should be established for this, and that group should be added to the ‘NETID\Group Policy Creator Owners’ group to permit them to create new group policies. It will be up to the creator of the group policy to adequately set security ACLs on that GPO such that the other GP Administrators in his organization can administrate that GPO.
The high cost of restoring deleted group policy objects suggests that group policy objects should not be easy to delete. Toward that end, not granting GP administrators the ability to delete GPOs would be one effective approach. To avoid cluttering the domain with old, unnecessary GPOs, a GP administrator could rename unnecessary GPOs in some fashion to indicate that they can be deleted, and then some automated mechanism could detect those GPOs, back them up using GPMC, and finally delete them.
The possibility of corruption or lost functionality means that all GP administrators *must* use the latest group policy management tools released from Microsoft. Those GP administrators who don’t follow this policy may lose their GP administrator privileges.
The lack of good change management tools for Group Policy strongly suggests that some common sense practices should be adopted by all GP administrators. Every GPO should be backed up via GPMC prior to any edit.
If your organization wants to re-use a GPO created and owned by another organization, you assume the risk of having that GPO changed out from under you. For this reason, re-use is discouraged, while copying the settings into your own GPO is encouraged. Likewise, re-use of WMI filters and IPSec policies is discouraged, while separate copies are encouraged. If you do re-use another organization’s GPO, WMI filter, or IPSec policy, you should make sure both organization’s GP administrators know about this and plan to follow some mutually agreeable change management process.
Given the potentially large number of GPOs that may ensue, GPOs which are unlinked or disabled for long periods of time should be periodically reviewed to see if they can be deleted.
The fact that IPSec policies can only be created/modified by Domain Admins presents a challenge in a shared, delegated domain. http://technet.microsoft.com/en-us/library/cc755942(WS.10).aspx describes some background around around this. The solution space for this issue is 3 fold:
a) Domain admins manage all MI ipsec filters and wmi filters, accepting the overhead of all such requests.
OR
b) Permissions are delegated to create/manage MI ipsec filters to all delegated OU group policy admins (i.e. to netid\group policy creator owners). This allows all MI group policy admins to edit *all* the MI ipsec filters. So one admin could edit another admin’s ipsec filter. But we address this issue via administrative policy, by telling folks that they should only edit their own ipsec filters.
OR
c) ‘Group Policy Creator Owners’ is allowed to create children (allowing ipsec policy creation) on the ‘ip security’ container (not OU). This doesn’t give delegated admins the ability to modify the ipsec objects after creation. So we also modify the schema changing the default explicit ACL on the relevant object classes to allow creator owner full perms. Then, because future MS schema updates will likely reset the default ACL on those object classes, we’ll need to keep an eye out for that event, and re-apply our schema mod afterward. This allows delegated ipsec policies, although creators will need to do a more intricate dance than with GPOs in order to delegate management to the rest of their org’s gp admins.
None of these options is stellar, but based on polling, apparently organizations outside the UW don’t consider this issue significant, so our approach may not need to be anything special.
Proposed Policy and Process
All group policy object/WMI filter/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>: *
The group policy administrators for a given organization will be in a group managed by MI engineering, named u_windowsinfrastructure_<delegated OU name>_gpadmins. This group will be put 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 as appropriate.
The group policy administrators for a given organization will initially be the delegated OU administrators. These delegated OU administrators can suggest and authorize other employees that should be given this level of privilege for their organization. MI Engineering will validate their UW employee status, and ensure that the appropriate admin NetID is put in the group noted above.
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 send requests that MI Engineering create and modify any IPSec filters and WMI filters needed. In cases where a high volume of changes are needed, MI Engineering will look to delegate individual objects. Delegated OU 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. Those GP administrators who don’t follow this policy may lose their GP administrator privileges.
All GP administrators should back up a GPO via GPMC prior to any edit.
If your organization wants to re-use a GPO created and owned by another organization, you assume the risk of having that GPO changed out from under you. For this reason, re-use is discouraged, while copying the settings into your own GPO is encouraged. Likewise, re-use of WMI filters and IPSec policies is strongly discouraged, while separate copies are encouraged. If you do re-use another organization’s GPO, WMI filter, or IPSec policy, you should make sure both organization’s GP administrators know about this and plan to follow some mutually agreeable change management process.
Example Use Cases
When the College of Pottery received a delegated OU, the group u_windowsinfrastructure_copott_gpadmins was created and initially populated with sadm_glassshard. Ms. Glass Shard was told at that time to use the Vista or WS2008 Group Policy Management Console only when editing or creating group policy objects in MI, and to follow appropriate change management processes. Glass now wants to add an additional person as a group policy administrator, and requests that Mr. Terra Cotta be added. MI Engineering verifies that Terra is a UW employee, and adds his admin NetID to u_windowsinfrastructure_gpadmins. MI Engineering also makes sure that Terra knows to use the appropriate tools and processes.
Outcome
This proposal was implemented with the release of Delegated OUs.