First published on CloudBlogs on Feb, 20 2007
Some of the fun we in product support have is that, once a new product is released nowadays, we get to chart the unexplored waters of new security settings interoperating with our customers real world environments.
With Windows XP and Server 2003 we saw that there were challenges brought about by the SMB signing, and LMCompatibility level security settings. SMB Signing is a way of guaranteeing the originator of the traffic since it is signed by that node. LMCompatibility, put simply, is a way of telling your computer to not use less than a certain version of NTLM authentication since older versions are less secure.
Both of these things are stunningly good things from a security perspective. To be frank, if they are disabled or lessened then your systems are less secure.
But in the real world there are plenty of people who have old computers (Windows 9x, NT) that may not be compliant with enhanced security. These types of things are may not always be disseminated well right at the release of a product so we play a little catch up. If you saw my post regarding TCP Auto-Tuning a few months ago then you’ve heard this tune before.
LM Compatibility level is a way of setting your Windows computer to use only a specified level of LanMan authentication (NTLM). This is done via a registry value which is noticed by the LSA at boot:
hklmsystemcurrentcontrolsetcontrollsa
Why am I bothering to post about this “old hat” stuff? Well, Vista defaults to LMcompatibliltylevel = 3. This is more secure, but can cause problems with other products which do not interoperate well with some of the more secure mechanisms. Some Unix based network file sharing devices, for example. In fact, if you have an account lockout policy specified and you could end up locking your user account out if you ran into this when trying to connect to a file share on such a device.
So, to see if you are running into this little nugget match these criteria:
-Problem occurs only when connecting to the resource from a Vista client, but may not occur from other operating systems
-You do not specify a custom LMcompatibliltylevel setting in any of your group policies
-Doesn’t necessarily have to be a network file sharing device back end…but more likely to be.
-Network traffic will appear similar to that below (SMB negotiation details excepted for brevity):
No. Time Source Destination Protocol Info
152 07:48:17.447552 34.52.40.213 34.224.36.2 SMB Negotiate Protocol Request
153 07:48:17.449232 34.224.36.2 34.52.40.213 SMB Negotiate Protocol Response
164 07:48:17.458380 34.52.40.213 34.224.36.2 SMB Session Setup AndX Request, User: DOMAINuser1; Tree Connect AndX, Path: \LOCALFILESVRIPC$
182 07:48:20.410098 34.224.36.2 34.52.40.213 SMB Session Setup AndX Response, Error: STATUS_LOGON_FAILURE
How can you work around this behavior? Well, the best way would be to bring the same minimum level of security to all devices involved. That can be a difficult thing to do when you are stuck with inherited infrastructure and a limited budget though.
So, if you can’t have all devices meet that minimum security then you will be forced to allow less secure authentication in order to get your business flowing. To do that, lower the LMcompatibliltylevel to a lower number that the other device can handle. Then reboot for that to take effect.
Here’s a link article that goes into good detail about NTLM authentication and what the LMcompatibliltylevel setting does:
http://www.microsoft.com/technet/technetmag/issues/2006/08/SecurityWatch/?related=/technet/tech...
Thanks to Joey “I’m Gonna Get You Sucka” Wray for help identifying this little gem.
