Managing Passwords

Password management in Connectivity means managing password synchronization, including:

  • Setting up and maintaining the scenario structure

  • Setting up and maintaining the password workflows

The sections in this chapter describe:

  • How DirX Identity’s password management feature works (generic operation)

  • How password changes flow from Windows domains

  • How password changes flow from Web applications

  • How to configure the password synchronization workflows

  • How the password synchronization workflows operate

  • How the password change algorithms operate

For troubleshooting hints in a password management scenario see the section "Password Synchronization" in the DirX Identity Troubleshooting Guide.

Understanding Password Management

DirX Identity password management comprises a set of comprehensive features to set up, maintain and distribute user passwords in a distributed environment:

  • The DirX Identity Web Center allows for user password management via self-service and administrative applications.See the DirX Identity Provisioning Administration Guide for more information.

  • The DirX Identity Windows Password Listener captures passwords at Microsoft Windows domain controllers.

  • The DirX Identity Password Event Manager receives password change notifications and processes them.

  • The DirX Identity Password Change workflows transfer the changed passwords via connectors immediately to the connected target systems.

The following figure shows how these components interact:

DirX Identity Password Management Component Interaction
Figure 1. DirX Identity Password Management Component Interaction

As shown in the figure:

  • A user changes his password via the Web Center (see the DirX Identity Provisioning Administration Guide for more information).The Web Center sends the password change notification to the DirX Identity Messaging Service.

  • Alternatively a user can change his password in the Windows domain.The Windows Password Listener captures this password change and sends it to the Messaging Service (see the DirX Identity Connectivity Reference for more information).

  • The User Password Event Manager subscribes to these notifications, joins the event to the correct user in the Identity Store, changes the password for the user and issues change events for all accounts in all target systems where this change is required.

  • The User Password Event Manager subscribes to these notifications, joins the event to the correct user in the Identity Store and processes change events for all accounts in all target systems where this change is required.

  • Target system-specific Set Password in XX workflows subscribe to these change events and perform the necessary password change via the related connector in the connected system.To support reporting and real-time status display, the workflows update the PasswordChangeHistory attribute, which contains the time, the result (success or failure) and the associated user.This attribute should be regularly cleared with the RemoveAccountPasswordChangeHistory consistency rule.

Depending on the supported API technology (Java or C/C), connectors run either in the Java-based Identity Server (IdS-J) (as part of the workflow) or in the C-based Identity Server (IdS-C).The communication between the Java-based workflow and the C++-based connector is performed via SOAP/HTTP in a synchronous mode.

All workflows use common services for logging, auditing, statistics and retry.Auditing and statistics information is also stored as status entries in the DirX Identity status area.See the section "Understanding Password Synchronization Workflow Operation" for more information.

Password Changes from Windows Domains

Users can change passwords with standard Windows methods at any Windows domain controller.The next sections describe how DirX Identity password management components process password changes from Windows domains.

Password Changes via the Windows Password Listener

The following figure illustrates how the DirX Identity password management components interact to process password changes from Windows users and distribute them to the relevant target systems.

DirX Identity Windows Password Listener Component Operation
Figure 2. DirX Identity Windows Password Listener Component Operation

