(SOLVED) Active Directory LDAPS for User source - LDAPS/SSL How to?

How can i check that they have been imported into the key store ok?. LDAP works fine, LDAPS not. no user list or login working.

Can anyone tell me how to check they have imported ok?

As both @Kevin.Herron and @ryanjmclaughlin have mentioned, just by dropping the certificate into the data\certificates\supplemental folder, and restarting the Gateway did the trick for me.

If that didn’t work for you, maybe you can check the following settings:

  • Primary Domain Controller Port: I have successfully used both 636 and 3269.
  • Use SSL: Checked.
  • Security Protocol: SSL (although Auto worked on a recent 8.0.14 installation).

And to check if the certificate was imported correctly, I ran the following command under the lib\runtime\jre-win\bin folder:

This will list all certificates:
keytool -list -v -keystore ..\lib\security\cacerts

But to filter the list, you can use the alias which in my case was the file name and extension
keytool -list -v -keystore ..\lib\security\cacerts -alias file_name.extension

Just substitue file_name.extension with the name of your certificate file.

But this begs the following question.

What happens when the certificate expires and it is replaced? Does dropping the new certificate into the suplemental folder and restarting the Gateway will handle it automatically or does one have to delete the certificate from cacerts manually?

Just adding a little note to this thread–everything mentioned above is accurate and works to enable LDAPS functionality. On a fresh install of 8.0.14, going through the SSL/TLS guided config for the Webserver properly placed the CA cert in data/certificates/supplemental and the gateway webserver began functioning properly in HTTPS mode; however, getting the LDAPS user source to function required a gateway restart (manual reloading of the gateway keystore via gwcmd -g was not enough either).

1 Like

Hi

Thank you for the help. I now have LDAP login working with SSL.

However I cannot get the user list working for the specific OU. It works with SSL off but not when enabled.

When I test my login it’s getting all the correct info back and the roles that had previously been assigned in ignition. But the user list isn’t coming up so I can’t add roles to new users.

Any ideas?

Hi Herbie,

Thank you for your post - it helped me out a log in getting my AD LDAP authentication working.

It was not smooth sailing even with the tips in your post a summary of my journey:

I found using KeyStore Explorer much easier to use than keytool. I put the CA root certificate into the JRE cacerts file as you suggested.

I was still not able to get the connection to the AD domain controller working even after putting the CA certificate into the cacerts file and restarting Ignition. I could see Ignition trying to connect to the domain controller in WireShark (monitored port 636) and kept seeing that the returned certificate was being rejected. There was no apparent reason.

Eventually I came across a few posts that describe how to get debug information out of the JRE. By adding a line line to the ignition.config file I was able to see that the correct certificate was being returned and that it was being rejected - more on that below. The line added was wrapper.java.additional.2=-Djavax.net.debug=“ssl,handshake,trustmanager”. After restarting Ignition, log information on the connection shows up in the wrapper log in the logs directory. The error message, “No subject allternate DNS name matching scada.domain.com found.” The name subject name on the returned certificate was mic-dc-01.scada.comain.com. To me it looks like this is a bug in Ignition. I hypothesize that Ignition expects a 3 part domain name as was ignoring the first part of my 4 part domain name.

In the end, I ended up specifying the domain controller host IP address in the configuration and added a SAN (subject alternate name) in the certificate. Everything works great now.

2 Likes

I have used KeyStore Explorer too, but I hadn’t figured out a way to generate the request to get a certificate from the AD Domain Controller properly. If you have tips on that, I’d appreciate that.

The biggest reason for adding the RootCA and the one generated for your specific instance is Java knows how to trust the certificates that will be coming from your domain controller. When Java receives it, it has to know how to validate it, and the RootCA and the intermediate certificates is how it does this. Getting yours generated appropriately is also important, as that is how the domain controller validates you.

One thing that has changed in the certificate generation process is the use of Subject Alternative Names. It’s important in the certificate request process that you include all names and aliases your gateway will be functioning as, otherwise browsers will show you the “bad certificate” message and require your users to accept to bypass the warning. Not ideal. For us, this was adding all DNS names, as well as IP addresses we could be communicating on. This ensure that no matter which way to connect, you are presented with a properly secure website. Remember, however, this is just so users connecting to your gateway are presented properly and has nothing to do with the LDAP connection. But doing that on the RootCA is equally important for the same reasons.

Part of the reason you were having issues is because you want to use a wildcard DNS name. By adding scada.domain.com and not *.scada.domain.com, you are saying it must match exactly. This is not a bug, but a part of the secure communications protocol in use by many systems (by the way, Java is the one enforcing this, not Ignition). Generating wildcard certificates isn’t as easy, but is much easier to deploy to multiple machines if you want to go that route.

Glad you got everything working though!

Hello all,
I have managed to get LDAPS communication working fine by setting up the following:

  • Using a GPO (or whatever automated process) I am getting our root and intermediate domain controller certificates (in .cer format ) from a central infrastructure share and copying them into the supplemental folder.
    This ensures that they are loaded by 8.x gateways and the domain itself is trusted.

I use Keystore Explorer to check in the embedded java CACERTS store and I see the domain certificates correctly imported.

I am also adding a System environment variable : “JAVA_TOOL_OPTIONS=-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT” and with all the above done it works seamlessly. Not sure if all the above is required but it works this way :slight_smile:

So the LDAPS part is good.
Now i’m looking at the SSL part - i have got it working for one gateway but am looking for a more global approach to manage multiple servers. If anything comes from that topic i’ll post a link to it here for future hunters to follow the breadcrumbs :slight_smile:
Thanks all for your help.
If you’re having issues getting LDAPS working, reply here and someone will help !!

1 Like

This shouldn’t have been necessary, and if it does what it says and is actually working then the “supplemental certs” mechanism Ignition has won’t work any more because you won’t even be using the Java keystore any more. If you can remove this and still get connected to AD I’d recommend that. Seems like less chance for confusion in the future.

i agree :slight_smile: i’ll loop back to this and unconfuse myself when writing up my internal procedures :slight_smile:

I am also having issues getting our AD/Internal Hybrid to connect to our Domain Controllers port 636
I have imported the .DER certificates into the supplemental folder and they are in the keystore. I am using 8.1.15 on Server 2019 and another Instance Windows 10 21H2. I have tried HostName and IP.
I have verified the cert with the nettools app also.