Bypassing domain and OU GPO settings using the Security Configuration and Analysis MMC

Bypassing domain and OU GPO settings using the Security Configuration and Analysis MMC

Secure Home | Search | About
 Microsoft Applications Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Bypassing domain and OU GPO settings using the Security Configuration and Analysis MMC Spin 05-11-2008
Posted by Spin on May 11, 2008, 9:40 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Gurus,

This is a re-post of a message sent solely to the group_policy NG. I'm
copying a wider audience here to engage some discussions amongst you IT
Security Managers/security consultants out there.

Running Windows Server 2003 SP2 in a single Active Directory domain (Lab
environment). I am experimenting with the Group Policy Security database,
secedit.sdb If you run the Setup Security INF in the Security Configuration
and Analysis Snapin against this database, you will bring your system back
Windows security default settings and it will remain that way until the next
Group Policy Refresh interval. You must be an admin on the machine to do
this. My question is, isn't this a security risk in it's own right,
bypassing domain and OU GPO settings? A respondent in the Group Policy
newsgroup (Marcin) stated that if my sole goal is to prevent use of Security
Configuration and Analysis, I have ability to restrict access to arbitrarily
selected snap-ins via GPO. In addition I could restrict ability to execute
Secedit (which one can do by following
http://support.microsoft.com/kb/323525). While I agree this is a major
technical challenge, has anyone else in these other NGs I've copied on this
message ever worried about this? Or should I just let it pass?

--
Spin


Posted by Kerry Brown on May 11, 2008, 11:21 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
If you want to keep the wolf out of the henhouse then don't give him the
key. There are several ways a local administrator can get around group
policy.

--
Kerry Brown
MS-MVP - Windows Desktop Experience: Systems Administration
http://www.vistahelp.ca/phpBB2/



> Gurus,
>
> This is a re-post of a message sent solely to the group_policy NG. I'm
> copying a wider audience here to engage some discussions amongst you IT
> Security Managers/security consultants out there.
>
> Running Windows Server 2003 SP2 in a single Active Directory domain (Lab
> environment). I am experimenting with the Group Policy Security database,
> secedit.sdb If you run the Setup Security INF in the Security
> Configuration and Analysis Snapin against this database, you will bring
> your system back Windows security default settings and it will remain that
> way until the next Group Policy Refresh interval. You must be an admin on
> the machine to do this. My question is, isn't this a security risk in
> it's own right, bypassing domain and OU GPO settings? A respondent in
> the Group Policy newsgroup (Marcin) stated that if my sole goal is to
> prevent use of Security Configuration and Analysis, I have ability to
> restrict access to arbitrarily selected snap-ins via GPO. In addition I
> could restrict ability to execute Secedit (which one can do by following
> http://support.microsoft.com/kb/323525). While I agree this is a major
> technical challenge, has anyone else in these other NGs I've copied on
> this message ever worried about this? Or should I just let it pass?
>
> --
> Spin


Posted by Herb Martin on May 12, 2008, 1:25 am
If you were  Registered and logged in, you could reply and use other advanced thread options

> Gurus,
>
> This is a re-post of a message sent solely to the group_policy NG. I'm
> copying a wider audience here to engage some discussions amongst you IT
> Security Managers/security consultants out there.
>
> Running Windows Server 2003 SP2 in a single Active Directory domain (Lab
> environment). I am experimenting with the Group Policy Security database,
> secedit.sdb If you run the Setup Security INF in the Security
> Configuration and Analysis Snapin against this database, you will bring
> your system back Windows security default settings and it will remain that
> way until the next Group Policy Refresh interval. You must be an admin on
> the machine to do this. My question is, isn't this a security risk in
> it's own right, bypassing domain and OU GPO settings? A respondent in
> the Group Policy newsgroup (Marcin) stated that if my sole goal is to
> prevent use of Security Configuration and Analysis, I have ability to
> restrict access to arbitrarily selected snap-ins via GPO. In addition I
> could restrict ability to execute Secedit (which one can do by following
> http://support.microsoft.com/kb/323525). While I agree this is a major
> technical challenge, has anyone else in these other NGs I've copied on
> this message ever worried about this? Or should I just let it pass?

Moral is really "Don't make admins" who are not trustworth admins.

If you don't trust people to do the right thing, don't give them the
privilege.




Posted by Anthony [MVP] on May 12, 2008, 4:24 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Group Policy is a way of setting configurations that the OS exposes. The
client side extensions are run in the System context or the User context.
All these are available to the administrator of the machine. There is no
"third party" controlling the machine.
Secedit.sdb is just a template of settings.
I don't see a security risk in assuming the administrator has full control
of the local machine.
Anthony,
http://www.airdesk.co.uk




> Gurus,
>
> This is a re-post of a message sent solely to the group_policy NG. I'm
> copying a wider audience here to engage some discussions amongst you IT
> Security Managers/security consultants out there.
>
> Running Windows Server 2003 SP2 in a single Active Directory domain (Lab
> environment). I am experimenting with the Group Policy Security database,
> secedit.sdb If you run the Setup Security INF in the Security
> Configuration and Analysis Snapin against this database, you will bring
> your system back Windows security default settings and it will remain that
> way until the next Group Policy Refresh interval. You must be an admin on
> the machine to do this. My question is, isn't this a security risk in
> it's own right, bypassing domain and OU GPO settings? A respondent in
> the Group Policy newsgroup (Marcin) stated that if my sole goal is to
> prevent use of Security Configuration and Analysis, I have ability to
> restrict access to arbitrarily selected snap-ins via GPO. In addition I
> could restrict ability to execute Secedit (which one can do by following
> http://support.microsoft.com/kb/323525). While I agree this is a major
> technical challenge, has anyone else in these other NGs I've copied on
> this message ever worried about this? Or should I just let it pass?
>
> --
> Spin



Posted by Roger Abell [MVP] on May 13, 2008, 3:01 am
If you were  Registered and logged in, you could reply and use other advanced thread options

> Gurus,
>
> This is a re-post of a message sent solely to the group_policy NG. I'm
> copying a wider audience here to engage some discussions amongst you IT
> Security Managers/security consultants out there.
>
> Running Windows Server 2003 SP2 in a single Active Directory domain (Lab
> environment). I am experimenting with the Group Policy Security database,
> secedit.sdb If you run the Setup Security INF in the Security
> Configuration and Analysis Snapin against this database, you will bring
> your system back Windows security default settings and it will remain that
> way until the next

That setup security.inf will do that is a common belief, one that is
almost right, but not fully correct.

> Group Policy Refresh interval. You must be an admin on the machine to do
> this. My question is, isn't this a security risk in it's own right,
> bypassing domain and OU GPO settings?

What you are actually asking is:
Isn't it a security risk that people believe that group policy
will control settings such that they cannot be altered and/or
circumvented? To that I would say yes, anytime someone
running a system does not fully understand the operational
characteristics of the system, that poses a risk.
As others have said, a) it takes an admin to do what you
outline, b) it can be made more difficult to do, c) there are
many ways to change what group policy has set and those
changes will stay until group policy resets, which in some
cases can be a very long time.

Roger

> A respondent in the Group Policy newsgroup (Marcin) stated that if my sole
> goal is to prevent use of Security Configuration and Analysis, I have
> ability to restrict access to arbitrarily selected snap-ins via GPO. In
> addition I could restrict ability to execute Secedit (which one can do by
> following http://support.microsoft.com/kb/323525). While I agree this is
> a major technical challenge, has anyone else in these other NGs I've
> copied on this message ever worried about this? Or should I just let it
> pass?
>
> --
> Spin



Similar ThreadsPosted
W2k3 SP2 breaks Security Configuration and Analysis util April 7, 2007, 3:42 am
Security Configuration Editor - Custom Settings Removal August 16, 2005, 7:03 am
Security Configuration Wizard (SCW) March 1, 2007, 2:35 pm
Security Configuration Wizard December 10, 2007, 3:31 am
How to install security configuration wizard December 30, 2005, 1:37 pm
Correct Security Configuration for Mac Access to File Server March 3, 2006, 12:06 pm
User unlocking a locked account while bypassing the audit. April 24, 2006, 7:22 pm
where to upload unknown files for analysis June 29, 2006, 12:58 am
Folder Security - Finding Group or User Name in Security settings January 30, 2006, 11:09 am
Unable to Manage Security Settings in Security Center April 14, 2006, 11:14 pm

The site map in XML format XML site map

Contact Us | Privacy Policy