Known Participant

Question

Errors authenticating using CFLDAP

Forum|Forum|4 years ago
June 22, 2021
7 replies
10308 views

We have an application that uses CFLDAP, port 636 to authenticate user to Active Directory. We are getting the following error: An error has occurred while trying to execute query :xxx.yyy.zzzz:636.

The server is running CF2021 Enterprise, on a Windows 2016 server

I can get it to work randomly rebooting the server or starting/stopping the CF Application service. It might start working on the second, third, fourth reboot, etc. Once it is working it is fine until monthly patch reboots and the failure process starts all over again. We do have a CF2018 server also on Windows 2016 server and do not have the issue.

Here is what I have tried, all with no long-term luck in fixing the issue:

Reinstalled Windows and a fresh copy of CF2021
Tried different OpenJDK versions (all ver 11.x)
Tried importing our domain and server certs into the cacert in the JRE folder
Tried a completely different CF2021 server – same issue

The error output is not very helpful.

No entries in Windows, Apache or CF logs when the error occurs.

CFCATCH doesn’t provide anything useful

I feel like this is cert related but can’t find anyway to further diagnose the actual error above to provide any deeper details.

Thoughts/Suggestions?

This topic has been closed for replies.

D

DgcottonAuthor

Known Participant

Here is an interesting update.

In the process of setting of a different instance on Windows Server 2019, I downloaded the latest CF installer which had Update #2 folded into it. I proceeded to setup CF2021 as I had done previously, everything out of the box, used the JDK that is installed by CF2021.

I was able to utilize the secure CFLDAP calls without issue, where as before I could not and had to use port 389.

I have repeated the process twice now on Windows Serer 2016. Each time working as expected. A little too early to tell (knock on wood), but it looks promising.

I also noticed some of the bugs with the original installer have also been fixed. Some of the things I had to fix manually before are now present with the latest installer from the CF downloads web site.

D

DgcottonAuthor

Known Participant

Well.... success was short lived 😞

Restarted the CF Application service 3-4 times the day before - worked fine

Today, restarted the CF Application and it is back failing on port 636. Changed to port 389 and it works.

C

cartlon219870490rg3

Participant

i have also faced the same issue.

C

cartlon219870490rg3

Participant

don't know how to resolve it. surveyzop.com tellculvers

D

DgcottonAuthor

Known Participant

Adobe has provide a hot fix, suggested installing JDK11.0.13, requested additional debug settings to the jvm.conf file and applying update #2 for 2021. None of these have addressed the issue.

100% of the time if I restarted the server (Windows 2016), the application using secure port for CFLDAP, will fail to authenticate users. Roughly 75% of the time, if I just restart the CF application service, the application will properly authenticate

BKBK

Community Expert

@Dgcotton , Hats off to you, man. You have shown great patience in persevering with this cfldap issue.

I just got an idea. Consider it a test or proof of concept. If only for the sake of ruling things out.

We've been talking updates and upgrades right from the beginning of this thread. Namely, of ColdFusion, TLS and Java. We've so far ignored the one silent partner always lurking in the background: Windows Server 2016. What if some part of the server is too old for the changes we're making?

The idea to test:

What happens when you test your exact CFLDAP setup on Windows Server 2019?
The test in 1. is a test that takes us one step forward. Let's suppose you are unable to do it, for whatever reason.
Then there is an alternative test you can do. By taking one step backwards.
The test involves enabling TLS 1.0 and TLS 1.1 in your current environment, to see whether CFLDAP would then work as expected.
Steps to re-enable TLS1.0 and TLS 1.1 (Remember to back up your files before you proceed):

- open the JDK config file \conf\security\java.security in a text editor. Locate jdk.tls.disabledAlgorithms. Remove "TLSv1, TLSv1.1," from its value (assumed: this is the JDK that ColdFusion is using)

- launch the registry tool, regedit;
Enable the TLS 1.0 and TLS 1.1 registry keys. The paths are
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server

Restart Windows Server 2016.

- add the following 2 flags to java.args in the ColdFusion instance's jvm.config

-Djdk.tls.client.protocols=TLSv1.2,TLSv1.1,TLSv1.0 -Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1.0

Restart ColdFusion..

Do your CFLDAP thing. Does it work?

D

DgcottonAuthor

Known Participant

