Default Security Templates in Windows 2008

Hi, David here again. You might be familiar with Security Templates that we use in Windows 2000 and 2003. The template is sort of the master set of security settings that we apply to a server when you either set it up or configure it using the Security Configuration and Analysis tool. Here in DS we often work with customers who are troubleshooting problems with a security template they’ve applied, or who are trying to build a custom security template for the servers in their environment.

A few weeks ago, one of my coworkers asked me if we had the same functionality in Windows 2008. He was on the phone with a customer who had modified some settings and needed to restore the defaults because their applications were now not working properly.

Note: this is why we always recommend testing and more importantly documenting security changes that you make.

The answer, of course, was yes. Security templates do still exist in Windows 2008, but, as you might have guessed – they’ve changed.

If you look at a Windows 2003 server, you’re going to see a bunch of default security templates:

•    Setup Security.inf
•    DC Security.inf
•    Compatws.inf
•    Secure*.inf
•    Hisec*.inf
•    Rootsec.inf
•    …and so on

These files can be found at the following location on Windows Server 2003: %systemroot%\security\templates.

(Here’s a handy list of what those templates all do, by the way)

However, if you look at a Windows 2008 server, there are actually only 3, and only 2 of them are really used.

•    Defltbase.inf (not really used)
•    Defltsv.inf (for servers)
•    Defltdc.inf (for DCs)

These files are located at the following location on Windows Server 2008: 
%systemroot%\inf.

There are a few additional templates as well, that apply to specific upgrade/installation scenarios. For example, dcfirst.inf is applied when building the first domain controller in a forest. The main difference here is that it sets the account policy as well. However, the three I listed above are the only default templates that should ever be applied manually.

Here’s a snip of what a security template looks like:

That’s just a portion of the service settings – the templates are pretty big and affect a lot of things – user rights, service settings and permissions, file system permissions, and registry permissions, just to name a few. All those character strings you see there are SDDL strings. If you’d like to learn more about how those work, my buddy Jim wrote an excellent blog post (in two parts: Part 1 and Part 2) a little while back that shows how it all fits together.

Please note: Reapplying the default security templates to a system does have the potential to remove any custom configuration that has been performed. This can be used to resolve problems resulting from incorrect security settings, but it may also break applications that relied on the custom configuration in order to function. Please also note that this is not a panacea – custom security settings in areas that the security template doesn’t cover (such as a data volume that you create after installation) will not be rolled back by this. Proceed with caution.

If you do need to set a machine back to the default template, here’s how to do it. First, open a new MMC, and add the Security Configuration and Analysis snap-in.

The console helpfully tells you how to create a new database right there in the middle pane. When you do this, you’ll be asked to import the template you want to use initially. Start with defltsv.inf (if this is a member server) or defltdc.inf (if this is a DC). Once the template is imported, right-click, and choose Analyze Computer Now…

This is the real strength of the snap-in. It has the ability to look at the system and tell you what’s different from the template that you loaded. Often this means that you don’t have to apply the template at all – instead you can zero in on the differences to find the source of the problem. You can browse through the different areas and look for red X’s – this will tell you that something on your computer is different from the base template. Here’s an example of how it looks:

A green checkmark means we’re the same, and a red X means that we’re different. This may not always be a bad thing, so it’s important to evaluate each setting individually. Usually if you are going through this process you already have an idea of where the problem is (file system permissions, registry permissions, etc), so that will help you narrow down the number of things to look at.

Note: These settings can also be pushed through group policy, so make sure that you’re familiar with any policies applying to the computer before you start trying to apply a security template to it. You can see what policies are applied to the computer and what they’re doing by running gpresult /v from an elevated command prompt.

Ok, so you’ve gone through all of this now and you still think you need to blow the machine back to default settings – the console can do that for you. All you’d have to do is right-click, and choose Configure Computer Now…

Use this option with caution because you rolling back changes that you’ve made is not easy (you should do this after first using secedit /GenerateRollback in conjunction with the log file – see this link for more details). But once you’ve done this, your server will be back at the default settings. You’ll have to go back in afterwards and redo any changes that you needed.

For Server Core installations, or if you just like the command line, you can also accomplish all of this by using the SecEdit command-line tool.

We generally recommend using the MMC when possible, as it’s a bit easier to use and gives you a nicer way to browse through settings that may be different, but the command-line tool can do everything that the MMC snap-in can do.

The security configuration tools are pretty powerful, and in addition to everything I talked about above they give you the ability to create your own custom security templates, which you can then apply using the MMC or the SecEdit utility, or even through group policy. If you’d like to know more about any of this, there’s a fairly in-depth write up on TechNet, which you can find here.

One final bit of advice – whatever you do, make sure to test and document those changes. Here in DS, we talk to people every day that are having problems because security changes were made to their servers and those changes were never tested or documented. So if you’re careful and methodical in your approach to securing your servers, you can save yourself a lot of time and frustration down the road in your production environment, as well as make troubleshooting much easier and simpler if problems do occur.

David Beach

Comments

• Anonymous
  May 28, 2008
  PingBack from http://windows2008security.com/network-security/default-security-templates-in-windows-2008/

• Anonymous
  July 21, 2009
  Are the security Templates in 2008 in the same format as the ones in 2003. The main reason I ask is we have some templates we import into all new servers being built and we're getting ready to roll some of our first 2008 machines and I dont know if I can simply run my existing SECEDIT script using the existing Template, or not. The items we are configuring are in the following section headings: [System Access] [System Log] [Security Log] [Application Log] [Event Audit] Thanks, Dan

• Anonymous
  July 21, 2009
  Nope.  Formatting is similar but not identical.  They both use SDDL but the defaults and the various things you can manipulate are different between the two systems.  If you try to apply a 2003 template to a 2008 computer (or vice versa) you'll usually break things in bad ways. Best thing to do in this scenario is recreate the template specifically for 2008.  Tools/methods described here: http://technet.microsoft.com/en-us/library/cc754373(ws.10).aspx --David