Delegation to link GPOs missing

[PatrickOnGit]

There is not delegation to link GPOs on workstations or users OU.

[merddyin]

This is correct. The elements are available in the SQLight DB to enable this, but this isn't something I typically recommend delegating out. This tool is based on Microsoft's Enhanced Security Administrative Environment (ESAE) model guidance. In that guidance, they have the concept of a 'Gold Card Administrator' which would isn't bound by tiers...you would theoretically only have 2-3 of these in an enterprise. It is my opinion that, unless you are employing a tool such as Quest GPOAdmin, the ability to mess with policy links could result in exposure of the environment, so by default, only Gold Cards should be provisioning GPO objects or messing with links. All the settings should be held in specific levels of the structure, rather than split into hundreds of separate policies, as this makes auditing and review easier. As I said though, the pieces are all present to enable creating an OU focused set of permissions groups, which can include GPO links.

[PatrickOnGit]

Managing GPOs and GPO links do have certainly a security impact, but are common task's. Specially when talking about Clients but also Terminal servers. Managing GPOs should be done by trusted personnel but not necessary domain admins. The delegation of linking GPOs should be done at very least on tier level an inherited. And may be done on SL or SLO level, always inherited. Everything else would generate to much TDGs in with always the same members. There is no documentation on how these delegations can be enabled and where the permissions would actually be granted.

I think this is a valid request and do not agree with the label invalid.

Thank you for providing insides on how to configure delegations within the SQLite db.

[merddyin]

So, the intent with this framework approach, is that GPOs are linked at the top Tier, the Focus, and the Org layers. The Org layer can consist of between 1 and 3 levels, which is necessary to support large global orgs with distributed admins at varying levels. For example, I have run into customers that had need of city, country, and regional level admins, with hundreds of cities. This would result in exceeding either the max token size, or the max group memberships supported by AD. While some orgs do organize their servers by location, most do so by function, so the active code base supports 1-3 layers under the Servers Focus that are not necessarily the same as the other Focus OUs.

Along with this, the intent is that each OU, other than the Class OUs, will have two GPO objects created that are specific to that path; one for User settings, and the other for Computer settings. The name of the GPO is specific to the path, so it is easy to tell if a particular GPO has been linked somewhere it shouldn't be, or if it has been unlinked improperly. In theory, any trusted admins who would be allowed to edit GPOs would be delegated access within the GPO itself, which isn't something the module currently handles. Ideally however, the customer will implement a tool, such as AGPM from Microsoft or GPOAdmin from Quest. The key piece here is that linking and unlinking of GPOs is only intended to be performed during provisioning or deprovisioning of an OU, with all settings incorporated into these GPOs. For targeting of settings, the framework leverages Policy Preferences versus OUs...too many orgs treat OUs as folders for organization and ignore the ability to leverage metadata. You would be surprised at how easy it is to manage local security groups for servers using a tag on the server in AD and a policy preference for group assignment. Further, since nearly every GPO setting is technically a registry value at the end of the day, almost everything can be targeted. I have so far only encountered a very small number of use cases where specialized policies were actually required.

Again, I see your point, and the module could technically support it with a minor addition to the DB, but this module is intended to implement a secure framework. Unfortunately I have been in too many environments performing a post-breach clean-up where the cause of breach was an improperly linking GPO.