How to wreck your Windows network (Part 2)

If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the Real time article update newsletter.

If you would like to read the first part in this article series please go to How to wreck your Windows network (Part 1).


As we saw in the first article in this series, good advice can sometimes be a bad thing. For example, the recommendation “you can decrease the attack surface of Windows computers by disabling any services that aren’t needed in your environment” is actually bad advice because it can make your environment less reliable (and probably not more secure). Let’s continue with some more “worst practices” for ensuring your Windows environment is secure, reliable, manageable and performing well. Remember, these are things you should avoid, so I’ve highlighted the word don’t in each of the topics listed.

Disable 8.3 name creation

You’re an admin of a Windows-based network, which means you’re in charge of the IT infrastructure that keeps your company’s business going and ensures you’ll get a paycheck each week. You want the services and applications running on your network to be secure, reliable, and perform well.

You’ve been doing this for a long time, and way back in Windows NT 4.0 days you learned that disabling 8.3 name creation on NTFS volumes can speed up file system performance. In fact, there’s even a Microsoft Knowledge Base article that says this, it’s KB 121007 “How to Disable the 8.3 Name Creation on NTFS Partitions” and it clearly says:

The creation of 8.3 filenames and directories for all long filenames and directories on NTFS partitions may decrease directory enumeration performance. This article describes a method of disabling the 8.3 name creation on all NTFS partitions.

Here, you can read it for yourself.

Note that the above KB article adds a little caveat:

Although disabling 8.3 name creation increases file performance under Windows NT, some 16-bit applications may not be able to find files and directories with long filenames.

OK, forewarned is forearmed, so you’ll be sure to test any legacy 16 bit applications running on your Windows computers to make sure they still all work once you’ve disabled 8.3 name creation on them. You’ve only got a few of those 16 bit programs still kicking around, and they’re critical to the operation of your company’s business, but Microsoft has published a workaround for this issue in another KB article so no big deal, right?

[later] Whoops! What’s going on? Some strange things have been happening on your network since you disabled 8.3 name creation on some of your computers. Why?

Unfortunately disabling 8.3 name creation on Windows networks can impact a lot more than just some old 16-bit applications you still have kicking around. For example:

  • It can cause problems with batch files that expect 8.3 filenames to work and use %~s1 for expanded paths or omit quotes for names that might contain spaces.
  • It can cause issues if you use Microsoft System Center Configuration Manager 2007 to manage your environment, see this blog post for details.
  • It can cause issues with certain third-party products such as ones from McAfee, Symantec and others.

In other words, disabling 8.3 name creation can cause application compatibility issues, which can impact the reliability of your network. There may be workarounds for some of the resulting issues, but workarounds by definition tend to increase the complexity of your environment, and anytime complexity goes up manageability tends to go down (complex stuff is generally more difficult to manage than simple stuff).

So don’t disable 8.3 name creation on NTFS volumes to try and “boost performance” of the filesystem.

Tighten up permissions on %SystemDrive%

I’ve heard all kinds of “recommendations” about how to “tighten up” the default permissions (Discretionary Access Control Lists or DACLs) on the system drive (C: drive) of Windows computers to “make them more secure”. The trouble is, all that kind of advice is just bunk. It’s usually motivated not by IT but by some “auditor” or “consultant” hired by management who is trying to justify his high fees by thinking up new and exciting ways of trying to improve on the solid foundation of baseline security that Microsoft has built into its Windows platforms. But that’s just “security theater” as Jesper M. Johansson and Steve Riley termed it in their classic two-part article Security Myths:

So before you try modifying the default DACLs on your system drive, for example by removing Authenticated Users, understand that doing that is very likely going to break Windows, or at the very least render the computer unsupportable and unserviceable. So don’t do that, ever. But if you’re interested, see Figure 1 for an example of system drive DACLs on a Windows computer that is VERY secure.

Figure 1: The system drive on this Windows computer is REALLY secure!

But why do people even think about doing this sort of thing? The answer lies in the past, when organizations like the NSA used to recommend tons of specific changes to file permissions on system rives to conform to what the NSA believed a secure computer system should look like. Unfortunately, the NSA’s idea of what a secure computer looks like probably differs a lot from what the average business thinks one should look like. That’s because businesses are concerned about making money, whereas organizations like the NSA are focused on, well, you can read their mission statemen here.

But the days of the NSA providing explicit advice for ACLs on Windows file systems is far in the past. That’s because Microsoft worked closely with the NSA and industry organizations like NIST when it designed the ACLs for Windows XP. This cooperation resulted in the Federal Desktop Core Configuration (FDCC) for Windows XP, which has since evolved into the US Government Configuration Baseline (USGCB) for the Windows platform which you can learn more about from their blog. The goal of this initiative was to develop a set of baseline settings for Windows in high security environments.

Unfortunately, even this process had its hiccups along the way. For example, when Microsoft published their original Windows XP Security Baseline guidance, one of its recommendations was that Registry Editor (regedit.exe) should have its permissions modified so that ordinary users couldn’t launch the program. Why? Because it’s obvious that letting ordinary users have access to the Registry Editor was a gaping big security hole, right? Unfortunately it was soon discovered that locking down regedit.exe like this prevented Windows XP from successfully loading the user’s profile, so the guidance had to be modified to accommodate this problem (see this link for more on this story).

Fast forward today, and you’ll find that none of the big security and standards organizations like NIST, CIS, NSA, DISA, DoD and so on provide any recommendations for modifying the default security for the system drive of Windows Vista or Windows 7. That’s because almost all changes you make to the default DACLs will cause some kind of application compatibility problem on the computer. And in fact, some of the recommendations that these organizations used to make before Windows XP were actually found to loosen the security of the computer rather than tighten it.

If you do need a “more secure Windows” then be safe and confine yourself to the recommendations of the USGCB found here and don’t try to make up your own security guidance. Stick with well-known and proven solutions as Aaron Margosis describes in his blog. That way your Windows network will stay secure, reliable, manageable, and will perform well.

Summary so far

Here’s what we’ve learned so far in the first two articles of this series:

  • Want to make your Windows computers less reliable? Write directly to the registry locations where policy settings are stored!
  • Want to copy local policy settings from one computer to another in a workgroup? Xcopy the Registry.pol files, cross your fingers and hope everything still works! It won’t though, something will probably break.
  • Want to make your computers really secure? Disable a bunch of services that are configured to start automatically by default. Congratulations, your computer is now more secure but less reliable (and less usable too)!
  • Want to cause problems with some third-party applications, System Center Configuration Manager, batch files, legacy apps, and other stuff in your network? Try disabling 8.3 name creation on your system drive!
  • Want to break lots of different functionality and possibly leave your network wide open to attack? OK go ahead and modify the default permissions on the system drive of your Windows computers!

More terrific ways to wreck Windows in future articles in this series!

If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the Real time article update newsletter.

If you would like to read the first part in this article series please go to How to wreck your Windows network (Part 1).

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top