[Fedora-directory-users] best practice for uid provisioning?

[Pierangelo Masarati]

On Fri, 2006-05-12 at 11:53 -0700, Scott wrote:
> Keyword is "decent" :)  It is an issue of
> authentication. The user submits uid, the entry is
> searched and the dn is retrieved for authn but the rdn
> doesnt match the uid. Some apps dont expect this. And
> it is an issue of a unique identifier for entries.
> Apps expect uid to be unique, expect it to be in the
> dn which is available anonymously.
> 
> I have had programmers write code in various languages
> like .NET to authenticate to ldap and have issues. And
> code examples or scripts they use assume uid is in the
> dn. Sometimes it works but usually it breaks and I
> have to explain to them that the uid is not in the dn.
> 
> Out of the box, products expect uid to be in the dn
> for authentication and unique identifier purposes.
> They will work but you have to modify them to use a
> different attribute as the rdn. Some network
> appliances that supposedly go against an ldap, fail,
> and are difficult to customize. And depending on the
> scope of the product, like the Sun Java Enterprise
> System, this issue can cause a rippling effect of
> customization. Their whole suite expects uid to be in
> the dn.
> 
> IMHO using a custom attribute may be an issue compared
> to a standard attribute in that the app needs to know
> the custom schema.

Custom attributes in the DN are actually discouraged by <draft-ietf-
ldapbis-dn>; this is not a good reason to assume that knowledge from an
entry can be safely inferred from the DN.  I think those applications
are just broken, and designing a DIT to take care of those broken
clients does not put enough pressure on implementors and maintainers to
fix them.

The typical silly requirement for uid in the DN is to "speedup"
authentication, so that the DN is build as

"uid=" + uid + ",ou=People,dc=example,dc=com"

or, even worse, the uid is extracted from the DN by a regex like

"^uid=([^,]+),ou=People,dc=example,dc=com$"

Note that <draft-ietf-ldapbis-dn> in Section 5.1 highlights that a DN
could inadvertently disclose sensitive information.  For example,
putting the uid in the DN of a publicly accessible DSA would allow
anonymous to know the uid of all users if the uid is protected by ACLs
but the DN is not.  The uid is half of one's credentials.

p.




Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati at sys-net.it
------------------------------------------