Skip Headers
Oracle® Fusion Middleware Troubleshooting Guide for Oracle Directory Server Enterprise Edition
11g Release 1 (11.1.1.7.0)

Part Number E28966-01
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

7 Troubleshooting Identity Synchronization for Windows

This chapter provides information to help you troubleshoot problems you may encounter while using Identity Synchronization for Windows. It includes the following topics:

This chapter contains the following sections:

7.1 General Troubleshooting Guidelines

This section provide general guidelines to help you troubleshoot problems with Identity Synchronization for Windows. It includes the following sections:

Note:

Before you begin troubleshooting your problem, be sure to check the Release Notes for explanations about known issues as well as information about patch requirements.

7.1.1 Configuring and Using the Logs

Some events are not included in a log file until you adjust the log level to FINE or higher. To adjust the log level, see Configuring Your Log Files in Installation Guide for Identity Synchronization for Windows 6. The log level should be left as INFO during all idsync resync operations.

When troubleshooting a problem, look at the central error log located in the following directory:

isw-hostname/logs/central/error.log

Almost all errors will be reported in the central error log file. Additional information about the error may be available in the audit.log file. To simplify the correlation between related log entries, the audit.log file also contains the information found in the error log.

For the Windows NT SAM Change Detector subcomponent to be effective, you must turn on the NT audit log as follows:

  1. From the Start menu, go to Programs, Administrative Tools, then User Manager.

  2. Select Policies, then Audit Policies.

  3. Select Audit These Events and check the Success and Failure check boxes for User and Group Management.

  4. Select Event Log Settings in the Event Viewer, Event Log Wrapping menu. Next, select Overwrite Events as Needed.

7.1.2 Using the idsync printstat Command

The idsync printstatcommand displays the connector IDs and the status of each connector. The output also displays a list of the remaining steps you have to perform to complete the installation and configuration process. This status information can be useful for troubleshooting problems with Identity Synchronization for Windows.

For example, the command is run as follows:

# idsync printstat

