[Date Prev][Date Next]
Re: passwd extop backend selection (ITS#2851)
At 09:07 AM 12/1/2003, Pierangelo Masarati wrote:
>> I think this patch should not be applied. (redirected discussion to
>> The problem you are trying to solve is internal to slapd(8) and hence
>> shouldn't be addressed without regard to what's on the wire. That is,
>> the problem here is purely with slapd(8) management of which backend(s)
>> is associated with the current LDAP association.
>> While we could change slapd(8) to support changing of selected (by
>> userIdentity) passwords, then that's what slapd(8) has to do when a
>> userIdentity is provided. That is, it must change the password
>> associated with userIdentity. That cannot be assumed to be the same
>> user as that of the current LDAP association.
>I don't quite understand your comment. Can you elaborate
>on "LDAP association"?
The "LDAP association" refers to the authentication and
authorization context established between the client and
server at the LDAP layer in the protocol stack. That is,
at the server, it refers to the identity associated with
the client at the LDAP layer (as opposed to other layers
such as TLS, IPSEC, etc.).
>Moreover, my point was quite "smooth": if slapd serves
>"dc=a,dc=com" in one database and "dc=b,dc=com" in another
>database, then if "uid=foo,dc=a,dc=com" tries to change
>"uid=bar,dc=b,dc=com"'s password, which should be legal
>as soon as "uid=foo,dc=a,dc=com" authenticated and has write
>access to "uid=bar,dc=b,dc=com"'s password, then slapd
>currently looks up "uid=bar,dc=b,dc=com" in "dc=a,dc=com",
>which gives no such object.
>My change uses "uid=bar,dc=b,dc=com"'s naming context to
>select the appropriate backend.
>The point I was concerned with is: is this acceptable?
Ah, so. I was looking at your patch in the context that
we only supported changing of the user's password (userIdentity
not present). Seems your patch is actually intended to
be taken in the context of other recent changes to the code.
In looking at current HEAD (which includes your patch),
I think the patch is acceptable.
One note (for the community): we shouldn't assume that the
userIdentity field is a DN. It could be a simple user name
(or maybe an authzid). So, like we do for SASL userids and
authzid, apply appropriate mappings and, if in the directory,
do directory updates, and if in SASLDB, do sasl updates.
>I think it is, but dealing with secrets makes me think
>twice before going straight down the path ;)
>> At 10:47 PM 11/30/2003, email@example.com wrote:
>>>Full_Name: Pierangelo Masarati
>>>OS: Linux RH
>>> Submission from: (NULL) (220.127.116.11)
>>>Submitted by: ando
>>>passwd_extop() in servers/slapd/passwd.c uses
>>> op->o_conn->c_authz_backend (the authorizing backend) to operate the
>>> password change. This patch uses the ID field in reqdata, if any, to
>>> select the appropriate backend, in view of using passwd_extop across
>>> backends in glued backend pools.
>>>Any drawback or security issue?