Previous Section Table of Contents Next Section

The ASP Security Context

ASP pages run under a specific security context, and the identity of that context depends on a few factors. First, bear in mind that the IIS service itself runs under the LocalSystem account. As the name implies, LocalSystem has almost complete control over all local resources, and practically no authority to access network resources. However, although IIS runs under the LocalSystem account, actions performed by Web pages (including ASP pages) do not have LocalSystem privileges. That's because IIS uses a system of impersonations to grant security privileges to Web pages.

The first impersonation IIS does is the Anonymous user account. That's the IUSR_machinename user account that's created when IIS is installed. It's a local account, not a domain account, and it isn't a member of the machine's Users group-it's a member of the Guests group. That membership severely restricts the functionality that the account has, and pretty much limits it to reading Web pages. IIS performs this impersonation whenever anonymous access is enabled for a Web site, as shown in Figure 23.1.

Figure 23.1. Enabling anonymous access for a Web site

graphics/23fig01.gif

NOTE

Windows Server 2003 doesn't use the IUSR_machinename account by default. Instead, it uses a special new built-in user account named Network Service. Regardless, many administrators commonly change IIS to use a more restricted user account, which may affect what your scripts can do.


Note that you can change the user account used to grant anonymous access. I don't recommend ever using a more powerful account, though, as you enable completely unauthenticated users to perform some powerful operations. For example, the Anonymous user account doesn't have permission to run WMI scripts or queries; you could configure IIS to use the local Administrator account for anonymous access instead. That would get your WMI scripts running, but it would also allow complete strangers to have full control over your Web server. Not a good idea!

Remember, IIS uses the Anonymous user account whenever anonymous access is allowed, and when there are no special NTFS permissions on the Web page a user requests. If you want to force IIS to use another form of impersonation, you have to disable anonymous access, as shown in Figure 23.2, or apply restrictive NTFS permissions to the Web pages. Those permissions must not allow the Anonymous user account, meaning you'll have to remove the Everyone group from the NTFS permissions, and ensure that neither the Anonymous user account nor the Guest group has permissions.

Figure 23.2. Disabling anonymous access for a Web site

graphics/23fig02.gif

When anonymous access is disabled (either through the Web site or by NTFS permissions to the Web page), IIS requires the user to provide logon credentials. The Web site's Authentication Methods properties (shown in Figure 23.2) allow you to determine which methods are available.

  • Digest authentication is available for domain member servers and domain controllers. This authentication is reasonably secure, but isn't supported by a very wide range of Web browsers.

  • Basic authentication passes logon credentials in clear text. This is compatible with most Web browsers, although it should only be used when the Web server offers HTTPS encrypted connections. Clear text passwords can be easily intercepted when they're not encrypted by HTTPS.

  • Integrated Windows authentication works primarily with Internet Explorer, and provides the most transparent and secure authentication. Domain users logged on to a domain member workstation generally don't have to retype their user name or password when this type of authentication is used.

When any of these types of authentication are enabled, IIS impersonates the user indicated by the logon credentials. For example, suppose you configure only Integrated Windows authentication, and then log on to your workstation as a member of the Domain Admins group. If you access a Web page, the Web page will be able to execute with Domain Admin privileges. If another non-administrator user accesses the same Web page, the page will only execute with normal Domain User permissions.

TIP

Most administrative Web pages need administrative privileges to execute properly. To accommodate them, I generally set up a separate, dedicated intranet Web site-either on a standalone small Web server or in a separate Web site-to host my administrative Web pages. That way, I can configure the site to require Integrated Windows authentication, and use NTFS permissions to restrict access to only administrators.


Understanding the security context that your scripts are using is important for troubleshooting purposes. I always recommend running complicated scripts as a regular VBS script (which you run under Wscript.exe) before incorporating them into a Web page. Doing so allows you to ensure that the scripts are working correctly; any errors that crop up when you move the script into a Web page is likely to be a security context problem. If you're having problems and you suspect that authentication security is the issue, try running the Web page shown in Listing 23.1. You'll immediately see what user IIS is trying to impersonate when running ASP pages.

Listing 23.1. WhoAmI.asp. Shows the user account IIS is using for security impersonation.

<%



Dim sUser

sUser = Request.ServerVariables("LOGON_USER")



If sUser = "" Then

 Response.Write("ANONYMOUS")

Else

 Response.Write("Logged on as " & sUser)

End If



%>

Obviously, you need to make sure this Web page resides in the same Web site as the one you're testing. Different Web sites can have different authentication settings.

    Previous Section Table of Contents Next Section