Hi,
Looking at smbk5pwd overlay I'm trying to build something similar. One of the attributes I need to change is userPassword for selected uid (not dn). In my LDAP tree I have several places where uid=user1 exists. Now I need to change userPassword for this user in all these places at once (through passwd). From my perspective EXOP_MODIFY_PASSWD is not suitable for me. So I though about creating overlay for this issue. I'm looking for low level operation for changing userPassword attribute with respect to previous password hash.
Could anyone advise how can do this?
Regards, Marcin
Marcin Giedz writes:
Looking at smbk5pwd overlay I'm trying to build something similar.
Actually it does not sound similar, since that just modifies incoming update operations while you need to spawn multiple search-and-updates:
One of the attributes I need to change is userPassword for selected uid (not dn). In my LDAP tree I have several places where uid=user1 exists. Now I need to change userPassword for this user in all these places at once (through passwd).
Look at how the refint overlay handles modrdn operations. They trigger a search for other entries to modify or delete.
From my perspective EXOP_MODIFY_PASSWD is not suitable for me. So I though about creating overlay for this issue. I'm looking for low level operation for changing userPassword attribute with respect to previous password hash.
Not sure what "with respect to previous password hash" means, if not EXOP_MODIFY_PASSWD. That's exactly what it does. You just need an overlay in addition, to spawn updates to other entires. And if you want to catch add and modify operations too, the overlay can do that as well.
Or do you mean: If you update uid=foo,ou=bar with password X and the overlay also finds uid=foo,ou=baz with another password Y, should then the other password be updated as well? Don't know but I guess you just duplicate the operation of the modify password exop with the old password. Note that if you read the password to verify, you may run into access control rules that just allow minimal access: write and auth.
Hallvard B Furuseth wrote:
Marcin Giedz writes:
Looking at smbk5pwd overlay I'm trying to build something similar.
Actually it does not sound similar, since that just modifies incoming update operations while you need to spawn multiple search-and-updates:
Precisely!
One of the attributes I need to change is userPassword for selected uid (not dn). In my LDAP tree I have several places where uid=user1 exists. Now I need to change userPassword for this user in all these places at once (through passwd).
Look at how the refint overlay handles modrdn operations. They trigger a search for other entries to modify or delete.
I will
From my perspective EXOP_MODIFY_PASSWD is not suitable for me. So I though about creating overlay for this issue. I'm looking for low level operation for changing userPassword attribute with respect to previous password hash.
Not sure what "with respect to previous password hash" means, if not EXOP_MODIFY_PASSWD.
I mean. If userPassword uses md5 hash change it to new one but keep/use the same hash.
That's exactly what it does. You just need an overlay in addition, to spawn updates to other entires. And if you want to catch add and modify operations too, the overlay can do that as well.
So as I understand: 1) in my overlay check if EXOP_MODIFY is trigged if so let him do the job 2) then back to my overlay and "search and modify" the other entries of userPassword, right?
Marcin.
Or do you mean: If you update uid=foo,ou=bar with password X and the overlay also finds uid=foo,ou=baz with another password Y, should then the other password be updated as well? Don't know but I guess you just duplicate the operation of the modify password exop with the old password. Note that if you read the password to verify, you may run into access control rules that just allow minimal access: write and auth.
Marcin Giedz writes:
Hallvard B Furuseth wrote:
Not sure what "with respect to previous password hash" means, if not EXOP_MODIFY_PASSWD.
I mean. If userPassword uses md5 hash change it to new one but keep/use the same hash.
Oh. Just grab the old one, ignoring any access control rules, and see if it starts with '{something}'. Note that if it does but slapd doesn't know a hash method with that name, it may be because it comes from some other installation which does recognize it. In that case you can either fail or use some hash method which you or slapd do know.
That's exactly what it does. You just need an overlay in addition, to spawn updates to other entires. And if you want to catch add and modify operations too, the overlay can do that as well.
So as I understand:
- in my overlay check if EXOP_MODIFY is trigged if so let him do the job
And you can't do it with plain modify operations if the target uses a different hash than the modify operation does, since you can't decode the modify operation's hash.
- then back to my overlay and "search and modify" the other entries of
userPassword, right?
Yes. Unless you want to search and replace first and modify the requested entry afterwards, so any failure in the other entries will leave the requested entry unmodified. Either way has it advantages.
In case of BDB, maybe you can also get a transaction where you can rollback your changes if any change fail. I don't know.
BTW, remember that the userPassword attribute is multi-valued. One can match the submitted passwords, others not. Or several can match it, but with different hash methods.
Also, you may find user entries without userPassword. Do you add one, or not?
Hallvard B Furuseth writes:
I mean. If userPassword uses md5 hash change it to new one but keep/use the same hash.
Oh. Just grab the old one, ignoring any access control rules, and see if it starts with '{something}'. (...)
Or look at how libraries/liblutil/passwd.c:lutil_passwd() does it. But note that lutil_password() can trigger SASL, callbacks to slapd, and whatnot, looking for how to authenticate the password. If you want to do the same (authenticating other entries), you need to set thread-specific data with key slap_sasl_bind, like be_isroot_pw() does in slapd/backend.c. I have no idea where that leads, having only looked superficially at the code myself.
openldap-software@openldap.org
-
Hallvard B Furuseth -
Marcin Giedz