Use non-identifiable user DNs - PingDirectory - 10.0

Attributes like uid, mail, and cn are often used as RDN attributes. However, this can lead to a few undesirable issues:

• This leads to personally identifiable information in the DNs for their accounts, and DNs are susceptible to being exposed in more ways than other content in user entries. For example, DNs commonly appear in log files. Further, if a client has access control permission to see any attributes in an entry, then they can also see its DN.
• Personal information might need to change. For example, a person can change their name, username, or email address. If this information is included in an entry’s DN, then it requires a modify DN rather than a modify operation to change it. This is more onerous for applications, and it can often mean that two operations are required when making such a change (a modify DN to change the values of attributes used in the entry’s RDN, and a separate modify operation to change other affected attributes that are not used in the RDN). It also means that an entry’s DN might not be a stable identifier over the life of that entry.
• If DNs contain identifiable information, then they also likely contain predictable information. If it is possible to make reasonable guesses about what a user’s DN might be, then their account is more susceptible to targeted attacks.

A better alternative is to choose an RDN attribute that is both unpredictable and unrelated to the user. UUIDs (universally unique identifiers, as described in RFC 4122) are a good way to accomplish this, and the PingDirectory server already generates a UUID value for every entry stored in the server, as the value of the entryUUID attribute, as described in RFC 4530.

The entryUUID operational attribute type is declared with the NO-USER-MODIFICATION constraint, which means that clients are not allowed to specify its value, nor should they attempt to do so, because it is vital that it be unique across all entries in the server. This means that clients can’t use it as the RDN attribute when adding new entries to the server. However, the PingDirectory server provides support for automatically using the entryUUID value that it generates as the entry’s RDN attribute, using it in place of whatever RDN the client initially provided. There are two ways to accomplish this:

• Clients can use the name with entryUUID request control in add requests to explicitly request that the server replace the RDN that it provides with one based on the entryUUID attribute.
• The server can be configured with criteria to automatically identify which entries should be automatically created with entryUUID as the naming attribute. This can be done with the following properties in the global configuration:
  • auto-name-with-entry-uuid-connection-criteria — Connection criteria that can be used to identify clients whose add requests should automatically be updated to use entryUUID as the naming attribute.
  • auto-name-with-entry-uuid-request-criteria — Request criteria that can be used to identify which add requests should automatically be updated to use entryUUID as the naming attribute.

If you cannot or do not wish to use entryUUID itself as the naming attribute for accounts, then you might still be able to define a custom attribute for this purpose. In that case, clients would generate the value and use it as the naming attribute in add requests.