I tried asking this on the developer list and didn't get an answer so 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? 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
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 . . .
so 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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@redhat.com wrote:
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 . . .
so 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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@redhat.com wrote:
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 . . .
so 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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 second step.
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@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@redhat.com wrote:
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 . . .
so 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org
-
Paul Robert Marino -
Rich Megginson