Use Cases

Best Practices: Elevated Rights for PingDirectory

This document provides an overview of Ping Identity’s recommendations for management of elevated rights in PingDirectory.

PingDirectory is designed as a security product and provides a number of mechanisms that can be used to provide fine-grained control over the elevated rights that can be assigned to an administrator or service account.

Capabilities

Privileges

PingDirectory has a number of defined privileges that are used for fine-grained control of privilege.

The capabilities of the Directory Manager account that is created by default during a PingDirectory install is granted by assignment of privileges. This default Directory Manager account itself does not possess any special privileges or capabilities beyond those assigned by privileges. Any account in the directory that is assigned the same privileges as that default Directory Manager will have exactly the same level of access as that Directory Manager account.

The privileges assigned to the Directory Manager account can be removed (or the account itself can be deleted) without impacting the functionality of the directory.

Privilege name Root privilege Privilege description

audit-data-security

Yes

Provides the ability to audit the security of data in any backend. The user still needs access control permission to perform the requested operation

backend-backup

Yes

Provides the ability to perform a backup of one or more backends with the server online via the tasks interface. The user still needs access control permission to perform the requested operation.

backend-restore

Yes

Provides the ability to perform a restore of a backend with the server online through the tasks interface. The user still needs access control permission to perform the requested operation.

bypass-acl

Yes

Provides the ability to bypass all access control evaluation for any type of operation.

Users with the bypass-acl privilege can still be subject to other restrictions, such other privileges that might be required to process a particular operation.

bypass-pw-policy

No

Provides the ability to exempt an administrator from certain types of password policy evaluation when performing an operation against another user.

bypass-read-acl

No

Provides the ability to bypass all access control evaluation, but only for bind, compare, and search operations. Normal access control evaluation is still performed for add, delete, extended, modify, and modify DN operations.

collect-support-data

Yes

Allows the requester to invoke the collect-support-data tool using an administrative task or extended operation.

config-read

Yes

Provides the ability to perform search and compare operations in the server configuration. These operations are still subject to access control restrictions.

config-write

Yes

Provides the ability to perform add, delete, and modify operations in the server configuration. These operations are still subject to access control restrictions.

disconnect-client

Yes

Provides the ability to terminate an arbitrary client connection. The user still needs access control permission to perform the requested operation.

exec-task

No

Allows the requester to schedule an exec task.

file-servlet-access

Yes

Indicates that the requester may be permitted access to the content exposed by file servlet instances that require this privilege.

jmx-notify

No

Provides the ability to subscribe to receive JMX notifications.

jmx-read

No

Provides the ability to perform read operations using JMX.

jmx-write

No

Provides the ability to perform write operations using JMX.

ldif-export

Yes

Provides the ability to perform LDIF export operations with the server online through the tasks interface. The user still needs access control permission to perform the requested operation.

ldif-import

Yes

Provides the ability to perform LDIF import operations with the server online through the tasks interface. The user still needs access control permission to perform the requested operation.

lockdown-mode

Yes

Provides the ability to cause the server to enter and leave lockdown mode or to access the server while it is in lockdown mode. The user still needs access control permission to perform the requested operation.

manage-topology

Yes

Provides the ability to manage a topology of server instances, including adding servers to and removing servers from a topology. The user still needs access control permission to perform the requested operation.

metrics-read

Yes

Provides the ability to search or retrieve data in the metrics backend. The user still needs access control permission to perform the requested operation.

modify-acl

Yes

Provides the ability to modify access control rules. The user still needs access control permission to perform the requested operation.

password-reset

Yes

Provides the ability to change another user’s password. The user still needs access control permission to perform the requested operation.

permit-externally-processed-authentication

No

Provides the ability for the requester to issue a bind request that uses the UNBOUNDID-EXTERNALLY-PROCESSED-AUTHENTICATION Simple Authentication and Security Layer (SASL) mechanism.

permit-forwarding-client-connection-policy

No

Provides the ability to request that an operation be processed using a specified client connection policy.

permit-get-password-policy-state-issues

Yes

Provides the ability for the requester to issue a bind request that includes the get password policy state issues request control. The bind request must also include the retain identity request control.

privilege-change

Yes

Provides the ability to alter the set of privileges assigned to an individual user or to change the set of privileges that can be automatically assigned to root users.

proxied-auth

No

Provides the ability to request that an operation be processed using an alternate authorization identity, such as using the proxied authorization or intermediate client request control or using a SASL authorization identity.

server-restart

Yes

Provides the ability to request a server restart using the tasks interface. The user still needs access control permission to perform the requested operation.

