This is related to the 2020 LDAP channel binding and LDAP signing requirement for Windows up coming change.
If you were not aware, Microsoft soon begin enforcing LDAP channel binding and signing requirements for Windows - the full article is here.
The key take-away is:
"The security of a directory server can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing (integrity verification) or to reject LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection."
That last part is a key consideration as, if you use an LDAP connection via Mid Server for user and group provisioning (not a direct connection for authentication) then odds are this change will impact your integration in a negative way. The good news is it's not too terribly difficult to get out ahead of this and prevent any impact, but you may need some time to pull together everything that you need. ServiceNow does provide a simple document that outlines the procedure here, but it's a little light on the details and doesn't offer much in the way of guidance.
Things that you will need (or need to know)
The first thing that you need to know is, you are likely to spend some time with trial and error before you get everything working. Accept it - deep breath - and move on.
The next thing you are going to need is access to log on interactively to the host machine(s) where your Mid Servers are running, or access to an individual with this ability and at least enough technical skill for you to walk them through the procedure. You shouldn't necessarily required administrative rights (I performed these steps with the same account the mid server service was running under) but your milage may vary.
The second thing you will need it access to someone who understands the Domain environment and can provide you with details regarding what certificates you actually need to trust in order to make a secure connection. Depending on the environment you will need at least one (The Signing Certificate Authority Certificate) but there may be intermediate certificates that you'll need as well. Hopefully there is someone who can tell you which ones you need, and provide them to you ready to go, otherwise this is where trial and error will come into play.
Once you know what certificates you actually need, you will need to export them from a machine where they are currently installed. The machine your Mid Server is running on would be a good candidate, in fact if the certificates are not on that machine for some reason you will need to add them there too! To do so, double click the .cer files and select "install Certificate", Local Machine and let the Wizard automatically select the certificate store.
Exporting a Certificate (Windows)
To export a certificate you would need to open a cmd prompt and type mmc and hit enter to open the Console.
Go to File > Add/Remove Snap-in
Double Click on Certificates.
Select Computer Account and click Next.
Click Finish
Click Ok
Expand Certificates by clicking the "greater than" sign.
Expand the Cert Store where you certificate is located - for me it was Trusted Root Certification Authorities
Click on the Certificates subfolder
Find your Cert in the list, right click on it, go to All Tasks and then Export
Click Next on the Wizard.
In my case, I left the default selected; DER encoded binary X.509 (.cer)
Click Next
Select Browse and choose directory and a file name to save the file to - do yourself a favor here, you will using this path in a later command, so the shorter and easier the better!
Rinse and Repeat for any additional Certs that you require.
Adding the Certificate the Keystore
Ok, now what you have the certificates you need, we can place them in the keystore! To do this you will need to locate keytool.exe and path to lib\security\cacerts. The documentation from ServiceNow gives an example of "C:\Program Files\Java\jre1.8.0_161\bin" however that is not likely to be what you need!
I found that the correct path was within the same folder where the Mid Server was installed. For example my paths were:
D:\agents\midserver1\agent\jre\bin\keytool.exe
D:\agents\midserver1\agent\jre\lib\security\cacerts
Next, you need to open a cmd prompt (run as administrator) and switch to the directory where keytool.exe exists. First change to the appropriate drive (if needed) by typing the drive_letter: and hitting enter
If you are lucky and your path contains no spaces, you can enter cd and then copy and paste the whole path (right click to paste in a cmd) and hit enter.
If you are not lucky, you will have to use cd and a directory name to change directories one at time until you reach bin.
Once you are there, you will need to execute this command, replacing the values to match your directories. Make note of the use of "" around paths - you need to include them.
keytool -import -alias <certificate alias> -file "<path to certificate>" -keystore "<path to the JRE>\lib\security\cacerts"For alias you can use whatever name you would like, as long as it is unique within the keystore. I went with RootCert.
In my case, I saved my cert to d:\certs with a name of RootCert.der so my command looked like this:
keytool -import -alias RootCert -file "D:\certs\RootCert.cer" -keystore "D:\agents\midserver1\agent\jre\lib\security\cacerts"Answer yes when prompted whether you want to add the certificate.
When prompted for a password, the default password is all-lower-case changeit
You should see a message that the certificate was added to the keystore successfully. Review the response for any errors.
After you have added the Certs to the Keystore
You're not quite done. The next step (which is not documented anywhere I could find and is not entirely intuitive) is to restart the Mid Server Service. You can use your method of choice.
Once the Mid Server has restarted you will need to adjust your LDAP configuration within ServiceNow.
Navigate to System > LDAP
Open LDAP Servers
Select a Server and open the record.
Under the embedded list, select the LDAP Server URL and open the record.
Modify the URL using the following format: ldaps://<hostname_fqdn>:636 and update the record.
From the LDAP Server record, click Test Connection under the Related Links and....
If all has gone well you will see a happy message:
Hopefully this can help others that will be facing this situation in the coming months!
If you found this article helpful or useful, please be kind and click appropriately. If you found it really useful, you could always use the 3-dot menu to bookmark it for later!
Michael Jones - Proud member of the CloudPires team!
