On Sat, 29 Jun 2013, Simo Sorce wrote:
On Sat, 2013-06-29 at 07:46 +0300, Alexander Bokovoy wrote:
On Fri, 28 Jun 2013, Alexander Bokovoy wrote:
>Found today when preparing my talk at LVEE conference:
>When running 'ipa passwd <user>' or 'kinit <user>' for the first time
>(i.e. forcing a password change), ipa-pwd-extop causes denial of
>password change:
>[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Received extended operation 
request with OID
>[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Pre-Encoded passwords are not 
>[28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_post_op
>[28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_cache_change_notify
>[28/Jun/2013:22:02:43 +0300] roles-plugin - <-- roles_post_op
>[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Failed to update password
>Apparently, we receive password encoded as {SSHA} scheme and it breaks
>any password change. Appropriate code checks are in
>I've reproduced it with Fedora 19 RC2 ISO, with git master rpms, and
>with freeipa-devel repo. Basically, this is release blocker for 3.3
>right now.
Thanks to Nathan to point out to this change in 389-ds-base:

I added

passwordAdminDn: cn=admins,cn=groups,cn=accounts,$SUFFIX

to cn=config and got it fixed for stock FreeIPA configuration.
However, the change like this would not be enough for delegated roles.

Patch that fixes basic problem is attached, please review.

Although the patch 'fixes' the problem for the admin group it break s
the IPA model.
We need to get a way to disable this behavior in 389DS (we already do
our own checks since long), and work for a long term solution where
policy checks can be delegated to a plugin.

It is a priority to revert the new logic in 389DS immediately, and work
on a plan.
389-ds team (thanks Nathan and Noriko!) released fixed version and it is
now available in Fedora 19. I've checked and it fixes the
issue without additional changes to FreeIPA.

/ Alexander Bokovoy

Freeipa-devel mailing list

Reply via email to