server-shutdown

Yes

Provides the ability to request a server shutdown using the tasks interface. The user still needs access control permission to perform the requested operation.

soft-delete-read

Yes

Provides the ability to retrieve, compare, modify, delete, or undelete soft-deleted entries. The user still needs access control permission to perform the requested operation.

stream-values

Yes

Provides the ability to use the stream directory values extended operation to obtain a list of all entry DNs or unique attribute values or to use the stream proxy values extended operation to obtain information from the global index. The user still needs access control permission to perform the requested operation.

third-party-task

Yes

Provides the ability to invoke a third-party task in the server. The user still needs access control permission to perform the requested operation.

unindexed-search

Yes

Provides the ability to perform an expensive unindexed search in a local DB backend. The user still needs access control permission to perform the requested operation.

unindexed-search-with-control

No

Provides the ability to perform an unindexed search if the request also includes the permit unindexed search request control.

update-schema

Yes

Provides the ability to alter the server schema. The user still needs access control permission to perform the requested operation.

use-admin-session

Yes

Provides the ability to use an administrative session to request that operations be processed in a dedicated thread pool.

Privileges are granted to an account by adding the desired privilege to the accounts ds-privilege-name attribute.

This attribute can be explicitly populated, populated with a virtual attribute, or a combination of the two.

Privileges allow us to grant accounts the ability to perform basic administrative tasks, such as server-shutdown, without needing to grant more powerful privileges, such as bypass-aci.

Access control instructions (ACI)

ACIs are used to define the level of access an account can have to entries and attributes in the directory. By default, PingDirectory is configured with an implicit deny, so read/write access to entries must be explicitly granted.

Client connection policy

A number of different client connection policies may be defined on a server. A client connection policy can, among other things, determine:

  • Which branches of the directory are accessible

  • Allow operation types (for example, search, add, delete, and modify)

  • Allowed filter types

  • Search size and time restrictions

  • Attributes to be excluded from search results

  • Attributes that cannot be included in search filters

  • Attributes that cannot be modified (even if ACIs would normally allow)

Which client connection policy applies to an authenticated account can be determined by:

  • Included/excluded IP address or IP range

  • Connection type (HTTPs, LDAPs, LDAP)

  • Location of authenticated account in the directory

  • Group membership of authenticated account

  • Attribute value contained in the authenticated account

  • Authenticated account privileges

A common use of client connection policies is creating a connection policy for insecure LDAP communications where only accounts in specific groups are allowed to connect insecurely and can only see a limited number of entries and attributes.

ACI best practices

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.

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.

GL-SYNC-1

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 (bob.smith@company.com)

BA – Bob Jones (bob.jones@company.com)

Privileges best practices

Privileges are assigned to an entry through the population of the ds-privilege-name attribute with a list of the privileges that entry should have.

Ongoing maintenance and auditing of privilege assignment can be challenging if privileges are assigned through direct population of the ds-privilege-name attribute. Ping Identity does not recommend direct population of this attribute except in special cases.

Ping Identity recommends the use of group-membership based virtual attributes to populate privileges.

For example, to assign the pwd-reset privilege a virtual attribute would be created similar to:

dsconfig create-virtual-attribute \
 --name ADM-Password-Reset-Priv --type constructed \
 --set enabled:true --set attribute-type:ds-privilege-name \
 --set enabled:true --set attribute-type:ds-privilege-name \
 --set group-dn:cn=ADM-PasswordReset,ou=groups,ou=admins,dc=example,dc=com \
 --set value-pattern:password-reset

Using this virtual attribute, an account can be granted the password reset privilege by adding the user to the ADM-PasswordReset group.

Exception

You might encounter a potential bug with applications that heavily use Proxy Auth privileges where security context changes multiple times over a single connection. This behavior is typically limited to applications such as PingFederate and Siteminder. An existing connection that’s heavily used for Proxy Auth might forget what privileges it has unless they are explicitly assigned to the entry’s ds-privilege-name attribute.

Client connection policy best practices

Client connection policies can be used to control what a client can see or do at a very high level. You can use client connection policies to enforce a certain level of security that is not available through other mechanisms.

There are a number of common use cases for client connection policies:

  • Allow exceptions to requirement for secure connections based on a service account’s group membership

  • Limit the subtrees viewable or accessible to a client

    • Useful when storing both employee and customer data on the same server to logically isolate the branches from each other for most applications

  • Restrict access or disallow access to PingDirectory based on client IP address (for example, don’t allow adds/mod/writes from the Internet even if the account has ACIs granting those permissions)

  • Place restrictions on allowable search filters

  • Enforce limits on poorly behaving applications or applications that are yet to be vetted by the directory administrators

  • The calculation of expensive virtual attributes can be restricted so that they only occur over a specific connection policy

