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(a)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(a)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