Problems in Complex Scenarios

Check that the Windows Password Listener service on the domain controller machine is running correctly. (On Windows, use the Services panel together with the Event Viewer.) If something is not correct, restart the Windows Password Listener service and check again. If this does not help, follow the instructions in section "Check Windows Password Listener" to solve the problem.

Check that the C++-based Server is running correctly. (On Windows, use the Services panel together with the Event Viewer.) If something is not correct, restart the C++-based Server and check again. If this does not help, follow the instructions in section "Analyzing Message Server Operation" to solve the problem.

Check that the Java-based Server is running correctly. (On Windows, use the Services panel together with the Event Viewer.) If something is not correct, restart the Java-based Server and check again. If this does not help, follow the instructions in section "Analyzing Java-based Server Operation" to solve the problem.

Check the current state of the queue your_domain.http://mc0x5ngc.ww930.my-it-solutions.net:8161/admin/browse.jsp;jsessionid=10jdd39ri3r5seytbedqscdg0?JMSDestination=my-company.dxm.event.pwd.changed[xm.event.pwd.changed] with ActiveMQ Web Console (Queues page) and note the following values for later reference:

The number of messages enqueued and dequeued. The number of consumers should be one. The number of pending messages should be low or zero.

The number of sent requests and received responses the PasswordChangeListener in the Java-based Server has processed up to now.

Change a password of an account in the Windows domain. This action should increase the number of enqueued and dequeued messages in Web Console.

If the Messaging broker does not receive a message, check the Windows Password Listener for correct operation (go to the section "Checking Windows Password Listener".)

If there is no subscriber queue, either the Java-based Server does not run or the PasswordChangeListener adaptor does not work (it has not subscribed). Proceed to the section "Analyzing Java-based Server Operation".

If both conditions are fulfilled, the password change message was transferred correctly to the Java-based Server. If not, proceed with the section "Analyzing Message Server Operation".

Check that the number of sent requests of the PasswordChangeListener adaptor in the Java-based Server has increased by one. Check also that the number of received responses has increased by one.

If this is not the case, proceed with section "Analyzing Java-based Server Operation".

Check with Web Center that the password of the user was changed correctly. If not, proceed with section "Analyzing Event Manager Operation".

Check in one of the connected target systems that are prepared for password synchronization that the password of the user was changed correctly.

If this is not the case, proceed with section "Analyzing Target System Workflow Operation".

If this is the case, your password change scenario works correctly.

Stop the Windows Password Listener service.

Set Trace=3 in the file libdxmEventListenerAds.ini in the folder conf.

Change a password of a user. Check that there is a file in the PasswordFiles directory; for example, a file that look like 20080308131048823_1010. Also check the file dxmEventListener.log. It should clearly indicate that there was a password change for the user. This shows that the plug in the domain controller works correctly.

Set Trace=0 in the file libdxmEventListenerAds.ini in the folder conf.

Start the Windows Password Listener service. Check that it runs correctly.

Check whether the file in the PasswordFiles directory is gone. If yes, the Windows Password Listener service works correctly. (It could send the encrypted password to the Messaging Server.)

If you still cannot see that a new message passed the dispatcher queue, check the parameters in the options.ini file to see if you’re using the correct Messaging Service. If this is the problem, set the correct parameters and restart the Windows Password Listener service.

If the Windows Password Listener does not work correctly (the password file is still in the PasswordFiles folder), check that a folder CertFile contains a certificate file (Certificate.txt).

If there is no certificate file that is required for correct encryption of the password, check that the Windows Password Listener server can contact the Messaging Service (it tries to send a certificate request message to get the certificate from the LDAP directory).

Check the messages in the Event Viewer and in the related log files whether there are errors. Eventually increase the trace level in the file options.ini file, restart the Windows Password Listener service and check for more detailed information. Check also that the Messaging Service is reachable from the domain controller machine. If not, change your firewall configuration.

If there are any other messages in the Event Viewer, analyze them and solve them.

If the Messaging Service is reachable, check that a certificate request message from the Windows Password Listener passed the subscriber queue with the topic dxm.event.certificate.*. If not, proceed with section "Analyzing Message Server Operation".

If yes, check with the Web Admin, that the ConfigurationHandler adaptor of the Java-based Server processed the message and sent a certificate.

If not, check that a correct certificate is available at the server_admin object (use the DataView of the DirX Identity Manager for this check) and if that is the case, proceed with the section "Analyzing Java-based Sever Operation".

