Not Defined vs. Disabled Security Settings

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

If security options settings are left as "not defined", how does that differ
from "disabled"? For example, if the setting "Devices: Restrict CD_ROM
access....." is left not defined what state is it in?

If you do not want a setting to be active is it ok to leave it not defined
or should you specifically set it to "disabled"?
 
SecAdmin said:
If security options settings are left as "not defined", how does that differ
from "disabled"? For example, if the setting "Devices: Restrict CD_ROM
access....." is left not defined what state is it in?
Click to expand...

The default state (in this case unrestricted) OR
the state of any previous GPO which would set it.

If you do not want a setting to be active is it ok to leave it not defined
or should you specifically set it to "disabled"?
Click to expand...

In other words the difference between "not defined"
and "disable" is QUITE striking since disabled means
this setting will NOT be the case (i.e., the negative
will be the case), but "not defined" says NOTHING
about the state (i.e., it is left unchanged from what it
was before the policy was processed.)

There also are difference in a "No override" policy
since with "not defined" there is nothing to override
and subsequent policies may change this setting (either
way.)
 
Not defined can be dangerous for security options. There is a default
setting for undefined but if a policy had been previously applied and then
set back to undefined you can have unpredictable results and undefined may
not longer mean the default setting. If you want a security option to be
either enabled or disabled then configure it exactly the way you want it. It
is also a good idea to use the Security Configuration and Analysis mmc
snapin tool to check for security settings against a template such as setup
security.inf to see what it reports with an analysis compared to what you
expect. The various free Microsoft security guides can be very helpful when
looking for information on security options such as the Windows 2000
Security Hardening Guide available at the link below. --- Steve

http://www.microsoft.com/technet/security/prodtech/windows2000/win2khg/05sconfg.mspx
 
Steven L Umbach said:
Not defined can be dangerous for security options. There is a default
setting for undefined but if a policy had been previously applied and then
set back to undefined you can have unpredictable results and undefined may
not longer mean the default setting.
Click to expand...

While what Steven says it true, 'undefined' may be very
useful too (the vast majority of GPO setting may remained
undefined).

Undefined just means THIS GPO will not make a change
(or enforce a setting) either way.
If you want a security option to be
either enabled or disabled then configure it exactly the way you want it.
Click to expand...

Exactly, but if you are setting it from another GPO
there is no reason to ALWAYS set the same options
since it is common to divide up GPOs by the general
"purpose" of that GPO and there may be many items
you just don't care about -- or at least not at the "level"
(Site, Domain, OU) or in that GPO.
It
is also a good idea to use the Security Configuration and Analysis mmc
snapin tool to check for security settings against a template such as setup
security.inf to see what it reports with an analysis compared to what you
expect.
Click to expand...

Good advice too.
The various free Microsoft security guides can be very helpful when
looking for information on security options such as the Windows 2000
Security Hardening Guide available at the link below. --- Steve
Click to expand...

http://www.microsoft.com/technet/security/prodtech/windows2000/win2khg/05sconfg.mspx
 
I certainly don't propose that a user needs to define all settings in a
Group Policy. That would be a huge headache to say the least. I was
specifically referring to security options which are mostly defined already
in Local Security Policy and can cause a lot of problems if incompatible
settings are unintentiallly configured. The administrative templates
settings in Group Policy are usually very good about reverting back to what
they are supposed to be as explained in the setting description when set
back to undefined . --- Steve
 
Steven L Umbach said:
I certainly don't propose that a user needs to define all settings in a
Group Policy. That would be a huge headache to say the least. I was
specifically referring to security options which are mostly defined already
in Local Security Policy and can cause a lot of problems if incompatible
settings are unintentiallly configured.
Click to expand...

Thus the reason for leaving them undefined
in all but those policies where you are explicitly
changing OR overiding them.
 
Back
Top