Thanks Phil. From my experience its a good idea to have a userid "and" a unique identifier for all entries in the ldap. We use a uuid, and thats our rdn. At some point in the netscape/iplanet/sun/aol directory server road to red hat, it began assigning a uuid as an operational attribute for internal purposes. Same thing really but since its operational its not easy to work with. Like you, I have had mixed results with COTS. Some work and some dont have any flexibility. Hopefully we can instill in vendors and their developers that we are going to have a unique identifier other than the uid and hey, what a surprise, it might be in the DN. --- Phil Lembo <phil.lembo at gmail.com> wrote: > 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 > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
