Password Synch fails in Single Sign on environment

Our development team has been testing a single sign on solution which will synchronize all passwords across our various systems. The design of the system (at request of our IT VP) incorporates the password change at the AS400 level.

We force users to change their AS400 signon every quarter on the first of the month. When that password is changed, it synchs up all other passwords: internet, VPN, Sametime, windows desktop, and (should synch) Notes. Our current problem exists that when the synch is complete, Notes gives us the “Notes password does not match desktop password”. If the Windows Desktop password is changed, then Notes synchs just fine. It just won’t allow an external synch process to change the desktop and have the Notes client synch as well.

I found a response on here which details a similar situation with this problem (http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/ad17898113afe74d85256cf5005120ec?OpenDocument), but we would like to know how we can change the password elsewhere, have the Windows Desktop password change (this is working in our environment), and have the Notes client accept and synch it’s password.

Any suggestions?

Thanks, Brian

Subject: Password Synch fails in Single Sign on environment

I have seen a customer who is also is implementing a self-service password reset mechanism. I am not involved in the development so this is a conceptual description but it may start you down the path of further discussion.

They have a tool which creates a new password, does not reset using an original one. For example, in Windows, a user who does CTRL-ALT-DEL change password has to know the old password and then type in a new one.

Windows API calls can be used to just set a new password, without knowing the old one.

Now, with Notes single sign-on installed, the Notes client uses a security API to check for password changes in the OS and updates the Notes ID when the Windows password is changed. There is a caveat to this. In the current client, the service does not detect the password change if it is an admin reset and not user initiated. There are 2 API calls that change a Windows password. When ctrl-alt-delete is used, one is called and this is the one Notes single sign-on detects.

When an admin reset is used the second API call is used and Notes does not detect this one.

Detecting both of these API calls would allow a user to go to a website, enter a new password and have the tool do an admin reset of Windows password to new one and have the Notes client follow suit to effect a self-service password reset.

Obviously, security of this is paramount but a potential solution.