iis4.0+visual-interdev.txt

`Date: Mon, 18 Jan 1999 11:58:06 -0800  
From: Adam Berns <[email protected]>  
To: [email protected]  
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 <root web> 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.  
[email protected]  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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.  
[email protected]  
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 <[email protected]>  
To: [email protected]  
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  
<Webdir>/_vti_bin/_vti_adm  
  
Authoring (i.e., opening a file)  
Author.dll  
<Webdir>/_vti_bin/_vti_aut  
  
Browsing (i.e., viewing links)  
Dvwssr.dll  
<Webdir>/_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  
  
`