On Mon, 17 Feb 2014, Nathaniel McCallum wrote:
On Mon, 2014-02-17 at 12:32 +0200, Alexander Bokovoy wrote:
On Thu, 13 Feb 2014, Alexander Bokovoy wrote:
>On Wed, 12 Feb 2014, Nathaniel McCallum wrote:
>>Through the review process, patches are getting shifted around, added,
>>deleted, etc. So I'm now just going to be posting all the patches as an
>>ordered set. The set attached is ordered according to my preferred merge
>>order. It also places easy to review patches up front. I hope this helps
>>reviewers. This format will definitely help me manage the patches.
>>
>>The first three patches should be very easy reviews and can be merged
>>independently.
>>
>>All current patch critiques have, to my knowledge, been addressed in
>>this latest series of patches.
>I have tested all the patches altogether, including Web UI patches, and
>everything works.
>
>I have set up a COPR repo for others to try:
>http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/
>
>However, there is one issue which I was not yet able to pin-point in the
>SLAPI plugins. During FreeIPA install and later on actual use I see
>these in the dirsrv error log:
>
>[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter
>[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL
>[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter
>[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL
>[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin
returned error code -1
>[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter
>[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL
>[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter
>[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL
>
>Additionally, when slapi-nis is enabled, LDAP bind with identity from
>compat tree fails for OTP use and succeeds for password authentication.
>
>In compat tree we are doing this trick:
>1731 /* Otherwise force rewrite of the
>SLAPI_BIND_TARGET_SDN 1732 * and let
>other plugins to handle it.
>1733 * slapi-nis should have plugin ordering set below standard
50 to succeed */
>1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, &sdn);
>1735 if (sdn != NULL) {
>1736 slapi_sdn_free(&sdn);
>1737 }
>1738 sdn = slapi_sdn_new_dn_byref(ndn);
>1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn);
>1740 ret = 0;
>1741 }
>
>I tried to play with plugin precedence and it didn't really help.
>
>There is definitely a bug (or more) in ipa-pwd-extop in handling
>authentication cases.
Some progress on this investigation.
Plugin precedence setting is broken in 389-ds. It is only set once,
before running init function provided by the plugin and does not take
into account all callbacks that the init function may register. As
result, all these functions get classified with default precedence (50)
and no configuration could change this, we get ipa-pwd-extop's pre-bind
callback called before schemacompat's one, thus working on the compat
entry DN instead of the new one. Since that entry has no userPassword
attribute, OTP code refuses to accept any password.
When user is allowed to use password auth along with OTP, the fact that
there is no userPassword get ipa-pwd-extop plugin through the failure.
schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of
389-ds code checks actual password.
So we have two issues here: OTP code needs to gracefully ignore entries
without userPassword set, and we need to be able to re-arrange
schemacompat and ipa-pwd-extop precedence for pre-bind operation.
If schemacompat goes first, it rewrites the TARGET_SDN to the correct
entry. This entry should have userPassword set, no?
Yes, it should. However, if somebody binds with an entry that has no
userPassword, it is not business of ipa-pwd-extop pre-bind callbacks to
decide what to answer, we have 389-ds core logic for that already.
I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on
the latter.
The messages from the log are not yet solved...
I've spent the better part of today trying to reproduce this and I
haven't been able to yet. Can you reproduce the problem in a clean
install?
Yes, that's my plan, hopefully tomorrow.
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
