До того, як Microsoft "прийняла, розширила та змінила" LDAP, у більшості реалізацій були об'єкти, які представляли корінь дерева. Тобто треба починати звідкись.
З причин, про які мені не зовсім зрозуміло, в Active Directory кожен домен у дереві / лісі вкорінений з ім'ям, яке dc = домен, dc = com, що насправді не є двома окремими об'єктами, скоріше це віртуальний корінь каталогу простір імен.
Я думаю, що деяка частина цього походить від того, що незалежно від того, що сказано про Active Directory, це все ще є низка пов'язаних доменів, і кожен домен потрібно розглядати як окрему сутність.
Тепер в дереві AD є автоматичні транзитивні трести, тому для кінцевих користувачів це стає менш важливим, але, хоча простір імен виглядає як суміжний, це насправді.
Це стає більш очевидним при деяких правилах називання з AD. Наприклад, sAMAccountName повинен бути унікальним у домені, незалежно від того, перебувають вони в одному контейнері чи ні. Тобто повне відоме ім’я повинно бути унікальним (у вас не може бути двох користувачів Джона Сміта в одному контейнері), але коротке ім'я, яке використовується для багатьох речей внутрішньо (sAMAccountName), має бути унікальним у всьому домені.
Інші служби каталогів або мають дещо подібні вимоги, наприклад, унікальний ідентифікатор дійсно повинен бути унікальним у всьому каталозі, але це більше, тому що програми зазвичай роблять це припущення, оскільки автори програм занадто ліниві, щоб вирішити складну проблему (я не звинувачую їх, це складна проблема), як обробити двох користувачів із короткими іменами jsmith, які намагаються скористатися послугою, але наявними у двох різних контейнерах. (Тобто, можливо, cn = jsmith, ou = London, dc = acme, dc = com і cn = jsmith, ou = Texas, dc = acme, dc = com).
Як ваша програма за допомогою цього каталогу повинна вирішити, якого користувача використовувати? Звичайна відповідь - нехай користувач вирішує. Але це означає втілити цей випадок, представити користувальницький інтерфейс користувачеві на вибір і що інше.
Більшість авторів програм просто ігнорують цю можливість і просто використовують uniqueID або sAMAccountName, тому що це унікально (свого роду) і простіше зробити.
Різниця між uniqueID та sAMAccountName полягала б у тому, що uniqueID повинен бути унікальним у всьому просторі імен каталогу. Тоді як sAMAccountName є унікальним лише у домені. Якщо дерево AD має кілька доменів, немає гарантії унікальності між доменами.