!!! Overview
[{$pagename}] is used to explain one of the reasons for [Best Practices For Unique Identifiers]

!! [Use case] for [{$pagename}]
Jane L Doe was hired in [2001|Year 2001] and assigned jdoe as a [UserId] then terminated in [2005|Year 2005]

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

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

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

The [Auditing Monitoring Metrics Logging] applicaitons recorded only the [UserId] "jdoe" within the logs. How can we reasonably prove [{$pagename}] 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|LDAP Entry]
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|Authorization] 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|Authorization] 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:
[{ReferringPagesPlugin before='*' after='\n' }]