[Looking for Charlie's main web site?]

My New Adobe Dev Ctr Article: Multi-user access for CF Admin and RDS

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
I have a new 16-page article that was posted to the Adobe CF Developer Center yesterday:

Enabling multiple user access to the ColdFusion Administrator and RDS

If you're using CF 8 Enterprise or Developer edition, you should at least be aware of this feature. Even if it doesn't sound like something you'd need or want to use, check out at least the introductory section.

Besides explaining the features, and showing how to set them up and use them for practical solutions. It also addresses many gotchas and cautions to note, some of which may be surprises.

It shows using the multi-user admin feature for spreading out who can work on different parts of the admin (and shows enabling it even only for access to the CF 8 Server Monitor.)

And for the multi-user RDS feature, it shows leveraging it specifically within Eclipse and Dreamweaver (and points to resources for more on each and on using it with HomeSite+/CF Studio.)

I welcome comments or questions about the article here.

PS If you want to comment asking why one would use RDS due to security concerns, please read the article first. This addresses one significant concern and also points readers to additional resources to consider other concerns.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
On a vaguely related note.. when you're doing this to improve security, following it up by cleverly setting the admin password to be the former password wrapped in cfoutput tags and pound signs may be slightly less clever than previously thought, as it provides the best possible security -- the complete and total inability to log in as admin.
# Posted By jc | 3/31/09 12:00 PM
@jc , that's an interesting thought. You say "than previously thought". Is this concept discussed somewhere in particular? I'd never heard of it myself.

Anyway what's with the idea of wrapping it in CFML tags? I suppose I could see how changing it to have any HTML tag in it would cause the input to be blocked on submission then, if one has CF's "global script protection" feature enabled. Is that what this is relying on?

And is the real point that you're saying one may want to somehow disable use of the root Admin username/password entirely? I'd think a simpler solution would be to change the root Admin username to something else (which requires editing the neo-security.xml file, as discussed in the article. If you're reading this and wonder, "huh? root admin username", please see the article.) Sadly, it doesn't appear that one can disable the root admin user entirely, even by editing the xml file (though I admit I've not tried deleting it entirely or setting it to the empty string.)
Sorry that wasn't clear. I was effectively calling myself an idiot and trying to be funny about it.

I needed to change the admin password to something stronger but I wanted it to be something I could remember... so I basically took the previous password and wrapped it as if it was a coldfusion variable... so <cfoutput>#myoldpassword#</cfoutput> -- because I knew I could remember that, but it was complicated enough that it was going to be hard to guess and very hard to brute force.

I wasn't *trying* to disable the root admin... just give it a better password. The disabling was inadvertent and unwelcome.

But yes, changing the username is a grand idea and I think I'll do just that.

But I suppose, if you wanted to, you *could* effectively disable it by doing as I did, setting a password that can't actually be used to log in with. Then the only way to access it is by modifying the xml file to reset the password.
# Posted By jc | 3/31/09 12:56 PM
Thanks for the clarification. So I'm curious: was the fact that it failed in fact due to having the global script protect feature on? And the tag gets caught that way? I don't suppose you were really expecting it to execute that CFOUTPUT tag somehow, right? :-)
Wasn't expecting to execute it, no... just thought it was clever and an easy way to remember a more complex password -- I've got a couple of managers who need to know the PW and I couldn't make it too complicated without worrying about post-it notes. I figured they all knew enough CF syntax to get it, and worst case they could postit the syntax without the password inside.

I was guessing that the first pound commented out the rest in whatever properties file the data ended up in. Scriptprotect only affects script/meta/object/applet tags, so that couldn't be it. I do have a function in the application.cfm files that replaces the >< signs, but that wouldn't be inherited by CF Administrator.
# Posted By JC | 3/31/09 10:29 PM
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting