Permissions
This section describes the File Access Manager permissions and the operations available under the Permissions menu in the Administrative Client and Forensics menu within the website.
General
Many of the key File Access Manager Permissions use cases involve every aspect, from gaining visibility to actual active involvement of management in permission reviews.
Permissions describe the access that a specific User or Group must a specific Business Resource.
Examples of permissions include:
-
Mary Jones has Read access to the Finance folder directly
-
John Smith has Write access to the Finance folder because he is a member of the Finance AD Group
-
Larry Taylor has Write access to the Finance folder directly because he is a member of the Admins AD Group
Atypically, a permission may also include an Allow/Deny modifier.
Permission Modeling
Basic rules are used to model permissions from various systems into a single coherent view.
Every permission consists of a combination of the following four elements:
-
User
-
Group
-
Permission
-
BR
Not all components are required for all permissions, since some systems provide direct permissions to users, while others only enable permissions through groups.
User
The user is an object that represents an account associated with a permission.
Standard user attributes include:
-
User type - User, orphan, or local.
-
User disabled / enabled - Whether the user account is enabled or disabled in the managed application or the identity store.
-
User domain - The security domain in the identity store in which the user is defined. For example, you can define the identity store as an Active Directory forest, in which you define the User in one of the domains of the forest.
User data is commonly part of an identity collector connected to a relevant identity store.
For example, when an identity store is set as an organization's Active Directory, extended attributes may be Department and Manager.
Group
A Group is a container of users that represents a Group, Responsibility, or Profile.
Some endpoint systems only set permissions through groups.
Standard Group attributes include:
-
Group Type is often provided in accordance with the group type, depending on the type of endpoint system.
For example: SharePoint local groups - "SharePoint group"
-
Group Domain is the security domain in the identity store in which a group is defined. For example, the identity store is an Active Directory forest, with the Group defined within one of the forest domains.
Group Nesting
Normally, it is possible to nest Groups (one group resides within another group). For example, assume that Group A contains both User A and User B. If Group A is also a member of Group B, then it follows that Group B also contains User A and User B. File Access Manager examines all nested groups when it analyzes which entities are effective group members for a given group.
Permissions
Permissions are functions enabled, or denied to, a user or group.
Permissions are identified for out-of-the-box supported systems.
The standard permission attributes (that provide context) include:
-
Permission Type - the function name
-
Access Control List (ACL) Allowed - Allow/Deny
-
Is Inherited - defined locally or inherited
Note
“Is Inherited” is crucial to Permission queries, since it eliminates permission duplication by showing only unique permissions.
Owner Permission
Most permission mechanisms utilize a special Owner permission type. Typically, the Owner permission cannot be blocked, revoked, or customized, and provides full access rights.
Different applications and permission mechanisms may interpret Owner permission differently. The table below describes the permission types that File Access Manager treats as an Owner permission. For each platform, the Owner permission is defined and named (queried by the listed name in the AFM query filter controls).
| |
|---|---|
Permission Scheme | Description |
Microsoft ACL | Microsoft Access Control Lists contain a special field that indicates the owner user/group) of the resource (for example, a file or a folder). There can be only one entity defined as the Owner (but that Owner can be a group). Since an Owner has full control of the ACL, the Owner effectively grants all permissions. The Microsoft ACL Owner applies to:
|
Unix | When a file(/folder) is created in Unix/Linux, its creator is automatically set as the Owner.
There can only one owner user and one owner group per file/folder. Since only the Owner (or root) can change file permissions, an Owner effectively grants all permissions. The Unix file system Owner applies to:
|
SharePoint | A SharePoint server features Site Collection containers, which function as separate entities, and permission scopes. Different Site Collections may have different users, groups, and permission types. One or more users in a Site Collection may be defined as a Site Collection Administrator. The Administrator has full control of the resources in the Site Collection’s inner structure. The SharePoint Site Collection Administrator applies to:
|
Cloud Storage Providers | Typically, cloud storage providers include a permission type named “Owner” which grants full access rights to the resource (file, folder etc.). The generic “Owner” permission is employed in:
|
Business Resource
A business resource (BR) is a monitored application object, such as a folder on a file server, a site on SharePoint, or a mailbox on Exchange.
Business resources can have child BRs, and can inherit permissions from a parent resource.
Standard business resource attributes include:
-
Name - the name of the resource
-
Full Path - the path with all its hierarchy levels (a unique business resource identifier, for example C:\Finance\CTO)
-
Inherits Permissions - a flag identifying whether or not a business resource inherits permissions
In cases of applications which support file level permissions, the business resource tree will include BRs on a file level, where:
-
The application is configured in the setup to includes file level permissions
-
The file has unique permissions, compared to its parent nodes.
Inheritance
While inheritance can make management easier, it also can result in unnecessary duplication.
Permission analysis analyzes inheritance by determining whether a business resource inherits permission, and whether a specific permission is inherited.
The table below lists the relationships involved in permission analysis.
| Business Resource Inherits Permission | Permission is Inherited | Result |
|---|---|---|
| True | True | The permission is not unique and derives from the father permission. |
| True | False | The permission is unique and even though the business resource inherits permissions, the specific permission is not inherited. This is a common scenario in NTFS. |
| False | False | The permission is unique. |
| False | True | The permission is unique. |
Note
The last case in the table is a situation that occurs in a few specific end systems (as it is logically inconceivable). For example, the system enforces SharePoint Policy Rule Permissions from the Web application level. Therefore, even if the business resource does not explicitly inherit any permissions, permissions are still inherited.
Permission Examples
The table below lists examples of the results of combining specific permission elements.
| BR | Permission | User | Group | Result |
|---|---|---|---|---|
| Folder X | Read | Asmith | Group1 | User Asmith has read permission on Folder X derived from Group1. |
| Folder X | Read | Asmith | User Asmith has a direct read permission on Folder X. | |
| Folder X | Read | Group1 | Group1 has read permissions on Folder X. The group is empty. |
Permission Capabilities Overview
This section describes the Permission capabilities available, including:
What-If Scenarios
Access Certification
Access Requests
What-If Scenarios
“What-If” is a component that simulates the addition or removal of users to and from groups.
The output contains the resources and permissions for which the user loses or gains permissions.
Access Certification
Access Certification is a component that manages permission review campaigns. These campaigns fine tune user permissions by enabling managers, data owners, or other relevant personnel to review user current permissions.
Access Requests
File Access Manager can accept, process, and manage user requests and provide users with access to certain system resources.
The Access Request module manages and controls the access request process.
Fixing Faulty Permissions
Faulty permissions may occur in CIFS-based applications, where:
-
Permission set on a parent Business Resource is not inherited by sub-resources, although inheritance is configured.
-
A Business Resource includes an inherited permission, which is missing on the parent Business Resource.
Contact the SailPoint support team for assistance in configuring File Access Manager to identify and fix faulty permissions.