I have had the privilege of contributing to several projects where the clients were required to meet very strict compliance guidelines, and my role was to develop solutions using Active Directory and Group Policy. After recently witnessing a colleague struggle with the same task I felt compelled to share my experience. This paper deals specifically with enforcing security compliance on servers. The same principals are relevant to enforcing security compliance on workstations.

Changes to a production environment

Any change to a production environment without proper testing can have a disastrous effect. One morning I was cornered by a department head who insisted that I put a Group Policy into production immediately. It had not been tested and contained a custom administrative template that defined where Domain Controllers would sync their time (Windows 2000 didn't have this GPO setting native). I tried to explain how Kerberos could be affected and the entire network of 100 thousand users could crash. Well, I applied the policy and the ADM worked, but what if it hadn't? This is why in a production environment it is imperative, in my opinion, to observe several phases: 

1. Design
2. Proof of Concept (lab)
3. Pilot
4. Implementation

In a new environment soon to be production security compliance planning and lab testing should have already been completed. I have witnessed engineers use a new environment as a test bed and it's a bad idea. 

Start with a healthy Active Directory

One of my AD security projects was a production environment having locations all over the world. They had been trying to implement a compliance GPO for quite some time without success. When I arrived it didn't take long to discover they had serious AD infrastructure problems including improperly configured DNS, replication, Group Policy processing (or lack of it), and numerous errors in event logs containing cryptic details. After about two weeks of troubleshooting and getting approval to implement changes everything was running like clockwork, but a sick AD is the reason their in-house staff stumbled. 

Order of Group Policy Processing

When a computer is started or reaches the Group Policy refresh interval various settings are applied depending on where the Group Policies are linked in the OU structure. For any setting the last policy processed has the valid configuration, with certain exceptions. The order in which policies are processed is:

1. Local
2. Site
3. Domain
4. OU (top level down)

Even though local policy is superseded by Group Policy, it's a good practice to have one configured that mirrors the Baseline or "Compliance" Group Policy (discussed later). In the event the network goes down or the server is physically taken off the network it will still be secure. 

OU Structure

Given the order of processing, the mandate to meet compliance, and the specific services and account permissions different applications require, the strategy calls for an OU structure that allows for a granular application of Group Policy.

Using this OU structure as an example we can link the Baseline Group Policy that meets the compliance requirement to the Servers OU. Other GPOs that loosen restrictions and contain specific services and permissions can be linked to the appropriate child OU. 

Group Policies

Defining the Baseline Group Policy settings will depend on the compliance required. Guidelines for compliance can usually be provided by the organization's security team since they will likely run security validation scans before you’re finished. Predefined security templates are a good foundation on which to build, and in some cases may be all that is required. Microsoft's Windows 2000 Security Guide and Threat and Countermeasure Guide are also useful resources. I would be remiss if I didn’t mention Microsoft Security Compliance Manager and Baseline Templates for various Microsoft server applications. I am currently reviewing these tools and plan to post a review in the near future. 

Defining the Group Policy settings to loosen restrictions for an application is where it can get tricky. Applications require services and account permissions that can be easily identified using the install guide. The difficulty arises because the baseline Group Policy has so many settings defined that one or more settings may cause the application to break. Tweaking the Group Policy may have to be a trial and error process until the settings are identified and application works. Some of the settings that I have seen break apps are:

• Network security: Minimum session security for NTLM SSP based (including secure RPC) clients
• Network security: Minimum session security for NTLM SSP based (including secure RPC) servers
• Microsoft network server: Digitally sign communications (always)
• Microsoft network server: Digitally sign communications (if client agrees)

Lab testing by the stakeholder or someone knowledgeable of the application should be performed to determine of the app is functioning at 100% or has problems. Once lab testing has been validated the policies can be filtered on pilot servers and finally put into production.