File Archive Application
Our intranet needs a file archive application, where items such as PDF files, Excel spreadsheets, Powerpoint presentations, Word documents, and just about anything else imaginable can be stored and retrieved. In some cases, access to certain files and groups of files must be limited to specific groups of users. We'd like to maintain a parallel database file that would allow file creators to upload their files, as well as enter descriptions or comments about the file. I'm concerned about allowing this to get out of hand, in terms of the number of users and groups of users for which security permissions must be tracked. I'd like to solicit the mailing list's reactions on how best to set up and administer such a system, and what security model might be workable. JGB =========== Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 -- Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
CFM templates not accessible to clients
Gentlebeings... Bear with me, please, as I am somewhat new to Coldfusion and NT administration. I began development of our intranet site in VBScript on IIS 4.0, and then we switched to CF. The VBScript site, named cimnet2d, is still online, and all users can view it. The new site, named cimnetcf, is totally CFM-based. Admin-type users can see it, but not non-admin, ordinary users (hereafter referred to as 'Joe User'). The directory trees for each site have exactly the same ACL permissions set throughout, and the IIS 4.0 settings are the same. Both directory trees are configured for Win NT 4.0 NTLM authentication (no anonymous or basic), and have been given Read access throughout to members of the Authenticated Users group. I finally realized that Coldfusion itself might have something to do with the access problem, and tried an experiment. A very simple file, containing only HTML (no VBScript or CFM code), named 'simple.htm' was placed in the cimnet2d home directory ( which has always been accessible to Joe User). Log in as Joe User and access it with IE 4.0. Result: access good. Rename it to simple.asp: access good. BUT, rename to simple.cfm: no access! Same results in the cimnetcf home directory. The problem, thus, lies not in the directory permissions for the site or the IIS authentication settings, but in access to some Coldfusion resource. The ACL for the \programs\coldfusion directory tree on the server contains only SYSTEM and the Domain Admins group. Adding a user to the Doman Admins group gives him access to cimnetcf; not practical for security reasons, obviously. Windows NT is running the CF Server under the SYSTEM user. What resource(s) must I make accessible, and to whom, for the CF site to work for all authenticated users? How, in general, can I effectively integrate CF with IIS/NT 4.0 security? Many thanks... JGB =========== Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 -- Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: CFM templates not accessible to clients
Thanks for your help, Dan. Here's what my NT administrator and I have done: 1) Created a user named 'ColdFusion'. Assigned him to the Administrators group, as well as the default Domain Users group. 2) In the Services control applet, configured the three CF services to start up as the ColdFusion user. 3) Added the ColdFusion user to the ACL for the \COLDFUSION directory tree, with Full access. 4) Stopped and restarted the three CF services. Result: Joe User still has no access to any CFM templates. I'm slogging onward. Any additional thoughts will be welcome. JGB -- Original Text -- From: "Dan G. Switzer, II" <[EMAIL PROTECTED]>, on 4/19/00 8:55 AM: Jeffery, Instead of mapping the "System" account to the directory, you can map the actual CF service to a specific account. This has the advantage of being able to read mapped drives under the account you create for it. You can create a user account called "cfusion_system" (or whatever you like.) Then make sure that account has the privileges you want ColdFusion to have. If you've never set up a service to run as an account, here are some Allaire directions: http://www.allaire.com/Handlers/index.cfm?ID=1480&Method=Full&Cache=Off -Dan ++---+ | name | Dan G. Switzer, II| |company | PengoWorks.com| |www | http://www.pengoworks.com | | mailto | [EMAIL PROTECTED] | +----+-------+ -Original Message- From: Jeffrey G. Brown [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 18, 2000 4:33 PM To: [EMAIL PROTECTED] Subject: CFM templates not accessible to clients Gentlebeings... Bear with me, please, as I am somewhat new to Coldfusion and NT administration. I began development of our intranet site in VBScript on IIS 4.0, and then we switched to CF. The VBScript site, named cimnet2d, is still online, and all users can view it. The new site, named cimnetcf, is totally CFM-based. Admin-type users can see it, but not non-admin, ordinary users (hereafter referred to as 'Joe User'). The directory trees for each site have exactly the same ACL permissions set throughout, and the IIS 4.0 settings are the same. Both directory trees are configured for Win NT 4.0 NTLM authentication (no anonymous or basic), and have been given Read access throughout to members of the Authenticated Users group. I finally realized that Coldfusion itself might have something to do with the access problem, and tried an experiment. A very simple file, containing only HTML (no VBScript or CFM code), named 'simple.htm' was placed in the cimnet2d home directory ( which has always been accessible to Joe User). Log in as Joe User and access it with IE 4.0. Result: access good. Rename it to simple.asp: access good. BUT, rename to simple.cfm: no access! Same results in the cimnetcf home directory. The problem, thus, lies not in the directory permissions for the site or the IIS authentication settings, but in access to some Coldfusion resource. The ACL for the \programs\coldfusion directory tree on the server contains only SYSTEM and the Domain Admins group. Adding a user to the Doman Admins group gives him access to cimnetcf; not practical for security reasons, obviously. Windows NT is running the CF Server under the SYSTEM user. What resource(s) must I make accessible, and to whom, for the CF site to work for all authenticated users? How, in general, can I effectively integrate CF with IIS/NT 4.0 security? Many thanks... JGB === Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 -- Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. === Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 -- Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: CFM templates not accessible to clients
The ACL for the entire /cimnetcf/ directory tree includes 'Authenticated Users' with Read (RX/RX) permissions. Also, the ISCF.DLL is mapped to the CFM extension, and is marked as a 'Script Engine' in the MMC. 'Joe User' still can't access CFM templates. JGB -Original Message- CFM files must have executable access available to Joe User, unless you specify the DLL mapping as a "scripting engine" in the IIS MMC. Chris Olive DOHRS Website Administrator [EMAIL PROTECTED] -Original Message- From: Jeffrey G. Brown [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 18, 2000 4:33 PM To: [EMAIL PROTECTED] Subject: CFM templates not accessible to clients Gentlebeings... Bear with me, please, as I am somewhat new to Coldfusion and NT administration. I began development of our intranet site in VBScript on IIS 4.0, and then we switched to CF. The VBScript site, named cimnet2d, is still online, and all users can view it. The new site, named cimnetcf, is totally CFM-based. Admin-type users can see it, but not non-admin, ordinary users (hereafter referred to as 'Joe User'). The directory trees for each site have exactly the same ACL permissions set throughout, and the IIS 4.0 settings are the same. Both directory trees are configured for Win NT 4.0 NTLM authentication (no anonymous or basic), and have been given Read access throughout to members of the Authenticated Users group. I finally realized that Coldfusion itself might have something to do with the access problem, and tried an experiment. A very simple file, containing only HTML (no VBScript or CFM code), named 'simple.htm' was placed in the cimnet2d home directory ( which has always been accessible to Joe User). Log in as Joe User and access it with IE 4.0. Result: access good. Rename it to simple.asp: access good. BUT, rename to simple.cfm: no access! Same results in the cimnetcf home directory. The problem, thus, lies not in the directory permissions for the site or the IIS authentication settings, but in access to some Coldfusion resource. The ACL for the \programs\coldfusion directory tree on the server contains only SYSTEM and the Domain Admins group. Adding a user to the Doman Admins group gives him access to cimnetcf; not practical for security reasons, obviously. Windows NT is running the CF Server under the SYSTEM user. What resource(s) must I make accessible, and to whom, for the CF site to work for all authenticated users? How, in general, can I effectively integrate CF with IIS/NT 4.0 security? Many thanks... JGB ======= Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 ======= Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 -- Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
re: CFM templates not accessible to clients
Yes. In the same IIS web site directory, the access to which is under NT Challenge/Response control, 'Joe User' can access a template named either simple.htm or simple.asp, without ever seeing a userid/password dialog. However, rename that template (which contains no actual CF code) to 'simple.cfm', and NTLM refuses to allow the template to load -- _unless_ I add 'Joe User' to the 'Domain Admins' group (which, obviously, would be A Bad Thing in a production environment). JGB -Original Message- i'm sorry, i think i misunderstood the problem. you mean that NT is refusing access to the user? Chris Olive DOHRS Website Administrator [EMAIL PROTECTED] -Original Message- From: Jeffrey G. Brown [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 19, 2000 10:59 AM To: [EMAIL PROTECTED] Subject: Re: CFM templates not accessible to clients The ACL for the entire /cimnetcf/ directory tree includes 'Authenticated Users' with Read (RX/RX) permissions. Also, the ISCF.DLL is mapped to the CFM extension, and is marked as a 'Script Engine' in the MMC. 'Joe User' still can't access CFM templates. JGB -Original Message- CFM files must have executable access available to Joe User, unless you specify the DLL mapping as a "scripting engine" in the IIS MMC. Chris Olive DOHRS Website Administrator [EMAIL PROTECTED] -Original Message- From: Jeffrey G. Brown [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 18, 2000 4:33 PM To: [EMAIL PROTECTED] Subject: CFM templates not accessible to clients Gentlebeings... Bear with me, please, as I am somewhat new to Coldfusion and NT administration. I began development of our intranet site in VBScript on IIS 4.0, and then we switched to CF. The VBScript site, named cimnet2d, is still online, and all users can view it. The new site, named cimnetcf, is totally CFM-based. Admin-type users can see it, but not non-admin, ordinary users (hereafter referred to as 'Joe User'). The directory trees for each site have exactly the same ACL permissions set throughout, and the IIS 4.0 settings are the same. Both directory trees are configured for Win NT 4.0 NTLM authentication (no anonymous or basic), and have been given Read access throughout to members of the Authenticated Users group. I finally realized that Coldfusion itself might have something to do with the access problem, and tried an experiment. A very simple file, containing only HTML (no VBScript or CFM code), named 'simple.htm' was placed in the cimnet2d home directory ( which has always been accessible to Joe User). Log in as Joe User and access it with IE 4.0. Result: access good. Rename it to simple.asp: access good. BUT, rename to simple.cfm: no access! Same results in the cimnetcf home directory. The problem, thus, lies not in the directory permissions for the site or the IIS authentication settings, but in access to some Coldfusion resource. The ACL for the \programs\coldfusion directory tree on the server contains only SYSTEM and the Domain Admins group. Adding a user to the Doman Admins group gives him access to cimnetcf; not practical for security reasons, obviously. Windows NT is running the CF Server under the SYSTEM user. What resource(s) must I make accessible, and to whom, for the CF site to work for all authenticated users? How, in general, can I effectively integrate CF with IIS/NT 4.0 security? Many thanks... JGB === Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 -- Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: CFM templates not accessible to clients -- Resolution
Regarding the security issue I had posted a week ago: I finally broke down and opened an incident with Allaire. The young lady who returned my call (thanks, Laura!) explained that: (1) I must first grant NTFS access to any users who need access to the site to the following directories: x:\Program Files\ColdFusion\BIN\ ... ColdFusion binaries x:\Inetpub\wwwroot\ ... The site itself x:\WINNT\SYSTEM32\... Windows (Yipe!) (2) I must then stop the following services: Coldfusion Executive Coldfusion Application Server Coldfusion RDS World Wide Web Publishing (3) Finally, I have to restart the services in the reverse order. Right now, my site is wide open to anonymous users. For most of the site, that's OK -- but there will be some areas that will be restricted. The site is scheduled to go live tomorrow, after which I will set up another site in which I can try out different security schemes to determine what will work best for us. My ideal would be to have intranet users log in to NT, and then have all security on the site handled via NT challenge/response. Because we have some users in remote offices, and others who dial in, this may not be practical due to firewall issues. Anyway, thanks to all who assisted me in resolving this problem. JGB -- Original Text -- From: Jeffrey G. Brown@MIS@CM_PRODUCTS, on 4/18/00 4:32 PM: To: internet[[EMAIL PROTECTED]] Gentlebeings... Bear with me, please, as I am somewhat new to Coldfusion and NT administration. I began development of our intranet site in VBScript on IIS 4.0, and then we switched to CF. The VBScript site, named cimnet2d, is still online, and all users can view it. The new site, named cimnetcf, is totally CFM-based. Admin-type users can see it, but not non-admin, ordinary users (hereafter referred to as 'Joe User'). The directory trees for each site have exactly the same ACL permissions set throughout, and the IIS 4.0 settings are the same. Both directory trees are configured for Win NT 4.0 NTLM authentication (no anonymous or basic), and have been given Read access throughout to members of the Authenticated Users group. I finally realized that Coldfusion itself might have something to do with the access problem, and tried an experiment. A very simple file, containing only HTML (no VBScript or CFM code), named 'simple.htm' was placed in the cimnet2d home directory ( which has always been accessible to Joe User). Log in as Joe User and access it with IE 4.0. Result: access good. Rename it to simple.asp: access good. BUT, rename to simple.cfm: no access! Same results in the cimnetcf home directory. The problem, thus, lies not in the directory permissions for the site or the IIS authentication settings, but in access to some Coldfusion resource. The ACL for the \programs\coldfusion directory tree on the server contains only SYSTEM and the Domain Admins group. Adding a user to the Doman Admins group gives him access to cimnetcf; not practical for security reasons, obviously. Windows NT is running the CF Server under the SYSTEM user. What resource(s) must I make accessible, and to whom, for the CF site to work for all authenticated users? How, in general, can I effectively integrate CF with IIS/NT 4.0 security? Many thanks... JGB =========== Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 -- Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: Platform/Browser checkout
You may find the Backwards Compatibility Viewer <http://www.delorie.com/web/wpbcv.html> useful in this regard. JGB === original message === David Shadovitz <[EMAIL PROTECTED]> wrote: Is there a tool or a web site that I can use to check out my web site against different platforms and browsers? This has been discussed before, but I must admit that I've ignored such threads since I'd been working on intranet apps and my company has a small lab with a Mac, PC and Sun workstation, with various (recent) browsers. Thanks. -David =========== Jeffrey G. Brown Intranet Webmaster Milacron, Inc. Voice: 513-841-8655 Fax: 513-841-7345 -- Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