@BKBK Thanks. Its been tough. Fortunatly we haven't converted to CF2021 across the board and am able to still run CF2018 without issue.

I will see if our DevOps team can stand up a Windows 2019 server and report back the findings

D

DgcottonAuthor

Known Participant

Update: I have engagaed with an Adobe technical rep, we have not yet found the root cause of the issue but will post back to this thread once we do.

Charlie Arehart

Community Expert

Hey Dan, any update on that help Adobe offered last week?

/Charlie (troubleshooter, carehart. org)

D

DgcottonAuthor

Known Participant

Nothing yet

Charlie Arehart

Community Expert

I've read through all the messages over the past few months here, and I think I can offer some new things worth considering.

1) For example, I see dgcotton saying that it works always if he uses port 389 but haltingly if he uses 636. The latter presumes to use TLS, while the former does not. So first, to BeRadB and George and anyone else who has experienced issues with CFLDAP, can you confirm if you see that same pattern? Whether you do or do not, there's more to consider.

2) Equally important I think, there's something I never see clarified which is EXACTLY what Java version (point release, not major release) is being used with any CF that is failing (or working), whether with CF2021 or CF2018? Can each of you who has the error please confirm, for the failing and working ones?

And I raise this because the Java updates from April on (11.0.11 and 12, or 1.8.0_291 or 301) have an important change where the JVM no longer allows calls out to servers that support only up to TLS 1.1 or 1. (I have a blog post with more on that jvm update.) As such, a cfldap call, or cfhttp, or cfmail, or cfftp, and so on would all now FAIL if the server they are CALLING out to ONLY supports those and not TLS 1.2 or above, once someone applies those JVM updates or later. (And FWIW, I discuss in the post how one COULD modify things to ALLOW again calls to TLS 1.1 or 1.0, if necessary.)

Now, I know that the matter of TLS versions did come up briefly in the thread, and dgcotton said then that he confirmed that "both the client and server" showed supporting TLS 1.2, judging by his assessment of reg keys as suggested by BKBK. (I'll assume that by "server" he means he checked the LDAP server that CF is trying to call, rather than the CF server itself, as that doesn't matter in this case of a cfldap call.)

3) But here's something else to consider, especially given the on again/off again nature of the problem dgcotton saw: what if somehow the request leaving CF is going to some server OTHER than the actual one you checked? What if the ldap is somehow behind a load balancer? If somehow only ONE of those servers was setup for TLS 1.2 and the other was still 1.1 or 1.0, then CF (the JVM) would reject that request if you were on either of those updated Java versions above.

4) In wrapping up, again, please confirm that java version (major and minor numbers) first and foremost--and all the more, dgcotton, please check what it is in the "working cf2018", because if THAT CF's jvm is EARLIER than one of those above, then THAT could be why that CF instance "never" has this problem.

Finally, to be clear, one should not base any assertion of "what the java version is" on what they think they know about what JVM's are or show to be installed in the OS. What matters specifically is what JVM that CF instance points to, as the java home, in the CF Admin. And if the version is not in the folder name, look at the CF admin "settings summary", as that lists the jvm version.

It could really be that this is not at all "about CF2021" but just about the JVM version, and this TLS issue, especially given some of what's been discussed above.

But I'm just going based on that. Perhaps new info will show things to be otherwise. Hope that's helpful.

/Charlie (troubleshooter, carehart. org)

D

DgcottonAuthor

Known Participant

Hi Charlie, I have tried many different versions of the JRE.

I have been working with three different servers, trying different things.

I did take my "test02" server, uninstalled CF21, deleted folders, and did a fresh install - nothing else changed and now it works! I have NOT applied update #1

For the other servers here is all the versions I have tried.

All servers have the same configured path d:\ColdFusion2021\jre

cftest02 - working
java version "11.0.1" 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)

prod06 - Failing
java version "11.0.1" 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)

prod06 - Failed
openjdk version "10" 2018-03-20
OpenJDK Runtime Environment 18.3 (build 10+44)
OpenJDK 64-Bit Server VM 18.3 (build 10+44, mixed mode)

prod06 - Failed
openjdk version "16.0.1" 2021-04-20
OpenJDK Runtime Environment (build 16.0.1+9-24)
OpenJDK 64-Bit Server VM (build 16.0.1+9-24, mixed mode, sharing)

