Using Null Session Shares

Administrators don't typically need to use null session shares. However, under certain circumstances, they're useful. Consider a Win32 service such as Microsoft IIS that must access data on remote machines. By default, IIS creates a local user account called IUSR_machinename. When someone accesses your Web site as an anonymous user, IIS logs on (or impersonates) using that account. So when IIS tries to access a file or Active Server Pages (ASP) page—including using a Universal Naming Convention (UNC) path to access a file on a remote machine—it uses IUSR_machinename's credentials. The remote machine can't use the IUSR_machinename account to authenticate the user because the account exists only on the IIS machine. If, however, the UNC refers to a shared directory that has a null session share, the remote machine doesn't challenge the IIS machine for credentials, and the IUSR_machinename account has full access to the UNC share.

In addition, some services require null session shares, so during their setup routines, the services might add share names to the registry's null session share list. For example, Microsoft Dfs creates a null session share called DFS$. If you remove this share, Dfs services might fail to function properly. Most Windows machines create a COMCFG null session share, which apparently is used for SNA communication services. Other services, such as the UNIX Line Print Remote (LPR) utility and some antivirus packages (e.g., McAfee's VirusScan, Computer Associates'—CA's—Inoculan AntiVirus), use null session shares as well.