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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20060514/cd6eb422/attachment.html
