Pierangelo has it exactly right. The place to fix this is at the
application that's attempting to authenticate. A few years ago, I had
to push back on a certain vendor of portfolio/project management
software and got their development team to admit they'd hardcoded their
LDAP config to work with a certain fixed DIT scheme. My response to
them was that they should be ashamed of themselves for such shoddy
programming. Subsequent versions of the same software now do The Right
Thing (TM) and allow you to define the user ID attribute to be used and
then do a search on LDAP to pull back the dn of the corresponding entry
before attempting to authenticate. As others have said on this thread,
which you could use a custom attribute for the user ID, down the road
you'll regret it because you're inevitably going to have integration
problems with COTS applications you may need to integrate with.
The scheme I've found most useful is to assign a unique
identifier to each user. Something completely meaningless, like a
lowercase letter followed by a bunch of digits (that pattern will work
as an ID in most NOS or non directory systems like AD, NDS, Unix, NT
SAM, etc). Just increment the numeric suffix as you assign each new ID.
Using e-mail like aliases is generally a pain because it requires you
to change the ID every time you have a name change. Same is true for
IDs that are tied to a user's role (like using different letter
prefixes for employees and temps). It's usually pretty easy to build a
routine into your user provisioning software that will increment the ID
value automatically. Any provisioning software that won't let you do
this should get rejected out of hand (with a pointed memo to the vendor
giving the reason for the rejection). Getting any enterprise,
especially one where system administration is decentralized, to adopt a
common ID scheme is almost always difficult and usually requires
considerable effort on the 8th layer of the OSI model -- Politics.
Phil Lembo