PingDirectory

Key access control features

The directory server provides important access control features that provide added security for its entries.

Improved validation and security

The server provides an access control model with strong validation to help ensure that invalid access control instructions (ACIs) are not allowed into the server.

The server ensures that all access control rules (ACRs) added over LDAP are valid and can be fully parsed. The server rejects any operation that attempts to store one or more invalid ACIs. It also validates ACIs contained in data imported from an LDIF file. The server rejects any entry containing a malformed aci value.

As an additional level of security, the server examines and validates all ACIs stored in the data whenever a backend is brought online. If the server finds any malformed ACIs in the backend, it generates an administrative alert to notify administrators of the problem and places itself in lockdown mode. While in lockdown mode, the server only allows requests from users who have the lockdown-mode privilege. This action allows administrators to correct the malformed ACI while ensuring that no sensitive data is inadvertently exposed because of an ACI not being enforced. When the problem has been corrected, the administrator can use the leave-lockdown-mode tool or restart the server to allow it to resume normal operation.

Global ACIs

Global ACIs are a set of ACIs that apply to entries anywhere in the server or scoped to only apply to a specific set of entries.

Global ACIs work in conjunction with ACRs stored in user data and provide a convenient way to define ACIs that span disparate portions of the directory information tree (DIT).

In the Server, global ACIs are defined within the server configuration, in the global-aci property of the configuration object for the access control handler. To view and manage global ACIs, use configuration tools like dsconfig and the administrative console.

The global ACIs available by default in the Server include:

  • Allow anyone, including unauthenticated users, to access key attributes of the root DSA-specific entry (DSE), including:

    • namingContexts

    • subschemaSubentry

    • supportedAuthPasswordSchemes

    • supportedControl

    • supportedExtension

    • supportedFeatures

    • supportedLDAPVersion

    • supportedSASLMechanisms

    • vendorName

    • vendorVersion

  • Allow anyone, including unauthenticated users, to access key attributes of the subschema subentry, including:

    • attributeTypes

    • dITContentRules

    • dITStructureRules

    • ldapSyntaxes

    • matchingRules

    • matchingRuleUse

    • nameForms

    • objectClasses

  • Allow anyone, including unauthenticated users, to include the following controls in requests made to the server:

    • Authorization identity request

    • Manage DSA IT

    • Password policy

    • Real attributes only

    • Virtual attributes only

  • Allow anyone, including unauthenticated users, to request the following extended operations:

    • Get symmetric key

    • Password modify request

    • Password policy state

    • StartTLS

    • Who Am I?

Access controls for public or private backends

Depending on their intended purpose, the PingDirectory server classifies backends as either public or private.

A backend is private if one of the following applies:

  • Its content is generated by the server itself, such as the root DSE, monitor, and backup backends.

  • It is used in the operation of the server, such as the configuration, schema, task, and trust store backends.

  • Its content is maintained by the server, such as the LDAP changelog backend.

A public backend is intended to hold user-defined content, such as user accounts, groups, application data, and device data.

The server access control model also supports the distinction between public backends and private backends. Many private backends do not allow writes of any kind from clients, and some of the private backends that do allow writes only allow changes to a specific set of attributes. As a result, you should define any ACI intended to permit or restrict access to information in private backends as global ACIs, rather than attempting to add those instructions to the data for that private backend.