GCDS error messages

Network problem: Unable to connect to the specified LDAP server: simple bind failed: servername:636, reason: SSLHandshakeException - No subject alternative names present

Network problem: Unable to connect to the specified LDAP server: simple bind failed: servername:636, reason: SSLHandshakeException - No subject alternative DNS name matching servername found

The certificate's Common Name (CN) and Subject Alternative Name (SAN) don't match the name of the LDAP server in your GCDS configuration file.

To fix this, either:

• Correct your GCDS configuration file–If you have added the LDAP server IP address in the GCDS configuration, enter its Fully Qualified Domain Name (FQDN) as well (for example, dc01.solarmora.com).
• Add a SAN to the certificate–Make sure that the SAN includes the name of the LDAP server that you're using in the GCDS configuration.

As a temporary workaround, you can turn off endpoint identification by adding a new line to the config-manager.vmoptions and sync-cmd.vmoptions files in the GCDS installation folder. Remove the line break before adding to the files:

-Dcom.sun.jndi.ldap.object. disableEndpointIdentification=true

sun.security.provider.certpath.SunCertPathBuilder Exception: unable to find valid certification path to requested target

ldap_simple_bind_s() failed: Strong Authentication Required

Another process is accessing the cache folder or files at the same time as GCDS.

To troubleshoot, download and run Microsoft's Process Monitor and create a filter. In the filter options, use Path, Contains, and path-to-folder\syncState to identify the processes that are accessing the folder or files.

For more information about users' search queries, go to Omit data with exclusion rules & queries.

If you get this message when you're connecting to the LDAP server, the server has closed the connection. Possible reasons are:

• You're using LDAP+SSL and the LDAP server isn't configured to accept the TLS parameters that GCDS supports (for example, cipher suite). Make sure your LDAP server has the latest security updates and settings.
• A firewall rule is blocking the connection.

1. Make sure that only one instance of GCDS is running on your computer.

   You can run only one instance of GCDS at a time using the same XML file.

2. Restart the system to ensure that no other processes are accessing the GCDS cache database. Then, run the sync again.
3. If the issue remains, locate and rename the SyncState folder to force GCDS to create a new cache database. You can find the folder under the user profile folder (Windows) or in the home directory (Linux).

• GCDS is running as a different user than the one that installed GCDS
• Permissions have changed since installation

GCDS uses UTF-8 as the default character encoding. You should use the same encoding for your configuration files, although other encodings are compatible.

To resolve this issue:

1. Change the encoding of your configuration file to UTF-8:
   1. Open a text editor.
   2. Save the file with a different encoding.
2. Verify that the content of your configuration file is correct.
3. Try to load the configuration file on GCDS again.

The most common unsupported encodings are UTF-7 and UTF-8 BOM.

GCDS attempts to complete the SSL handshake up to 3 times. If you see the following message in the logs, GCDS completed the handshake successfully on subsequent attempts, and no further action is needed: [usersyncapp.sync.FullSyncAgent] No differences detected, no changes necessary.

Work with your local network administrator to see what might be causing network timeouts.

If you get the error in the sync summary report and the sync didn’t complete correctly, contact support. For details, go to What GCDS information do I need before contacting support?

• LDAP ConfigurationOrg Units Search Rules
• LDAP ConfigurationUsersUser Sync
• LDAP ConfigurationGroupsGroup Search Rules
• LDAP ConfigurationUser ProfilesUser Profiles Sync
• LDAP ConfigurationShared ContactsContacts Sync

For more information, go to Set up your sync with Configuration Manager.

For more information, go to How will you synchronize passwords? and Update GCDS.

1. Add the following line to your configuration file, in the <features> section:
   GROUP_NESTED_GROUPS_AS_USERS
2. Enclose the line in <optional> tags.
3. Save your configuration file and sync.

To duplicate a GCDS configuration file, always use the Save As option in Configuration Manager. Doing so ensures that the new configuration file has its own cache.

For more information, go to Work with configuration files.

Alternatively, create a new, blank XML configuration file. GCDS then enables an independent group sync, which forces GCDS to resolve group members regardless of user sync rules. If you're not sure, this is the recommended option.

