Another Look at Folder Permissions: Beyond AGLP

AGLP is Microsoft’s four-letter abbreviation for guiding admins in setting permissions in an Active Directory environment. Account, Global, Local, Permission just means the following: you put user accounts (A) into global groups (G), put the global groups into domain local groups (L), and then grant permissions (P) to the domain local group. Makes sense, right?

It’s a convenient way to permission users based on their roles.

All your sales people are added into the Sales group, the marketing folks into the Marketing group, etc. The domain local groups are then associated with a resource—say a file share or a printer.

You place Sales and Marketing into a domain local group called, say, Presentations, which controls access to a file share. Finally you apply appropriate permissions — read access, or read-write access — to the domain local group.

The fancy name for what I just described is referred to by another four-letter abbreviation, RBAC, or role-based access controls

Problems

AGLP has a nice side benefit. It’s far easier to audit access controls: you just focus on the domain local groups. But this comes at a price.

AGLP can’t be easily applied to selected users across multiple business roles. Several approaches have been tried to resolve this problem, known of course as SUAMBR, but with little success. In most cases, the attempts to work around AGLP’s lack of permission granularity leave the file system’s permission in a state of over-permissive access.

It’s a major problem when recertifying file permissions for certain data security regulations and compliance standards—for example, HIPAA or SOX.

What are some of the things that can go wrong with AGLP? We have a list:

1. Over-Permissive Access to Sensitive Data Caused by Using Functional Groups

A common practice is to grant an entire functional group, business role, or global access group, permissions to a data share. Because Microsoft requires that permissions are granted through Active Directory groups, this method is widely used to provide access. Although this approach ensures that users who require access have sufficient rights, it also poses a security risk. Many unauthorized users are also granted permission to sensitive data, mainly because they are included as a member of a specific role.

2. User and Non-Group Permissions are Directly Assigned on an ACL

Another way to manage permissions on sensitive data is to directly grant user account permissions on the folder instead of the security group. This ensures that only authorized users have access; however, it also makes permission recertification a very complicated process. It’s then difficult to effectively manage access across the file system: you’re now faced with tracking individual files and folder and updating the ACL when a user no longer requires access because of a role change.

3. Ordinary Users are Intentionally Assigned Full Control Permissions

In many cases, administrators intentionally grant Full Control permissions to ordinary users. This approach brings a security risk: in the event of a malware or cyber- attack, Full Control permissions could be leveraged by hackers. For example, the hacker (or employee who becomes an insider threat) removes all permissions from other groups, or deletes all data within the folder. Even regular users with Full Control permissions can accidentally change folder permission settings, resulting in the loss of access or deletion of data.

4. Ordinary Users are Unintentionally Assigned Full Control Permissions

IT administrators may unintentionally grant Full Control permissions to ordinary users by failing to limit default Owner rights. This approach also poses a security risk for the same reasons mentioned above.

It is important to note that Owner rights should be explicitly defined on the ACL with Modify permissions and not Full Control permissions. Additionally, attempts to remove Owner rights will only remove the visual display of the permission and revert the Owner rights to Full Control.

5. IT Administrators are Unnecessarily Granted Full Control Permissions

IT administrators are usually granted Full Control permissions to all data, including sensitive data. This practice may be acceptable in tightly controlled organizations. But it’s not unusual now for administration to be outsourced to providers, where there is greater opportunity for errors, negligence and malicious behavior.

6. Failure to Audit and Recertify Access

In most environments, there’s no clear definition of what data is considered sensitive. In cases where sensitive data is identified, having both multiple functional security groups and direct permissions can make auditing access and permission recertification a time consuming and error prone task. Data owners who fail to audit and recertify access to sensitive data risk that data being exposed by hackers.

Solutions

We have ‘em too! Check out the full list in our awesome Best Practices For Planning and Implementing NTFS Permissions For Recertification!