RE: userPassword not SINGLE-VALUE ?

["Howard Chu" <hyc@symas.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of V Alex Brennen

> On Fri, 7 Nov 2003, Ace Suares wrote:
>
> >  - where is attibutetype userPassword defined ?
>
> It is defined in core.schema.  If it is commented
> out in your installation, you should not have been
> able to add any values for it.

In OpenLDAP 2.1 the definition is hardcoded in slapd, which is why it's been
commented out of the core.schema file.

> >From RFC2256 Section 5.36:
>
> 5.36. userPassword
>
>     ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
>       SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
>
> RFC2256: A Summary of the X.500(96) User Schema for use with LDAPv3
> http://mirror.cryptnet.net/rfcs/rfc2256.txt
>
>
> >  - is attribute userPassword meant to be Multivalued ?
>
> Yes, userPassword is meant to be Multivalued.  This is useful
> if you're working with legacy systems and attempting to a
> migration of a service such as unix user authentication in
> which some systems may be able to support a more secure
> password format such as MD5 hash over traditional unix
> crypt.
>
>
> > - if so, how does an application (qmail, proftpd, whatever)
> >   determine which userPassword to use ? Will it always use
> >   'the first' ?
>
> It can be application dependent depending on how the author
> of the application decided to implement the authentication.
> However, the author should have written code that would have
> tried each value of userPassword in order to match the
> standardized authentication of the LDAP Server itself.

Applications generally don't (and can't) use the userPassword attribute
directly. This attribute is used by the LDAP server for authenticating
connections to the LDAP service. On a typical installation with reasonable
ACLs, applications don't even have the access to read the attribute, let
alone discover that it contains multiple values. It's a non-issue at the
application level.

> >From RFC2829 Section 6.2:
>
>   "The server will, for each value of the userPassword
>    attribute in the named user's entry, compare these for
>    case-sensitive equality with the client's presented
>    password.  If there is a match, then the server will
>    respond with resultCode success, otherwise the server
>    will respond with resultCode invalidCredentials."
>
> RFC2829:  Authentication Methods for LDAP
> http://mirror.cryptnet.net/rfcs/rfc2829.txt
>
> In my opinion, if you come across an application that does
> not try each value of userPassword a bug should be reported
> to the author and a patch submitted.

Applications don't iterate over the values of the userPassword. The LDAP
server does, when processing a Bind request. It may also execute a Compare
request, but in neither case does the application know the actual content of
the userPassword attribute.

When an application uses LDAP as its authentication authority, it generally
performs an LDAP Bind request and the LDAP server takes care of the details.
The application needs no knowledge of what happens under the covers, it just
needs to know success/fail status.

> On Fri, 7 Nov 2003, Ace Suares wrote:
> > Hi,
> >
> > maybe a stupid question, but in what schema is the userPassword attribute
> > defined ?
> >
> > I am using
> >
> > core.schema
> > cosine.schema
> > nis.schema
> > qmail.schema
> >
> > and my own schema,
> >
> > but in noe of them is userPassword defined. (It's defined
> in core.schema and
> > cosine.schema, but for some reason commented out).
> >
> > I am asking this, because I tried to add userPassword as a
> Multi Valued
> > attribute, and it worked (i.e. I seem to have an entry
> which has two
> > userPasswords now).
> >
> > My questions:
> >
> > - where is attibutetype userPassword defined ?
> > - is attribute userPassword meant to be Multivalued ?
> > - if so, how does an application (qmail, proftpd, whatever)
> determine which
> > userPassword to use ? Will it always use 'the first' ?
> >
> > As usual, surprised and confused.
> >
> > _Ace
> >
> > website: http://www.suares.nl * http://www.qwikzite.nl

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support