How to enable random Windows passwords - utilizing eTrust Single Sign-On Bi-directional Windows Password Synchronization and Certificate Authentication.

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


One of the domains of SSO is the capability to protect applications by enforcing strong password policies, like the requirement to use special characters and frequent change.

However, by nature, the more complex a password is, the more difficult it is to remember, and the chance we will  get confused increases.  On top of this, the lower the password change interval is defined the higher the chance is for further confusion.

Therefore the SSO Server can

  • automatically generate a application's login password complying with the set password policy

  • securely store it in it's database

  • retrieve it upon application logon

  • submit it to the application's login dialog by means of a script.

The challenge hereby is to synchronise the generated password with the physical application's login credentials for a given user. This process is specific for each application and typically accomplished by a scripting approach.

This document is intended to help you understand how to Secure, Hide, Randomize and Synchronize Users Windows Domain passwords using Certificate Authentication and SSO's Bi-directional Password Synchronization Agents.


SSO 8.1 provides the new bi directional Windows Password Synchronisation Agent, comprising of two components:

  • Active Directory to SSO Server synchronization (password filter)

  • SSO Server to Active Directory synchronization (password exit)

Installation of both components allows enforcing arbitrarily complex Windows password policies and automatically setting randomly generated passwords for the Windows user.

To still enable the user to logon to the OS without knowing its password, we will need to utilise another secure but easy to use login method provided by SSO which does not rely on the user's Windows credentials. The Certificate Authentication Method offers us this capability.

Since the logon credentials are to be sent to the SSO system for validation first, rather then to Windows, the usage of the SSO GINA (without pass through) is required.

To setup, the following would need to be done:

  1. Integrate  Active Directory as the SSO User Datastore  which is described in the SSO Implementation Guide Chapter 7, pages 112 - 114

  2. Setup Certificate Authentication so that any issued Certificate allows logon of a matching Windows User from the above AD User datastore

  3. Rollout SSO Clients with SSO Gina (without pass through) and Certificate Authentication

  4. Setup the Domain Application matching the Windows' NetBIOS Domain Name.
    It can be configured with Pwd sync to serve as Master Application for subordinate applications.
    This is the application the Password Filter module utilises to synch the user's OS password changes to SSO.

    Figure 1

  5. Setup a Password Policy which meets your security requirements.
    Note, that it needs to be more strict than the OS password policy already in place to avoid manual interaction

  6. Setup the SyncToOS application which is used by the Password Exit and enable Password Generation

    Figure 2

  7. Assign the SyncToOS application a script that allows the Password Exit to be triggered, containing only:
    sso getmode
       sso notify -event login -status 0 -appname $_APPNAME
  8. Install the PSA's password filter on each Windows Domain Controller

  9. Install the PSA's password exit on each SSO Server

  10. Create a Shortcut in the Startup folder on any user's SSO Client Workstation targeting:

    "C:\Program Files\CA\eTrust SSO\Client\bin\ssointerp.exe" SyncToOS

    You may configure the sync applications as hidden, so that they are not shown in the SSO Client's Application List. Also you can configure offline availability; however no password change should be attempted while running offline.

To verify the overall functionality the PSAudit.log reveals the following after the Password Interval has passed and the SyncToOS has been run:

     12/31/06 12:00 AM - INFO (Thread ID: 0xa9956bb0)
     Source : eTrust SSO Server\SSO Server
     Message: (0xFF019700) User [User01 (cn=Users) AD_ACMECORP] 
              successfully authenticated using method CERT. IP:
     12/31/06 12:00 AM - INFO (Thread ID: 0xb65e2bb0)
     Source : eTrust SSO Server\SSO Server
     Message: (0xFF028100) User [PSA_PS_ACMECORPDC () SSO81LX1] has successfully updated password 
              for application ACMECORP for user [User01 (cn=Users) AD_ACMECORP]. IP:

WinPSAExit.log in debug mode shows:

2006-12-31 00:00:34 3070114736 [      ]   DEBUG - Successfully changed the password

For additional details on Bi-Directional Password synchronisation, please see also:

  • Implementation Guide Chapter 14: Implementing Password Agents

  • Administrator Guide Password Synchronization Agents