NULL credentials might be used when accessing remote systems from a process running under Local System account

Hi there,

In a number of support cases, I was requested to take a look at "access denied" network traces. In some cases the reason of why we get the access denied is related to Kerberos authentication and Local system account so I wanted to touch this subject in today's blog.

A service or application might be configured to run under "Local System" security context. Normally when such a service or application (like a scheduled task) needs to access network resources, it uses "domain\computername$" account to authenticate itself to remote parties. In one of the scenarios I was involved in, a scheduled task (which runs under Local system security context) ran a script which in turn accessed a server share (\\server\share). When the script was run that way, it got an access denied error from the destination server and failed to run properly.

In the network trace captured when that failure occured, it was seen that the source client tried to authenticate against the remote server with NULL credentials. Since anonymous authentication was not enabled at the destination server, it didn't authenticate the client and returned ACCESS DENIED:

Source Destination Protocol Info
====== ======== ======= ====
10.1.1.1 10.1.1.2 SMB Session Setup AndX Request, NTLMSSP_NEGOTIATE
10.1.1.2 10.1.1.1 SMB Session Setup AndX Response, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIRED
10.1.1.1 10.1.1.2 SMB Session Setup AndX Request, NTLMSSP_AUTH, User: \
10.1.1.2 10.1.1.1 SMB Session Setup AndX Response
10.1.1.1 10.1.1.2 SMB Tree Connect AndX Request, Path: \\Server\Share
10.1.1.2 10.1.1.1 SMB Tree Connect AndX Response, Error: STATUS_ACCESS_DENIED
10.1.1.1 10.1.1.2 SMB Logoff AndX Request
10.1.1.2 10.1.1.1 SMB Logoff AndX Response

Note: It can be seen in the 3rd frame that the client is sending NULL credentials

The above problem was stemming from a Kerberos authentication failure. Normally "domain\computername$" account is used when the service/application runs under Local System security context but it's done only if the authentication protocol is Kerberos. So if Kerberos works fine, than the given account is used. If Kerberos authentication fails for a reason (like name resolution issues etc) and the client needs to fall back to NTLM, NULL credentials are used instead of "domain\computername$".

If the related service/application is configured to run under "Network service" account context, domain\computername$ account is used when authenticating with either Kerberos or NTLM protocol.

In the above scenario, after addressing the Kerberos issue, the NULL credentials problem was resolved.

As an additional information for Windows 7 & Windows 2008 R2, an application/service running under "Local System account" security context can use domain\computername$ account when authenticating against remote servers with either Kerberos or NTLM authentication. This could be configured via group policies for those systems

https://technet.microsoft.com/en-us/library/dd566199(WS.10).aspx Changes in NTLM Authentication

Hope this helps

Thanks,
Murat