Microsoft Security Compliance Manager vs Local Security Policy (secpol.msc)

dmoore44

A few questions for some of TE's Windows Gurus...

I know that using MS Security Compliance Manager (SCM) audits a machine's local group policy against a SCM baseline...

So, my questions:

1. How does the Local Security Policy management console affect/interact with Local Group Policy?
2. Is it overly redundant to set a machine's security posture using SCM and the Local Security Policy snap-in?
3. If there are differences in the settings configured via Local GPO and Local Security Policy, what are they, and how do they affect the system?

I'm sure I'll come up with other questions, but since it's still relatively early, that's all I can think of for now...

Edit: I understand that the settings configured in secpol.msc are really just subsets of settings configured in gpedit.msc... but there must be some sort of subtle difference... For instance: In secpol.msc, if you were to read the properties of the "audit logon events" setting, you would see that there are more granular settings that can be configured via gpedit.msc. So, if I set "audit logon events" in secpol.msc to "Success, Failure" and then hop over to gpedit.msc and look at the account logon settings, the more granular settings mentioned in the "audit logon events" properties dialog from secpol.msc are shown as "not configured". What's the deal?

Claymoore

I would have to do some digging to verify all this, but I'm feeling lazy today so I won't. Feel free to verify and prove me right or wrong.

I don't believe that security settings were in the first release of group policy with Windows 2000. I think they were separate and not added to the normal GPO until Windows XP. Anyway, I was deploying applications to Win2k workstations and we regularly had to adjust file and registry permissions for the applications to run. We used local security policies to create an SDB file of our settings and applied that using the secedit command line within our packages. SDB files are still used by the Application Compatibility Toolkit to deploy shims and app compat settings today.

Group Policy is another way to edit the registry. If a setting is not surfaced in the registry, GPO can't touch it, which should explain why you have more settings in a local SDB database of settings than you do in GPO.

GPO does not edit the registry directly, instead it's settings are kept in the Policies subkey with the same registry key hierarchy underneath that subkey. This is a good thing as it prevents settings from tatooing the registry and thus allows you to turn settings 'off' later. I believe that secedit edits the registry directly. If true his would mean a few things:

1. Secedit tattoos the registry. To change a setting you must apply another SDB file rather than just disable the one you already applied.
2. GPO can't see the secedit settings as it is looking at it's database and Policies subkey, not the SDB and the actual registry key.
3. Since the settings in the Policies subkey override the settings in the normal registry keys, a GPO will override the registry settings from a local security policy SDB. It should also override the file and folder permissions as those would be a foreground refresh every time GPO is processes vs the SDB file which is applied once.

I prefer to manage everything I can using Group Policy or Group Policy Preferences. It's easy to run reports and see the settings when everything is centrally managed. If you start using local policies or local manual settings, you have to run individual audits against every workstation to see their settings.