I am using Windows 2008 servers in a terminal services environment. After upgrading to 2008 R2 on the servers, we are no longer able to authenticate with a client's web server. After using Fiddler2 and doing much troubleshooting, I've determined that the issue is due to the website only offering NTLMv1 authentication, and that method being disabled in 2008 R2 IE8. Unfortunately, we can't make the client upgrade their system and we need to be able to access the website. I have attempted to resolve the issue various ways, such as changing the Local Security Policy Security Option for "Network Security: LAN Manager authentication Level" back to "Send LM & NTLM - use NTLMv2 session security if negotiated" and rebooting, but this does not seem to have had any effect. I've followed various other instructions as well. (http://serverfault.com/questions/153216/can-you-change-windows-7-ntml-settings-to-be-more-like-windows-xp) So I have two questions: 1. Can someone point me to an official MS resource that indicates NTLMv1 was disabled in 2008R2 IE8 (in case I need to convince them to fix the server)? 2. Is there any way to re-enable NTLMv1, as the above mentioned setting doesn't help? I'd really appreciate any assistance.

First, NTLM v1 sends all passwords across the wire as hashes, which are trivial to crack with today's computers. HOWEVER, if you are determined to get this to work ASAP and have other security measures in place, you may also want to check your server's policy setting for: Minimum session security for NTLM SSP based clients C Shane Cribbs http://www.georgiatechnologies.com

Thanks for the reply! I had noticed those and set them to "No minimum" earlier and reboot. Didn't seem to affect IE8 though. If it were up to me I'd just have them upgrade their side to support NTLMv2. Unfortunately we are 1 out of several vendors and we are the only ones with a problem because we try to keep things up-to-date. I am really not looking forward to having to downgrade back to 2008 R1, as there seem to be some GPO issues with that release. If you can think of anything else I might have missed, I'd appreciate the input.

Sorry, but I think I misunderstood your problem. You are the CLIENT (as far as the computing model goes). Have you looked into this setting? http://support.microsoft.com/kb/322822 Of course there's always Firefox and Chrome. :-) C Shane Cribbs http://www.georgiatechnologies.com

That's one of the things we've looked at. I actually made it bypass our proxy too, so I could eliminate that as a possibility (I know proxies break a lot of stuff). I've been working with MS support for the past couple of days over the phone now (using one of my 2 Technet Incidents) but so far they are just having me get network captures of the undecryptable SSL traffic, so I doubt I'll get anywhere. This is my understanding of the problem (changed the data so it's safe to post): When a system does NTLM authentication over HTTP, it is a multi-part process. First, the server sends back a 401 with a WWW-Authenticate header telling the client to authenticate. Next, the client responds with another request, with an authentication header containing a “Type 1” NTLM message. This message contains flags that tell the server what features are supported (NTLM version, signing capabilities, etc). Next, the server responds with another 401 message, with an NTLM “Type 2” message in it. This message tells the client software (browser) what features the servers supports by including a flag similar to the one sent by the client, and also contains an NTLM challenge. Finally, the browser should make another request with an NTLM “Type 3” message containing the answer to the challenge and completing authentication. The server should respond to this with the webpage if authentication succeeded. The problem we are having here is that IE sends the “Type 1”: -[NTLM Type1: Negotiation]------------------------------ Provider: NTLMSSP Type: 1 OS Version: 6.1:7601 Flags: 0xa2088207 Unicode supported in security buffer. OEM strings supported in security buffer. Request server's authentication realm included in Type2 reply. NTLM authentication. Negotiate Always Sign. Negotiate NTLM2 Key. Supports 56-bit encryption. Supports 128-bit encryption. Domain_Offset: 0; Domain_Length: 0; Domain_Length2: 0 Host_Offset: 0; Host_Length: 0; Host_Length2: 0 Host: Domain: ------------------------------------ And the Server sends the Type 2: -[NTLM Type2: Challenge]------------------------------ Provider: NTLMSSP Type: 2 OS Version: 0.0:0 Flags: 0x8201 Unicode supported in security buffer. NTLM authentication. Negotiate Always Sign. Challenge: 00 02 02 02 00 00 00 00 ------------------------------------ But IE just displays the 401 error and never sends a type 3 message back to the server. The type 3 message looks like this in IE6: -[NTLM Type3: Authentication]------------------------------ Provider: NTLMSSP Type: 3 OS Version: 5.2:3790 Flags: 0x2008205 Unicode supported in security buffer. Request server's authentication realm included in Type2 reply. NTLM authentication. Negotiate Always Sign. lmresp_Offset: 128; lmresp_Length: 24; lmresp_Length2: 24 ntresp_Offset: 152; ntresp_Length: 24; ntresp_Length2: 24 Domain_Offset: 72; Domain_Length: 30; Domain_Length2: 30 User_Offset: 102; User_Length: 16; User_Length2: 16 Host_Offset: 118; Host_Length: 10; Host_Length2: 10 msg_len: 176 Domain: the.server.name User: username Host: HOST lm_resp: 2F CB 1B 9E 97 6C 3F 4B E4 21 18 B9 3A D4 65 18 75 4F E9 A3 F6 4C 51 F8 nt_resp: 0C 9F A5 1F B0 D9 A8 B1 EE 70 D7 C5 1E 8E 8C DF 8F D6 9B 92 81 FB 85 11 The “Type 2” message from the server is indicating that it only supports NTLMv1. You can tell this because it doesn’t include any NTLMv2 signing capabilities. As I have heard from numerous sources that IE8 on 2008R2 disabled NTLMv1 authentication completely, it makes sense to me that this is why IE8 is deciding not to send a “Type 3” NTLM message back after learning NTLMv2 is not supported.

Of course there's always Firefox and Chrome. :-) C Shane Cribbs http://www.georgiatechnologies.com I wish... The old software our customer is using was designed for, and only supports IE. Pages are malformed and just don't work right in other browsers, although they do authenticate.... I thought I'd be clever and see if IEtab in Firefox would use FF to auth and load the page in an IE frame but it unfortunately Auth's with IE8. As a workaround, have you ever heard of anyone running IE older than 8 on 2008R2? Even a bad hack would suffice. I REALLY don't want to go back to 2008R1, as some of the security GPOs don't work properly in that version.

How about a virtual machine with Windows Server 2003 or XP or whatever has worked in the past? I realize this isn't the most graceful solution, but it may get you by for now. You could even use Unity mode in VMware Workstation to hide the virtualization interface. C Shane Cribbs http://www.georgiatechnologies.com

It is a good idea, though we have about 100 users on 5 terminal servers. Maybe one terminal server with 2008R1 on it? But that would need a lot more terminal services licenses. Our customer has actually committed to take a look and see if they can support something other than NTLMv1 on their side now, so I'll keep my fingers crossed there. MS finally sent it back to the IE team where it belongs, but I have a feeling after days of working with them the answer is going to be "doesn't work, never will." I do appreciate the ideas, and through this I've learned a lot about NTLM and HTTP authentication mechanisms that could be handy in the future. I'll update the thread with whatever I get from MS's support team in the end. Thanks again!

Hi, I would like to confirm what is the current situation? If there is anything that I can do for you, please do not hesitate to let me know, and I will be happy to help. Regards, Arthur Li Forum Support Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I've been working with MS Support using one of my TechNet incidents. The IE team sent me to the DS team despite my explanation that it was an IE issue. Now after a week working with them on it they are finally understanding the problem I explained to them last week and sending it back to the IE team for investigation. On the business side, we ran out of time and I've started rolling all of our servers back to 2008 (non-R2). I plan to keep one running R2 just long enough to finish troubleshooting with MS support, so hopefully we can someday go back to R2. I must say that while I understand the tendency of tech support not to take the customer's word for what is going on and figuring it out for themselves, it would be nice if they would at least listen to a thorough explanation of the issue for those of us who *know* what the issue is already. So far no one I've spoken to has heard that NTLMv1 was disabled in IE8/2008R2 and Windows 7. As I've only seen unofficial posts reference that "fact" I can't really provide anything to support about it. If anyone has seen an official MS resource that states it, I'd really appreciate the information so I can give it to support.

I would contact the website you are trying to reach and see if certificate based auth is a possiblity with them, much more flexible and offers a tighter solution.

Yeah... unfortunately the fact that it only supports NTLMv1 means that it is terribly out of date, and they aren't going to be willing to make auth changes just for me. It is actually a CGI app not using a standard web server like IIS or apache. Their position is actually that since we are the only ones having the problem, it's our problem and not theirs. The politics of the situation mean that we can't really argue with them. I had their techs willing to look for a possible solution until management on our side decided to unwisely press them for updates and now they are unwilling to work with us.

Windows 7 and Windows Server 2008 R2 default to LMCompatibilityLevel=3, no NTLMv1 response. Try changing LMCompatibilityLevel=2 You may also need to disable CBT http://support.microsoft.com/default.aspx?scid=kb;EN-US;976918 Please see the workaround mentioned in: http://support.microsoft.com/kb/954387/en-us Also refer to: http://www.activedir.org/ListArchives/tabid/55/forumid/1/postid/40550/view/topic/Default.aspx Sumesh P - Microsoft Online Community Support

Thanks for the response. That is one of the many things we've attempted. It does enable NTLMv1 for file and share operations, but has no effect on IE8.

Try disabling the "Integrated Windows Authentication" in IE advanced properties. Other resources of interest are: 908209 Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003 http://support.microsoft.com/default.aspx?scid=kb;EN-US;908209 You should consider whether or not Extended Protection for Authentication is involved: Try setting SuppressExtendedProtection to 0 968389 Extended Protection for Authentication http://support.microsoft.com/default.aspx?scid=kb;EN-US;968389Sumesh P - Microsoft Online Community Support

Did you try the steps above? Sumesh P - Microsoft Online Community Support

Yeah, those were some of the things we have attempted. So far none of the OS settings seem to affect IE8. MS's IE team said they were escalating the issue but so far no word back from them. Here's a list of some of the stuff we've checked so far... Suppress Extended Protection settings Local Security Policies for minimum NTLM encryption levels LM & NTLM version support Local Policies (LM Compatibility Level) Integrated Authentication in IE Advanced settings All combinations of SSL/TLS support in advanced settings in IE Various combinations of automatic/prompt for log in settings in IE security for the zone IE disconnect/reconnect on 401 settings and other SSL registry settings for IE.

Please continue to work with the Escalation team. I will stop further research on this to avoid duplication. Feel free to post the solution back to the thread.Sumesh P - Microsoft Online Community Support