RE: userIdentity in LDAP Password Modify

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

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]

> At 03:59 PM 12/1/2003, Howard Chu wrote:
> >> -----Original Message-----
> >> From: owner-openldap-devel@OpenLDAP.org
> >> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> >
> >> Note that this field may or may not be a DN.  It may be just
> >> a simple user name, e.g. "bob", or it may even be an LDAP
> >> authzid (e.g., u:bob or dn:cn=bob,dc=example,dc=com).
> >
> >> Hence, we should do, much like we do for SASL authzids, apply
> >> appropriate mappings to produce the internal DN representing
> >> the user.
> >>
> >> Additionally, the user's password may or may not be held in the
> >> directory.  It could be held in sasldb or other external store.
> >>
> >> Anyways, this message is intended just to enumerate some of the
> >> things which should find their way onto the TODO list.
> >
> >Thinking out loud about what steps are needed...
> >
> >If a DN is provided, do we need to apply SASL-regexp mapping
> >to it? I would think not.
>
> I would think we'd apply the same regexes (and lookups) we do to
> DN generated/provided via SASL mechanisms.

We do mapping for SASL-generated DNs because they were not directly provided
by the user, and because these generated DNs aren't meant to be actually used
in the directory. In this case though, the DN *is* directly specified by the
user. I don't think we should be altering it at all, the user should have
provided a valid DN for an entry to operate on. Looking back, I'd consider
the fact that we alter (regexp-map) user-provided dn: authzIDs as a bug.

> >If we get a "u:" prefix we can let SASL take care of it.
>
> Or map it to a DN (like we do in our SASL code) and then map it.

Right. Currently the SASL code requires a "dn:" prefix on incoming DNs
(except for a DN from SASL/EXTERNAL). Anything else (with or without a "u:"
prefix) is considered a simple username. This kind of says we should require
a "dn:" for the extop ID field as well. It would be nice if we could make
this explicit requirement.

I had thought that mapping the simple names would be taken care of
automatically when we call sasl_setpass, but that's not so good. Currently we
restrict SASL setpass to only changing the current user's password. Since
slapd often runs as a privileged user, and there are no other privilege
checks in sasldb etc., we probably need to maintain this policy.

To provide maximum functionality when using slapd for the SASL secrets, I
guess we need to map the username first, and see if we have a valid entry for
it. If so, we can attempt the change. If the username is the same as the
current session's SASL username, we can also attempt the change. Otherwise we
have to reject it.

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