Fedora directory users - May 2006 - best practice for uid provisioning?

I inherited an ldap with odd design. It has a custom
attribute as the rdn in the dn for all entries. The
rdn is not the uid. People entries are provisioned
automatically and users choose a uid after their entry
has been created for login purposes. The custom
attribute for the rdn serves as a unique identifier.
The uid is also unique.

I found that getting products to work with this ldap
is difficult because they expect the uid to be in the
dn. Comments? Should I put the uid back in the dn?
Seems like it would make my life a lot simpler.

And what methods are best to create entries for users
without a uid? Maybe assign a temp and have them
change it? Or just assign them which is always the
easiest. Thanks.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Scott Gilbert wrote:
> I inherited an ldap with odd design. It has a custom
> attribute as the rdn in the dn for all entries. The
> rdn is not the uid. People entries are provisioned
> automatically and users choose a uid after their entry
> has been created for login purposes. The custom
> attribute for the rdn serves as a unique identifier.
> The uid is also unique.
>
> I found that getting products to work with this ldap
> is difficult because they expect the uid to be in the
> dn.
Which products have problems?
> Comments? Should I put the uid back in the dn?
> Seems like it would make my life a lot simpler.
>   
Sure.  A simple modrdn when the uid is assigned.
> And what methods are best to create entries for users
> without a uid? Maybe assign a temp and have them
> change it? Or just assign them which is always the
> easiest. Thanks.
>   
Either way, but the former sounds like more work.
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Scott Gilbert schrieb:
[...]
> I found that getting products to work with this ldap
> is difficult because they expect the uid to be in the
> dn. Comments? Should I put the uid back in the dn?
I don''t know of any decent LDAP-aware software that has such
requirements. Can you give examples?

-- 
CU,
   Patrick.

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.

--- Patrick von der Hagen <hagen@rz.uni-karlsruhe.de>
wrote:
> Scott Gilbert schrieb:
> [...]
> > I found that getting products to work with this
> ldap
> > is difficult because they expect the uid to be in
> the
> > dn. Comments? Should I put the uid back in the dn?
> I don''t know of any decent LDAP-aware software that
> has such
> requirements. Can you give examples?
> 
> -- 
> CU,
>    Patrick.
> > --
> Fedora-directory-users mailing list
> Fedora-directory-users@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

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@sys-net.it
------------------------------------------