prod06 - Copied jre folder from working test02, rebooted server - still failed

Prod05 - Failing
java version "11.0.1" 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)

prod05 previous tries

Failed
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment Microsoft-22268 (build 11.0.11+9)
OpenJDK 64-Bit Server VM Microsoft-22268 (build 11.0.11+9, mixed mode)

Failed
java version "11.0.9" 2020-10-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.9+7-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.9+7-LTS, mixed mode)

Failed
java version "11.0.1" 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)

Charlie Arehart

Community Expert

dgcotton, as for this server that now "works", are you saying it's worked for minutes, hours, days, or weeks? That could be useful to know. 🙂

Also, I see that Priyank has stepped in and is offering to dig through the ssl/tls debug logs (as George had suggested back in June, and you shared only some of the results in one of your attachments). Perhaps if you share more with Priyank he may see something helpful.

Until then, you have responded here with what I can tell is the output of the java -version command, as I gather you ran on each of the servers you were assessing. To be clear, are you sayign you went to that d:\ColdFusion2021\jre folder you mention and ran that there?

I specifically tried to avoid any confusion about things when I asked instead that you (and any involved here) report specifically the jvm verison shown in the CF Admin's "settings summary" page.

Can you report that, for the one that IS working, and for any where it is NOT working? I realize it may seem pointless, but we can't know (and folks could make incorrect assumptions) until it's confirmed.

/Charlie (troubleshooter, carehart. org)

BeRadB

Inspiring

I am having the same issue but with cold fusion 2018. I have tried all the suggestions metionned in this post but no luck resolving. I saw that they closed the ticket on tracker for 2021. Can anyone help with debugging this on cf2018?

Iambradb.com Adobe ColdFusion Specialist.

D

DgcottonAuthor

Known Participant

My test CF21 systems still exhibit this issue. I did take one of the systems that was having the problem, uninstalled CF21 and reinstalled BUT did not apply update #1.

I have rebooted it half dozen times and it is working as it should.

This has to 100% a CF issue. I changed nothing else on the server. Only uninstalled and reinstalled. At some point I will have to re-install the updates on this test box.

Still no understanding why this is happening

D

DgcottonAuthor

Known Participant

Also: I used KeyStore explorer to import the certs. I also installed "CertMan" in CF. Both tools show the domain and DC certs and not expired.

George____

Inspiring

I recommend creating a test page with a hard coded ldap call that you can use to duplicate this issue. It'll be a lot simplier if you're able to remove all the variables that probably exist in your current code. On that test page put <cfdump var="#server.system.properties.java#"> so you can verify the java version and location that's being used.

One advantage of a seperate test page is that if you're current LDAPS connection isn't working, but your test page is it'll indicate the issue is probably not with LDAP, but something you're doing prior to that. For example, however you're creating the filter may not be working right and it's generating an invalid LDAP call.

Try using an LDAP client on the windows server. If you're having problems connecting with that it may indicate the issue is not with CF.

You can try adding -Djavax.net.debug=ssl to your jvm.config and then restart coldfusion. I forget exactly which log that will go to, but I believe the coldfusion-error.log. If you don't see anything useful you could try -Djavax.net.debug=all instead.

D

DgcottonAuthor

Known Participant

Hi George. I tried your suggestions and still get the same random results. Working with two fresh “dev” servers built to troubleshoot this issue.

I create a simple page with no variables. I added the debug line to the jvm.config file and rebooted. Snippet of CFLAD code attached

This is the odd part – it took 6 reboots to get it to fail. Reboots 1 through 5, the sample page worked fine, authenticated and returned a good dump result. Reboot 6 the failed. Subsequent reboots would result in around 50% failure rate. Both servers had similar experiences.

I have tried the OpenJDK, Microsoft OpenJDK, JRE that was installed with CF and a copy of the JRE from the CF2018 server that works fine.

The coldfusion-error log didn’t have anything useful that I can see, error message attached

I used LDAPAdmin from the server at a time when the sample app was failing and was able to make a connection.

I have imported the certs from the various domain controllers and domain – same issue repeats.

My gut tells me it is something to do with certs but can’t find anything definitive, especially since some reboots the app will work fine.

Also attached the system variables.

I do believe it is something with CF2021 as the CF2018 server does not exhibit this issue

error.txt

sample_code.txt

environment.txt

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded