Udostępnij za pośrednictwem

Configuration Drift

  • Artykuł

 

 

In my last blog I introduced a new Solution Accelerator called the Security Compliance Management toolkit. Today I'd like to help you learn more about this new Accelerator, but in a somewhat indirect way—by discussing a problem space known as configuration drift.

 

Probably the simplest way to understand configuration drift is to think about those servers in your server room that have been configured with local settings. To illustrate the problem space, let's consider the need to manage a server that requires a custom setting, such as the right to log on locally.

By default, Windows Server 2003 assigns the ability to log on locally as follows:

  • Administrators - Permit
  • Server Operators - Permit
  • Backup Operators - Permit

 

This is a good representation of who should be able to log on locally to a server. In fact, this configuration is recommended by the Windows Server 2003 Security Guide as one that should be enforced using Group Policy.

 

The need to restrict which users can access a server locally is a good security measure. However, it can be inconvenient in certain situations—for example, when a server requires service and a non-administrator user needs to perform that service. Typically, one of the following two quick solutions is used:

 

  • Add the user to the Administrators group temporarily, and 'trust' the user will not abuse their new power.
  • Create a group for non-Administrator users and assign this group the right to logon locally to the server.

 

Both are poor methods for managing local access to a server—but both are excellent examples of configuration drift.

 

So the question is how will you manage one-off changes like this? Also, how can you discover and identify changes that have occurred in a network that may not follow policy?

 

It's simple to correct a change in one system. However, how can you validate your systems' configurations, and then update or correct any ad-hoc changes that were made? The problem is complex, and difficult to resolve. However, for those of you using System Center Configuration Manager 2007, a feature known as Desired Configuration Manager (DCM) can be used to discover your network's configuration state. Configuration Packs that work with Configuration Manager were designed by the Solution Accelerators – Security and Compliance team (SA-SC), and you can use these Packs to check the configurations for the Windows XP, Windows Vista, and Windows Server 2003 computers in your network.

 

The one thing that's needed to accomplish such a check is a set of desired configuration values. SA-SC considered this a vital requirement for DCM. When they looked at the security knowledge within the different security guides that they created, it was clear that translating this knowledge to DCM configuration items would be of great value for IT professionals.

 

In upcoming blogs I'll look more closely at DCM, the required components for exploring configuration drift, and how this can be done effectively for a network. For now, if you haven't looked at the Security Compliance Management toolkit I recommend you take a few minutes to see if it can help you manage configuration drift in your organization.

https://go.microsoft.com/?linkid=9040607

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://ntoolz.net/blog/2008/07/13/windows-security/configuration-drift/

  • Anonymous
    January 01, 2003
    Excellent blogs/info/tools!  Kudos for making our enterprises more manageable.   Is there a timeframe that we can expect Reporting for DCM Config Baselines/Config Items?   Something similar to the GPO Reports from GPMC would be superb.  Thanks!