NTFS group membership calculations
Data Governance Edition uses the following criteria to determine the "best fit" groups that would provide the requested access to an NTFS resource:
- Origin domain: Groups in the same domain as the requesting employee are considered favorable. Groups from forests outside of the forest of the requesting employee are considered less favorable. Groups from synchronized domains are considered favorable. Domains are synchronized with One Identity Manager through a manual process; they are not done whole forests at a time, but rather, one by one. A group found in a resource’s ACL may be from a group that is not in a synchronized domain.
- Distance from the resource: Groups directly in the resources access control list are considered favorable. A group that is nested one or more steps away from the access control list is considered less favorable.
-
Group type: Groups are favored in the following order: Global group, Universal group, and Domain Local group. Built-in groups are never considered suitable selections.
- IT Shop: Groups that have been published to the IT Shop are considered favorable. For a group to be in the IT Shop, it must be in a domain that is synchronized and an administrator must have added it specifically to the IT Shop.
- Access rights: Groups that contain the exact rights that were requested are considered favorable. A group with slightly more rights may still be suggested, but is considered less favorable.
- Access inheritance: Groups whose rights to the targeted resource are explicit are favorable. Groups that have been delegated access to the targeted resource through inherited permissions are considered less favorable.
- Domain Local group membership: Domain Local groups with no other Global or Universal groups nested within them are favorable. Domain Local groups with these types of nested groups are considered less favorable.
- Group membership rules: Global groups that exist in the same domain as the employee are favorable. If the group is Universal, the employee must exist in the same forest as the group.
|
|
Note: The criteria used to determine suitability for group selection is based on Microsoft best practices for setting file and folder security in a distributed environment. Under certain conditions, a security group that would give employees their requested access may be deemed inappropriate and therefore the group is not available as an option. |
SharePoint group access calculations
Data Governance Edition uses the following criteria to determine the "best fit" groups that would provide the requested access to a SharePoint resource:
- Group membership: Data Governance Edition favors groups that grant the requested access without any additional permissions. Groups that provide extra permissions are considered less favorable. Groups that confer farm administrator, site collection administrator, or allow for the delegation of permissions are considered ineligible.
- Self-service access: Data Governance Edition favors groups to which the user can request access through the web portal. These groups are likely to be the safest way to gain access to a resource without unintended side affects.
- Active Directory groups: Active Directory groups that are nested within SharePoint groups are given preference. The nesting of Active Directory groups provides a balance between the visibility and features of a SharePoint group, and the provisioning power of an Active Directory group. Global and Universal groups are favored.
- SharePoint groups: If your organization prefers to use SharePoint groups instead of Active Directory, preference can be given to these groups.
- WebApp policy: Data Governance Edition ignores groups that are denied access to a resource through a WebApp policy, even if access is directly conferred elsewhere.
Troubleshooting resource access requests
The following topics explain possible causes and resolutions to issues you may encounter when working with self-service resource access requests:
No groups available for resource access request
On the Pending Requests page of the web portal, there is no group listed. When Select a group is clicked, the following message appears, " No groups available", and the request cannot be approved.
Cause
The system automatically calculates the "best fit" groups and assigns the resource to a group that matches the access requested. When the business owner logs on to the web portal, the "best fit" group is displayed for the self-service access request on the Pending Requests page. The business owner can approve the suggested group or manually specify a different group that meets the criteria of the request by clicking the Select a group button. If no groups are available or no groups are found that match the access request, the request cannot be approved.
When no groups are listed for the selected request, means that Data Governance Edition could not find any groups that match the level of access requested. That is, no groups met the criteria used to calculate the "best fit" group.
- For NTFS group membership calculations, the system takes the following into consideration: origin domain, distance from the resource, group type, whether the group is published to the IT Shop, access rights, access inheritance, Domain Local group membership, and group membership rules.
- For SharePoint group access calculations, the system takes the following into consideration: group membership, self-service access, Active Directory groups, SharePoint groups, and WebApp policy.
For more information on processing requests and how Data Governance Edition calculates the "best fit" group for resource access, see Group access calculations.
Resolution
If you are requesting access to a share, use the Object Browser to check the UseFolderForITShop property in the QAMDuG table. If this flag is set to True, the backing folder security (Folder Permissions) is being used (not the Share permissions). Verify that there are groups that meet the requested access defined for folder security. See Wrong group displayed for Share access request for more information on reviewing a governed share's properties in the QAMDuG table.
Review the criteria used for calculating a "best fit" group and create a group that satisfies the access requested. For example, consider the following when creating a group:
-
Access rights: Create a group that contains the exact access rights requested. For example, if an employee requests read access, but all available groups allow more rights (for example, write or full access), no groups are found. Creating a group that is limited to read access would satisfy the access requested.
Note: Review the Advanced options for the group to ensure that only the default permissions are set; setting different advanced permissions may also affect the "best fit" group calculations.
-
Group type: Create a Global group and a Domain Local group; nesting the Global group within the Domain Local group. The Domain Local group is ACL'd on the resource, but the Global group should be suggested as the correct group.
Note: Data Governance Edition follows Microsoft best practices when ranking groups, where Global groups are ranked higher than Domain Local groups.
The "best fit" group is determined using a series of calculators that return a value in the range of -2 to +2. Review the Data Governance Service log.txt file to see the groups that were evaluated and the results of these calculations. The calculators cannot be changed; however, you can modify the positive and negative multipliers in the DataGovernanceEdition.Service.exe.config file if necessary. For more information on modifying these multipliers, see Modifying the calculators.
Additionally, valid groups must be associated with products in the IT Shop and be requestable by the requester.