timbo343 Posted January 29, 2020 Posted January 29, 2020 With MS dropping support for LDAP and want everyone to use LDAPS, we thought we would look at GCDS and try to get it to work. We have imported the DC certificate into the cacerts file as described here >> https://serverfault.com/questions/852604/need-help-setting-up-google-cloud-directory-sync-with-ad-using-secure-ldap however we are finding an issue when testing the connection in GCDS. We are receiving: "Exception: Network problem: Unable to connect to the specified LDAP server: simple bind failed: *serverNetBIOSName*:636, reason: SocketException - Connection reset" The firewall on both DC and Gsync server have port 636 allowed. Can anyone help?
PyROm Posted January 29, 2020 Posted January 29, 2020 If you dont have CRL revocation setup properly/are not using it and are using your on CA server, then you need to disable CRL checking in GCDS (details on this page https://support.google.com/a/answer/3075991?hl=en ).
mavhc Posted January 29, 2020 Posted January 29, 2020 Test with ldp.exe, remember to use the fqdn not an ip address
timbo343 Posted January 29, 2020 Author Posted January 29, 2020 Ah! looks like ldp.exe doesn't like port 636 as it says it cannot connect to the server. Error <0x51> Looks like i'm going to have to go back a few steps before this is going to work.
TechMonkey Posted January 29, 2020 Posted January 29, 2020 LDP does work with 636, I've been doing testing with it. As Mavhc said, make sure you use FQDN and that it is a proper certificate, unless you can install the cert on all the devices using it.
mavhc Posted January 29, 2020 Posted January 29, 2020 Also you can set the logging level higher and use get-content gcds.log -tail 100 -wait and see the errors in real time when you click Test Sync
timbo343 Posted January 29, 2020 Author Posted January 29, 2020 I think this issue is bigger than i first thought. The Certificate for the DC in question, found in MMC > Certificates > Local Computer Account > Personal > Certificates had 1 year on it and expired 2017 and it was issued by an internal issuing server. I wonder if this is the issue?
TechMonkey Posted January 29, 2020 Posted January 29, 2020 I think this issue is bigger than i first thought. The Certificate for the DC in question, found in MMC > Certificates > Local Computer Account > Personal > Certificates had 1 year on it and expired 2017 and it was issued by an internal issuing server. I wonder if this is the issue? Almost certainly.
timbo343 Posted January 29, 2020 Author Posted January 29, 2020 So im going to ask, whats the best way to get round this? I hate certificates the best of times! 1
free780 Posted January 29, 2020 Posted January 29, 2020 Do you have a PKI? If you don't have ADCS. Do not put it on a DC. I'm not sure if Let's Encrypt can be used.
TechMonkey Posted January 30, 2020 Posted January 30, 2020 So im going to ask, whats the best way to get round this? I hate certificates the best of times! https://www.petri.com/enable-secure-ldap-windows-server-2008-2012-dc-configuration or https://support.microsoft.com/en-gb/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority
Arthur Posted January 30, 2020 Posted January 30, 2020 I'm not sure if Let's Encrypt can be used. Let's Encrypt would work as long as the AD domain uses a suitable FQDN (i.e. whoever setup the domain followed best practices and didn't use .local ). The following blog post contains details on how to set it up... www.dvolve.net/blog/2019/12/using-lets-encrypt-for-active-directory-domain-controller-certificates/ If you've ever had to setup an HTTPS website in the past couple years, you've most likely heard of Let's Encrypt which is arguably the largest public certificate authority in the world. Not only are their certificates free, the entire ordering and renewal process can be completely automated using a recently finalized protocol standard known as ACME (RFC 8555). But there are endless apps and services other than HTTP based web sites that can also use TLS certificates. On Windows specifically, there are things like Remote Desktop (RDP), SQL Server, WinRM, Exchange, and Active Directory. Many folks don't realize that the certificates you get from Let's Encrypt can be used for these other services as well and they don't even need to be exposed to the Internet as long as the domain name is real and obtained from a public domain registrar. This can be a huge operational win for smaller organizations who don't have the resources or expertise to design, implement, and maintain an internal Public Key Infrastructure (PKI). Active Directory is historically a bit more picky about certs than some other services and ever since I wrote Posh-ACME, I've been curious if Let's Encrypt certs would work with it. As it turns out, they work great with a couple minor caveats. USING PUBLIC CERTS FOR INTERNAL SERVICES In order to get a certificate from a public CA like Let's Encrypt, the FQDN in the cert must be part of a domain that was obtained from an ICANN recognized domain registrar. If your internal domains end in TLDs like .local or .int, you're out of luck. You're also more likely to run into future problems like everyone who was using .dev until Google purchased it. So if you're doing that, stop it.
Arthur Posted January 30, 2020 Posted January 30, 2020 Here's another guide on how to use OpenSSL to create the appropriate certificate(s). https://gist.github.com/magnetikonline/0ccdabfec58eb1929c997d22e7341e45
localzuk Posted January 30, 2020 Posted January 30, 2020 (edited) OK. So I've just done this here. I have PKI set up. So, I exported the CA's root cert, and imported that into the java keystore using: c:\Program Files\Google Cloud Directory Sync\jre>bin\keytool.exe -keystore lib\security\cacerts -import -file c:\cs2cert.cer -alias cent-cs-01 The default keystore password is changeit Then I edited the 2 files config-manager.vmoptions and sync-cmd.vmoptions in c:\program files\google cloud directory sync to add 2 lines: -Dcom.sun.net.ssl.checkRevocation=false -Dcom.sun.security.enableCRLDP=false Opened the configuration tool and edited the LDAP configuration to use the FQDN for the DC, port 636 and connection type LDAP+SSL. Tested and working OK. Edited January 30, 2020 by localzuk 3
timbo343 Posted February 27, 2020 Author Posted February 27, 2020 (edited) Just coming back to this thread after now sorting out the certificates with my RootCA and SubCA, i have added the DC certificate to the JRE cacerts and have tested GCDS connection with LDAP + SSL via port 636 which gives a successful connection however when running a simulation we get an error which looks like the following code. I can see it's trying to get to shs.com which is our internal domain but obviously cannot see it. I'm hoping this isn't trying to find shs.com on the net as it won't resolve. I know that LDAPS is working against the DC as i can successfully run LDP.exe on port 636 and it connects and on the wifi control, using port 636 authenticates users without any issues. [2020-02-27 14:56:12,511+0000] [AWT-EventQueue-0] [iNFO] [general.syncdialog.SyncDialog] Starting simulation [2020-02-27 14:56:18,058+0000] [pool-4-thread-5] [ERROR] [plugin.ldap.AbstractLdapHandler] Failed trying to connect to the specified LDAP server: null, reason: CommunicationException - simple bind failed: shs.com:636 [2020-02-27 14:56:18,058+0000] [pool-4-thread-5] [FATAL] [page.general.AbstractSimulateSyncWorker$WorkerStatusLogger] Exception while attempting to retrieve results javax.naming.NamingException: Failed trying to connect to the specified LDAP server: null, reason: CommunicationException - simple bind failed: shs.com:636 [Root exception is javax.naming.CommunicationException: simple bind failed: shs.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]] at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(Unknown Source) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(Unknown Source) at com.google.usersyncapp.plugin.ldap.LdapQueryExecutorImpl.runQuery(LdapQueryExecutorImpl.java:76) at com.google.usersyncapp.plugin.ldap.AbstractLdapHandler.executeRule(AbstractLdapHandler.java:530) at com.google.usersyncapp.plugin.ldap.AbstractLdapHandler.executeOrgunitRule(AbstractLdapHandler.java:118) at com.google.usersyncapp.plugin.ldap.LdapOrgunitRule.execute(LdapOrgunitRule.java:42) at com.google.usersyncapp.plugin.ldap.LdapFulfill.doFulfillOrgunits(LdapFulfill.java:591) at com.google.usersyncapp.plugin.ldap.LDAPPlugin.doFullFill(LDAPPlugin.java:460) at com.google.usersyncapp.sync.FullFillWorker.call(FullFillWorker.java:54) at com.google.usersyncapp.sync.FullFillWorker.call(FullFillWorker.java:22) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: javax.naming.CommunicationException: simple bind failed: shs.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] at com.sun.jndi.ldap.LdapReferralContext.(Unknown Source) at com.sun.jndi.ldap.LdapReferralException.getReferralContext(Unknown Source) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(Unknown Source) ... 14 more Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) at sun.security.ssl.Handshaker.fatalSE(Unknown Source) at sun.security.ssl.Handshaker.fatalSE(Unknown Source) at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source) at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source) at sun.security.ssl.Handshaker.processLoop(Unknown Source) at sun.security.ssl.Handshaker.process_record(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source) at sun.security.ssl.AppOutputStream.write(Unknown Source) at java.io.BufferedOutputStream.flushBuffer(Unknown Source) at java.io.BufferedOutputStream.flush(Unknown Source) at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source) at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source) at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source) at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source) at com.sun.jndi.ldap.LdapCtx.(Unknown Source) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Unknown Source) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Unknown Source) at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(Unknown Source) at javax.naming.spi.NamingManager.getURLObject(Unknown Source) at javax.naming.spi.NamingManager.processURL(Unknown Source) at javax.naming.spi.NamingManager.processURLAddrs(Unknown Source) at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source) ... 17 more Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(Unknown Source) at sun.security.validator.PKIXValidator.engineValidate(Unknown Source) at sun.security.validator.Validator.validate(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) ... 40 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.build(Unknown Source) at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source) at java.security.cert.CertPathBuilder.build(Unknown Source) ... 46 more [2020-02-27 14:56:19,298+0000] [pool-4-thread-6] [iNFO] [plugin.google.LocalAndRemoteKeyStore] 1,395 Unique ID (Non-Address Primary Key) mapping(s) retrieved. [2020-02-27 14:56:37,706+0000] [pool-4-thread-6] [iNFO] [plugin.google.GoogleFulfill] Skipping retrieval and processing of calendar resources. [2020-02-27 14:56:37,706+0000] [pool-4-thread-6] [iNFO] [plugin.google.GoogleFulfill] Skipping retrieval and processing of licenses data. [2020-02-27 14:56:37,706+0000] [pool-4-thread-6] [iNFO] [plugin.google.GoogleFulfill] Skipping retrieval and processing of custom schemas. [2020-02-27 14:56:37,706+0000] [pool-4-thread-6] [iNFO] [plugin.google.GoogleFulfill] Skipping retrieval and processing of identity mapped groups. [2020-02-27 14:56:37,706+0000] [swingWorker-pool-1-thread-2] [ERROR] [sync.agent.FullSyncAgent] Caught Throwable during full synchronization - com.google.usersyncapp.sync.FullFillWorker$FillFailureException: javax.naming.NamingException: Failed trying to connect to the specified LDAP server: null, reason: CommunicationException - simple bind failed: shs.com:636 [Root exception is javax.naming.CommunicationException: simple bind failed: shs.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]] java.util.concurrent.ExecutionException: com.google.usersyncapp.sync.FullFillWorker$FillFailureException: javax.naming.NamingException: Failed trying to connect to the specified LDAP server: null, reason: CommunicationException - simple bind failed: shs.com:636 [Root exception is javax.naming.CommunicationException: simple bind failed: shs.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]] at java.util.concurrent.FutureTask.report(Unknown Source) at java.util.concurrent.FutureTask.get(Unknown Source) at com.google.usersyncapp.sync.SynchronizationPluginGroup.executeFullFill(SynchronizationPluginGroup.java:99) at com.google.usersyncapp.sync.agent.FullSyncAgent.fullFill(FullSyncAgent.java:500) at com.google.usersyncapp.sync.agent.FullSyncAgent.call(FullSyncAgent.java:133) at com.google.usersyncapp.ui.page.general.AbstractSimulateSyncWorker.doInBackground(AbstractSimulateSyncWorker.java:85) at com.google.usersyncapp.ui.page.general.AbstractSimulateSyncWorker.doInBackground(AbstractSimulateSyncWorker.java:28) at javax.swing.SwingWorker$1.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at javax.swing.SwingWorker.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: com.google.usersyncapp.sync.FullFillWorker$FillFailureException: javax.naming.NamingException: Failed trying to connect to the specified LDAP server: null, reason: CommunicationException - simple bind failed: shs.com:636 [Root exception is javax.naming.CommunicationException: simple bind failed: shs.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]] at com.google.usersyncapp.sync.FullFillWorker.call(FullFillWorker.java:68) at com.google.usersyncapp.sync.FullFillWorker.call(FullFillWorker.java:22) at java.util.concurrent.FutureTask.run(Unknown Source) ... 3 more Caused by: javax.naming.NamingException: Failed trying to connect to the specified LDAP server: null, reason: CommunicationException - simple bind failed: shs.com:636 [Root exception is javax.naming.CommunicationException: simple bind failed: shs.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]] at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(Unknown Source) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(Unknown Source) at com.google.usersyncapp.plugin.ldap.LdapQueryExecutorImpl.runQuery(LdapQueryExecutorImpl.java:76) at com.google.usersyncapp.plugin.ldap.AbstractLdapHandler.executeRule(AbstractLdapHandler.java:530) at com.google.usersyncapp.plugin.ldap.AbstractLdapHandler.executeOrgunitRule(AbstractLdapHandler.java:118) at com.google.usersyncapp.plugin.ldap.LdapOrgunitRule.execute(LdapOrgunitRule.java:42) at com.google.usersyncapp.plugin.ldap.LdapFulfill.doFulfillOrgunits(LdapFulfill.java:591) at com.google.usersyncapp.plugin.ldap.LDAPPlugin.doFullFill(LDAPPlugin.java:460) at com.google.usersyncapp.sync.FullFillWorker.call(FullFillWorker.java:54) ... 5 more Caused by: javax.naming.CommunicationException: simple bind failed: shs.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] at com.sun.jndi.ldap.LdapReferralContext.(Unknown Source) at com.sun.jndi.ldap.LdapReferralException.getReferralContext(Unknown Source) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(Unknown Source) ... 14 more Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) at sun.security.ssl.Handshaker.fatalSE(Unknown Source) at sun.security.ssl.Handshaker.fatalSE(Unknown Source) at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source) at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source) at sun.security.ssl.Handshaker.processLoop(Unknown Source) at sun.security.ssl.Handshaker.process_record(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source) at sun.security.ssl.AppOutputStream.write(Unknown Source) at java.io.BufferedOutputStream.flushBuffer(Unknown Source) at java.io.BufferedOutputStream.flush(Unknown Source) at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source) at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source) at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source) at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source) at com.sun.jndi.ldap.LdapCtx.(Unknown Source) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Unknown Source) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Unknown Source) at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(Unknown Source) at javax.naming.spi.NamingManager.getURLObject(Unknown Source) at javax.naming.spi.NamingManager.processURL(Unknown Source) at javax.naming.spi.NamingManager.processURLAddrs(Unknown Source) at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source) ... 17 more Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(Unknown Source) at sun.security.validator.PKIXValidator.engineValidate(Unknown Source) at sun.security.validator.Validator.validate(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) ... 40 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.build(Unknown Source) Edited February 27, 2020 by timbo343
timbo343 Posted February 27, 2020 Author Posted February 27, 2020 I might have just got it working. Had to import both SubCA certificate and the certificate from the DC into the JRE store with the command bin\keytool -keystore lib\security\cacerts -storepass changeit -import -file *location_to_.cer* -alias *FriendlyName*
markwilfan Posted May 19, 2020 Posted May 19, 2020 OK. So I've just done this here. -Dcom.sun.net.ssl.checkRevocation=false -Dcom.sun.security.enableCRLDP=false Been suffering with very slow ldap sync since turning on ldaps, fine in the gui sync but commandline was taking hours! Added this into the sync-cmd.vmoptions file which sorted it. Google Support told me to contact MS hahahaha. 2 hours of my life I'll never get back Thanks @localzuk
jthompson Posted February 9, 2022 Posted February 9, 2022 OK. So I've just done this here. I have PKI set up. So, I exported the CA's root cert, and imported that into the java keystore using: c:\Program Files\Google Cloud Directory Sync\jre>bin\keytool.exe -keystore lib\security\cacerts -import -file c:\cs2cert.cer -alias cent-cs-01 The default keystore password is changeit Then I edited the 2 files config-manager.vmoptions and sync-cmd.vmoptions in c:\program files\google cloud directory sync to add 2 lines: -Dcom.sun.net.ssl.checkRevocation=false -Dcom.sun.security.enableCRLDP=false Opened the configuration tool and edited the LDAP configuration to use the FQDN for the DC, port 636 and connection type LDAP+SSL. Tested and working OK. After upgrading to 4.7.14 today, this post has just saved me, thanks. I must have forgotten to document those two line additions when I last installed an update.
localzuk Posted July 19, 2022 Posted July 19, 2022 OK, so updated to 4.7.18 and the original commands don't quite work now. Changes below: I have PKI set up. So, I exported the CA's root cert (in my example below it is cs2cer.cer, and our CS server is cent-cs-01), and imported that into the java keystore using: "c:\Program Files\Google Cloud Directory Sync\jre\bin\keytool.exe" -keystore cacerts -import -file c:\cs2cert.cer -alias cent-cs-01 The default keystore password is changeit Then I edited the 3 files below: config-manager.vmoptions sync-cmd.vmoptions upgrade-config.vmoptions from c:\program files\google cloud directory sync to add 2 lines: -Dcom.sun.net.ssl.checkRevocation=false -Dcom.sun.security.enableCRLDP=false Then re-ran a sync, and everything worked again. 2
jthompson Posted July 19, 2022 Posted July 19, 2022 Interesting, I've been using 4.7.18 without issue for a while but without those two lines having been added to upgrade-config.vmoptions. I've added it to my notes for upgrading GCDS anyhow.
localzuk Posted July 19, 2022 Posted July 19, 2022 Interesting, I've been using 4.7.18 without issue for a while but without those two lines having been added to upgrade-config.vmoptions. I've added it to my notes for upgrading GCDS anyhow. The ones in upgrade-config may not be necessary, I was just being thorough.
jthompson Posted October 21, 2022 Posted October 21, 2022 Just upgraded GCDS to v5.0.20, and all still appears to be working okay after performing the the above steps (post #19).
jthompson Posted September 22, 2023 Posted September 22, 2023 Upgraded to v5.0.28 today at it seemed a little more fussy about certificates used for LDAPS. As per https://support.google.com/a/answer/9746852 it might also need the following lines removed from the "sync-cmd.vmoptions" and "config-manager.vmoptions" files: -Djavax.net.ssl.trustStoreProvider=SunMSCAPI -Djavax.net.ssl.trustStoreType=Windows-ROOT I was finding that the LDAPS test in the config editor app was happy, and any search rules were testing successfully in the editor, but when it came to a sync run it would error out on one of my rules (one for license assignments, which differs from all other LDAP search rules in that no base DN can be specified).
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now