IIS 7 and Above
401.1 not logged in IIS log by site
Last post Feb 16, 2018 05:30 AM by mahamr
Feb 07, 2018 04:03 PM|Aidan0o0|LINK
We have several sites configured on a windows 2008 server with IIS 7 and using NTLM authentication.
We know using fiddler that 401.1 responses are being sent by this server, but they are not shown in the IIS logs.
In fiddler we see the 2 401 responses and then the 200, but the log only shows a single 401.2
I've tried to search for a configuration setting or explanation without any luck.
Does anyone know why they are not displayed or how to enable them?
Feb 07, 2018 09:01 PM|lextm|LINK
If IIS logs do not record, then such should come from something else. Since you have Fiddler, you should review the raw response and see if its Server header can show some hints. I guess it might come from a proxy server, but you are the only person who
can see the Fiddler tracing. Before digging all you can get from Fiddler, I won't think searching for other information can help you right now.
Feb 08, 2018 09:58 AM|Yuk Ding|LINK
where is the IIS server located? In a intranet domain or a signal workgroup? In addition, could you pass the authentication with localhost and unassigned IP?
Feb 08, 2018 10:32 AM|Aidan0o0|LINK
There is a loadbalancer and firewall between the servers, but I don't think that's it for a couple of reasons. I have a win 2003 server with similar setup, and on there the IIS logs record both 401s. And if it was something like that why is it the second
401, the 401.1, that isn't being captured, if that was the case wouldn't it be the first 401 or both of them?
There's nothing obvious in the header anyway:
HTTP/1.1 401 Unauthorized
Content-Type: text/html; charset=us-ascii
WWW-Authenticate: Negotiate TlR...
Date: Thu, 02 Nov 2017 12:34:05 GMT
Set-Cookie: TS01eb1431=012ee3e080258f23b80ea4802fa28a7f4792eb87f1aef64c3f7c3f605981a40639d443d037; Path=/
Set-Cookie: TS01eb1431_28=014d0f141e78ec94ce9a6f1407841333bd70e45042be003cd98098d5da50a6004cc400d0c118775a29e3be7c6a18fdae57c52cfefa; Path=/
Feb 08, 2018 10:33 AM|Aidan0o0|LINK
Hi Yuk Ding,
It's on a domain.
Good idea on localhost, i will try it, and that will eliminate any network interference.
Feb 09, 2018 10:17 AM|Aidan0o0|LINK
I'm still at a loss on this.
I wasn't able to connect via localhost, but I was able to connect direct to the server from another box on the same vlan, and that exhibited the same behaviour.
If i give incorrect credentials then I see both the 401.2 and the 401.1 in the iis log, but if i give correct credentials it only logs the 401.2 and the 200.
Feb 09, 2018 06:12 PM|lextm|LINK
As the Fiddler trace does not contain any useful information, you have to capture network packets on both the server and client, so that you can trace if the 401.1 comes from IIS.
Feb 12, 2018 12:05 AM|mahamr|LINK
With NTLM authentication, the 401.1 in a successful set of requests is handled by HTTP.sys, which is
below IIS, thus is not recorded in the IIS logs. This is when you have Kernel Mode enabled in the Windows Auth settings, which it is by default.
The part you do not see is the NTLM Type-2 message, which is the NTLM challenge. Since Kernel Mode is enabled, HTTP.sys handles retrieving the challenge and sending it back to the user with the 401.1. This is a performance enhancement since HTTP.sys is in
the kernel, avoiding the additional context switch up to user mode (IIS).
Overall, this is normal and is nothing to worry about.
EDIT: One extra thing, you can tell this comes from HTTP.sys by taking a look at the HTTP "Server" header - it should say "HTTPAPI/2.0" if I remember correctly.
Feb 12, 2018 10:28 AM|Aidan0o0|LINK
That makes perfect sense. I ran wireshark just to check and you are 100% correct, the server header is "Microsoft-HTTPAPI/2.0"
Do you know where that's documented? Hopefully some other puzzled admins will find this post in the future.
Feb 12, 2018 08:51 PM|mahamr|LINK
I don't believe the actual HTTP request flow of kernel mode and NTLM is documented anywhere, at least not that I know of. What kernel mode itself does, in general, is documented here:
For the latter link, the useKernelMode attribute of the <windowsAuthentication> node is the one that enables/disables this feature.
Maybe I'll write a blog entry showing this... if I do, I'll update this post.
Feb 16, 2018 05:30 AM|mahamr|LINK
Here's that blog entry I mentioned, hopefully this helps!