The client connection policy associated with a particular connection can change over time. The client connection policy will be determined:

  • When the connection is initially established

  • After any successful Bind operation

  • After a StartTLS request is received

Not a replacement for ACIs

Care should be taken not to rely too heavily on connection policies to enforce security that can be addressed at a lower level by ACIs or Privileges.

If you don’t want a particular user to have access to ou=Customers, for example, you could create a connection policy that prevents that user from seeing ou=Customers. However, ACIs should also be created to ensure that the user does not have access to those entries if a client connection policy mistake is made.

Creating new client connection policies can easily introduce issues in the client connection policy evaluation order and process a more permissive policy before the more restrictive policies.

Define unauthenticated/insecure policy

When clients connect to PingDirectory, the initial connection is almost always unauthenticated.

If you are deleting the default client connection policy (or modifying it), make sure that there is at least one client connection policy that allows for a connection to transition from an unauthenticated state to an authenticated state or to allow an unauthenticated connection to send a StartTLS control.

Set restrictive client connection criteria

The evaluation order defined for a client connection policy will determine which client connection policy a client receives if it meets the criteria for more than one client connection policy. This has the potential to create unexpected scenarios if a valid client connection state is not considered or tested during the design of the client connection criteria and client connection policies.

Best practice is to implement mutually exclusive client connection criteria where possible to reduce or eliminate reliance on the evaluation order index when a connection’s client connection policy is determined.

Examples

The following is a sample list of group based ACIs that might be created for an OU that contains employee accounts:

dn: ou=people,ou=internal,dc=example,dc=com

aci: (target =
"ldap:///ou=people,ou=internal,dc=example,dc=com")(targetattr = "* || +") (version 3.0; acl "IP1 read internal people ou"; allow
(search,read,compare)
(groupdn="ldap:///cn=ADM-InternalPeopleRead,ou=groups,ou=admins,dc=example,dc=com");)

aci: (target =
"ldap:///ou=people,ou=internal,dc=example,dc=com")(targetattr != "userpassword || authpassword") (version 3.0; acl "IP2 write internal people"; allow (write) (groupdn="ldap:///cn=ADM-InternalPeopleUpdate,ou=groups,ou=admins,dc=example,dc=com");)

aci: (target = "ldap:///ou=people,ou=internal,dc=example,dc=com")(targetattr = "userpassword || authpassword") (version 3.0; acl "IP3 password update internal people"; allow (write)
(groupdn="ldap:///cn=ADM-InternalPeoplePwdReset,ou=groups,ou=admins,dc=example,dc=com");)

aci: (target = "ldap:///ou=people,ou=internal,dc=example,dc=com") (version 3.0; acl "IP4 add internal people"; allow (add)
(groupdn="ldap:///cn=ADM-InternalPeopleAdd,ou=groups,ou=admins,dc=example,dc=com");)

aci: (target = "ldap:///ou=people,ou=internal,dc=example,dc=com") (version 3.0; acl "IP5 delete internal people"; allow (delete)
(groupdn="ldap:///cn=ADM-InternalPeopleDel,ou=groups,ou=admins,dc=example,dc=com");)

aci: (target = "ldap:///ou=people,ou=internal,dc=example,dc=com") (version 3.0; acl "IP6 move branch internal people"; allow
(import,export)
(groupdn="ldap:///cn=ADM-InternalPeopleModDN,ou=groups,ou=admins,dc=example,dc=com");)

In this example, if we wanted to give the help desk the ability to search for user accounts, read user accounts, and reset passwords, we would place the help desk users into the following groups (either directly or, more likely, by creating a help desk group and nesting it into these groups):

  • ADM-InternalPeopleRead

  • ADM-InternalPeoplePwdReset

With descriptive group names, this makes the determination of a user’s rights to the directory intuitively obvious.

One further item to note is that the ACI that grants write access to userPassword (IP3) will need to be used in conjunction with the password-reset privilege before the help desk user can reset an employee’s password. In the Privileges best practices section, there is an example virtual attribute that is used to assign the password-reset privilege to users that are direct or indirect members of the group ADM-PasswordReset.

To enable help desk users to reset the passwords of employees, those help desk users would need to be added to ADM-InternalPeoplePwdReset, which grants write access to userPassword. Then you would need to nest the ADM-InternalPeoplePwdReset group into the ADM-PasswordReset group that is used by that virtual attribute, which will grant those help desk users the password-reset privilege.