ACI best practices - PingDirectory

Group based

Ping Identity highly recommends using a set of standardized, group-based ACIs to grant permissions to the directory. Managing the application of ACIs through group membership provides a number of benefits:

• Easier to understand
  • You only need to look at group membership to determine what a user has access to. You don’t need to decode ACIs to see which ACIs apply to a user.
• Simplified auditing (just look at group membership)
• Greatly simplifies the granting of rights
• Reduces the total number of ACIs
  • ACIs always get evaluated, so keeping the number of defined ACIs relatively small can help performance.
• Reduce risk and ACI proliferation
  • Application-specific or user-specific ACIs can be difficult to maintain. It can be difficult to know if an ACI is safe to remove or if it grants too many rights to an application. Group-based ACIs transform this issue into a group management issue that administrators are much better equipped to deal with.

  • Creating generic, reusable ACIs greatly reduces or eliminates the need to create custom, application-specific ACIs for each new application or unique use case.

Example

For a specific user organizational unit (OU) in the directory, you could create a set of group-based ACIs that grant the following:

• Read/Search access to non-sensitive attributes
• Read/Search access to sensitive attributes, such as SSN or date of birth.
• Write access to non-sensitive attributes
• Write access to sensitive attributes
• Create permission for specific entry types (create for inetOrgPerson or groupOfUniqueNames)

• Write access to specific attribute (for example, uniqueMember grants the ability to manage group membership separately from the ability to create/delete groups)

• Import/Export rights (to allow for moddn operations)

• Delete permission for specific entry types

This might initially look like a lot of ACIs to create for each OU in your directory. However, these ACIs greatly reduce or eliminate the need for the creation of future ACIs, as 95% of your conceivable use cases for granting of permissions can now be accomplished through group membership.

PingDirectory allows for the use of nested groups, so it is possible to create a Level1 Help Desk group and nest it into multiple ACI groups across multiple OUs to simplify administration.

Use implicit deny, not explicit

Using the above methodology means an entry will by default have no access to any entries in the directory. Any access granted to an account will be an accumulation of explicitly granted permissions. Starting from a position of no privilege and only having permissive ACIs greatly simplifies the evaluation of privileges when troubleshooting or verifying that an account has the correct rights.

One of the biggest issues with a deny ACI is that the deny is being implemented as a security control to remove access that would otherwise be granted. This implies that the account in question would by default have access to data it should not unless action is explicitly taken to deny that access.

Having only permissive ACIs means that mistakes in granting rights to a user will usually result in a user not having enough access. Using a deny ACI opens us up to the possibility of a mistake granting a user rights they should not have.

If you don’t grant a user enough privileges, the user will usually let you know. Detection of this type of mistake is usually easy (the user is motivated to let you know) and poses low security risk to the organization.

If you grant a user or account too many permissions, no one will likely notice. Even if a user or application owner notices, they might not consider this an issue and are unlikely to report it. Detection of this type of mistake is very difficult and can pose a high security risk to the organization.

Use names with identifiers in ACIs and document

When an ACI has been in place for an extended period of time it might not be a simple process to determine why that ACI exists, what exactly it does, and if it’s safe to modify or delete it. This presents a number of auditing and supportability concerns and can produce a directory whose security stance cannot be fully determined.

It is highly recommended when creating ACIs that each ACI contain a descriptive name with a unique identifier that can be cross-referenced with a version document containing:

• ACI Unique Identifier
• ACI High Level Description
• ACI Business Case
• Change order/request id used to implement the ACI
• Responsible party
• Parties to be informed if ACI needs to be deleted or changed

For example, we might have an ACI that looks like:

(target="ldap:///cn=changelog")(targetscope="subtree")(targetattr="*||+")(version
          3.0; acl "GL-SYNC-1: Allow Read access to changelog backend";allow(read,search,compare)
          groupdn="ldap:///cn=SyncReadGrp,ou=Groups,ou=Administrators,dc=example,dc=com";)

With a corresponding entry in the ACI document similar to the following.