Cannot get ColdFusion 2023 Administrator to run after install

[CF_Jen]

I am trying to install ColdFusion 2023 on a new Windows virtual machine.

I set it up as Development Type - Development with CF Server Profile - Development Profile.  

After installation I ran the Web Server Config tool and added the IIS website/all

Here is what IIS has after installation & web config

After this I tried to access the localhost and receive this error message

The ColdFusion administration doesn't load either

Windows Virtual Machine

Microsoft Windows Server 2022 Standard64-bit

VMware 7,1

CPU: Dual 3.10 GHz Intel Xeon(r) Gold 6254@, Memory: 32768 MB

C: 79.62 GB (43.86 GB free)

Any help is greatly appreciated.  Thank you!

[BKBK]

What about this URL: http://localhost/CFIDE/administrator/index.cfm ?

[CF_Jen]

Hello BKBK,

Turns out the ColdFusion Application Service was not started.  Once I started it I was able to access the CF Admin.  

Now i'm running into issues where I am unable to access my site via another computer.  I believe this is an IIS issue and not a ColdFusion issue. 

Thank you for your help.

Jen

[BKBK]

Hi Jen,

Like you, I too am inclined to believe it is now an IIS issue. On which URL were you able to access the ColdFusion Administrator?

[Charlie Arehart]

Jen, as you discovered, the errors you should would have suggested cf is not running. Glad you sorted that out. 

As for the rest you offer in that comment, there's more to consider that may be helpful (some relating to your original post). If you have a couple minutes, you might find an answer or at least better help us help you. 

1) As for your next problem of being "unable to access my site via another computer", you're probably right how that would not be a cf problem. Here are some questions to guide you/us. 

What is such a page request showing? Is it hanging before failing? Would it fail or hang the same way if you DID stop cf? If so that would exonerate cf. Perhaps it's an iis setting, such as a limit in its optional "ip address and domain" feature, though I doubt it. 

Instead, what if you even stop iis: does the request (from "another computer") still fail or hang the same way? If, so that exonerates iis. It could be a firewall issue, or a proxy issue. 

2) One more question about this failing request from "another computer": was that your trying to access the cf admin? Via its port (like 8500)? If so, that's different. First, cf does by default limit access to that to be accessed only from the computer running cf itself (by default which can be changed). 

Second, your firewall (on the cf machine, and/or in your network) would also by default be blocking any non-standard port such as that 8500. You definitely need to open that port (carefully) to be able to access that from off the cf machine...and you'd need to tell the cf admin to allow in such an ip address, as mentioned above. 

3) Finally, as for your showing a CFIDE virtual directory in  iis, that would not have been done by the cf wsconfig tool...at least it's not been done (a CFIDE vd added) since cf2016, which is when they switched to the cf_scripts (for serving js and other files needed for some lesser-used cf tags). As for admin access, that version started enabling the built-in web server defaulting to 8500.

If you look at that CFIDE vd in iis, you will likely find it points at some folder other than your current cf's cfusion/wwwroot/CFIDE folder, and as such it should be removed.

And FWIW, a cf (and wsconfig) update last year now even explicitly prevents the connector from passing into cf any CFIDE request. (I suspect BKBK wasn't thinking of that and the previous point when he proposed you try that CFIDE url.)

I realize you may have already known some or all of the above. We can't tell from what you shared. As I help people with such problems almost daily, I've tried to share the questions and possibilities that seem most appropriate here. Some confuse that for arrogance and condescension, which are never my intent. (I also try to write in a way that might help others who find this thread, now or in the future.)

Let us know how things go on this next aspect you've presented. 

[BKBK]

Charlie, I suggested testing with http://localhost/CFIDE/administrator/index.cfm for one simple reason: CF_Jen reported to have tested with http://localhost:8500/CFIDE/administrator/  . 

[Charlie Arehart]

Indeed, you did. And it doesn't change at all why I said what I did. 

[TheNephalim]

I'm a bit flumoxed as to what the resolution of this is.

I have a DoD set of STIG rules that state I'm not supposed to use the internal ColdFusion Administrator.

OK.

I create an IIS website on a separate internal IP address over SSL and denying anonymous access.  

Now I have ColdFusion blocking me from using anything with CFIDE in the URL.

While I have been upgrading from 2018 to 2023, I have the internal administrator available.  I applied the suggestion of adding the IP address I'm using to attempt to access the CF administrator and this does not work at all.

So how am I supposed to administer ColdFusion while remaining compliant with DoD rules to maintain our authority to operate?

[Charlie Arehart]

There's not currently any good news on this front.

1) Since an update in Oct 2023 the cf admin can ONLY be reached via the built-in web server, not through the Tomcat AJP connector that Adobe implements via the wsconfig tool. 

