Description of problem: A call to check_account_lock() (providing a slapi_entry) goes on to check password expiry etc. with a call to new_passwdPolicy() passing in the DN of the entry. new_passwdPolicy() then searches the db for the entry (that we already have). This occurs in the bind code path so any optimization here would be good. There should be a way to pass in the entry to avoid the search. new_passwdPolicy() seems to get called a lot in the password management code, and there look to be other places that might be able to optimize out the search. new_passwdPolicy() also has this comment /* If we're doing an add, COS does not apply yet so we check parents for the pwdpolicysubentry. We look only for virtual attributes, because real ones are for single-target policy. */ I'm not sure why this would be true - if an entry could be passed in in from the add code this shouldn't be an issue I think, and the whole policy searching algorithm could be ripped out and rely on COS for adds too (might be an issue with regards to whether the add op has succeeded yet or something). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Write code to call check_account_lock() 2. 3. Actual results: Slower binds Expected results: Faster binds Additional info:
*** This bug has been marked as a duplicate of 184130 ***
Bug already CLOSED. setting screened+ flag