NTLM authentication may not work for websites based due to Network Security Policies


Issue:


===============


We used to get three prompts resulting in 401.1 while our website hosted on IIS 6 was configured to use NTLM. The event logs showed following entries during the issue.


 


Event Type:   Failure Audit


Event Source: Security


Event Category:       Logon/Logoff


Event ID:       529


Date:            10/08/2009


Time:            16:30:27


User:            NT AUTHORITY\SYSTEM


Computer:     ********


Description:


Logon Failure:


          Reason:                  Unknown user name or bad password


          User Name:   Administrator


          Domain:                  ****


          Logon Type:   3


          Logon Process:         NtLmSsp


          Authentication Package:       NTLM


          Workstation Name:   ******


          Caller User Name:    -


          Caller Domain:         -


          Caller Logon ID:       -


          Caller Process ID:     -


          Transited Services:   -


          Source Network Address:    ***********


          Source Port:  1856


 


 Resolution:


===============


We found that even the file shares were not working, so this was not just a website specific problem.


We took the network traces and found from the network traces that we were using NTLM v1 on the client as opposed to NTLM v2.


The v2 is more secure and is preferred. Probably they had set LMCompatibility to 0 as discussed in


http://support.microsoft.com/kb/239869


 


So we focussed our investigation towards the NTLM versions being used and the group policy settings for them. 


We found that our security group policies had prohibited NTLNv1 due to which we had the issue.


On the client and the web server the local security policy was set to "Send NTLM response only".


On the domain controller the domain controller security policy was set to "Send NTLMv2 response only\refuse LM & NTLM". So there appeared to be few mismatches according to our observation and the GP settings.


 We changed the domain controller security policy and the lcoal security policies on the web server and client machines, to ‘Send LM & NTLM – use NTLMv2 session security if negotiated’ and this fixed the issue. 


Comments (0)

Skip to main content