Sort of yes
I was hoping to avoid writing a matching plugin for 389 server if
possible but if that needs to happen then Ill do that latter as a
Heimdal allows me to add an external program which it calls to do a
password quality check. it passes the password and the principal name
to the external programs STDIN.
Initially what I intend to do is utilize it to have it map the realm
to a base search path OU then search for the user and update the
matching password fields appropriately.
This way the password fields in the LDAP database will match the
updated passwords in the Heimdal KDC this way programs which are
unfortunately written to directly read those fields will work. The
main reason for this is dealing with poorly written web interfaces
which claim to be LDAPv3 compliant but are really LDAPv2 applications
which don't utilize binds for authentication but instead try to handle
the authentication themselves.
latter I intended to write a reverse plugin down the line to handle
syncing in the other direction but if what you are saying is correct
then I need to do this in 3 stages.
1) A simple LDAP password field update plugin for Heimdal
2) A 389 server plugin for taking a clear password in a secondary
field and run it through the password quality checks and feed the pass
or fail results back to the first plugin.
3) A second 389 server plugin triggered by the password quality
checks to send the password to the KDC via the kadmin libraries.
probably utilizing a locking field to prevent loops.
I was originally hoping I could avoid step 2 but if that is what I
will need to do then eventually I will get to it. Right now only the
first one is critical for me the rest are nice to have features.
On Thu, Feb 27, 2014 at 10:12 AM, Rich Megginson <rmeggins(a)redhat.com> wrote:
On 02/26/2014 11:01 PM, Paul Robert Marino wrote:
> sorry for the delayed response I'm on vacation so I haven't been
> checking my email regularly.
> On Thu, Feb 20, 2014 at 5:15 PM, Rich Megginson <rmeggins(a)redhat.com>
>> On 02/20/2014 03:11 PM, Paul Robert Marino wrote:
>>> I tried asking this on the developer list and didn't get an answer
>> There is no good answer, which is probably why no one replied . . .
>>> im trying the user list now
>>> So here is my goal I am about to write a plugin for Heimdal KDC's to
>>> update matching password fields in LDAP servers.
>>> In the case of 389 server it will also allow 389 server to manage
>>> password quality checks.
>>> Ive been looking over the 389 servers docs and there is something I'm
>>> unclear about.
>>> How do I pass the password to 389 server to trigger the quality check
>>> and update?
>> There isn't a SLAPI way to do that. FreeIPA did something similar with
>> their samba/kerberos password plugin, and they copy/pasted liberally from
>> the core 389 server code.
> It doesn't need to be via SLAPI in fact for compatibility reasons its
> actually better if its not via SLAPI but instead a direct LDAP query.
> If it is as you say than I dont see how a user updating their pasword
> from a client node can ever be forced to use the password quality
> check which seam to make it somewhat useless. Instead I would have
> expected the check to be executed by a post modify trigger on the
> password field or some other intermediate field.
Ok. I see. You are wanting to do this in conjunction with the regular LDAP
password processing. Then I think it should work.
You will probably want to do this as a BEPOSTTXN plugin, so that your
changes occur inside the same transaction as the regular password changes.
>>> Is it simply just a bind as an administrator then update the users
>>> password field with clear text password and let 389 server check and
>>> hash it from there, or is there more to it like a C API call?
>>> If any one can point me to the appropriate doc or even better section
>>> of the appropriate doc that would be very helpful.
>>> If any one just happens to knows the answer I would appreciate that too.
>>> Note: The resulting plugin will be posted on Github with a GPL license
>>> when I'm done.
>>> Thank You
>>> 389 users mailing list
>> 389 users mailing list
> 389 users mailing list
389 users mailing list