Connector ID: CNN100
Type:     Active Directory
Manages:  example.com (ldaps://host2.example.com:636)
State:    READY
Connector ID: CNN101
Type:     Sun Java System Directory
Manages: dc=example,dc=com 
(ldap://host1.example.com:389)
State:    READY
Sun Java System 
Message Queue Status:  Started
Checking the System Manager status over the Sun Java System
Message Queue.
System Manager Status:  Started SUCCESS

If the command lists connectors, then you know that your configuration was saved successfully.

7.1.2.1 Troubleshooting Quick Checklist

This checklist provides questions to help guide you in your troubleshooting process:

  1. Was the Directory Server running during resource configuration?

  2. Is the core, including the Message Queue and the System Manager, currently running? On Windows, check for the appropriate service name. On Solaris and Linux, check for the appropriate daemon name. Use the idsync printstat command to verify that the Message Queue and System Manager are active.

  3. Was synchronization started from the Identity Synchronization for Windows console or from the command line?

  4. Are the directory sources that are being synchronized currently running?

  5. Use the Identity Synchronization for Windows console to verify that modifications and creates are synchronized in the expected direction.

  6. If synchronizing users and groups that existed in only one directory source, were these users and groups created in the other directory source using the idsync resync command?

    Note:

    You must run idsync resync whenever there are existing users and groups. If you do not resynchronize existing users, resynchronization behavior remains undefined.

  7. If synchronizing users that existed in both directory sources, were these users linked using the idsync resync command?

  8. If user creates fail from Active Directory or Windows NT to the Directory Server, verify that all mandatory attributes in the Directory Server object class are specified as creation attributes and values for the corresponding attributes are present in the original user entry.

  9. If synchronizing creates from Directory Server to Windows NT and the user creation succeeded, but the account is unusable, verify that the user name does not violate Windows NT requirements.

    For example, if you specify a name that exceeds the maximum allowable length for Windows NT, the user will be created on NT but can not be used or edited until you rename the user (User > Rename).

  10. Are the users that fail to synchronize within a Synchronization User List? For example, do they match the base DN and filter of a Synchronization User List? In deployments that include Active Directory, on-demand password synchronization fails silently if the Directory Server entry is not in any Synchronization User List. This most often occurs because the filter on the Synchronization User List is incorrect.

  11. Were the synchronization settings changed? If the synchronization settings changed from only synchronizing users from Active Directory to Directory Server to synchronizing users from the Directory Server to Active Directory, then the Active Directory SSL CA certificate must be added to the connector's certificate database. The idsync certinfo command reports what SSL certificates must been installed based on the current SSL settings.

  12. Are all host names properly specified and resolvable in DNS? The Active Directory domain controller should be DNS-resolvable from the machine where the Active Directory Connector is running and the machine where the Directory Server Plug-in is running.

  13. Does the IP address of the Active Directory domain controller resolve to the same name that the connector uses to connect to it?

  14. Are multiple Synchronization User Lists configured? If so, are these in conflict? More specific Synchronization User Lists should be ordered before less specific ones using the Console.

  15. If flow is set to bidirectional or from Sun to Windows and there are Active Directory data sources in your deployment, are the connectors configured to use SSL communication?

  16. If you are creating or editing the Directory source, and the Directory Server does not display in the Choose a known server drop-down list, check that the Directory Server is running. The Directory Server must be running to appear in the drop down list of available hosts.

    If the server in question is down temporarily, type the host and port into the "Specify a server by providing a hostname and port" field.

    Note:

    Identity Synchronization for Windows uses a short host name by default; however, the default host name may not work with your configuration. We recommend using a fully qualified name whenever you are asked to provide a host name.

7.1.3 Troubleshooting Problems with Identity Synchronization for Windows Installation

Confirm that you installation was performed on a clean machine. If you reinstall and the previous installation was not properly uninstalled, errors may occur. For information about uninstalling Identity Synchronization for Windows, see Chapter 7, Removing the Software, in Installation Guide for Identity Synchronization for Windows 6.

For information about whether the core installed correctly, see the log file in the following directory:

isw-hostname/logs/central/

If the connector installation failed, but the Identity Synchronization for Windows installation program thinks that the connector is installed, the installation program will not allow you to reinstall the connector.

Run the idsync resetconn command to reset the connector's state to UNINSTALLED. Next, reinstall the connector.

If you receive the following error while uninstalling the software, you need to increase the size of the swap file mounted at /tmp:

./runInstaller.sh
IOException while making /tmp/SolarisNativeToolkit_5.5.1_1  
executable:java.io.IOException: Not enough space java.io.IOException: Not enough space

After installation, confirm that all of the subcomponents were installed. Directory Server and the Windows NT connectors require subcomponents to be installed after the connector installation. The Directory Server plug-in must be installed in each Directory Server replica.

The Directory Server must be restarted after the Directory Server plug-in is installed. The Windows NT Primary Domain Controller must be restarted after the Windows NT subcomponents are installed.

7.2 Troubleshooting Memory Problems

If memory problems are suspected on Solaris or Linux environments check the processes. To view which components are running as different processes, enter

/usr/ucb/ps -gauxwww | grep com.sun.directory.wps

The output gives the full details including the ID of connectors, system manager and central logger. This can be useful to see if any of the processes are consuming excessive memory.

7.3 Troubleshooting Problems With Connectors

Use the information in this section to troubleshoot problems with your connectors. This section contains the following topics:

This chapter contains the following sections:

7.3.1 General Connector Troubleshooting Tips

Confirm that all of the connectors are installed. One connector must be installed for each directory source being synchronized.

Confirm that the source connector detects the change to the user. Use the central audit log to determine if the connector for the directory source where the user was added or modified detects the modification.

Verify that all connectors are in the SYNCING state using the Identity Synchronization for Windows console or idsync printstat command.

Determine if the destination connector processes the modification.

7.3.2 Determining the ID of a Connector Managing a Directory Source

You can determine the connector ID by using the central logs or by using the idsync printstat command.

You can find the connector ID of the directory sources being synchronized by looking in the central audit log. At start up, the central logger logs the ID of each connector and the directory source that it manages. Look for the last instance of the startup banner for the most recent information.

For example, the following log entry contains two connector IDs:

  • CNN101 is a Directory Server connector that manages dc=example,dc=com

  • CNN100 is an Active Directory connector that manages the example.com domain

[2006/03/19 00:00:00.722 -0600] INFO    16
"System Component Information:
SysMgr_100 is the system manager (CORE);
console is the Product Console User Interface;
CNN101 is the connector that manages
[dc=example,dc=com (ldap://host1.example.com:389)];
CNN100 is the connector that manages
[example.com (ldaps://host2.example.com:636)];"

For information about using the idsync printstat command to determine the connector ID, see Using the idsync printstat Command

7.3.3 Getting and Managing the Current State of a Connector

You can determine the current state of the connectors involved in synchronization using the Status pane in the Identity Synchronization for Windows console, using the idsync printstat command , or by looking in the central audit log.

To use the audit log, search for the last message that reports the connector state. For example, the following audit log entry shows the connector CNN101 is in the READY state:

[2006/03/19 10:20:16.889 -0600]
 INFO    13  SysMgr_100 host1
  "Connector [CNN101] is now in state "READY"."

Table 7-1 Definition of the Connector States

State Definition

UNINSTALLED

The connector has not been installed.

INSTALLED

The connector is installed, but is not configured.

READY

The connector is installed and configured, but is not synchronizing.

SYNCING

The connector is installed, configured, and in the process of synchronizing.


7.3.3.1 Troubleshooting a Connector in the UNINSTALLED State

If the connector is in an UNINSTALLED state, you need to install the connector.

7.3.3.2 Troubleshooting a Connector in the INSTALLED State

If a connector remains in the installed state for a long period of time, then might not be running or might be unable to communicate with the Message Queue.

On the machine where the connector is installed, look in the audit and error logs for potential errors. For example, if the connector can not connect to the Message Queue, then that error log will report the problem. If the connector can not connect to the Message Queue, see Troubleshooting the Message Queue Component for possible causes.

If the most recent messages in the audit log are old, then the connector may not be running. See Troubleshooting the Watchdog Process and Core Components for information about starting the connector.

7.3.3.3 Troubleshooting a Connector in the READY State

A connector remains in the READY state until synchronization begins all of the subcomponents connect to the connector. If synchronization has not started, then start it using the Identity Synchronization for Windows console or command-line utility.

If synchronization has started and the connector does not go to the SYNCING state, then you may have a problem with one of the subcomponent. See Troubleshooting the Connector Subcomponents for more information.

7.3.3.4 Troubleshooting a Connector in the SYNCING State

If all connectors are in the SYNCING state but modifications are not being synchronized, then verify that the synchronization settings are correct.

Using the Identity Synchronization for Windows console, verify that modifications and creates are synchronized in the expected direction, for example, from Windows to the Directory Server. Also verify that the attribute being modified is a synchronized attribute. If created user entries are not being synchronized, then verify that user creation flow is enabled in the Identity Synchronization for Windows console.

Note:

Passwords are always synchronized.

If you are still experiencing the problem, check if the source connector detects the change to the user. Use the central audit log to determine if the connector for the directory source where the user was added or modified detects the modification. Also verify that the destination connector processes the modification.

7.3.4 Troubleshooting Problems With the Active Directory Connector

If the Active Directory connector fails to contact Active Directory over SSL and the following error message displays, restart the Active Directory domain controller.

Failed to open connection to
ldaps://server.example.com:636,
error(91): Cannot connect to the LDAP server,
reason: SSL_ForceHandshake failed: (-5938)
Encountered end of file.

If detecting and applying change in Active Directory fails, it may be the result of insufficient permissions. If a non-administrator account is used for the Active Directory connector, then the default permissions for this user are not sufficient. Some operations, such as a resynchronization process from Active Directory to Directory Server, succeed while other operations, such as detecting and applying changes in Active Directory, fail abruptly. For example, if you synchronize the deletions from Active Directory to Directory Server, then even full permissions are insufficient. To resolve this problem, you must use a Domain Administrator account for the Active Directory connector.

7.4 Troubleshooting the Watchdog Process and Core Components

Use the information in this section to troubleshoot the Identity Synchronization for Windows Watchdog process and core components. The Watchdog process launches and monitors the central logger, system manager, and connectors. The core components include the configuration directory, command-line utilities, system manager, and the central logger. The information is provided for each operating system as follows:

This chapter contains the following sections:

7.4.1 Troubleshooting Processes on Solaris or Linux

The following command lists all of the Identity Synchronization for Windows processes that are currently running:

# /usr/ucb/ps -auxww | grep com.sun.directory.wps

The following table describes the processes that should be running.

Table 7-2 Identity Synchronization for Windows Processes

Java Process Class Name Component When it Should be Present

com.sun.directory.wps.watchdog.server.WatchDog

Watchdog Process

Always

com.sun.directory.wps.centrallogger.CentralLoggerManager

Central Logger

Only where Core is installed

com.sun.directory.wps.manager.SystemManager

System Manager

Only where Core is installed

com.sun.directory.wps.controller.AgentHarness

Connector

One for each connector installed


If the expected number of processes are not running, then issue the following commands to restart all Identity Synchronization for Windows processes.

# /etc/init.d/isw stop
# /etc/init.d/isw start

If the WatchDog process is running, but the expected number of java.exe processes are not running, then verify that all components were installed properly. For information about verifying the components, see Examining the WatchList.properties File.

Like other system components, the Directory Server plug-in sends log records over the bus that are managed by the central logger for end-user viewing. However, the plug-in also logs some messages that may not show up over the bus, such as messages that are written when the subcomponent cannot contact the connector. These log messages only appear in the plug-in's logs directory on the file system, which should look something like the following:

serverroot/isw-hostname/logs/SUBCid

Because the plug-in runs with the Directory Server process, there could potentially be a problem for the plug-in's ability to write into its logs directory. This happens if the Directory Server runs as a different user than the owner of the logs directory. If the Directory Server process runs as a different user, give the plug-in explicit permissions using native operating system commands.

7.4.2 Troubleshooting Processes on Windows

Using the Service control panel, check that the Sun Java System Identity Synchronization for Windows service is started. If it is not started, then Identity Synchronization for Windows must be started.

If the service is started, then use the Task Manager to verify that the Watchdog process, pswwatchdog.exe, is running and that the expected number of java.exe processes are running. You should have one java.exe process for each connector installed on the machine. If the core component is installed, you should also have a java.exe process for each of the following:

  • One for the message queue broker

  • One for the system manager

  • One for the central logger

Note:

Other active Java processes, such as the Directory Service Control Center, may be running.

If the Watchdog process is not running, then restart the Sun Java System Identity Synchronization for Windows service. If it is running but the expected number of java.exe processes are not running, then verify that all components were installed properly. For information about verifying the components, see Examining the WatchList.properties File.

7.4.3 Examining the WatchList.properties File

On each machine where a Identity Synchronization for Windows component is installed, the isw-machine_name/resources/WatchList.properties file enumerates the components that should run on that machine. The process.name[n] properties name the components that should be running.

On machines where the core component is installed, the WatchList.properties file includes entries for the Central Logger and the System Manager as follows:

process.name[1]=Central Logger
process.name[2]=System Manager

On machines where the connectors are installed, the WatchList.properties file includes a separate entry for each connector as follows. The process.name property is the connector ID.

process.name[3]=CNN100
process.name[4]=CNN101

If the entries in the WatchList.properties file and the actively running processes are not the same, then restart the Identity Synchronization for Windows daemon or service.

If the WatchList.properties file contains too few a number of entries, for example only one connector entry even though two were installed, then examine the installation logs for possible installation failures. The location of the installation logs vary depending on your operating system as follows:

  • On Solaris, installation logs are written to /opt/SUNWisw

  • On Linux, installation logs are written to /var/opt/sun/isw/logs

  • On Windows, installation logs are written to the %TEMP% directory, which is a subdirectory of the Local Settings folder located under

    C:\Documents and Settings\Administrator
    

    On some Windows systems, such as Windows 2000 Advanced Server, the Local Settings folder is a hidden folder. The following procedures describes how to view hidden folders.

7.4.3.1 To View Hidden Folders and the Temp Subdirectory on Windows

  1. Open your Windows Explorer.

  2. From the Tools menu, select Folder Options.

  3. When the Folder Options dialog box is displayed, select the View tab.

  4. Check the Show Hidden Files checkbox.

7.5 Troubleshooting the Connector Subcomponents

This section guides you through the steps you should take to troubleshoot problems with the connector subcomponents. Before you begin, confirm the following:

7.5.1 Verifying Subcomponent Installation

Verify that all of the subcomponents are installed. Subcomponent installation must be done after the connector is installed. The subcomponents installed depend upon the connectors used as follows:

  • For Active Directory Connectors, no subcomponents are installed.

  • For Directory Server Connectors, the Directory Server plug-in must be enabled on the Directory Server being synchronized.

  • For Windows NT Connectors, the Windows change detector and password filter subcomponents must be installed on the primary domain controller for each Windows NT domain being synchronized. These subcomponents are installed after the Windows NT Connector is installed.

For the Windows NT SAM Change Detector subcomponent to be effective, you must turn on the Windows NT audit log. To turn on the audit log, use the following procedure and then select Policies > Audit Policies. Select Audit These Events and then both the Success and Failure boxes for User and Group Management.

7.5.1.1 To Turn on the Windows NT Audit Log

  1. In the Start menu, select Programs, then Administrative Tools and User Manager.

  2. In the Event Viewer, select Event Log Settings and then Event Log Wrapping.

  3. Select Overwrite Events as Needed.

7.5.2 Verifying Server Restart After Installation

After you have installed the subcomponents, ensure that the correct post-installation steps have been taken. For example, after the Directory Server plug-in has been installed, the server must be restarted. After the Windows NT change detector and password filter have been installed on the primary domain controller, the server must be restarted.

7.5.3 Verifying Network Connections

If your subcomponents are still causing problems, confirm that they have established a network connection with the connector. On the machine where the connector is running, verify that the connector is listening for the subcomponent's connection by running the following command:

# netstat -n -a

For example, the netstat command shows that the connector is listening for incoming connections on port 9999 and the subcomponent has successfully connected as follows:

# netstat -n -a | grep 9999
*.9999
*.*    0   0 65536    0 LISTEN
12.13.1.2.44397 12.13.1.2.9999
73620 0 73620    0 ESTABLISHED
12.13.1.2.9999
12.13.1.2.44397 73620 0 73620
0 ESTABLISHED

However, if the subcomponent has not connected, the netstat command instead shows the following:

# netstat -n -a | grep 9999
*.9999
*.*    0   0 65536    0 LISTEN

After verifying that the subcomponent is running, examine the subcomponent's local logs for potential problems.

Verify that the correct port number was specified. Verify that the connector is running and is in the READY state. Examine the connector's local logs for potential problems.

If the connector is not listening for incoming connections, then the output of the netstat command appears as follows:

# netstat -n -a | grep 9999
#

7.6 Troubleshooting the Message Queue Component

This section describes how to troubleshoot problems with the Message Queue component and its broker. It contains the following topics:

This chapter contains the following sections:

7.6.1 Using telnet to Verify That the Message Queue Broker is Running

Verify that the Message Queue broker is running. Using the telnet command to connect to the machine and port where the Message Queue broker is running returns a list of the active Message Queue services:

# telnet localhost 7676
Trying 127.0.0.1...
Connected to localhost.
Escape character is \q^]\q.
101 psw-broker 3.0.1
cluster tcp CLUSTER 32914
admin tcp ADMIN 32912
portmapper tcp PORTMAPPER 7676
ssljms tls NORMAL 32913
jms tcp NORMAL 32911
Connection closed by foreign host.

If the ssljms tcp NORMAL service is not listed in the output, then examine the Message Queue logs for potential problems. The location of the log depends on the platform you are using as follows:

  • On Solaris, the log is in the following location: /var/imq/instances/psw-broker/log/log.txt

  • On Linux, the log is in the following location: /var/opt/sun/mq/instances/isw-broker/log/log.txt

  • On Windows, the log is in the following location: installation_root\isw-machine_name\imq\var\instances\isw-broker\log\log.txt

    If the telnet command fails, then either the broker is not running or the wrong port was specified. Check the port number in the broker's log. For example, the log contains a line for the broker's port as follows:

[13/Mar/2003:18:17:09 CST] [B1004]:
'Starting the portmapper service using tcp
[ 7676, 50 ]
with min threads 1 and max threads of 1'

If the broker is not running, start it on Solaris and Linux by running the /etc/init.d/imq start command. On Windows, start the broker by starting the iMQ Broker Windows service.

If you install Message Queue on Solaris 8, and you run the mquinstall command to install all of the packages, be sure to set IMQ_JAVAHOME propertybefore running the mqinstall command. This ensures that the software picks the correct version of Java.

If you have not yet installed the core component, you do not have to set the IMQ_JAVAHOME property because the Identity Synchronization for Windows installation program tells the Message Queue broker which version of Java to use.

7.6.2 Collecting Additional Information About the Message Queue Broker

You can run the broker with the debug log turned on to help collect additional information about your problem. To turn on the debug log level, use the following command:

# imqbrokerd -loglevel DEBUG

You can get a debug dump of the broker using the following command:

imqcmd dump bkr -edebug -u admin -o file=filename

7.6.3 Troubleshooting Communication Problems With Directory Server

The Message Queue broker authenticates clients with the Directory Server that stores the Identity Synchronization for Windows configuration. If the broker cannot connect to this Directory Server, no clients can connect to the Message Queue. The broker log will contain a javax.naming exception, such as "javax.naming.CommunicationException or javax.naming.NameNotFoundException.

If a javax.naming exception occurs, take the following steps:

  • Verify that all imq.user_repository.ldap properties in the /var/imq/instances/isw-broker/props/config.properties file have the correct values. If any of the values are incorrect, stop the Message Queue broker. Correct the errors, save the file, and restart the broker. Note that machine running the Message Queue broker must be able to resolve the Directory Server host name.

  • Verify that the imq.user_repository.ldap.password property in the /etc/imq/passfile file is correct.

  • Sometimes, the broker can not search for entries if the root suffix contains spaces. Verify that the root suffix name does not contain spaces.

7.6.4 Troubleshooting Memory Problems

During normal operation, the Message Queue broker consumes a modest amount of memory. However, during idsync resync operations, the broker's memory requirements increase. If the broker reaches its memory limit, undelivered messages will accumulate, the idsync resync operations will slow down dramatically or even, and Identity Synchronization for Windows may be unresponsive.

When the broker enters a low-memory state, the following messages will appear in its log:

[03/Nov/2003:14:07:51 CST] [B1089]:
In low memory condition,
Broker is attempting to f
ree up resources [03/Nov/2003:14:07:51 CST] [B1088]:
Entering Memory State [B0024]:
RED  from previous state [B0023]:
ORANGE - current memory is 1829876K,
90% of total memory

To avoid a low memory state, take the following steps:

  • Increase the broker's memory limit to 1 or 2 GB, as explained in Release Notes for Oracle Directory Server Enterprise Edition.

  • During an idsync resync operation, keep the log level set to INFO. Changing the log level to FINE or higher increases the load of the broker as more log messages are sent to the central logger.

  • Run the idsync resync command for one synchronization user list at a time.

7.6.5 To Recover From a Message Queue Broker Low Memory Condition

  1. Verify that the broker has a backlog of undelivered messages.

    Examine the broker's persistent message store in the appropriate directory for your operating system:

    • On Solaris: /var/imq/instances/psw-broker/filestore/message/

    • On Linux: /var/opt/sun/mq/instances/isw-broker/filestore/message/

    • On Windows: installation_root\isw-machine_name\imq\var\instances\isw-broker\filestore\message\

    Each file in this directory contains a single undelivered message. If there are more than 10,000 files in this directory, then the broker has a backlog of messages. Otherwise, an undelivered message backlog is not causing the problem with the broker.

    The message backlog usually contains log files related to an idsync resync operation and you can safely remove them.

  2. Stop the Message Queue broker.

    For more information, see Starting and Stopping Services in Installation Guide for Identity Synchronization for Windows 6.

  3. Remove all files in the persistent message store.

    The easiest way to remove these files is by recursively removing the message/ directory and then recreating it.

  4. Restart the Message Queue broker.

    To avoid running out of memory in the future, take the steps described earlier in this section.

7.7 Troubleshooting Problems With Identity Synchronization for Windows Over SSL

This section describes how to troubleshoot problems using Identity Synchronization for Windows over SSL. It contains the following topics:

This chapter contains the following sections:

7.7.1 Troubleshooting Problems With SSL Between Core Components

The Identity Synchronization for Windows installation program cannot verify that the SSL port provided during core installation is correct. If you type the SSL port incorrectly during core installation, then the core components will not be able to communicate properly. You may not notice a problem until you try to save your configuration for the first time. The Identity Synchronization for Windows Console displays the following warning:

The configuration was successfully saved,
however, the System Manager could not be
notified of the new configuration.

The system manager log contains the following entry:

[10/Nov/2003:10:24:35.137 -0600] WARNING 14
example  "Failed to connect
to the configuration directory because "Unable to connect: (-5981)
Connection refused by peer."
Will retry shortly."

If you receive these warning and error messages, uninstall the core and install it again with the correct SSL port number.

7.7.2 Troubleshooting Problems With SSL Between Connectors and Directory Server or Active Directory

If a connector is unable to connect over SSL to the Directory Server or Active Directory, then the following message appears in the central error log:

[06/Oct/2006:14:02:48.911 -0600]
WARNING 14  CNN100 host1
"failed to open connection
to ldaps://host2.example.com:636."

Open the Identity Synchronization for Windows Console and go to the Specifying Advanced Security Options panel. Confirm that the SSL port is correct.

7.7.3 Troubleshooting Problems With SSL Between the Directory Server and Active Directory

By default, Directory Server does not communicate with Active Directory over SSL when performing on-demand password synchronization. If the default is overridden to protect this communication with SSL, then the Active Directory CA certificate must be added to the Directory Server certificate database of each master replica as described in Chapter 1, Understanding the Product, in Installation Guide for Identity Synchronization for Windows 6.

If the Active Directory CA certificate is not added, users fail to bind to Directory Server with the error DSA is unwilling to perform. The plug-in's log, isw-hostname /logs/SUBC100/pluginwps_log_0.txt, reports the following:

[06/Nov/2006:15:56:16.310 -0600]
INFO    td=0x0376DD74 logCode=81 
ADRepository.cpp:310
"unable to open connection to Active Directory server 
at ldaps://host2.example.com:636, reason: "

If you receive these errors, you must add the Active Directory CA certificate to Directory Server's certificate database and restart Directory Server.

7.7.4 Troubleshooting Problems With Certificates

This section describes how to troubleshoot various problems using certificates with Identity Synchronization for Windows. It contains the following sections:

This chapter contains the following sections:

7.7.4.1 Untrusted Certificates

Go to the central audit log when you receive notice that the certificate is untrusted. For example, if the LDAP server's SSL certificate is not trusted, this message is logged as follows:

[06/Oct/2006:14:02:48.951 -0600] INFO
14  CNN100 host1  "failed to open connection to 
ldaps://host2.example.com:636, error(91):
Cannot connect to the LDAP server,
reason: SSL_ForceHandshake failed:
(-8179) Peer's Certificate issuer
is not recognized."

When you receive this sort of error, it is usually because the CA certificate has not been added to the connector's certificate database. Run the certutil tool to see if the certificate has been added. For more information about this tool, see About the ssltap Tool.

In this example, the certificate database contains no certificates:

# /usr/sunone/servers/shared/bin/certutil
 -L -d /usr/sunone/servers/
 isw-host1/etc/CNN100
Certificate Name             Trust Attributes
p    Valid peer
P    Trusted peer (implies p)
c    Valid CA
T    Trusted CA to issue client certs (implies c)
C    Trusted CA to certs(only server certs for ssl) (implies c)
u    User cert
w    Send warning

In the following example, the certificate database contains only the Active Directory CA certificate:

# /usr/sunone/servers/shared/bin/certutil -L -d
/usr/sunone/servers/ isw-host1/etc/CNN100
Certificate Name                                 Trust Attributes
example.com CA                                    C,c,
p    Valid peer
P    Trusted peer (implies p)
c    Valid CA
T    Trusted CA to issue client certs (implies c)
C    Trusted CA to certs(only server certs for ssl) (implies c)
u    User cert
w    Send warning

As shown here, the trust flags of the CA certificate must be C,,. If the certificate exists and the trust flags are set properly but the connector still can not connect, then verify that the connector was restarted after adding the certificate. Use the ldapsearch command to help diagnose the problem. If ldapsearch does not accept the certificate, then neither will the connector. For example, ldapsearch can reject certificates if they are not trusted as follows:

# /usr/sunone/servers/shared/bin/ldapsearch 
-Z -P /usr/sunone/ servers/isw-host1/etc/CNN100
-h host2 -b "" -s base "(objectclass=*)
"ldap_search: Can't contact LDAP server
SSL error -8179 
Peer's Certificate issuer is not recognized.)

The -P option directs ldapsearch to use the CNN100 connector's certificate database for SSL certificate validation. After the correct certificate is added to the connector's certificate database, verify that ldapsearch accepts the certificate, and then restart the connector.

7.7.4.2 Mismatched Hostnames

When Identity Synchronization for Windows tries to establish SSL connections, the connectors verify that the server's hostname matches the hostname in the certificate that is presented by the server during the SSL negotiation phase. If the hostnames do not match, the connector will refuse to establish the connection.

The directory source hostname in the Identity Synchronization for Windows configuration file must always match the hostname embedded in the certificate used by that directory source.

You can use ldapsearch to verify that the hostnames match as follows:

/var/mps/serverroot/shared/bin/ldapsearch.exe
-Z -P /var/opt/SUNWisw/etc/CNN100 -3
-h host2.example.com -p 636 
-s base -b "" "(objectclass=*)"

If the hostname given in the ldapsearch command-line and the hostname embedded in the certificate are not the same, then the following error message is displayed:

ldap_search: Can't contact LDAP server 
SSL error -12276
(Unable to communicate securely with peer: requested 
do main name does not match 
the server's certificate.)

If the hostnames match, the ldapsearch command is successful and displays the contents of the root DSE.

7.7.4.3 Expired Certificates

If the server's certificate has expired, the following message appears in the log:

[06/Oct/2006:14:06:47.130 -0600]
INFO    20  CNN100 host1 
"failed to open connection to ldaps://host2.example.com:636,
error(91): Cannot connect to the LDAP server,
reason: SSL_ForceHandshake failed: 
(-8181) Peer's Certificate has expired."

If you receive this message in your log file, the server must be issued a new certificate.

7.8 Troubleshooting Active Directory Domain Controller Problems

The Active Directory domain controller is a global catalog server that stores the objects from all domains in the forest. When you restore an Active Directory domain controller from backup files, some counters are not reset. To ensure all counters are reset appropriately, resynchronize all users after restoring an Active Directory domain controller.