Tool does not take advantage of property set

[PatrickOnGit]

The tool creates a lot of groups and setting single permissions and may group those permissions using the same group.
This results in dozends of ACL entries and slows down AD.
It should rather make use of property sets which allow setting a single permission and bundle several properties.

AD property-sets

[merddyin]

It actually has very little performance impacts on AD, based on my benchmarks. I am very familiar with property sets, however the challenge is that the property sets would result in too much access being granted. The whole point of this tool is to create a least privilege framework. The groups that get created are all specific to a single AD path and object class, and are limited to a specific subset of privileges by design. These can be used to build out Role Groups or Role Accounts that are embedded into one or more access groups.

[PatrickOnGit]

Thank you for your feedback.
Property sets are customizable, yet less flexible than your solution.
On the other hand, there is no documentation how to change how the permissions are grouped and which apply where and why.
The tool is missing any explanation on this.

[merddyin]

I completely agree that there is a lack of documentation at present. The updating of associations is simple enough however. All mappings between Task Groups and properties in AD is kept in the AP_PropertyGroupMap table. The property name comes from the AD_Classes table to ensure a valid lookup to the GUID when setting ACLs. The pgrpname is the name of the Task Group from the AP_PropGroups table. The value in AP_PropGroups determines the suffix of the Task Delegation Group when it is provisioned to AD...this is essentially a friendly identifier to assist in locating the group by hand. The first portion of the TDG name (before the first dash) relates to the OU structure (each TDG is specific to a single path and class). The second portion (between the two dashes) identifies the AD class, the scope of the permissions to be applied (object, property group, or single property), and what actual permission to set. AP_Identifers provides the mapping of the scopes, while AP_Rights provides the ACLs values to be set. Both of these tables also include extension values to allow for the creation of TDGs, or in the new code base also TCGs (non-privileged task groups) to allow for use of the framework for items outside of administrative access to AD. These items will cause a TDG/TCG to be generated for the appropriate class and focus, but will not result in configuration of any actual ACLs...this is controlled by the OBJ_assignAcls columns...setting it to 0 tells the tool to create but not attempt to set permissions.

Presently, in most instances, the property groups are associated to tabs on the AD Users and Computers object properties. For example, ADUCGeneral items should include all properties found on the General tab for that object class within ADUC, as well as any undisplayed attributes that might be required to update the visible values. I should note that extended rights are also accounted for in the mapping table.

I've also updated the tag on this one to be documentation.