Check that the Java-based Server startup was successful. (On Windows, use the Event Viewer; on UNIX, use the log files in the folder install_path\ids-j-domain-Sn\logs.)

Check that there are no warning or error messages in the server-* log files.

If there are warning or error messages, analyze the reason of the message. (See the "Logging Messages" chapter for details.) Solve the related issue. If the reason is not obvious, use higher logging levels for the relevant component, restart the server and then check the messages again.

Check the parameters host, port, user and domain in the install_path\ids-j-domain-Sn\bindcredentials.xml file are set correctly. Change it or perform a configuration again if not.

Be sure that the ldap (password) and pin values in the file install_path\ids-j-domain-Sn\private\password.properties are correct. If you are in doubt, set the values again in clear text. After the next start of the server, the values are encrypted again.

If you use two certificates in parallel (during a certificate migration phase), be sure that the previousPin parameter in this file is set correctly. Set it again in clear text if you are in doubt.

In Web Admin, click the Java Server node and then check the server state (which should be "The server is running"). If the server is suspended, click Resume Server.

Open the Adaptors section and check for each adaptor the state (which should be "The adaptor is running"). If an adaptor is suspended, click Resume Adaptor.

Check that the PasswordChangeListener is in the state "listening". If not, suspend and resume the adaptor. If this action does not help, check the error reason in the logging. Check also that the Messaging Service is reachable from this machine.

Check the DeadLetterQueue. Click Search Requests and open the password change request that failed. Check for correct topic (cluster and resource are filled correctly).

Open Workflow Definitions → Real-time Workflows and check that your Event Manager workflow is present. If not, proceed with the section "Analyzing Event Manager Operation".

If the Event Manager workflow is visible, check that the whenApplicable section is set correctly. If not, proceed with the section "Analyzing Event Manager Operation"

In DirX Identity Manager’s Connectivity view, check that the Event Manager workflow is set to active.

Check that the Is applicable for section is set correctly. You can restrict the type of application (see the password message for correct setting), and you can also restrict the Event Manager to specific Cluster and Domain values. Typically, all these values are set to *.

Perform Load IdS-J Configuration to upload the changed workflow to the Java-based Server.

With Web Admin, check that the Event Manager is now present in the Workflow Definitions → Real-time Workflows section.

If this is the case, but the workflow does not work correctly, check the other parameters of the workflow definition like Connected Directory and Bind Profile. Set the password of the bind profile again if you are not sure whether it is correct.

Be sure that the SMTP part of the workflow definition is set correctly (SMTP Server and Bind Profile). Set the correct email addresses.

If the Event Manager workflow works, check the status entry in the Monitoring view of the Connectivity view group (is located under the Event based node).

If you encounter the message
"Searching account; Exception: siemens.dxm.connector.DxmConnectorException: ERR(JOIN516): Account "name" doesn’t exist for target system "target system""
then the Windows account of the user could not be found. Verify that the account is not in the target system of DirX Identity. Check your target system synchronization and validation workflows for correct operation.

If the account can be found, the status entry should indicate that the password of the user could be changed successfully. Note that DirX Identity checks whether the password was really changed. If not, the password change operation is aborted. No further action is performed.

You should also find for each target system (besides the Windows target system that issued the modification) a message indicating that a synchronization action has been triggered. If this is not the case, check for all relevant target systems that Prevent Password Synchronization is not set.

In DirX Identity Manager’s Connectivity View, check that the relevant password synchronization workflow is set to active.

Check that the Is applicable for section is set correctly. The Type, Cluster and Domain fields must fit with the corresponding fields of your target system definition in the Provisioning view group.

Perform Load IdS-J Configuration to upload the changed workflow to the Java-based Server.

In Wed Admin, check that the password synchronization workflow is now present in the Workflow Definitions → Real-time Workflows section.

If this is the case, but the workflow does not work correctly, check the other parameters of the workflow definition like Connected Directory and Bind Profile. Set the password of the bind profile again if you are not sure whether it is correct.

Be sure that the SMTP part of the workflow definition is set correctly (SMTP Server and Bind Profile). Set the correct email addresses.

If the password synchronization workflow works, check the status entry in the Monitoring view of the Connectivity view group (is located under the Event based node).

If you encounter error messages, analyze them and solve the problem.

If encryption mode is set, which should always be the case in a productive environment, all components do a strong encryption and no problems arise with password display.

If encryption mode is not set, the server_admin user object in the Connectivity Database should not have a userCertificate. Otherwise, the Account Password Manager encrypts passwords strongly and Web Center expects a scrambled password only because encryption mode is not set.