Active Directory Blog : Vista, Network

Server 2008 and Windows Vista: Encryption Better Together

Tim Springston — Fri, 02 Nov 2007 15:00:00 GMT

A while back I did a blog post about some problems that were seen with people testing Windows Vista and then “rolling back” to Windows XP and some problems that could be seen when using the same computer object (also known as account) in AD. If you didn’t get a chance to read it here’s the post. What that scenario highlighted was the added level of encryption, by way of leaving behind a little of the supporting infrastructure in the msds-supported-encryptiontypes attribute value. In this post we’re going to talk about the Big Picture of the new authentication encryption available and a few things to keep in mind....(read more)

All The Logging In The World

Tim Springston — Mon, 08 Oct 2007 19:40:00 GMT

There’s normal troubleshooting and then there’s the stuff you do when the basic troubleshooting doesn’t get things resolved. Normal troubleshooting can be things like selecting “last known good” on a reboot after installing a new driver and having a blue screen. Or perhaps uninstalling and then reinstalling an application, or altering settings for the application or operating system to alleviate a problem. Sometimes we have to dig in and find out more. Many admins out there in the world live that every day. Which is why we add methods to find out more into our products. This post is all about listing all of the data gathering methods that a Directory Services person may ever need to know. Since there are so many it will be difficult to organize well in one uber post but I’m going to put out here for you all anyway, disorganized or not....(read more)

Access Denied, or other Access Failure to SMB Shares From Vista Clients

Tim Springston — Wed, 21 Feb 2007 00:26:00 GMT

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:

hklm\system\currentcontrolset\control\lsa

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: DOMAIN\user1; Tree Connect AndX, Path: \\LOCALFILESVR\IPC$

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/technetmag/issues/2006/08/SecurityWatch

Thanks to Joey “I’m Gonna Get You Sucka” Wray for help identifying this little gem.

Vista Networking, An Issue With a Limited View

Tim Springston — Mon, 04 Dec 2006 16:15:00 GMT

Every few years we release a new operating system and, no matter how much testing, training and documentation we have, some unexpected behaviors occur. We at Microsoft spend a lot of effort to try and prevent problems from occurring in our products at all, but if they do occur we focus on figuring out what the problems is and how to work around or fix it. Sometimes these issues are interopability ones (the interaction of old technologies and new ones), sometimes it is simply a matter of educating folks to expect different functionality. Truth is, each issue is unique, so all the careful planning in the world is out the window when the unexpected happens.

The first truly Windows Vista issue came across to myself and my colleagues. At first, we thought that the customer we were speaking with was seeing a variety of unrelated problems. The confusion may have been exacerbated by the issues being reported to us by a Microsoft person through a partner consulting firm as told to them by their ultimate customer. Picture in your mind a line of people as long as a football field where they each repeat the phrase “Joe wants a large slushy” starting at one end, but the message arrives at the last person as “Joni Loves Chachi”.

Here’s a brief rundown of the various problems (or symptoms of the same problem?) they were seeing:

-Indefinite delay (hang) when opening the Certificate Services snapin

-Slow (sometimes no) group policy application

-Trying to select a domain user in order to add that principal to a local security group (the object picker) would hang indefinitely

-using Instant Messaging was not working well (sometimes at all)

-Access to local file servers was slow and sometimes did not succeed at all (appear to hang).

Local computer actions, meaning things which did not require access to remote resources across the network , worked without intermittency or delay. On a more confusing note, these same actions on the same local area network, worked without any problem whatsoever on legacy Windows clients like Windows XP.

Add to that the fact that this behavior has not been reported (and none of us who had been using Vista exclusively for over a year had seen it) and you can bet that we were really scratching our heads.

A more confusing point of data was that they could take that same Vista computer onto a different physical site and they wouldn’t see the same problem.

We took quite a few traces as a variety of actions were tested on the client, and compared them to working traces. It felt like a needle in a haystack. This was an issue that several of us were working together. You all have heard that we specialize in different areas at Microsoft product support services, and that I am a Directory Services specialist. We of course were working with Network specialists on this one.

This issue was finally determined to be a feature that is a huge bonus-really a reason to buy Vista all by itself-that 99.9% of the time will give about 40% more network speed out of TCP/IP. That feature is TCP Auto Tuning. This feature uses a scaling factor communicated by client to server, and server to client, to negotiate a bigger window size during connection establishment so that more traffic can be transported in less time. Windows XP and earlier do not have this feature.

Here’s a bit more on that:

http://www.microsoft.com/technet/community/columns/cableguy/cg1105.mspx

and the relevant excerpt that applies to what we saw (credit to The Cable Guy for this):

Note Some Internet gateway devices and firewalls block packet flows because they do not correctly interpret the scaling factor used in TCP connections. Because of this, Internet Explorer in Windows Vista uses an initial scaling factor of 2. Other applications use a default initial scaling factor of 8. Microsoft is investigating changing the initial scaling factor for Internet Explorer-based connections to 8 in a future update of Windows Vista. Microsoft is working with the manufacturers of these devices so that they can be updated for compliance with TCP window scaling.

To see if this issue applies to you, first see if the criteria and symptoms I mentioned above apply. If they do, take some traces. The TCP Auto Tuning can be seen in the packets like these truncated samples:

Working (no problem seen):

...TCP\Window: 8192 (scale factor 0) = 8192

...TCP\TCPOptions

......WindowsScaleFactor not listed

Failing (problem supremely evident and most annoying):

...TCP\Window: 8192 (scale factor 8) = 2097152

...TCP\TCPOptions

......WindowsScaleFactor:

......type: Windows scale factor. 3(0x3)

......Length: 3 (0x3)

......ShiftCount: 8 (0x8)

If the above appears you can try disabling this feature as a workaround and this will certainly tell the tale on what the problem is if the issue no longer happens afterward. From a command prompt:

netsh interface tcp set global autotuninglevel=disabled

If the issue no longer occurs this reveals that you have a network device in your environment that doesn’t support RFC 1323 “TCP Extensions for High Performance”.

More on that here: http://www.ietf.org/rfc/rfc1323.txt?number=1323 . The primary focus should be on replacing that network device to get the most out of the rest of the network infrastructure. But the netsh command can be a good workaround and test until you’ve saved enough dollars/loonies/euros/rubles/rupees or livestock to pay for a new one.

It took a village to resolve this issue (at times I felt like said village’s idiot) and here’s a few of the villagers that need some recognition:

“Big” Boyd Benson

Joey “I’m Gonna Git You Sucka” Wray

Mike “Bambi” Hunter

Thanks all, until next time. Post a question, I promise I’ll try to respond in a timely manner.