#1064 [DS] Password is not immediately expired after admin reset.
Closed: Fixed None Opened 13 years ago by sbose.

If I try to change a user password immediately after an admin reset with a sequence like

echo admin_pwd |kinit admin ; echo reset_pwd | ipa passwd testuser ; echo -e 'reset_pwd\nnew_pwd\nnew_pwd' | kinit testuser

the password of testuser is still reset_pwd in most of the cases. If I add a 'sleep 1' after 'ipa passwd' it is working as expected.


We will need to to check with DS team.

Can convert the password plugin to a betxnpreoperation/betxnpostoperation plugin.

memberOf and referint are already converted, can be used as models.

In those the type of plugin is controlled by nsslapd-plugintype config option.

The actual callback functions don't need much changing, except to grab the SLAPI_TXN from the pblock and store it in any pblocks created

From richm:

In ipapwd_init you'll have to change "postoperation" to "betxnpostoperation" too

Add'll suggestions from Rich:

I think you'll just have to change ipapwd_post_op - grab the SLAPI_TXN, use slapi_search_internal_get_entry_ext instead of slapi_search_internal_get_entry

You'll have to change ipapwd_getPolicy ipapwd_apply_mods to allow you to pass in the txn from the caller

you'll have to change ipapwd_setkeytab to get the txn from the pb, or pass it from the caller if it is using a constructed pb and not the one passed from the plugin code

Moving the ticket to the next month iteration.

I have a working patch in my tree but switching to transactions is causing the schema-compat plugin to deadlock ns-slapd. I have a limited patch for that which at least fixes the deadlock (but could break who knows what). BZ for it is https://bugzilla.redhat.com/show_bug.cgi?id=758830

I filed an additional bug since this problem extends beyond slapi-nis. If memberof is configured as a betxnpostoperation plugin it also causes a deadlock, BZ https://bugzilla.redhat.com/show_bug.cgi?id=759183

Moving to next month iteration.

389-ds is going to work their transactions to to use Thread Local Storage to store the transaction handle so plugins don't have to know anything about transactions.

https://fedorahosted.org/389/ticket/167

Current target 389-ds 1.2.11

The 389-ds-base-work isn't going to be done until 1.3

Transactions for extended operations are not supported yet. There are some pre/post operations that can be converted to support transactions but the password change itself cannot.

See https://fedorahosted.org/389/ticket/523

Moving to NEEDS_TRIAGE for now. Where we place it will depend on where the 389-ds ticket lands.

The 389-ds ticket is closed, see the ticket for details.

Metadata Update from @sbose:
- Issue assigned to rcritten
- Issue set to the milestone: FreeIPA 3.1 Stabilization

7 years ago

Login to comment on this ticket.

Metadata