[Freeipa-devel] [PATCHES] OTP Patches

[Nathaniel McCallum]

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?

> 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?

Nathaniel