How does Single Sign-On support username changes in Microsoft Active Directory?

Document ID : KB000051675
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

In the event that a company undergoes a re-organization of how user accounts are displayed in Active Directory, your SSO solution can remain in sync with these changes if a few simple steps are performed beforehand.

Solution:

The solution will involve both the SSO Active Directory Service Listener and the SSO Windows Password Sync Agent to be working and hand over notifications to SSO server.

Scenario: User account name John.Doe will be renamed to U010101.

  1. In Active Directory Users and Computers, change the user account name details as required by your business model.

  2. After the rename is complete set the flag for user to change his/her password at next login.

    • The ADS Listener will conduct a move of the user account name, but not in the sense of location, but rather a move of user from name A to name B.

      Here is an example of what you would see in the ADListener.log file
      6/20/2010 12:40:01 AM - INFO (Thread ID: 0x000001a0)Source : AD Listener\PS Notification ManagerMessage: (0x0) Successfully sent the following notification to Policy Server:Notification type: Move_UserCurrent container dn: OU=ssousersCurrent name: John.DoeNew container dn: OU=ssousersNew name: U010101
  3. In jxplorer or any ldap browser connect to the Policy Server LoginInfos directory and find the user in question.

    • You will now see that there is an orphan account name "John.Doe" in the correct OU string, with no SSO application entries under it.

    • You will also see the new account name "U010101" with the application entries present under it in the same DN string. The application entries have been moved correctly to the new name.

    • But the eTssoLoginID that SSO is expecting will still be the same. The AD Listener does not modify this value. The SSO enabled applications that user accounts launch on a daily basis use eTssoLoginID for the username entry.

    • This is where the Windows Password Sync Agent comes into play. Setting the flag in Active Directory to have the user update his/her password at next login will then update the master application with the new eTssoLoginID to match what has been changed in Active Directory Users and Computers.

    • Now all applications that use the Master application (DOMAINNAME for example) for its ID and password will continue to function normally.

    • As for applications that do not use a master application as its ID and password, these will involve user interaction on a learn mode level if required by the specific application. For example, if your intranet application does not use DOMAINNAME for its master ID and password, and this new naming convention requires the user to have this new name for the Intranet application, then the user will need to update their credentials in the SSO client via the advanced user options in the Launchbar. Or the UserID can be changed in SSO Policy Manager. There are also solutions that involve TCL scripting. Please consult with your CA Account Manager on enlisting CA Technical Services for custom TCL coding as it falls out of support scope.