A null session is how Windows represents an anonymous user. To understand how it is used, imagine the sort of code you have to write in a server to deal with authenticated clients. After authenticating a client using Kerberos (WhatIsKerberos), say, your server receives a token for that client that contains group SIDs, and you can use that token to perform access checks against ACL'd resources (WhatIsACLBasedSecurity). For instance, given the client's token it's quite easy to check whether that client should be granted write access to a file. We can simply impersonate the client (WhatIsImpersonation) and try to open the file for writing. The operating system will compare the DACL on the file with the client's token (that we’re impersonating) to make this determination. The administrator can control access to files by editing their ACLs. But what if you also service anonymous requests—that is, those for which you won't get any token for the client at all? It's impossible to impersonate a client for whom you don't have a token.

This is where the null session comes in. It’s a logon session that represents anonymous users, and here's how you use it. In your code that services anonymous requests, grab a token to represent the anonymous logon by calling the Win32 API ImpersonateAnonymousToken (see HowToDealWithUnauthenticatedClients for sample code). This is a null session token, and it has a user SID of ANONYMOUS LOGON and a single group SID, Everyone¹. One group SID conspicuously not present is Authenticated Users (all tokens other than null sessions or guest logons have this special SID, in case you were wondering). This is the key to using the null session. By granting access to Everyone, you’re granting access to all users, both authenticated and anonymous. By granting access only to Authenticated Users, you’re implicitly denying anonymous users. This simple model allows an administrator to use ACLs to control access to all users, both authenticated and anonymous.

Sometimes you'll find yourself using a null session when you don’t necessarily mean to. For example, say Alice (a remote client) authenticates with you and you impersonate her (WhatIsImpersonation). If you attempt to authenticate with another machine while impersonating Alice, you’ll very likely find that you've established a null session on that machine instead of establishing a logon for Alice. This is because Alice was happy to prove her identity to you but she didn't send along any credentials that you could use to prove to another server that you are Alice (note that this protects Alice from your misusing her credentials on the network). For more information on this topic, see WhatIsDelegation.

Null sessions are quite useful when used properly, but historically Windows has granted way too much access to them. For example, many Windows systems are configured to allow an anonymous remote user connected via a null session to enumerate user account names. Heck, once I know the names of all the local accounts on a machine, I can mount a brute force or dictionary attack against their passwords. If you read books like Hacking Exposed (McClure etal. 2001), you find that hackers often use null sessions to attack machines running Windows. So over the years more and more constraints have been placed on them. For example, there’s a security option in the local security policy of Windows XP called "Network access: Let Everyone permissions apply to anonymous users." If this option is disabled (and it’s disabled by default) null session tokens on the machine omit the Everyone SID. In this case, granting access to Everyone doesn't grant access to null sessions because they don't have that SID. Weird, don’t you think? To grant access to a null session in this case, you need to explicitly grant access to ANONYMOUS LOGON.

The file server in Windows has some built-in limitations on null sessions. If you look in the registry under HKLM/SYSTEM/CurrentControlSet/Services/lanmanserver/parameters, you'll find a couple of named values: NullSessionShares and NullSessionPipes. By default, null sessions can’t access any shares or named pipes unless they’re listed here.

COM has no built-in limitation on null sessions. Oddly enough, regardless of a COM server's required authentication level, null sessions are allowed in. The only way to block them from using a COM server is via the server's access control policy. For this reason, you should avoid adding the Everyone group to a role in a COM+ application, unless you really do want to include anonymous users. If you're not sure, stick with Authenticated Users instead, as I suggested earlier.

IIS has a unique way of dealing with anonymous users. Instead of relying on the null session, when installed it creates a special account on the machine called IUSR_MACHINE, where MACHINE is replaced by the machine's name. IIS keeps a logon session for this account lying around and uses it to represent any anonymous requests. This is very similar in spirit to the null session, and you've got to wonder why the IIS team isn't simply using the null session instead. The main drawback to the IIS approach is that the resulting token for IUSR_MACHINE contains the Authenticated Users SID, which pretty much breaks the whole idea of what Authenticated Users is supposed to represent. So much for consistency!

Here's a good practice you should learn. Get out of the habit of using Everyone when working with ACLs, and start using Authenticated Users. Only when you're absolutely sure you want to allow anonymous users should you consider using the Everyone SID to grant access.

¹ In some cases the token will also contain the NETWORK SID as well.

PortedBy MattSetzer