Andrew Clarke

systems architect, internet developer, team leader

Andrew Clarke

Lock down ColdFusion Administrator in multi-instance mode

May 2, 2011 · 6 Comments

ColdFusion Enterprise can be installed in multi-instance mode.  This means you can have as many instances of ColdFusion running as your server's memory will allow.  As with ColdFusion Standard, by default each instance will have its administrator console publicly available.  This creates a large security risk.  There are several tutorials out there on how to lock down access to the standard ColdFusion Administrator.  This tutorial shows a method for locking down access to a multi-instance installation of ColdFusion Enterprise.  I'm using ColdFusion 9.0.1 on Windows 2008 & IIS 7.

There are probably as many different ways of doing this as there are ColdFusion users out there.  This isn't necessarily the best way; it's just the way I've done it.  If you have any better ideas, please leave them in the comments section.  Thanks!

JRun does some tricky stuff that it must be very proud of.  Even though your /CFIDE/administrator directory doesn't exist in your IIS web site, JRun will catch all requests made for these URLs and will serve them from its location, which in the example below is c:\JRun4\servers\test\cfusion.ear\cfusion.war\CFIDE\administrator.  Therefore, what you need to do is to make sure that on your publicly available site, this directory doesn't exist.

You still need to access your ColdFusion administrator from somewhere, of course.  I'll also show an example of how to set up a separate site for your ColdFusion Administrator console, that you can lock down as you see fit.

I'll start by assuming you've already set up a ColdFusion instance, and have connected it to IIS.  The process I'm outlining can be easily replicated with Apache or another web server, and is not specific to Microsoft Windows.  Many of the steps below can be completed in a different order.  You can click on any image for a larger version.

1. Turn off the internal JWS web server.

Enter the ColdFusion Administrator of your default instance.  On the left nav, click on Enterprise Manager -> Instance Manager.  You'll see a screen like this:

Click on your instance, which in our case is "test".  You'll get this screen:

Deselect "Enable JWS (Internal Web Server)" and "Directory Browsing", and click "Submit".

This will stop JRun from listening on its own web server port (in this case 8302).  You likely only want IIS serving pages for this instance.  Running JWS as well means that your server is running on unnecessary ports, which is a security risk.

2. Create a directory for a new IIS site.

In this case, I created c:\inetpub\test_cfadmin.  While you're at it, create a subdirectory under here called CFIDE, i.e. c:\inetpub\test_cfadmin\CFIDE.

3. Stop the ColdFusion service.

You'll need to stop the Windows service associated with this ColdFusion instance.  In this case it's called "Adobe ColdFusion 9 AS test".

4. Move your "administrator" directory over.

In this case, the directory we need to move is C:\JRun4\servers\test\cfusion.ear\cfusion.war\CFIDE\administrator.  Move it to your newly created c:\inetpub\test_cfadmin\CFIDE\administrator or wherever you are putting your new admin site.

Once this is done, you'll no longer be able to access your ColdFusion Administrator from your old site, which was part of the goal of this tutorial.

5. Turn your ColdFusion service back on.

See step 3, and do the opposite ;-)

6. Create a new web site in IIS for your ColdFusion Administrator.

We already created the directory for this in step 2.  Now we're going to actually create the IIS web site.  Open your IIS Manager, right click on "Sites" and choose "Add Web Site...".  Fill in the fields similarly to this:

You'll notice that I've bound the site to SSL.  This isn't a necessary step but it's one I highly recommend.  You can create a self-signed certificate in IIS7 very easily, although I won't explain that here.  A self-signed certificate will generate a browser warning, but that doesn't by itself make it less secure than an expensive one from another provider.

7. Connect your new site to the ColdFusion instance in the Web Server Configuration Tool.

Adobe provides a tool called the "Web Server Configuration Tool".  It's in your start menu under Start -> All Programs -> Adobe -> Web Server Configuration Tool or something like that.  Start it up, and you'll get a screen like this:

Click "Add...":

This is where you'll configure your specific ColdFusion instance "test", with your specific IIS site, "test_cfadmin".  This tool will restart IIS when it's done, so be aware of this effect on a production system.

You're done!  Now, you'll be able to access your ColdFusion administrator under (in our example),

I suggest locking this site down by IP, and also preferably don't use the default IIS user.  Require an authenticated user.  This way, the site is not available on the public internet, requires an authenticated user, and communicates over SSL.  That's an improvement, don't you think?

Tags: ColdFusion

6 responses so far ↓

  • 1 Jon // Jun 18, 2012 at 11:58 AM

    Thank you very much. This greatly enhances the security within Coldfusion. Much appreciated.
  • 2 Paul V. // Jan 3, 2013 at 9:33 AM

    I am running CF8. I don't have the Web Server Configuration Tool on my server. Is this only for CF9? If so, how do I acheive the same results? I'm running IIS 7 and CF 8.
  • 3 Andrew Clarke // Jan 4, 2013 at 10:58 AM

    Hi Paul. No, you should have the Web Service Configuration Tool on there somewhere. I can't remember if the GUI for that is an optional install or not. If it's not in your Program Files, check directly on your drive.
  • 4 Eymard Ventura // Mar 20, 2013 at 4:03 PM

    look for wsconfig.exe in your CFHome. In my case it is in c:\JRun4\bin
  • 5 Qs // Aug 28, 2013 at 11:49 AM

    Hey Andrew - great write-up!

    Is the link in the last section suppose to be:

    instead of

  • 6 Andrew Clarke // Aug 28, 2013 at 11:57 AM

    I'd set up IIS to listen on port 4432 rather than port 443. See . That's why I specified the port; otherwise I could have just left it out of the URL.

    I did this because I was running a few different development environments on the same server, and running things on different ports made that easier. It has the added benefit that someone would have to run a port scan before knowing there's something listening on that port.

Leave a Comment

Leave this field empty