When making any configuration changes or creating a new configuration file, make sure you run a simulation and review the results before running a full sync.

For more information, go to Define your user list.

In Configuration Manager, go to Google DomainSettings, and verify the administrator account information specified in Admin Email Address.

For more information, go to Define your Google domain settings.

• In Configuration Manager, go to User AccountsExclusion Rules and create user exclusion rules that exclude users in external domains.
• Change your user search rules so that users in external domains are not returned.
• Add the missing domain to your Google Account as a secondary domain.

• In Configuration Manager, go to User AccountsSearch rules and limit the scope of your user search to return fewer users.
• In Configuration Manager, make sure you've specified the proper DN that points to the root containing only users that need to be imported into the Google domain.

If a proxy is required to access the web from the machine running GCDS, it must be configured properly.

To work around the issue, you can disable the certificate revocation list (CRL) check. To disable the CRL check, add the following lines to the config-manager.vmoptions and sync-cmd.vmoptions files in the GCDS installation directory:
-Dcom.sun.net.ssl.checkRevocation=false
-Dcom.sun.security.enableCRLDP=false

For more information, go to How GCDS checks certificate revocation lists.

• LDAP ConfigurationOrg UnitsSearch Rules
• LDAP ConfigurationUsersUser Sync
• LDAP ConfigurationGroupsGroup Search Rules
• LDAP ConfigurationUser ProfilesUser Profiles Sync
• LDAP ConfigurationShared ContactsContacts Sync

Note: When using Active Directory, use your domain's fully qualified domain name as the server name.

Ensure that GCDS can connect to these specific URLs and ports by completing the steps in Allow access to URLs & ports.

Security software on the local computer might create connection problems. Ask your administrator to disable any security software on the client machine and try again.

For more information, go to Authorize your Google Account.

If that does not resolve the issue, and you're certain that the DN is valid, the issue might be with DNS resolution. You might see additional error information in the log such as:

• javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: domain.com:389 [Root exception is java.net.ConnectException: Connection refused: connect]]
• javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: domain.com:389 [Root exception is java.net.ConnectException: Connection timed out: connect]]

These errors identify that the hostname is refusing the connection or timing out. Try running a DNS lookup on this hostname, and make sure that all of the addresses being returned are valid and allow connections on the port you've configured.

Note: These errors can occur even if you've specified a valid hostname or IP address in the GCDS configuration. Active Directory might issue an LDAP referral response, directing GCDS to connect through a hostname. This referral might ultimately be to the hostname that is failing to resolve. You can avoid these referrals by connecting to your Active Directory server using the Global Catalog port, which defaults to 3268. For details, consult your Microsoft documentation.

If you have trace-level logs enabled, you can also see the full HTTP request for the custom schema.

To resolve this issue, go to What if I'm seeing memory-related errors?

• You’re using the correct communication protocol. If the LDAP server requires a secure protocol, use LDAP + SSL.
• The LDAP server is active and doesn’t have any connection issues.

Make sure that the authorized user and their password are correct. You should add the authorized user using their complete DN. For details on adding the authorized user, go to LDAP connection settings.

• The base DN exists in the LDAP server.
• The authorized user has permissions for the base DN. For details, go to LDAP connection settings.

• The <base-dn> object exists and is accessible to the authorized user. For details, go to LDAP connection settings.
• The <attribute> exists for the <base-dn> object in the LDAP server.

Member already exists

• You have a member whose primary LDAP address is an alias address in Google Workspace. Avoid this situation, if possible (for example, use a different username for the alias).
• A user account has the same username for 2 alias addresses. And, on the Google Domain Configuration page, you have checked the Replace domain names in LDAP email addresses box.

  When you check the box, both email addresses are changed to match the domain listed in the Alternate email domain field.

Uncheck the box or change one of the alias usernames.

If you also get the following message in the logs: "Error while adding member user-email-address to group group-email-address due to address collision" check whether:

• GCDS excluded the user with user-email-address from the sync based on your exclusion rules. Check your exclusion rules and try again. For details, go to Omit data with exclusion rules & queries.
• You updated the user or group outside of GCDS. Clear the cache and try again.