WCF: Review System.Net and Network traces for Windows Authentication/Delegation based troubleshooting
<?xml version=”1.0″ encoding=”utf-8″ ?>
<trace autoflush=”true” />
<add name=”System.Net” type=”System.Diagnostics.TextWriterTraceListener”
initializeData=”c:\traces\System.Net.trace.log” traceOutputOptions=”DateTime” />
<add name=”System.Net” value=”Verbose” />
<add name=”System.Net.Sockets” value=”Verbose” />
<add name=”System.Net.Cache” value=”Verbose” />
<add name=”System.Net.HttpListener” value=”Verbose” />
Once the data is collected follow below steps to review:
- Search for following key words “InitializeSecurityContext”
- This will give you the socket number associated with the request:
- Follow the socket number upwards and you should see the web request associated with it.
- You might see multiple “InitializeSecurityContext” call, so make sure to search for one more key word “Received headers”
- This received header is very crucial as it contains the authentication scheme supported by server and the challenge for authentication.
- Just after this, we should find the “InitializeSecurityContext” call with the service principle name listed.. used to get the Kerberos token from DC
- As we can see above, I am using the SPN listed via “targetName” value. Above screen shows that I am using a BAD SPN and eventually this will fail to get the Kerberos Token from DC
- In just next frame, you can see client trying to use a NTLM toknen:
Network traces review
- Next we will see how we read this conversation over the Network, because Network traces will also reflect that we failed to get Kerberos token.
- Once you have the data collected, please use following filter to review the logs “Kerberosv4 / Kerberosv5”’
- Now we should try to review the Response received from the DC, many a time you might find multiple responses received and it may be difficult to identify the one which we called.
- So the trick is, with in the response… you will see the service principle name set/seen via System.Net traces
- As we can see this response is indeed coming for the request we initiated… and along with that we also Kerberos error code:
- Keep this kb handy to review the status codes:
- Clearly error indicates that the service principle name is not registered.
Hope this helps in performing basic troubleshooting for windows authentication/delegation failure.