It is a common practice to include identifiable information in user distinguished names (DNs).
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.
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
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
- 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
- The server can be configured with criteria to automatically identify which
entries should be automatically created with
entryUUIDas 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
entryUUIDas 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
entryUUIDas 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.
It is not possible to use
entryUUID as the naming
attribute in the accounts for root users and topology administrators. These accounts
reside in the configuration, and the server’s configuration framework requires that
cn be used as the naming attribute for those entries. However,
we strongly recommend creating those accounts with a
cn value that
is not predictable and does not contain any identifiable information. This also
applies to alternate bind DNs for those users.