Auditing data content

It’s also a good idea to keep track of the data itself and identify any potential security-related issues that affect user entries or other data.

Data security auditors

One way to do this would be to regularly export the data to LDIF (ideally in encrypted form so that it is not exposed in the clear) and examine its content for unusual or undesirable conditions. You could also do this with search operations. However, in large data sets, such searches can be expensive and time consuming.

The server also provides an “audit data security” administrative task and an associated audit-data-security command-line tool that can help with this. When invoked, the task causes the server to efficiently iterate through all entries in the configured set of backends, comparing each one against a configured set of data security auditors.

The report is written into a directory structure on the server filesystem. There is a summary.ldif file that provides a summary of all of the processing that was performed. There is also a subdirectory for each of the backends that were examined with a set of LDIF files containing more detailed output from each of those auditors.

Data security auditors included with the PingDirectory server do the following:

Identify all entries that contain ACIs.
Identify administratively disabled users.
Identify users with passwords that are expired or are about to expire.
Identify users whose accounts are locked because of too many failed authentication attempts because it’s been too long since the user authenticated or because the user did not change their password in a timely manner after an administrative reset.
Identify users who have multiple passwords.
Identify users who have explicitly configured privileges or root users or topology administrators who inherit the default set of root privileges.
Identify users who have passwords encoded with password storage schemes that are considered weak.
Identify all accounts with password policy state issues that can currently or soon affect their usability.
Identify all accounts with activation times in the future, expiration times in the past, or expiration times in the near future.
Identify accounts with passwords encoded using a deprecated password storage scheme.
Identify accounts for users that have not authenticated in longer than a specified length of time.
Identify accounts that are configured to use a nonexistent password policy (and are therefore unable to authenticate).
Identify accounts that match a specified search filter.

You can also use the PingDirectory server SDK to develop custom data security auditors for identifying other kinds of issues.

The audit-data-security tool offers the provided set of command-line arguments in addition to the usual options for connecting and authenticating to the server and scheduling tasks:

--outputDirectory: The directory (on the server filesystem) where the report files are created. If this is not specified, then it defaults to a directory whose name reflects the current time in the reports/audit-data-security subdirectory.
--reportFilter: An optional filter that can be used to indicate which entries should be examined. If this is provided, then only entries matching that filter are audited. Otherwise, all entries are examined. This can be provided multiple times if multiple filters should be specified, and only entries matching at least one of those filters are examined.
--backendID: An optional set of backend IDs for the backends to examine. If this is not provided, then all supported backends, including local DB backends and the server configuration, are examined.
--includeAuditor: An optional set of the names for the data security auditors that are invoked. By default, all data security auditors defined in the configuration are included, except for those excluded by the --excludeAuditor argument.
--excludeAuditor: An optional set of the names for the data security auditors that are not invoked.

Soft deletes

Normally, when an authorized client deletes an entry, it is completely removed from the server. However, the PingDirectory server provides support for soft deletes, in which the server preserves the entry instead of removing it. When an entry is soft-deleted, the server makes the following changes to it:

The server adds the ds-soft-delete-entry auxiliary object class to the entry, which causes it to be hidden from normal search results.
The server renames the entry to add the entry’s entryUUID attribute to the set of RDN attributes. This allows a new entry to be created with the same distinguished name (DN) as the former entry without conflicting with the soft-deleted form of the entry.
The server adds the following additional operational attributes to the entry:
- ds-soft-delete-from-dn — The original DN for the entry.
- ds-soft-delete-timestamp — The time that the entry was soft-deleted.
- ds-soft-delete-requester-dn — The DN of the user that requested the delete.
- ds-soft-delete-requester-ip-address — The IP address of the client that requested the delete.

There are two ways that regular deletes can be turned into soft deletes. The first is to include the soft delete request control in the delete request, such as using the --softDelete argument to ldapmodify.

However, it is also possible to have the server automatically convert regular deletes into soft deletes. This can be done by creating a soft-delete policy, which can include the following properties:

auto-soft-delete-connection-criteria: Connection criteria that can identify client connections whose deletes should be converted to soft deletes.
auto-soft-delete-request-criteria: Request criteria that can identify delete requests that should be converted to soft deletes.
soft-delete-retention-time: The maximum length of time that soft-deleted entries should be retained in the server.
soft-delete-retain-number-of-entries: The maximum number of soft-deleted entries that should be retained in the server.

After a soft delete policy has been created, the global configuration can be updated to use it with the following property:

soft-delete-policy: The soft-delete policy that should be used by the server. If this is not configured, then soft deletes are disabled in the server, even for delete requests that use the soft delete request control.

Only soft-delete policies that contain values for at least one of the auto-soft-delete-connection-criteria and auto-soft-delete-request-criteria properties can automatically convert regular deletes to soft deletes. If the server has a soft delete policy without criteria, then soft deletes are only allowed with the soft delete request control.

Turning deletes into soft deletes provides a way to verify the content of deleted entries. Even though soft-deleted entries are excluded from search results by default, users with the soft-delete-read privilege can retrieve them by including the soft-deleted entry access request control in the search request, such as by providing the --includeSoftDeletedEntries argument to ldapsearch.

If necessary, soft-deleted entries can be resurrected with the undelete request control in an add request, such as using the --allowUndelete argument to ldapmodify. The attributes of the add request can be used to provide the details of the undelete. In particular, the DN from the add request specifies the DN to use for the resurrected entry, and the ds-undelete-from-dn attribute specifies the DN of the soft-deleted entry to undelete.