Date: Mon, 18 Jan 1999 11:58:06 -0800 From: Adam Berns To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: IIS4.0 and Visual Interdev Using Visual Interdev 6.0, I can connect to an IIS 4.0 Server without being asked for any security passwords. The server is running IIS4.0, with Service Pack 4, with the following patches: The enhanced Security Configuration manager, with the hisecdc4 configuration Front Page Server Extension, with it configuring the security The ASP.dll Patch (q177036 kb article) The msiisp1i386 Patch (q148188 kb article) The ctrfix (q185349 kb article) The IISUPDI Patch (q192224 kb article) The nprpc Patch (q195733 kb article) The ftpfix Patch (q189262 kb article) The iis4-datafix (q188806 kb article) The persimmons on the root web directory are as follows: Drive:\webroot Administrators: Full Interactive: List Network: RX System: Full Drive:\webroot\public_html (root web) Administrators: None Interactive: List Internet Guest Account: RX I have encountered multiple sites using IIS4 that I can attach to with visual Interdev 6.0 and make changes to their websites. This does not even show up in the even log as a logon session. The site in question is not the one listed in my signature below. ~~~~~~~~~~~~~ Adam Berns Systems Administrator Silicon Gaming, Inc. adamb@ubet.com http://www.silicongaming.com 650-798-7813 desk 650-798-8223 fax 415-307-8746 cell ----------------------------------------------------------------------- Date: Tue, 19 Jan 1999 13:08:38 -0500 From: Christopher Timmons To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: IIS4.0 and Visual Interdev The problem most likely is that he has applied pre-SP4 hotfixes which do not contain the newset code... only the following post-SP4 have been released: clik-fix (Q195540.TXT) nprpc-fix (Q195733.TXT) sms-fix (Q196270.TXT) tcpip-fix (Q195725.TXT) One of them (roll-up) has been removed and will be reposted later As for IIS4: ftp-fix (Q189262.TXT) IIS4-datafix (Q188806.TXT) infget-fix (Q192296.TXT) sfn-fix (Q179148.TXT) ctr-fix (Q185349.TXT & Q188832.TXT) So, the problem is someone NOT reading the Knowledge Base notes that go with the fixes. Here are your cuplrits: > The msiisp1i386 Patch (q148188 kb article) > The ASP.dll Patch (q177036 kb article) These are both PRE-SP4 and PRE-NT4 Option Pack ~ Christopher Timmons Ph: 763-6620 Security Technology, Nortel Networks With special thanks for this fix to: ---------- Patrick Timmons (MCSE+I - MCT) Integrator Systems http://www.int-sys.com ----------------------------------------------------------------------- Date: Wed, 20 Jan 1999 11:09:08 -0800 From: Adam Berns To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: IIS4.0 and Visual Interdev-Some solutions Here is what I have found to be the problem. 1. It has nothing to do with any service packs, nothing with SP4, or any of the IIS packs. 2. It has everything to do with the New enhanced Security stuff. Currently, security is set in a downward scheme. Where permissions to a child object are forced onto it from the parent. It then takes those securities as its own. For example, if I assign permissions to the parent folder, I tell it to replicate the permissions all the way down it's child folder. I can then go in and manually change those permissions. However, with the new security stuff, that changes. Security is inherited from the parent folder. When you install the new security stuff, how permissions are handled are different. Meaning that the child folder says "I want to look like my parent". So that it does not have its "own security" but instead uses the one above it. Well unfortunately, the Front Page security check/fix option does not know how to handle this. So I went a broke the parent/child relationship for all of the items in Q162144 and then had Front Page check/fix. Well the BSOD my machine on a re-boot. So basically what I am saying here, is DO NOT install the enhanced security stuff on an IIS machine. Though it is nice having all of the extras, it just does not work with IIS and Front Page. This was repeatable. To test it here is what I did: 1. Took a server, installed SP4 and IIS4, and ran the front page check/fix to tighten security. 2. At that point security was acceptable (asking me for name and password), though somebody can still see all of my front page web sites 3. I then installed the enhanced security management, and I was then able to access the web sites with no security required. ~~~~~~~~~~~~~ Adam Berns Systems Administrator Silicon Gaming, Inc. adamb@ubet.com http://www.silicongaming.com 650-798-7813 desk 650-798-8223 fax 415-307-8746 cell ----------------------------------------------------------------------- Date: Mon, 25 Jan 1999 21:30:56 -0600 From: Charlie Roberts To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: IIS and InterDev - some info I found the following excerpt from the msdn library (search for 'security' under the InterDev section), maybe this will shed some light on the prob. -------------------------- FrontPage Server Extensions Visual InterDev works through the FrontPage server extensions to provide the ability to manage design-time Web permissions using the underlying security model of the host operating system on the master Web server. If your operating system is Windows NT with the NTFS file system, the FrontPage extensions manage access for administrators and authors using file ACLs for the DLLs in the following table. These directories are hidden to the Web server but available to the file system: --Function --DLL --Location Administrative(i.e., setting Web permissions) Admin.dll /_vti_bin/_vti_adm Authoring (i.e., opening a file) Author.dll /_vti_bin/_vti_aut Browsing (i.e., viewing links) Dvwssr.dll /_vti_bin/_vti_aut When you perform a function, such as changing permissions on a Web application, your request is sent over HTTP at the server and routed to one of these ISAPI DLLs. For example, a request to perform an administrative function is handled by that Web application's Admin.dll. In the request, the client provides credentials that identify the user who is logged in to the client workstation. This user must have read permission (equivalent to read and execute individual permissions) for the DLL handling the request; otherwise, the request is denied. Thus FrontPage restricts who may perform a given request by controlling read permission on the DLLs in _vti_bin. Whenever a change is made to a Web application's permissions via the Web Permissions dialog box, the FrontPage extensions on the server modify the ACLs on the DLL's _vti_adm and _vti_aut directories in that Web application's _vti_bin directory accordingly. Note FrontPage does not change ACLs on content files to manage design-time security; it only changes ACLs on the directories that contain the gatekeeper files admin.dll, author.dll, and dvwssr.dll. FrontPage manipulates content file ACLs to manage run-time security, which is the topic of the next section. ---------------------------- Charles Roberts Systems Admin - Career Center University of Mississippi