Efficient Active Directory Security Design | Professional Windows Desktop and Server Hardening (Programmer to Programmer)

There is an art and a science to effective Active Directory security design. Here are the ideas:

Use role-based security.
Create a role-based OU structure.
Create and use a one-time security template on all computers.
Create and use a Local Computer Policy.
Create and use a Baseline Security Policy for the domain.
Create and use a role-based Incremental Security Policy.
Name GPOs with version numbers.

The following sections cover each of these in more detail.

Use Role-Based Security

Using Role-Based Access Control (RBAC) means creating an Active Directory infrastructure that reflects the operational roles of the environment. Ultimately, the most secure security design is one that follows the principle of least privilege. No user or computer should have more rights than is necessary to do the authorized job. In order to accomplish this, the Active Directory OU structure must be role-based.

Most administrators use groups to manage their security permissions. Some readers might think that role-based security and groups are the same. Groups are normally departments (e.g., IT, Admin, HR, Accounting, etc.). Role-based security takes those same groups and breaks them down further into each employee's functional role (i.e., for the IT department, you might have IT Admin, Help Desk, Network Technician, Programmer, etc.). Ideally, you would want a separate OU (and eventually GPO and security template) for each employee role or position. This may sound like overkill at first, but in reality this is what all administrators should have been doing all along. Anything less than this was ineffective security or security managed to the most common denominator (not least privilege).

Create a Role-Based OU Structure

Once role-based groups are created, it's time to create a role-based OU structure to support the role-based security templates and GPOs. Because GPOs are applied to computers and users, the top OU structure must first reflect this branch in the tree. If this step is skipped, it can easily lead to poor GPO performance. The top-level OUs are often named with the word Computers and Users in the name, but they cannot just be Computers and Users, because those are existing containers, which cannot be linked to GPOs. Instead, choose something easy like ContosoUsers and ContosoComputers.

The computer branch should be divided into Domain Controllers (which already exists and should be left alone) and Member Servers (i.e., non-DCs). The Member Servers node should be broken down into all the different roles that a server computer fulfills in the environment. Figure 15-14 shows example roles under the top parent Computer OU, including Web Servers, File Servers, Print Servers, DNS Servers, Exchange Servers, OWA Servers, SQL Servers, Multi-purpose Servers, etc.

image from book
Figure 15-14

A more filled-out role-based Active Directory infrastructure would look something like Figure 15-15.

image from book
Figure 15-15

Create and Use a One-Time Security Template on All Computers

Think of every possible default security setting, using the previous chapter's recommendations as your guide. For example, from Chapter 5, "Protecting High-Risk Files," create a list of every default installed file that you don't want non-admins to execute. From Chapter 11, "Protecting E-mail," create a list of every file type that should be blocked by default. The idea is to create a detailed list of what is and isn't allowed to run on each PC, develop a security policy from the results, and then implement it using a security template on every PC in your environment.

This is a high bang-for-the-buck proposition. By creating a one-time security template that is applied to all PCs, every Windows workstation, server, and laptop in your environment will be set to the same common default security settings. No need to guess what the baseline is; you've got it documented and applied. Apply it only once, or re-apply once a year or at some other set interval. And because the settings are applied once and tattoo the registry, the hundreds of applied security settings do not slow down the PC, as would a GPO or Local Computer Policy.

Create and Use a Local Computer Policy

Then create and use a Local Computer Policy that reapplies medium to critical computer settings each time the PC starts or the user logs in. If the one-time security template applied hundreds of settings, the local computer policy applies less than a hundred. For example, if the one-time security template blocked 120 different file types, the Local Computer Policy would only block those file types most likely to be seen during the year that you don't want to see executed. The file block list would contain perhaps a dozen or two file types.

Note

A Local Computer Policy is also instrumental in making sure a policy is applied if a domain controller can't be found.

Create and Use a Baseline Security Policy for the Domain

Create two baseline security templates and GPOs: one for the custom top-level Computers OU and one for the custom Users OU. It should contain shared default settings and critical security settings that should be re-applied frequently across a wide swath of users and computers. You want the top-level policies to frequently protect against the biggest threats. For example, the Local Computer Policy re-applied 1-2 dozen file types. The top-level domain policies should block less than a dozen file types — only the ones most likely to affect your users. And if a new file type starts to be used maliciously, add it (for the duration of the biggest threat period) to the domain policy. The other hundred file types have already been blocked by the one-time security template and Local Computer Policy; we're just using a domain-level GPO to make sure the highest-risk stuff is blocked.

Create and Use a Role-Based Incremental Security Policy

Role-based incremental OUs, GPOs, and security templates should be created. The incremental policies should be applied to the role-based OUs and contain settings specific to each computer and user role, plus apply settings to prevent specific threats that might compromise a specific role. For example, don't allow, by default, the IIS or World Wide Web service to be started on normal workstations. Enforce the use of the Enhanced Security Configuration application on W2K3 servers with Internet Explorer. Using Software Restriction Policies, prevent Outlook Express, Outlook, and Microsoft Office from being installed or activated on your servers. Require smart cards for remote admin logons. The idea is to put in a smaller subset of role-based security settings, probably around one to three dozen settings, that will make specific types of users and computers more secure.

Name GPOs with Version Numbers

Lastly, name each of your GPOs with a version number (see Figure 15-16). Every time you modify a GPO, update the version number. This makes troubleshooting GPOs significantly easier. When checking whether a particular computer or user has had the latest GPO applied, run Gpresult.exe or RSoP and verify the version number.

image from book
Figure 15-16

Design Summary

Here are the steps for designing and deploying an effective Active Directory security policy:

Create and apply locally (using Secedit.exe or the Security Configuration and Analysis console) an extensive one-time security template to all new and existing PCs. Re-apply annually or when needed.
Create two top-level OUs, one called XComputers and one called XUsers (e.g., ContosoComputers and ContosoUsers).
Create baseline GPO, with critical security settings enabled, for top two GPOs.
Create role-based sub-OUs under each parent OU (e.g., File Servers, MemberServers, Web Servers, Exchange Servers, and Remote Laptops, etc., under ContosoComputers; and Executives, IT, HR, and Accounting under ContosoUsers).
Create sub-OUs under each parent group (e.g., IT Admin, HelpDesk, Network Techs, etc. under IT).
Create role-based incremental GPOs to support role-based OU structure.
Create baseline and role-based security templates to support baseline and role-based OU structure.
Import the appropriate baseline and role-based security templates into the appropriate baseline and role-based GPOs.
Link the appropriate baseline and role-based GPOs with the baseline and role-based OUs (see Figure 15-17).
Import baseline and appropriate role-based security templates into the computer's Local Computer Policy.

image from book
Figure 15-17

Figure 15-18 summaries the various parts and criticalities of the Active Directory objects. If done thoughtfully, this method will apply a very effective and efficient security policy with minimal performance delay.

image from book
Figure 15-18

If you already have an existing Active Directory infrastructure that looks nothing like a role-based model, don't panic. A role-based model is the best way to secure a Windows network, but it doesn't have to be implemented in totality immediately. As long as you understand the concept and strengths of role-based security, and how all the various pieces fit together, you can move your organization's existing infrastructure closer to a role-based one with everything that you do. The change can be gradual, but with each move your infrastructure gets stronger and your security better.