 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / ColdFusion / Server Administration / August 2008Q: Removing CF admin from sites on multi-site IIS server?
I have CF installed on an IIS-based server hosting multiple Web sites; not all of those Web sites even use CF. Let's call the server "server1.my.com", and the sites are hosted as "site1.my.com", "site2.my.com", etc.. Let's further assume that I have a couple dozen fairly low-traffic sites hosted on this same box in this same manner. (I mention this only as background, and because I am hoping not to saddle myself or my server admin with a significant maintenance effort as sites come and go on this box.) What I'd like is to have the CF administrator interface available only as server1.my.com/CFIDE/Administrator/index.cfm and to have access to the CF admin restricted to a specific set of IP addresses. In addition, I want that to be the /only/ way in which the CF administrator can be accessed. I have the first part of that set up, and the IP-based restriction seems to work fine. What I can't find a way to do is the elimination of access to the CF administrator on all of the other Web sites hosted on this same box. I can, for example, pull up the CF administrator as site1.my.com/CFIDE/Administrator/index.cfm or site2.my.com/CFIDE/Administrator/index.cfm, etc., regardless of what IP I am requesting it from. I can do that even for sites hosted on the box that don't use CF. (I am a little hamstrung here because I don't have access to the IIS administrative console, but have to rely on a server admin to make changes there. I will also be the first to admit that I am not an IIS expert by any stretch of the imagination.) The CFIDE folder is set up as a virtual directory on IIS under the server1.my.com configuration, but is not set up as a virtual directory for any of the other sites hosted on the box. We've checked the IIS configuration for all of them. Questions: 1. Given the above, why is IIS providing site1.my.com/CFIDE/Administrator/index.cfm when there is nothing there as far as a virtual directory AND given the IP address restriction? (There is clearly another path that stuff is going through here, when site1.my.com/CFIDE/Administrator/index.cfm is requested versus server1.my.com/CFIDE/Administrator/index.cfm.) 2. More importantly, what do we have to do to the IIS and/or CF server configuration to achieve what I have outlined? Thanks for any insight any of you might offer. I've done some digging for recommendations in the Adobe tech notes and here on the forums and haven't really found something that specifically addresses this situation. -- /ron Go into your CF admin and make sure you have "Cache web server paths" unchecked (you'll need a restart to kick that one in). Then, on your site you want to manage CFIDE on, set IP restrictions on the CFIDE/administrator (and if you have adminapi, delete it if you're not using it) in IIS. If you want to take it to the next level, you can install something like ISAPI Re_Write and write a rule that'll really restrict how people connect to your web server. We run multi-instance here. Even without the /CFIDE/administrator mapping (or even with the folder installed) CF was still calling the administrator. It was broken, but it still worked. Since we're using multiple instances, we hit a given port to manage the CF install. So, with ISAPI Re_Write, we locked everyone out from calling anything remotely close to /cfide/administrator. Works like a charm. ok, sounds like you're doing it the correct way although IIS won't let you go to a /CFIDE directory unless it is 1) mapped via Virtual folder or 2) has been copied into the webroot for the site itself. It's a little confusing what you mean by: [Q] The CFIDE folder is set up as a virtual directory on IIS under the server1.my.com configuration, but is not set up as a virtual directory for any of the other sites hosted on the box. We've checked the IIS configuration for all of them.[/Q] When you view the IIS admin you'd see the server listed and then all the virtual servers beneath it for each site. You can't set virtual folders at the server level, you set defaults for logging, security etc which are used when you create a new Virtual Server but mappings are very much with each virtual server. Not having IIS admin could be a bit of a pain - but you can obviously deduce what's going on here if you see a CFIDE folder when you look at the site via FTP then it's 2 else the folder is being presented as a virtual directory. Remember a few things here though, CFIDE presented to one site will show the same as that presented to another site so one site could see all the datasources for the ENTIRE server - CF8 gave you the ability to have different users for your admin but i'm not sure how granular you can be with permissions. In regards to not having a CFIDE per site you can run into some troubles depending on what the site does. What I do across all my servers is store the orginal CFIDE and have only my default site with access (locked down to 127.0.0.1) what I then do is take a copy of CFIDE to CFIDE_noadmin and remove the administrator, debug, componentutils directory and i present that via virtual folder to each site named CFIDE. Some CF features (CFAJAX, form validation etc) expects to be able to access the scripts folder in CFIDE - although this can be tweaked via the CFADMIN). If you're really worred about security then you need to write a custom admin interface and use the cfadminapi provided to allow users to control their own datasources/mappings etc. If you could get a screen shot of the IISadmin interface with a few of the sites expanded I could tell you in a second what the problem is, john. johnab and ke4pym: Thanks for the quick responses from both of you. I'll try to provide answers to some of your questions/suggestions here, and I will get my server admin to get me a screenshot of the IIS console. 1. I have verified that we have both "Cache web server paths" and "Trusted cache" disabled on the CF administrator. They, to the best of my knowledge, have never been enabled, and the server has been completely restarted a couple of times in the past couple of days for unrelated reasons. 2. I have verified that the CFIDE folder exists in only one location of the server's disk space. I'll get a screenshot of the IIS console and find a means to get you a copy of it in sanitized form. Maybe there will be something there that will help. -- /ron johnab and ke4pym: What's going to be the easiest way to get screenshots of the IIS management console to you, assuming I can get my server admin to send them to me?  Signature/ron Some additional details, in response to the follow-up above, that may help: @johnab: Based on what the server admin has described, you're right about what I described above being confusing. The server in this example is named "server1.my.com". Within the IIS admin interface, there is an website called "server1" that is what the server responds to when I invoke http://server1.my.com/ -- that Web site in the IIS admin interface has a virtual folder called "cfide" that maps to "c:\cfusionmx7\wwwroot\cfide" and has a home directory of "d:\server1". Also within the IIS admin interface, if I expand the entry for "site1", there is no entry for cfide, and that site has a home directory of "d:\webs\site1". We've also verified that the only CFIDE folder on the system is the above-referenced folder in the CF installation directory. Further, site1.my.com has a different IP address than server1.my.com. I'm kind of at a loss as to why site1.my.com/CFIDE/Administrator/ is being served up -- albeit with missing images -- given the above. Does that description a) make sense in terms of the IIS configuration? b) explain why we're seeing the behavior we are? c) provide enough that you might point us in a direction to make the CF admin interface visible only via the server1.my.com domain (and nowhere else)? -- /ron I think the first step here is to verify whether each site is serving up what we expect. Into the root of each website create a file that clealy outputs something different, eg server1 and server2 - that way we know that the two sites are different, make sure they are a.cfm extension to see if the 'cache webserver path' issue is coming into play here because if it is you'll see the same content on both sites, then let us know, john. Each site is indeed serving up unique (and expected) content. In working with the server admins, I /think/ I understand what is happening but I'm not sure I understand why. We've also identified a less than optimal -- it seems to me -- solution, but if there is a better approach, I'm all ears. Here's what it seems is happening: 1. Only the Web site for "server1" has a virtual directory for CFIDE, and that virtdir points back to the CF installation directory. No other site on the box has either a CFIDE virtdir or a CFIDE physical directory. 2. When I access the CFadmin as server1.my.com/CFIDE/Administrator/index.cfm, it works fine and all images, etc. are present. We have restricted access to the Administrator folder -- through IIS -- to a small set of IPs and have verified that it can't be accessed from IPs not in that small set. 3. When I access the CFadmin as site1.my.com/CFIDE/Administrator/index.cfm, it works but all images, etc., are missing. It seems to be the same CFadmin as server1.my.com/CFIDE/Administrator/index.cfm based on the password required to get in and what I see once I sign in. It is accessible from all IPs. This same behavior is present for all sites on the server (with the above-noted exception of server1.my.com) regardless of whether those sites use CF or not. 4. It /appears/ that when IIS sees that a .cfm file has been requested via site1.my.com (or any site), it is handing that request over to the CF appserver without any examination of whether the file and path requested actually exist. Once handed over to the CF app server, the CF app server is seeing that it has the /CFIDE mapping (which can't be changed or removed in the CF admin) and continuing to process it. (This is the part that I'm not entirely sure makes sense given the absence of the virtual directory under the site1.my.com Web site configuration in IIS.) This would seem to jive with the way IIS and CF handle missing templates: IIS never checks, once it sees that a .cfm file has been requested, and it is left to the CF app server to deal with. The only solution we've found so far is to create the CFIDE virtdir under each site in IIS's admin interface and then restrict access to the Administrator folder under that to localhost or something like that (with the obvious exception being the server1.my.com site, which is the only CFadmin interface we want and is already configured and restricted). Clearly, though, this doesn't scale well (we've got quite a few sites on this server, and are continuing to add more). It also seems like we'd be better off removing the CF configuration from the non-CFML sites altogether as part of this change, too, to take the CF app server completely out of the picture for those sites. And looking at the multi-homing section of the Adobe docs, it talks about what one should do in a multi-homed environment to make the CFadmin interface accessible, but it doesn't talk about what to do to make it /not/ accessible. The behavior in the absence of the CFIDE virtdir is a little troubling, particularly in that it applies the IP restrictions only if the directory is present. Does that make sense and/or help? Any ideas on other approaches? Thanks again for the help! -- /ron > Here's what it seems is happening: > 1. Only the Web site for "server1" has a virtual directory for CFIDE, and that [quoted text clipped - 6 lines] > 3. When I access the CFadmin as site1.my.com/CFIDE/Administrator/index.cfm, it > works but all images, etc., are missing. Correct. .cfm is mapped in web.xml and will be forwarded to CF, the rest of the extensions is not mapped and will not be forwarded. > It seems to be the same CFadmin as > server1.my.com/CFIDE/Administrator/index.cfm based on the password required to > get in and what I see once I sign in. It is accessible from all IPs. This same > behavior is present for all sites on the server (with the above-noted exception > of server1.my.com) regardless of whether those sites use CF or not. You have one set of settings and one password per CF instance. That does not mean the templates are the same ones. > 4. It /appears/ that when IIS sees that a .cfm file has been requested via > site1.my.com (or any site), it is handing that request over to the CF appserver > without any examination of whether the file and path requested actually exist. Correct. > Once handed over to the CF app server, the CF app server is seeing that it has > the /CFIDE mapping (which can't be changed or removed in the CF admin) and > continuing to process it. I don't think so. The mapping should be used for translating internal CFML constructs (cfinclude, cfinvoke etc.), not for translating a path from the webserver. Do you have any occurence of the CFIDE folder anywhere under the install dir of ColdFusion? > The only solution we've found so far is to create the CFIDE virtdir under each > site in IIS's admin interface and then restrict access to the Administrator > folder under that to localhost or something like that (with the obvious > exception being the server1.my.com site, which is the only CFadmin interface we > want and is already configured and restricted). Have you tried moving the Administrator somewhere else then in the CFIDE folder? Jochem SignatureJochem van Dieten Adobe Community Expert for ColdFusion @jochem: Thanks for the follow-up.... >You have one set of settings and one password per CF instance. That does >not mean the templates are the same ones. I'm reasonably certain that the templates are the same; there is only the one CFIDE folder on the entire server located at c:/cfusionmx7/wwwroot/CFIDE, while all of the Web sites on somewhere below d:/ -- we've make sure that no other CFIDE folder exists and that none of the Web sites other than the server1.my.com Web site has a virtual folder called CFIDE. >> 4. It /appears/ that when IIS sees that a .cfm file has been requested via >> site1.my.com (or any site), it is handing that request over to the CF appserver [quoted text clipped - 9 lines] >CFML constructs (cfinclude, cfinvoke etc.), not for translating a path >from the webserver. I agree, but that's not the behavior we are seeing, and see below for one additional item we've tracked down that would seem to indicate that this is really what's happening. >Do you have any occurence of the CFIDE folder anywhere under the install >dir of ColdFusion? As noted above, the /only/ occurrence of the CFIDE folder is within the CF install directory. >> The only solution we've found so far is to create the CFIDE virtdir under each >> site in IIS's admin interface and then restrict access to the Administrator >> folder under that to localhost or something like that (with the obvious [quoted text clipped - 3 lines] >Have you tried moving the Administrator somewhere else then in the CFIDE >folder? We haven't tried this. We found one additional approach to solving this, and it seems to substantiate the idea that the CF app server is "helping" in a way it shouldn't: within IIS, you can edit the properties for the various file types, and tell IIS to check to ensure the file exists. When we turn this setting on for the .cfm files for the site1.my.com Web site and then try to access the CF admin interface via site1.my.com/CFIDE/Administrator/index.cfm, IIS hands back a 404 error -- as well it should. The requested file is not physically present nor is there a virtual mapping for IIS to get to it. That would seem to indicate that the CF engine itself is responsible for serving it up, which in this case, it doesn't seem like it should. At this point, then, we've identified two approaches to removing access to the CF admin for all these sites: 1) Create the virtual directory and restrict access by IP 2) Leave the virtual directory absent and turn on existence checking in IIS Neither of these feels optimal, as they are something that has to be done on every site that currently exists, as well as remembering to do them for each additional site deployed there in the future. It still feels to me, the more we've wrestled with this, that CF shouldn't be serving it up in the current configuration (no virtual directory and existence checking disabled in IIS, which also gives us the advantage of using our missing template handler in CF). I'm not sure if I've answered your questions, or whether what I've offered up here as the two approaches to resolving this makes sense. As I indicated, neither seems all that great... -- /ron >>> Once handed over to the CF app server, the CF app server is seeing that it has >>> the /CFIDE mapping (which can't be changed or removed in the CF admin) and [quoted text clipped - 7 lines] > additional item we've tracked down that would seem to indicate that this is > really what's happening. Not necessarily. What the webserver connector passes on to CF can be one of two things: - an absolute path to a template (i.e. c:\inetpub\wwwroot\x.cfm); - a relative path to a template (i.e. /x.cfm). If CF receives an absolute path it will proceed to use that, if CF receives a relative path it will start to look for it from its own webroot. Its own webroot being c:/cfusionmx7/wwwroot/. So if CF receives a request for a /CFIDE/administrator/index.cfm relative path it will find the template. Not because there is a mapping, but because the path exists relative to the CF internal webroot. The proof of the pudding is in the eating: move your CFIDE folder out of your CF wwwroot, update the mapping for /CFIDE/ in CF (it is stored in neo-runtime.xml) and update the CFIDE virtual directory location in IIS. Jochem SignatureJochem van Dieten Adobe Community Expert for ColdFusion >>>> Once handed over to the CF app server, the CF app server is seeing that it has >>>> the /CFIDE mapping (which can't be changed or removed in the CF admin) and [quoted text clipped - 24 lines] >your CF wwwroot, update the mapping for /CFIDE/ in CF (it is stored in >neo-runtime.xml) and update the CFIDE virtual directory location in IIS. @jochem: thanks for your patience and your follow-up. I am willing to give this a try, but because I am dealing with a production box hosting a couple dozen sites (some of which are not mine) and because I have to work through my IIS admin, I just want to make sure I have a feel for what I'm going to be asking him to do and why, along with a feel for any possible repercussions for the sites also on the box... Questions: 1) Is there some means to determine whether IIS is passing a relative path or an absolute path to IIS on these requests? Is that something that can be configured somewhere? 2) I'm not sure I understand the intent of the changes you are asking me to try. Let's assume that I move c:/cfusionmx7/wwwroot/cfide to c:/cfusionmx7/cfide, then go to neo-runtime.xml configuration file and manually update CF's mapping for /CFIDE. The only existing IIS mapping to CFIDE at present is under the server1.my.com configuration in IIS and this is the only site I want the CF admin interface accessible through, so it makes sense to me that this is the IIS virtual directory that will need to be updated, right? At least on the surface, this doesn't /feel/ to me like the overall configuration of the server is really any different than it currently is (particularly, with all of the sites on the box configured to have their Web root directory on a completely different drive than the c:/cfusionmx7 installation and its Web root, and the absence of any of the other sites on the box having a virtual directory pointing back to the CFIDE folder or anything else under c:/cfusionmx7). -- /ron > Questions: > 1) Is there some means to determine whether IIS is passing a relative path or > an absolute path to IIS on these requests? Is that something that can be > configured somewhere? Enable verbose logging for the webserver connector. (Be careful, it is really verbose.) > 2) I'm not sure I understand the intent of the changes you are asking me to > try. Let's assume that I move c:/cfusionmx7/wwwroot/cfide to [quoted text clipped - 3 lines] > site I want the CF admin interface accessible through, so it makes sense to me > that this is the IIS virtual directory that will need to be updated, right? Correct. > At > least on the surface, this doesn't /feel/ to me like the overall configuration > of the server is really any different than it currently is Which is the nice thing about it: you only have to do it once :) Jochem SignatureJochem van Dieten Adobe Community Expert for ColdFusion |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.