jspωiki
Which Jane Doe

Overview#

Which Jane Doe is used to explain one of the reasons for Best Practices For Unique Identifiers

Use case for Which Jane Doe#

Jane L Doe was hired in 2001 and assigned jdoe as a UserId then terminated in 2005

Jane S Doe was hired in 2006 and assigned jdoe as a UserId then terminated in 2009

Jane L Doe was re-hired in 2010 and assigned jdoe as a UserId then terminated in 2011

Jane S Doe was hired in 2013 and assigned jdoe as a UserId then terminated in 2012

The Auditing Monitoring Metrics Logging applicaitons recorded only the UserId "jdoe" within the logs. How can we reasonably prove Which Jane Doe did what?
Sure we could fish out and coordinate the times, but if this shows up in court, who can explain it?

Use case NOT Unique LDAP Entries#

This same scenario applies when applicaitons utilize the UserId and expect UserId to be unique.

Often the application will use the UserId (as presented on the login page) as their identifier for the entity within the application rather than the Distinguished Name

In this Use case the Organizational Entity decided to use entries to avoid collisions of existing UserIds in a different OrganizationalUnit instead of remediating them.

This Use case exists when there are any non-unique UserIds in the DIB but in different locations.

Sometime passed and as always, things and personnel changed and an application used the LDAP Entry jdoe with a credential for the entity within the application. As the Bind Request passed, the application Authorized the LDAP Entry jdoe to the application.

A few days later, a LDAP Entry jdoe (from a different OU) with a credential for the entity within the application. As the Bind Request passed, the application Authorized the LDAP Entry jdoe to the application. This LDAP Entry jdoe did some work and thought it was curious that the data presented was not as they recalled, but continued.

As some applicaitons, even when multiple entries are returned, will use the first or last entry received and the LDAP RFCs clearly state there is no "order" guarantee in returned results, this Use case can and does happen.

More Information#

There might be more information for this subject on one of the following: