Integrating IIS with your network becomes a balancing act of how you want your Web application to be accessed, and how you want to manage your domain accounts. Probably the number one decision is whether or not anonymous access will be enabled.
The basic drawback with the anonymous logon account is that it is initially created only as a local user account. In situations where IIS is on a domain controller, this is not an issue because as the account is created it naturally becomes a domain account.
However, where IIS is on a stand-alone server, the anonymous logon account is local, and other remote resources will be accessed from that IIS machine, then the access authentication at the remote machine will fail. For example, when a remote SQL Server attempts to validate the connection, it will not find the user in the local user account information and the connection will fail.
The best approach is to make the anonymous logon account a domain account. This means that whenever authentication is required, the account will always be available to other network servers for validation. The most obvious advantage here is that it allows you to bypass SQL Server authentication through Named Pipes. By adding the anonymous logon account to the domain, this problem ceases to be an issue.
For More Information Choosing SQL Server's Network Protocol, in this chapter, introduces SQL Server authentication through Named Pipes. For a more extensive discussion of Web hosting security issues, search for "General Web Hosting Security Issues" in MSDN Library Visual Studio 6.0.