This section outlines additional security considerations.
Many IIS applications require resources provided by other software components. For instance, an ISAPI extension DLL may call an Automation server from a third-party software company, or a CGI application may launch an applet built with Microsoft® Visual Basic®. These components may have persistent information stored in the registry that they require in order to execute properly. For standard desktop use of these components, the registry information is read from the profile of the user currently logged on a computer with Windows NT. These applications often have problems when launched by IIS because the profile made available to an IIS application is that of the default user. The default-user profile is filled with information generic to all users, but, unfortunately, is specific to no users. Therefore, a component may run as expected when User1 executes it interactively on his or her desktop because it is reading information from User1's profile in the registry. The same application may not run at all from IIS because it will not have access to User1's profile. This is true even if IIS is impersonating User1's account using Basic or NTLM authentication.
Windows NT uses the concept of having multiple desktops on the same computer. A desktop can be thought of as the screen that you view when you are logged on your computer. Your desktop receives all the mouse and keyboard messages that you create as the user in front of the computer, and it allows for applications to interact with one another to a certain extent. For instance, one application on a desktop can post messages to other applications on the desktop. Support for multiple desktops implies that there are other desktops running; you just can't see them and you have no way of sending keyboard or mouse messages to them. This may seem like a futile concept, but, in fact, many applications that run as Windows NT Services require the capabilities that a desktop provides but don't want to interact with the interactive user's desktop. Therefore, each service gets its own desktop that won't be interfered with by the currently logged-on user.
The implication of this to IIS applications is that the IIS service has its own desktop. If your IIS application interacts with a desktop in any way (for instance, if it displays a message box), then it will display that message box on a desktop that cannot be seen on the computer's monitor. Similarly, an IIS application will not be able to send or post messages to an application on the interactive desktop. If your IIS application needs to interact with the interactive desktop, then you should use another form of inter-process communication such as named pipes.
ISAPI Filter DLLs, not to be confused with ISAPI Extension DLLs, run in the original context of the IIS service. All services run by default under the Local System account of the computer on which they are installed. The Local System account has access to almost all resources on the local computer not specifically denied to it, and no resources on any other computers on the network.
Launching a COM object on a computer running Windows NT requires certain permissions. This is normally not an issue for most interactive users because the default permissions for launching and accessing COM objects on Windows NT allows access to anyone logged on the local computer interactively. An IIS application, whether it is running in the context of the IUSR_<servername> account or an impersonated user account from Basic or NTLM authentication, is not interactively logged on. Therefore, the default permissions for launching and accessing COM objects will not allow an ISAPI extension DLL, CGI application, or Internet script to launch these objects successfully by default.
The utility DCOMCNFG on Windows NT 4.0 allows you to set the default permissions for all COM objects on your computer. You can use this utility to provide COM access to the IUSR_<servername> account as well as all user accounts that might be impersonated by your IIS configuration. You can even grant permissions to the Everyone group.
However, providing global access to all COM objects may not be in your best interest. DCOMCNFG will also allow you to specify permissions for specific applications so you can provide access only to the applications you will need to access from your IIS application. COM applications also have the ability to determine which permissions are associated with launching and accessing themselves. To do this from inside your COM server, see the CoInitializeSecurity function new to Windows NT 4.0, as well as CoCreateInstanceEx (in particular, the COSERVERINFO and COAUTHINFO structures) for manipulating OLE access from the client side.
Distributed COM (DCOM), also referred to as Remote Automation, requires all of the COM permissions discussed above. In addition, it needs to access resources across the network. If a request is received using Anonymous authentication, the IUSR_<servername> account user name and password credentials will be used to connect to the remote DCOM server. Unless the computer running IIS is also a domain controller, the remote computer by default will not know who the IUSR_<servername> account is (it only exists on the local computer running IIS). Adding access and launch permissions to the group Everyone does not help in this case because DCOM will not map access by an unknown account to the guest account in the same way that the Server service does for file sharing. The computer running DCOM server must explicitly know the account that is being used.
When you have IIS applications accessing resources (including DCOM resources) on remote computers, you need to have all the computers involved participate in a domain relationship. Then, in Internet Manager, you can change your anonymous account to an account in the local or trusted domain. Now, all computers in the domain structure will recognize the account and can explicitly add/delete access to their network resources for that account or any group that the account is a member of.
Be aware that if Basic authentication is used for an IIS request, access to network resources (including DCOM servers) will be done in the context of the user whose credentials were passed with the request. If the user specified does not have permissions to launch or access the DCOM server, the request will fail.
If the IIS request is validated using NTLM authentication, the impersonation level does not imply knowledge of the user name and password credentials. Therefore, access to network resources, regardless of the permissions on the resource, will be denied (with the exception of NULL Session resources).
For more information, please see article Q172925: Security Issues with Objects in ASP and ISAPI Extensions in the Microsoft Knowledge Base.