As shown in the figure, the detailed sequence of process steps is:

  • The user changes his password in the Windows environment.

  • The password change is sent as a Java Messaging Service (JMS) message to the DirX Identity Messaging Service. It contains the Windows user account name as well as the domain and forest information.

  • A User Password Event Manager is started in the Java-based Server (IdS-J) when such events arrive.

  • If a password change event arrives, the User Password Event Manager retrieves the relevant fields from the message. In this case, the User Password Event Manager identifies first the corresponding target system in the Identity Store with the help of the domain and forest information (these fields correspond to the fields in the Advanced tab of the target system object). Next, the manager searches the account within this target system.

  • If it locates the account, the User Password Event Manager follows the link to the corresponding user entry in the Identity Store and changes the password at the user entry. If it cannot locate the account, the manager stores the event for a configurable number of retries. It sends a notification event if it reaches the retry limit without successfully locating the account.

  • Using the information in the user entry, the manager retrieves all accounts that belong to this user that must be updated with the new password. For each account, the manager creates a request to change the password in the corresponding target system. The target system that generated the password change event is omitted (this would result in cyclic behavior otherwise).

  • Set Password in XX workflows are started immediately to process the requests. If the change is successful, the request is deleted. If it is not successful, a configurable number of retry cycles are issued. If all fail, a notification event is sent. In all cases, the workflows update the PasswordChangeHistory attribute at the accounts.

  • Target system interfaces that cannot be accessed via Java interfaces but in C or C technology are handled by connectors running in the DirX Identity C-based Server (this is not shown in the previous figure but is similar to the "Password Changes from Web Applications" section). A Set Password in XX workflow runs in the Java-based Server, produces a synchronous SOAP/HTTP request for the password change connector in the C++-based Server and waits for a synchronous response. If successful, the request is deleted. If not, a configurable number of retries is performed. If all fail, a notification event is sent.

For more information, see the section "About the Windows Password Listener" and the description of this component in the DirX Identity Connectivity Reference.

About the Windows Password Listener

The Windows Password Listener is a DirX Identity agent that captures passwords in clear text from the Windows domain controller and transfers them to the messaging service where the DirX Identity event manager picks them up for further processing.

The Windows Password Listener agent is implemented as a separate tool that does not need DirX Identity server components to be installed on the same machine.It must be installed and registered on each domain controller in the network.

When the Windows domain controller is started, it calls the Windows Password Listener’s initialize method, which sends a message to the event manager to retrieve the public encryption key.On the other hand, if the public encryption key is exchanged, the Java-based Server distributes the changed key to all Windows Password Listeners.

The Windows Password Listener captures password at the Windows domain controller, encrypts it with the public encryption key and transfers it as message to the messaging service (the message serves as an event and transfers the data in parallel).The message is marked with the originator APETA://ADS/domain.It includes the forest name, domain name, computer name, userName, and password (encrypted) attributes and the flag 'User must change password during next login'.

The DirX Identity Connectivity Reference provides more details about the Windows Password Listener.

Password Changes from Web Applications

Users can change passwords using Web applications.The standard method is to use the DirX Identity Web Center; for a detailed description see the DirX Identity Provisioning Administration Guide.As an alternative to Web Center, you can integrate the Java classes of the DirX Identity Web Event Trigger into your Web applications; for more information, see the corresponding section in the DirX Identity Connectivity Reference.

In both cases, the Web application sends a password change message to the DirX Identity Messaging Service for further processing.The following figure illustrates the event and how the DirX Identity password management components interact to process it.

Web-based Password Change Processing
Figure 3. Web-based Password Change Processing

As shown in the figure:

  • The user changes his password through the Web application.

  • A user who is working with the specialized Web Center for Password Management can de-select accounts from password change processing; passwords for these accounts will not be updated.

  • The password change is sent as a Java Messaging Service (JMS) message to the DirX Identity Messaging Service.

  • A User Password Event Manager workflow is started in the Java-based Server (IdS-J) when such events arrive.

  • If a password change event arrives, the User Password Event Manager retrieves the relevant fields from the message.The distinguished name (DN) of the user allows the User Password Event Manager to identify the user entry in the Identity Store.

  • If the User Password Event Manager can locate the user entry, it changes the password at the user entry.Otherwise, it stores the event for a configurable number of retries.After several unsuccessful retries, the User Password Event Manager sends a notification event.

  • Using the information in the user entry, The User Password Event Manager retrieves all accounts that belong to this user and that need to be updated with the new password, excluding those accounts that the user previously de-selected.For each account, the manager creates a request to change the password in the corresponding target system.

  • Set Password in XX workflows are started immediately to process the requests.If the change is successful, the request is deleted.If it is not successful, a configurable number of retry cycles are issued.If all fail, a notification event is sent.In all cases, the workflows update the PasswordChangeHistory attribute at the accounts.

  • Target system interfaces that cannot be accessed via Java interfaces but in C or C technology are handled by connectors running in the C-based Server.A Set Password in XX workflow runs in the Java-based Server, produces a synchronous SOAP/HTTP request for the password change connector in the C++-based Server and waits for a synchronous response.If successful, the request is deleted.If not, a configurable number of retries is performed.If all fail, a notification event is sent.

