Security Failures as SYSTEM

The following error is one that could be commonplace at any time during the last ten years. "SSPI negotiation has failed". "Login failed for user NT AUTHORITY\ANONYMOUS". My service isn't running as an anonymous user. Why isn't it able to connect?

There is a particular bit of behavior for making network requests that differs depending on whether you're using NTLM or Kerberos for authentication. With NTLM, there are some commonly seen circumstances under which you'll end up running as an anonymous user when you may not have expected to. The general issue is that the service principal being used for the outbound call is not correct for what you're trying to do. The specific issue can vary. For example, your service may have impersonated the client caller before trying to make an outbound connection. If you don't have explicit credentials to use for the service and you don't have permission to delegate the client credentials, then you'll have a null user session associated with the call. As another example, your service may be running as a local system account and trying to make an outbound call. NTLM doesn't support using this highly privileged machine account remotely so if you don't have explicit credentials to use for the service, then you will again end up as an anonymous caller.

Next time: Close Your Proxies

Comments

• Anonymous
  May 23, 2007
  I knew there was a reason why Microsoft called these accounts LOCAL system, LOCAL service, and the other one NETWORK service (which authenticates as the computer account as far as I know). Shouldn't these names ring a bell with every developer?

• Anonymous
  May 23, 2007
  Since we've spent some time talking about what doesn't work with serializers, let's look at some techniques