This was a security-motivated change by Adobe to PREVENT any unexpected, inadvertent access to the CFIDE folder by way of an external web server like iis or apache. The AJP connector NOW BLOCKS any attempt to use CFIDE for requests made through that connector.

2) The challenge you raise is based on the fact that the stig has not been changed since cf11 in 2014, when it proclaimed that running the cf built-in web server was a violation. That needs to be revisited. It's one thing to say one should not use that as the ONLY web server for accessing CF. It went too far in asserting it should be disabled entirely, especially when since cf2016 Adobe enables that web server in the installer by default, and ALSO changed the wsconfig tool to no longer even configure a CFIDE a virtual directory in iis or apache.

This latest change just solidifies that effort, making it impossible to get around--again, they woukd argue for the sake of security. This whole matter of the change and the stig challenge was discussed in another thread here at the time. 

FWIW, as for getting the stig reconsidered, I heard an announcement from Adobe at one of the cf conferences this year that they were indeed working with DOD on an updated stig. 

3) So what can you do in the meantime?

Some may argue (however unwisely) that one could choose to NOT update the connector (perform wsconfig upgrade) beyond the update which introduced the change. The counterpoint is that withholding such a connector upgrade should itself be discouraged because the connector updates also address other security or functionality issues. (Indeed, it should be a stig violation not to have the connector updated, just like one should not run cf itself without being updated, along with the Java underlying it.) 

Otherwise, it seems you must seek variance from the stig, given this security-motivated change by Adobe, to require use of the built-in web server for accessing the cf admin (which I realize may seem an effort of unacceptable hassle for some).

Or let's see what others may say. But really, this discussion is better suited for that other thread. This one here was for a entirely different problem, it seems. 

[TheNephalim]

I appreciate your reply.  

Frankly, I feel this change blows.  

Our environment is such that we cannot access browsers or the internet on our servers.

I can't create a proxy to the site because I have IIS STIGs that disallow the creation of a proxy site.

So....the only alternative(s) I can see are to keep the internal site active and lock it down per the guide.  I could also technically mark the STIG as "Not Applicable" because it's a different server (TomCat versus JRun) and we're going to be on ColdFusion 2023 versus ColdFusion 11.  Whenever we need to administrate ColdFusion, we'll have to put in an HBSS exception so we can use the browser.  

As an aside, I did follow the STIGs for the sandboxing.  I haven't put everything in there because it caused some of our site's applications to create for some unknown reason.

I guess I'm just going to keep plugging along.  The last issue I have to try to figure out is why the upgrade messed up some of the applications receiving JSON strings from CFC components.  Yay.

I'm guess I'm going to

[Charlie Arehart]

"Blow" though the change may seem to (for some), I'll clarify first that I did not propose you create a proxy. (If one DID setup the cf built-in web server, that COULD be done to forward proxy iis or apache to that web server, but at that point most folks needing the built-in web server only for cf admin use could just as well set things up to use the built-in web server securely.)