Configuring the Password Synchronization Workflows

There are two types of password synchronization workflows:

  • A User Password Event Manager workflow, which handles password change events published by Windows Password Listener or Web Center, updates the user password in the Identity Store and creates password change requests for all the user’s accounts.

  • A Set Password in XX workflow for each target system instance, which updates the account password in the target system according to the change request issued by the Password Change Event Manager workflow.

The structure of the password synchronization workflow configurations is very similar.All password synchronization workflows consist of one mandatory activity to update the password and an optional error activity, which notifies the affected user of failed password updates.

Each workflow is responsible for a specific family of events, which must be set in the Is applicable for section of the first tab of the workflow configuration entry, named "Workflow".

You must set the source of password change events for the User Password Event Manager. By default, there is only one manager that listens to all password change events. This is indicated by the wildcard "*" in all fields. For load distribution, you can deploy multiple User Password Event Managers, each listening for a different set of events.

In each change password request, the User Password Event Manager workflow sets a message topic, which includes the following fields from the target system entry: Type, Cluster, Domain. They are labeled differently in some target system types; for example, forest and domain for Windows systems. The Java-based Server finds the appropriate Set Password in XX workflow by matching the topic with the settings of the Type, Cluster and Domain fields in the workflow configuration.

A Set Password in XX workflow must be configured for each target system instance where passwords are to be synchronized. In order to associate the workflow and the target system, the fields Type, Cluster and Domain of the workflow configuration must match the corresponding fields of the target system entry.

The rest of the configuration is almost the same for all workflows.

Set the flag to write audit logs, enter the number of retries in case of temporary failures and the waiting time between retries.

Select the connected directory at which to update the password and a bind profile. The only exceptions are target systems, which are accessed by a C/ C# based connector. They run in C-based Servers. Therefore, the workflow configuration needs the C++-based Server and the connector within the server in order to know where to send the SOAP requests.

The resource family indirectly determines on which servers an activity may be run. It tells the system which resources it needs for processing. It is a good idea to associate resource families with target system types or target system instances, if there are a number of them. Choose a resource family "LDAP" to be associated with target systems of type LDAP, a resource family "ADS" to be associated with Windows systems, and so on. Setting the activity resource family "LDAP" instructs the system to run this activity only on servers that provide access to this type of resource.

Java-based Servers provide resources; for example, LDAP.Activities run only on servers that are associated with the same resource that the activity requires.An activity with a resource family LDAP needs a server that has a reference to the resource family LDAP.

Make sure that, for each activity, there is at least one Java-based Server associated with the same resource family!

The configuration of the error activities is the same for all workflows.With the flag "enabled" set, you decide that the workflow includes the error activity.Otherwise, the workflow contains only the "set password" activity.In this case, permanently failed requests are placed in the dead letter queue.See the chapter "Using Web Admin" in the DirX Identity User Interfaces Guide for information about how to view, re-process and delete these entries.

With the other options, you set the mail fields: from, to, subject, and body.

Even if you have configured a Set Password in XX workflow for your target system, you need to enable the target system for password synchronization.Reset the flag Disable Password Sync(hronization) at the target system object in the Provisioning view group to enable password synchronization.

Understanding Password Synchronization Workflow Operation

The following figure illustrates how the password synchronization workflows operate in more detail.

Password Synchronization Workflow Components
Figure 4. Password Synchronization Workflow Components

