Incorrect (?) mismatches in Security Configuration & Analysis Tool

[Robb Kidd]

After applying some policies, in verifying their application through
the Security Configuration & Analysis Tool I get several mismatches that
I cannot explain. For example, one of my policies disables several
services. Analysis says in the log that the service policies
mismatches, in the snap-in to investigate permissions (!?!) while the
Services control panel shows that the services are indeed disabled and
not running. Other mismatches appear in the file system (IE temp files,
I believe) and in registry key permissions (mostly class stuff).
These mismatches appear even after I use the Configure feature in
the snap-in. I need to be able to explain these mismatches to the
higher ups. Any help?

 

[Steven L Umbach]

Keep in mind that you can not simply import templates into "local" security policy
that have settings other than account and password policies. For the settings you are
implementing, it is best to apply via a OU Group Policy if in a domain otherwise you
will have to use the Security Configuration and Analysis tool to configure the
template or use secedit for configuration.

Other traps may be that the "computer setting" is the effective setting that may have
more than one policy applied to it depending on how you have your domain/OU is
configured [if using one] and therefore the computer setting can be different than an
applied template if other policy is overriding that template. Also keep in mind that
if you are analyzing with the same database that the imported templates are
cumulative and the last imported template will override previously defined settings
from a prior imported template. There is the option to clear a database before adding
a template to it or you can just use a new database for the analysis.

If you apply a template at the domain/OU level, that template will not apply right
away but running secedit /refreshpolicy machine_policy /enforce on first the domain
controller and then the domain computer to have it applied on should speed things up.
If this is strictly a local non domain computer configuration, if you import a
template into a fresh database and configure it and then run an analysis against the
same database, the results should match for defined settings in that template. ---
Steve

 

[Robb Kidd]

Thanks for your response, Steven. I realize I did not give much
information in my original post. I'll rectify that below.

Keep in mind that you can not simply import templates into "local" security policy
that have settings other than account and password policies. For the settings you are
implementing, it is best to apply via a OU Group Policy if in a domain otherwise you
will have to use the Security Configuration and Analysis tool to configure the
template or use secedit for configuration.

I'm using NSA's recommended policies[1] applied to all but one of my
computers through AD Group Policy. I get these mismatches regardless of
whether the policy has been applied through a GPO or via the Security
Configuration and Analysis tool's configure option.

Other traps may be that the "computer setting" is the effective setting that may have
more than one policy applied to it depending on how you have your domain/OU is
configured [if using one] and therefore the computer setting can be different than an
applied template if other policy is overriding that template.

The OU structure and policy setup is extremely simple. The
recommended domain policy is applied to the Default Domain Policy; the
recommended policy for domain controllers is applied to the Default
Domain Controllers Policy; and I've got a single OU for workstations
that get the recommended workstation policy. The only overlaps in
policy would come from the domain policy and there are no settings there
for registry or file system permissions.
Good thinking, though.

... Also keep in mind that
if you are analyzing with the same database that the imported templates are
cumulative and the last imported template will override previously defined settings
from a prior imported template. There is the option to clear a database before adding
a template to it or you can just use a new database for the analysis.

Started with a fresh database for every run.

If you apply a template at the domain/OU level, that template will not apply right
away but running secedit /refreshpolicy machine_policy /enforce on first the domain
controller and then the domain computer to have it applied on should speed things up.

These tests were run a week or two after the policies had been
applied in AD, so I don't think it's a time lapse between application
and testing.

If this is strictly a local non domain computer configuration, if you import a
template into a fresh database and configure it and then run an analysis against the
same database, the results should match for defined settings in that template.

Oddly, I've done this and still get mismatches. One computer is
local only. The template was applied through Local Policy. A week
later, the template was imported into a fresh config/anal tool database
and an analysis run. Mismatches appeared. I used the tool to configure
the system and reran the analysis. Some mismatches went away, some
remained, chiefly the services mismatches (set to disabled, reported as
mismatched, but the services *are* disabled and not running) and
registry (class branch stuff) and file permission (IE5 cache?) mismatches.

[1] http://www.nsa.gov/snac/downloads_win2000.cfm

 

[Steven L Umbach]

Hi Robb.

I have not used those templates in particular and can't think of much else to look
into right now as you sure seem to be doing everything right, but one question. For
the services mismatch, is the mismatch in startup, permissions or both? Permissions
could be a problem I suppose if the template contained a group not on the computer. I
would be less concerned if the startup was correct, and there was an incompatibility
in permissions due to a missing group. --- Steve

Thanks for your response, Steven. I realize I did not give much
information in my original post. I'll rectify that below.

Keep in mind that you can not simply import templates into "local" security policy
that have settings other than account and password policies. For the settings you are
implementing, it is best to apply via a OU Group Policy if in a domain otherwise you
will have to use the Security Configuration and Analysis tool to configure the
template or use secedit for configuration.

I'm using NSA's recommended policies[1] applied to all but one of my
computers through AD Group Policy. I get these mismatches regardless of
whether the policy has been applied through a GPO or via the Security
Configuration and Analysis tool's configure option.

Other traps may be that the "computer setting" is the effective setting that may have
more than one policy applied to it depending on how you have your domain/OU is
configured [if using one] and therefore the computer setting can be different than an
applied template if other policy is overriding that template.

The OU structure and policy setup is extremely simple. The
recommended domain policy is applied to the Default Domain Policy; the
recommended policy for domain controllers is applied to the Default
Domain Controllers Policy; and I've got a single OU for workstations
that get the recommended workstation policy. The only overlaps in
policy would come from the domain policy and there are no settings there
for registry or file system permissions.
Good thinking, though.

... Also keep in mind that
if you are analyzing with the same database that the imported templates are
cumulative and the last imported template will override previously defined settings
from a prior imported template. There is the option to clear a database before adding
a template to it or you can just use a new database for the analysis.

Started with a fresh database for every run.

If you apply a template at the domain/OU level, that template will not apply right
away but running secedit /refreshpolicy machine_policy /enforce on first the domain
controller and then the domain computer to have it applied on should speed things

up.

These tests were run a week or two after the policies had been
applied in AD, so I don't think it's a time lapse between application
and testing.

If this is strictly a local non domain computer configuration, if you import a
template into a fresh database and configure it and then run an analysis against the
same database, the results should match for defined settings in that template.

Oddly, I've done this and still get mismatches. One computer is
local only. The template was applied through Local Policy. A week
later, the template was imported into a fresh config/anal tool database
and an analysis run. Mismatches appeared. I used the tool to configure
the system and reran the analysis. Some mismatches went away, some
remained, chiefly the services mismatches (set to disabled, reported as
mismatched, but the services *are* disabled and not running) and
registry (class branch stuff) and file permission (IE5 cache?) mismatches.

[1] http://www.nsa.gov/snac/downloads_win2000.cfm