Yes, I have seen some, but very little use of semantically void values. Generally what I have seen for companies that have gotten past the display name issue inherent in the MSFT tooling via provisioning automation and instead use userids or employeeids or some other value that is already set up with some generation system to guarantee uniqueness and used for tracking employees throughout the company. Several of the userid systems in use were specifically designed/built and have existed for years to avoid any need for renames since some systems don't handle renames well.
Renames nor moves aren't generally much of a deal in the Active Directory world as the MSFT clients/apps mostly don't care. They dynamically look up the DNs via relatively static values to get to the objects that they need to deal with and dynamically discover the machines that provide the services they need. The issues generally crop up with non-MSFT based apps and systems using Active Directory that have hard coded values[1] instead of using discovery methods. Many if not most small/medium companies with very homogeneous environments will move and/or rename user objects and change server names/ips etc without a second though and generally no impact. Larger, more heterogeneous environments, especially those with a measurable *nix environment have learned that they have to be a lot more careful with any changes once they have tried to integrate them into the AD environment either for LDAP or Kerberos. joe [1] Both servers and DNs. -- O'Reilly Active Directory Fourth Edition - http://www.joeware.net/win/ad4e.htm Blog: http://blog.joeware.net -----Original Message----- From: bounce-ldap-5210...@listserver.itd.umich.edu [mailto:bounce-ldap-5210...@listserver.itd.umich.edu] On Behalf Of Peter Schober Sent: Wednesday, March 07, 2012 7:32 AM To: ldap@umich.edu Subject: [ldap] RDN construction (was: Re: LDAPS Connection difficulties) Digressing further from the original topic... * joe <j...@joeware.net> [2012-03-07 01:29]: > Probably not. The user ids usually aren't stored in the root of the > ldap directory and there is no telling what they used for the RDN of > the user object. Most companies, unfortunately, don't use username > as the RDN value, they are usually using a display name of some sort > (yes I know, stupid but is influenced by the default MSFT > provisioning tools and Exchange). In comparison with a person's real name using username (login name, NetID, whatever) as most specific RDN certainly is certainly preferrable. But I thought above moving away from using even the username for contruction of the RDN and instead create some semantically void, persistent, opaque identifier (think type 4 UUID or something like that, unknown to the user, so that's not something anyone would ever type into a login form for authN). I would hope to make object renames completely unnecessary (since usernames might still change -- by fiat -- how much we may try to avoid that) and also not give the username away when it's not needed, since it's currently always visible in the DN itself (or entryDN opattr). Is anyone doing that? Is it worth the effort? -peter