As shown in the figure, the sequence of steps is as follows:

  • The corresponding adaptor (Password Change Listener) reads events from an external queue (for example, a JMS queue).It adds the events into its own repository (persistent queue) and then into the memory-based Batch Queue and deletes them from the external queue.

  • A Workflow Dispatcher component (not shown in the figure) analyzes the events in the Batch Queue and starts the workflows that can handle these types of events.In this case, the password event manager workflow (User Password Event Manager) is started.'

  • After start, the User Password Event Manager workflow analyzes the event’s content and tries to identify the relevant user in the Identity Store to which this password change event belongs:

  • If successful, the User Password Event Manager workflow changes the password of the user, but only if the new value and the old one does not match. If they are identical, the workflow stops processing this event and does not request changes for the accounts. This method effectively prevents password change loops. See the section "About the Password Change Algorithms" for details.

  • If the workflow successfully changes the user password, it creates setPassword requests for all accounts of this user where the password shall be changed and sends these to the internal temporary SetAccountPasswordListener JMS queue for further processing by the relevant SetPassword in XX workflows. These requests include all account attributes that identify the account in the connected system and the changed password.

  • If unsuccessful, the User Password Event Manager writes the event to the retry channel. After some waiting time, the Event Manager processes these events again until their retry limit is reached. See the section "Error Handling and Retry" in "Managing Java-based Provisioning Workflows" for details.

  • Events that fail even after retries are passed to the Error Activity, which sends an e-mail to the affected user. See the section "Error Handling and Retry" in "Managing Java-based Provisioning Workflows" for details.

  • In all cases, the User Password Event Manager workflow writes logging, auditing and statistics information to be processed by the corresponding handlers.

  • At the end of the workflow, successful or not, the requests are removed from the adaptor’s repository.

  • The Set Account Password Listener adaptor reads the events from the JMS Queue and packs them into the Batch Queue.

  • The Workflow Dispatcher analyzes the (set password) event and starts the Set Password in XX workflow that is configured for this target system instance.It associates the event and the workflow by their type, domain and cluster attributes.

  • After start, the Set Password in XX workflow reads the event from the JMS Queue:

  • Its first activity constructs the account identification in the target system and issues the password change request to the target system.

  • The workflow engine retries unsuccessful requests until the retry limit is reached, and then passes the requests and their responses to the error activity, which issues e-mail notifications to the affected user.See the section "About the Password Change Algorithms" for details.

  • In all cases, the Set Password in XX workflow writes logging, auditing and statistics information to be processed by the corresponding handlers.

  • At the end of the Set Password workflow, successful or not, the requests are removed from the JMS Queue.

About the Password Change Algorithms

This section provides details about the password change algorithms used by the DirX Identity password management components.

To minimize unnecessary password changes that could result in refused updates at the target system side due to password history mechanisms, DirX Identity checks each password change to determine whether or not the new password is identical to the previous one.It uses the password history attribute for this task even if the password history policy is not enabled for a specific user.

The algorithm for a user with enabled password history is shown in the following flowchart.

Password History Algorithm (Password History Enabled)
Figure 5. Password History Algorithm (Password History Enabled)

In this algorithm, DirX Identity changes the password if it is not already contained in the password history. The history is updated accordingly. Otherwise the password change is rejected.

The algorithm for a user with disabled password history is shown in the following flowchart.

Password History Algorithm (Password History Disabled)
Figure 6. Password History Algorithm (Password History Disabled)

In this case, DirX Identity changes the password if no password history is available. The password value is stored in the password history for further checks.

The test to determine whether the new password is identical to the existing one is made against the stored value in the password history. If the password is identical, the change is rejected. If it is not identical, the password is changed and the password history value is replaced with the new one.

The test relies on the fact that the new password is stored in the password history even if the password history policy is disabled for the user. The password policy, however, can also be configured to prevent storage of the new password if the history is disabled. In this case, the check for identical passwords will always fail, causing the new password to be processed as if it was different from the previous one. Since this will cause some issues in a system with one or more Windows Password Listeners, storing the new password must not be disabled in such a system.