best practice for uid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux