PingDirectory

Migrating ACIs from Oracle to the PingDirectory server

This section describes the most important differences in access control evaluation between Oracle and the server.

Support for macro ACIs

Oracle supports macro access control instructions (ACIs), making it possible to define a single ACI that you can use to apply the same access restrictions to multiple branches in the same basic structure.

Macro ACIs are infrequently used and can cause severe performance degradation, so the server does not support them. However, you can achieve the same result by creating the same ACIs in each branch.

Support for the roleDN bind rule

Oracle roles are a proprietary, non-standard grouping mechanism that provide little value over standard grouping mechanisms.

The server does not support Oracle Directory Server Enterprise Edition (DSEE) roles and does not support the use of the roleDN ACI bind rule. However, you can achieve the same behavior by converting the DSEE roles to standard groups and using the groupDN ACI bind rule.

Targeting operational attributes

The Oracle access control model doesn’t differentiate between user attributes and operational attributes.

In the Oracle access control model, using targetattr="*" automatically targets both user and operational attributes. Using an exclusion list like targetattr!="userPassword" automatically targets all operational attributes in addition to all user attributes except userPassword. This presents several significant security holes here users are unintentionally given access to operational attributes. In some cases, it could allow users to exempt themselves from password policy restrictions.

The server treats operational attributes differently from user attributes and never automatically includes operational attributes. For example, targetattr="*" targets all user attributes but no operational attributes, and targetattr!="userPassword" targets all user attributes except userPassword but no operational attributes.

You can target specific operational attributes by including the names in the list, such as targetattr="creatorsName||modifiersName". You can target all operational attributes by using the "+" character. For example, targetattr="+" targets all operational attributes but no user attributes, and targetattr="*||+" targets all user and operational attributes.

Example

The following example searches for all immediate children of ou=People,dc=example,dc=com. The attributes returned are restricted to sn, givenName, and all operational attributes.

ldapsearch --bindDN uid=admin,dc=example,dc=com --bindPassword password \
     --baseDN ou=People,dc=example,dc=com --searchScope one '(objectclass=*)' \
     sn givenName "+"

Example

You can use compound filters to search for a subset of the entries in the ou=People,dc=example,dc=com subtree. The following example limits the returned entry amount to 200, and the server will spend no more than 5 seconds processing the request.

ldapsearch --bindDN uid=admin,dc=example,dc=com --bindPassword password \
     --baseDN ou=People,dc=example,dc=com --searchScope sub --sizeLimit 200 \
     --timeLimit 5 "(&(sn<=Doe)(employeeNumber<=1000))" ds-entry-unique-id \
     entryUUID

Specify "*" in a search attribute list to represent all user attributes. Specifying "+" retrieves all operational attributes.

About this task

The following standards are used in PingDirectory as part of the LDAP specification.

Standard Overview

RFC 3673

Describes the use of "+" to represent all operational attributes

RFC 4511

Describes the use of "*" to represent all user attributes

Steps

  • To search the cn=schema entry and return all user and operational attributes, run ldapsearch.

    Example:
    bin/ldapsearch --baseDN cn=schema --searchScope base "(objectclass=*)" "*" "+"

Exclude attributes

The server accepts syntax, in addition to the RFC 3673, RFC 4511, and RFC 4529 standards, that allows you to exclude attributes from search results.

About this task

To exclude an attribute from the search results in PingDirectory:

Steps

  • Prefix the attribute name with either "^" or "!"

    Example:

    The following example returns organizational units (OUs) that are part of the object class group in Colorado with the exception of OUs in Denver.

    (&(objectClass=group)(&(ou:dn:=Colorado)(!(ou:dn:=Denver))))
    Example:

    The following example returns all users that aren’t device.

    (&(objectClass=user)(!(objectClass=device)))

    To exclude all attributes associated with an object class, prefix the object class name with either "^@" or "!@".

Specification of global ACIs

Both Oracle Directory Server Enterprise Edition (DSEE) and the server support global ACIs, which you can use to define ACIs that apply throughout the server.

In servers with multiple naming contexts, this feature allows you to define a rule once as a global ACI rather than maintaining an identical rule in each naming context.

In DSEE, global ACIs are created by modifying the root DSA-specific entry (DSE) to add values of the aci attribute. In the server, you manage global ACIs with dsconfig referenced in the global-aci property of the access control handler.

Defining ACIs for non-user content

In Oracle Directory Server Enterprise Edition (DSEE), you can write to the following backends to define ACIs:

  • Configuration

  • Monitor

  • Changelog

  • Tasks

In the server, you should define access control for private backends as global ACIs, such as the following backends:

  • Configuration

  • Monitor

  • Schema

  • Changelog

  • Tasks

  • Encryption settings

  • Backups

  • Alerts

Limiting access to controls and extended operations

Oracle Directory Server Enterprise Edition (DSEE) provides limited support for restricting access to controls and extended operations.

To the extent that you can control access to controls and extended operations with access control instructions (ACIs), DSEE defines entries with a distinguished name (DN), such as oid={oid},cn=features,cn=config, where {oid} is the OID of the associated control or extended operation. For example, the following DSEE entry defines ACIs for the persistent search control.

oid=2.16.840.1.113730.3.4.3,cn=features,cn=config

In the server, you can use the targetcontrol keyword to define ACIs that grant or deny access to controls. You can use the extop keyword to define ACIs that grant or deny access to extended operation requests.

Tolerance for malformed ACI values

If the server is running with less than the intended set of access control instructions (ACIs), it might prevent access to data that should be allowed or grant access to data that should be restricted. In Oracle Directory Server Enterprise Edition (DSEE), if the server encounters a malformed access control rule (ACR), it ignores the rule. This can cause the server to run with less than the intended set of ACIs. To guard against this, the server is more strict about the ACRs that it accepts.

When performing an LDIF import, the server rejects any entry containing a malformed or unsupported ACR. The server also rejects any add or modify request that attempts to create an invalid ACI.

In the unlikely event that a malformed ACI is accepted into the data, the server immediately places itself in lockdown mode. In lockdown mode, the server terminates connections and rejects requests from users without the lockdown-mode privilege. Lockdown mode allows an administrator to correct the problem without risking exposure to user data.

To review any rejected ACIs, run the import-ldif tool with the --rejectFile option.

About the privilege subsystem

In Oracle Directory Server Enterprise Edition (DSEE), only the root user is exempt from access control evaluation.

While administrators can create access control instructions (ACIs) that give normal users full access to any content, they can also create ACIs that would make a portion of the data inaccessible to those users. Additionally, some tasks can only be accomplished by the root user and the capabilities assigned to the root user can’t be restricted.

The server uses a privilege subsystem to control the capabilities available to various users. Non-root users can be granted limited access to certain administrative capabilities, and restrictions can be enforced on root users. Additionally, certain risky actions require that the requester have certain privileges in addition to the sufficient access control rights to process the operation.

These risky actions include:

  • Interacting with the server configuration

  • Changing another user’s password

  • Impersonating another user

  • Shutting down and restarting the server

Identifying unsupported ACIs

To determine whether access control instructions (ACIs) are suitable for use, the server provides a validate-acis tool that you can use to examine content in an LDIF file or data in another directory server, such as an Oracle Directory Server Enterprise Edition (DSEE) instance.

When migrating data from a DSEE deployment into a server instance, use the validate-acis tool to determine whether ACIs contained in the data are acceptable. If any problems exist, update the data to redefine the ACIs so they are suitable for use in the server.

For more information, see Validating ACIs before migrating data.