Data encryption is only applied to the on-disk storage for a Directory Server instance. It does not automatically protect information accessed or replicated between servers, although the server offers other mechanisms to provide that protection (i.e., SSL, StartTLS, SASL). Ensuring that all client communication uses either SSL or StartTLS encryption and ensuring that all replication traffic uses SSL encryption ensures that the data is protected from unauthorized individuals who may be able to eavesdrop on network communication. This communication security may be enabled independently of data encryption (although if data encryption is enabled, then it is strongly recommended that secure communication be used to protect network access to that data).

However, for client data access, it may not be as simple as merely enabling secure communication. In some cases, it may be desirable to allow insecure access to some data. In other cases, it may be useful to have additional levels of protection in place to ensure that some attributes are even more carefully protected. These kinds of protection may be achieved using sensitive attribute definitions.

Each sensitive attribute definition contains a number of configuration properties, including:
  • attribute-type . Specifies the set of attribute types whose values may be considered sensitive. At least one attribute type must be provided, and all specified attribute types must be defined in the server schema.
  • include-default-sensitive-operational-attributes . Indicates whether the set of sensitive attributes should automatically be updated to include any operational attributes maintained by the Directory Server itself that may contain sensitive information. At present, this includes the ds-sync-hist operation attribute, which is used for data required for replication conflict resolution and may contain values from other attributes in the entry.
  • allow-in-filter . Indicates whether sensitive attributes may be used in filters. This applies not only to the filter used in search requests, but also filters that may be used in other places, like the assertion and join request controls. The value of this property must be one of:
    • Allow (allow sensitive attributes to be used in filters over both secure and insecure connections)
    • Reject (reject any request which includes a filter targeting one or more sensitive attributes over both secure and insecure connections)
    • Secure-only (allow sensitive attributes to be used in filters over secure connections, but reject any such requests over insecure connections)
  • allow-in-add . Indicates whether sensitive attributes may be included in entries created by LDAP add operations. The value of this property must be one of:
    • Allow (allow sensitive attributes to be included in add requests over both secure and insecure connections)
    • Reject (reject any add request containing sensitive attributes over both secure and insecure connections)
    • Secure-only (allow sensitive attributes to be included in add requests received over a secure connection, but reject any such requests over an insecure connection)
  • allow-in-compare . Indicates whether sensitive attributes may be targeted by the assertion used in a compare operation. The value of this property must be one of:
    • Allow (allow sensitive attributes to be targeted by requests over both secure and insecure connections)
    • Reject (reject any compare request targeting a sensitive attribute over both secure and insecure connections)
    • Secure-only (allow compare requests targeting sensitive attributes over a secure connection, but reject any such requests over an insecure connection)
  • allow-in-modify . Indicates whether sensitive attributes may be updated using modify operations. The value of this property must be one of:
    • Allow (allow sensitive attributes to be modified by requests over both secure and insecure connections)
    • Reject (reject any modify request updating a sensitive attribute over both secure and insecure connections)
    • Secure-only (only modify requests updating sensitive attributes over a secure connection, but reject any such request over an insecure connection)

The allow-in-returned-entries, allow-in-filter, allow-in-add, allow-in-compare, and allow-in-modify properties all have default values of secure-only, which prevents the possibility of exposing sensitive data in the clear to anyone able to observe network communication.

If a client connection policy references a sensitive attribute definition, then any restrictions imposed by that definition will be enforced for any clients associated with that client connection policy. If multiple sensitive attribute definitions are associated with a client connection policy, then the server will use the most restrictive combination of all of those sets.

Note that sensitive attribute definitions work in conjunction with other security mechanisms defined in the server and may only be used to enforce additional restrictions on clients. Sensitive attribute definitions may never be used to grant a client additional access to information that it would not have already had through other means. For example, if the employeeSSN attribute is declared to be a sensitive attribute and the allow-in-returned-entries property has a value of Secure-only, then the employeeSSN attribute will only be returned to those clients that have both been granted permission by the access control rules defined in the server and are communicating with the server over a secure connection. The employeeSSN attribute will be stripped out of entries returned to clients normally authorized to see it if they are using insecure connections, and it will also be stripped out of entries for clients normally not authorized to see it even if they have established secure connections.