In the last issue of IIS Administrator UPDATE, I recommended searching your server (Windows 2000—Win2K—or Windows NT 4.0) for *.vbs. There is an amazing breadth and depth of great Windows Script Host (WSH) script on your server just waiting for IIS administrators. I promised that between then and now, I'd figure out how to enumerate the resources on a Microsoft Site Server 3.0, Membership-authenticated (Site Server 3.0 Personalization and Membership Directory Service—DS) Web site to display the authentication for every resource that has Anonymous access.
Before I began writing the tool, which you can use to audit security on your Web sites, I had to find the Web site iteration logic on my Windows 2000 Advanced Server (Win2K AS). The logic was in the Microsoft Windows 2000 Resource Kit in listmembers.vbs (\program files\resource kit). I found the logic that returns the authentication method applied to a Web resource in Site Server in pmadmin.vbs (\microsoft site server\bin\p&m). The WSH script that I wrote, which combines the logic from both scripts, is called auditdsauth.vbs. You can download it from the IIS Administrator Web site. I've provided this tool to a number of my clients, and it has exposed some glaring security holes that I have since shored up. The WSH script displays help about how to use it if you run it with the /h parameter (i.e., "cscript AuditDSAuth.VBS /h"), and the script is well documented within the code itself.
Anonymous access to resources on any protected area of a Web site is scary. Let me describe how the problem happens. Site Server 3.0 Membership authentication supports inheritance at the Web site, virtual directory, and folder levels. If you apply Anonymous access to the Web site itself, every file and folder beneath it inherits Anonymous access as well. If you apply Clear Text/Basic authentication then take away Anonymous access on a virtual directory or folder under the default Web site, every file and folder beneath that directory or folder inherits the same authentication method. If you apply authentication to a resource, it supercedes any authentication that it inherited. If you apply authentication to a file (e.g., an Active Server Pages—ASP—page), there is nothing downstream to inherit that authentication.
The inheritance feature is great, and being able to mix and match authentication types that supercede the inheritance is also great. The problem is that many Web sites that you protect by forcing an authentication allow Anonymous access to their homepages. You would, of course, carefully take away Anonymous access where appropriate from each file and folder downstream before going live. But, if one of your developers later adds new features by adding a folder off the root Web site and ASP pages to that folder, the folder and those pages inherit Anonymous access from the root Web site. Even if you apply Anonymous access to default.asp and every image that it uses and take away Anonymous access from the Web site itself, users will still be challenged (prompted with a username and password dialog box) when they browse the site itself.
I've seen and developed many content-management systems, and the type of accident I describe seems to happen no matter how careful you are or how rock solid your content-management process is. Consequently, you see the need for a tool like the one I've developed for Web sites that use Site Server 3.0 Membership authentication. Unfortunately, because of the nature of the Internet, security auditing is a priority task for IIS administrators.