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:

• Troubleshooting Problems With SSL Between Core Components

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

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

• Troubleshooting Problems With Certificates

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.

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.

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 Oracle Identity Synchronization for Windows 6.0 Installation and Configuration Guide.

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.

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:

• Untrusted Certificates

• Mismatched Hostnames

• Expired Certificates

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.

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.

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.