Date: Mon, 18 Jan 1999 11:58:06 -0800
From: Adam Berns <adamb@UBET.COM>
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 <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.
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 <ctimmons@NORTELNETWORKS.COM>
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 <adamb@UBET.COM>
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 <croberts@OLEMISS.EDU>
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
<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