You must make sure the users are not logged into any IFS environment when changing their Windows/network login via AD.  The new password has to be able to synchronize without being logged into IFS.  We have a similar difficulty when users change their AD password while logged into IFS, once they log out, they cannot get back in without resetting their AD password a second time.

Something more than just that single failed attempt to log into IFS is triggering the lock. 

As @ShawnBerk noted you need to ensure that the user is not logged in to IFS anywhere using AD when changing the AD account, because this will drive that mismatch.  If you have users who use multiple devices such as phones and laptops it gets more complex especially if you use something like  IFS TouchApps that they may not think about when logging off.

From a standard IFS Apps interface perspective I suspect (but don’t know for sure) that this may be caused by the way that IFS can create multiple database sessions for a user within a single IFS window, with subsequent sessions after the AD change triggering the issue. Automated retries of failing connections within those sessions may also be part of the impact.

HTH,

Nick

When configuring ldap authenication on some version of IFS it has a kind of “muliti athentication”. It works like this. If you fail authenticate against Ldap for any reason it will try to do the authentication against oracle database after the failed attempt against LDAP. If you have running IFS client somewhere with the old ldap password running you will then lock the oracle account quite fast if it’s used.