Best practices for the definition of ACIs in a PingDirectory environment include:

  • Default to deny
    • Don’t define any global permissive ACIs for all users.
    • Ensure that unless explicitly granted, all security decisions are a deny.
  • Group-based ACI
    • All ACIs should be assigned through group membership.
    • Do not assign ACIs to specific user accounts.
  • Implement ACI identifiers and document thoroughly

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.


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:

          3.0; acl "GL-SYNC-1: Allow Read access to changelog backend";allow(read,search,compare)

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

Description Grants read access to cn=changelog for the PingDataSync service account so it can monitor for changes to user data
Business case CRM Unit needs to monitor for new customer entries in the directory so they can retrieve application generated unique identifiers and associate those with customer entries in the CRM database
Change order Implemented 12/24/2020 under CR23423
Request ID Requested 6/15/2020 with REQ 1231254
Area owner US Customer Relations
Responsible parties

Manager – Alice Smith (

BA – Bob Jones (