I wanted to see if anyone else has set up a Google Cloud Directory Sync (GCDS aka GADS) with their Active Directory over secure LDAP (LDAPS). We've been syncing over port 389 and I'd like to encrypt that connection, but when I switch to port 636 the connection fails.

I am running the GCDS tool on a member server in my domain - is the connection that I'm trying to establish on port 636 going between Google's off-site servers and my DC, or is it between the GCDS tool and my DC? And even if it is between the GCDS tool and my DC, does it still require a 3rd party certificate or is a self-signed certificate sufficient because the software is being run on a domain-joined server? Should I run the program on a DC?

If this is an issue where I need a 3rd party certificate, some guidance would be appreciated as I'm not particularly knowledgeable in certificates. Thanks!


Google Cloud Directory Sync is a Java application. Java has its own set of trusted root certificate authorities and doesn't use the certs installed in Windows. The reason the TLS connection is failing is because the Java Runtime Environment installed with GCDS does not contain the trusted root certificate for your AD controller.

I just got this working myself. I followed Google's instructions here: https://support.google.com/a/answer/3075991?hl=en

The short answer is that you need to export the public certs from the DC and import them into the Java keystore.

On Windows, I did the following:

On the domain controller

Export the cert from the domain controller:

certutil -store My DomainController %TEMP%\dccert.cer

If the GCDS host is not the same as the DC, move this file to the GCDS host.

On the GCDS host

Change folders to the jre folder where GCDS is installed. For me it was:

cd "c:\Program Files\Google Cloud Directory Sync\jre"

Yours might be different depending on your environment.

Install the certificate into the Java keystore:

bin\keytool -keystore lib\security\cacerts -storepass changeit -import -file %TEMP%\dccert.cer -alias mydc

Clean up:

del %TEMP%\dccert.cer

  • Since you actually answered my question, I'm awarding this as the answer - I'm trusting it actually works ;) I appreciate the write-up! I don't know if I'll end up changing as it seems like adding SSL incurs more overhead, but it's definitely worth knowing how to do it should we need to in the future. – Mike Jul 12 '17 at 20:18
  • Leaving the insecure endpoint available is a security no-no which I'm trying to eliminate. The July 2017 patches contain something of a nudge. See portal.msrc.microsoft.com/en-us/security-guidance/… – Larry Silverman Jul 12 '17 at 20:39
  • GCDS lives on the machine it's authenticating against, so unless someone is sniffing that particular computer (highly unlikely), I don't see a need to use SSL. Now, if i had to authenticate over an unsecured network, then I'd definitely use SSL. – Mike Jul 14 '17 at 4:34
  • Sure, as long as you've firewalled 389 so external systems cannot get to it, you should be generally OK. – Larry Silverman Jul 14 '17 at 14:11

So, I just spoke with google support and it looks like I'm going to change direction on this. They confirmed that the client is communicating securely with the google servers. He also said that enabling SSL would increase the sync time significantly. Plus, if I run the client on a DC and use, then I don't even have to worry about exposing the traffic on our network, and even then it would still be confined to our private server network were I to run it on a member server.

So, I'll probably play around with it a little more to see if I can get 636 working just for kicks, but I probably won't spend too much time on it as I've got a good amount of other stuff to take care of. What's weird is that I tried using the MS LDP tool from that computer that's has the GADS client on it and it connects to my DC on port 636 without issue. I've been trying all sorts of domain\username combinations, all of which connect fine on 389, but once you change it to 636 and LDAP+SSL, it spits out:

Initializing... Error: Connection failed Exception: Failed to execute query because the object at Base DN: "DC=mydomain,DC=com" is missing or inaccessible.

So yeah, I'm not quite sure why it's not connecting on 636, but it looks like I don't even want it to anyways.

  • You most likely have to tell it that it should use SSL on that port. (Not sure how todo that for the sync tool) – eckes May 29 '17 at 7:29
  • There's a dropdown that allows you to select LDAP or LDAP+SSL – Mike May 29 '17 at 15:26
  • @Mike I've been facing this same type of issue. Running Google Cloud Directory Sync on the Domain Controller itself might be one option, but for setups that may require a separation between the Domain Controller and other services, there ought to be a way to resolve this issue in order to use the LDAP+SSL option. I'm currently looking for more documentation on this... – summea Jun 22 '17 at 22:47
  • 1
    After a conversation with Google, there really was no need to go the SSL route, especially because it would add significant slowdown to the sync and the tool and my DC are on the same secure network. Also, LDAPS has nothing to do with the issues we were having so it wasn't really worth the effort to figure it out. So yeah, you'll probably need to chat with Google to figure out how to get LDAPS working - sorry I don't have more info! – Mike Jun 23 '17 at 3:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.