I get your frustration. Your other proposed alternative is in line with what I proposed. (Technically, even cf 11 and 10--from 2012--ran on tomcat rather than jrun. That's another reflection on how quite dated the stig is.) 

As for whatever is amiss about json coming back from cfc's, I'd strongly recommend you create a new thread for that as it's quite separate from this one. 

[BKBK]

@TheNephalim , regarding access to the ColdFusionAdministrator, you seem to have your finger on the pulse. "..To keep the internal site active and lock it down per the guide": wordup. However, I would be wary about marking a Security Technical Implementation Guide (STIG) as "Not Applicable". The STIG was put in place for a reason.

The issue, "upgrade messed up some of the applications receiving JSON strings from CFC components", sounds interesting. Please create a new thread for it. Then we can discuss it separately.

[TheNephalim]

Thanks for your response.

Regarding this statement:  "However, I would be wary about marking a Security Technical Implementation Guide (STIG) as "Not Applicable". The STIG was put in place for a reason."

I'm curious about the course of action you took. If you marked it as a finding, then ostensibly, you need to create a POA&M to document your planned course of action for resolution. Currently, there is no resolution other than removing ColdFusion from the system, which is not an option for us at this juncture.

I expressed the comment with reluctance. The STIGs certainly exist for a purpose, and I strive to adhere to them. Regrettably, Adobe has removed the decision-making power from server administrators and developers. Currently, I am considering the following options:

1.   Set up the ColdFusion administrator using an IP address that is reachable within an internal network through a port of your choosing. Ensure it is configured to utilize TLS. While the Connector element allows you to specify a particular address to listen on, it does not seem to provide attributes for defining the hostname. However, this should not be an issue provided there is a corresponding DNS entry. Nevertheless, this approach may be irrelevant as it necessitates opening a port on our server, which is unlikely to occur in the near future.
2.   Execute the built-in administrator on localhost and determine the steps to configure TLS on Tomcat, which is expected to be a pain.
3.   Disable the built-in administrator.

Technically, it's possible to circumvent the STIGs issue by disabling the built-in administrator account when it's not in use. We could activate it as needed for managing the application server and then deactivate it upon completion. However, this approach is not ideal as it necessitates restarting the ColdFusion service.

Running the built-in ColdFusion administrator continuously results in a violation of the STIG. Should it be marked as a finding since we have it enabled due to Adobe removing our ability to implement the IIS alternative? Or should it be marked as "Not Applicable"? Although it can be disabled, no other viable option exists to administer the application server. The resolution described applies to ColdFusion 11 and ColdFusion 2018, but not to 2021/2023, thus technically rendering it "Not Applicable."

Concerning the last issue you mentioned, the root cause was either a user error (PEBKAC) or the necessity to apply patches. Currently, I'm uncertain. However, after applying all the patches and confirming that the "Preserve case for Struct keys for Serialization" option was selected, the issue was resolved.

[Dave Watts]

I think you're all making this much more difficult than it has to be, except for @Charlie Arehart - and this is not a sentence I thought I'd be writing today ... or ever. (Sorry, Charlie!)

The "G" in STIG means "Guide". It is not a be-all end-all ironclad rule. If you can't meet the requirement of the STIG because you're using a newer version that works differently, then it is perfectly acceptable to mark it as "Not Applicable". After all, you are not running ColdFusion 11 and the literal name of the STIG is "Adobe ColdFusion 11 Security Technical Implementation Guide". There is no STIG for Adobe ColdFusion 2023, and the two products are significantly different. Maybe in the future, Adobe will fix that, but meanwhile you shouldn't just blame Adobe without digging into the problem a bit. Let's ask DoD Cyber Exchange:

https://public.cyber.mil/stigs/faqs/#toggle-id-10

(I bolded some of the important parts below)

"What do I use if there is no STIG?
Determine if a STIG has been published for an earlier version of the same product. Many checks and fixes in earlier versions of STIGs can be applied to the new version of the product. If a STIG for an older version of the product is available, review the check and fix procedures to determine which of these work with the new product version. Where possible, use the checks and fixes that work directly with the new version. The remainder of checks and fixes that no longer work with the new product version will need to be evaluated and proper check and fix procedures will need to be determined for each requirement. New product features and configuration settings must also be accounted for based on the relevant SRG.

If there is no related STIG, the most relevant SRG can be used to determine compliance with DoD policies.

In fulfilling a requirement, be it from an SRG or an earlier version of a STIG, vendor documentation may be followed for configuration guidance."

That seems pretty clear to me, although I'm no STIG expert. But there are also alternatives. You could write a POA&M that simply specifies "We're waiting for a vendor response b/c this feature has significantly changed." There's a new version of CF around the corner - there always is - and that might address this problem. I've seen my share of POA&Ms that do this (and written some that do this). When the new product comes out, and presumably nothing changes, you'd update the POA&M accordingly.

Or, you could do (2), where you configure Tomcat to use TLS. You expect that to be a pain. I guess it might, but do you think it'll be significantly harder than configuring other Linux web servers like Apache HTTPD or nginx? Anyway, Adobe has a help page on this very topic.

https://helpx.adobe.com/coldfusion/kb/enable-ssl-coldfusion-administrator.html

And of course, the Tomcat site has pages for each recent Tomcat version. Here's the one for Tomcat 10 - it'll answer some questions that the Adobe page doesn't.

https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html

Honestly, this looks pretty similar to what you'd do with Apache HTTPD.

Or, you could do (1) and configure CF and your web server to bypass the new limitation. I don't actually know if this is possible or easy, but CF's restrictions are usually included in the Tomcat configuration file and the IIS connector configuration, and these are all text files. So, you'd have to figure out what they are, then try to bypass them. This would be a pain, I think, but I'd guess it's doable.

OK, I've reached the end. Nothing in here should be construed as an insult or anything like that. This stuff is hard! But you should at least try some of these things and see if you can solve the problem.

Dave Watts, Eidolon LLC

[Charlie Arehart]

Um, thanks? 🙂 

[BKBK]

Regarding this statement:  "However, I would be wary about marking a Security Technical Implementation Guide (STIG) as "Not Applicable". The STIG was put in place for a reason."

I'm curious about the course of action you took.

By @TheNephalim

Simple really.

1.  I look into why the STIG was put in place.
2.  I may analyze the risks, if necessary, and then motivate and document why the decision is "Applicable" or "Not Applicable"