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

  • Thread starter Thread starter Spin
  • Start date Start date
S

Spin

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
 
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/



"Spin" <Spin@invalid.com> wrote in message
news:68pld0F2u4ee4U1@mid.individual.net...
> 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
 
"Spin" <Spin@invalid.com> wrote in message
news:68pld0F2u4ee4U1@mid.individual.net...
> 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.
 
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




"Spin" <Spin@invalid.com> wrote in message
news:68pld0F2u4ee4U1@mid.individual.net...
> 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
 
"Spin" <Spin@invalid.com> wrote in message
news:68pld0F2u4ee4U1@mid.individual.net...
> 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
 
Like the others said the moment you give someone enough rights they can do
whatever they want.

But I wonder why one would go through all the trouble to disable the GPO as
you've described it. Isn't it much simpler to download the KillPol tool from
my site, and simply enter the right administrative username and password?
Running the tool again will bring back the GPO. Quite useful for
troubleshooting and management scenarios.

www.petri.co.il/killpol.htm

Daniel Petri
www.petri.co.il



"Spin" <Spin@invalid.com> wrote in message
news:68pld0F2u4ee4U1@mid.individual.net...
> 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
 
"Daniel Petri" <daniel@petri.co.il.removeme> wrote in message
news:%23vAz6JPtIHA.2292@TK2MSFTNGP03.phx.gbl...
> Like the others said the moment you give someone enough rights they can do
> whatever they want.
>
> But I wonder why one would go through all the trouble to disable the GPO
> as you've described it. Isn't it much simpler to download the KillPol tool
> from my site, and simply enter the right administrative username and
> password? Running the tool again will bring back the GPO. Quite useful for
> troubleshooting and management scenarios.
>
> www.petri.co.il/killpol.htm

Daniel I just tried Kilpol.exe from your web site and while it looked
promising, after I executed it, I immediately ran another RSOP.msc and all
of the customized domain policies were showing still in place. What am I
doing wrong?
 
Because RSOP sees that last applied policy, not what is applied at that
given moment.

Try disabling something visible, you'll see KillPol works...


--
Daniel Petri
www.petri.co.il



"Spin" <Spin@invalid.com> wrote in message
news:690tajF2vak5gU1@mid.individual.net...
> "Daniel Petri" <daniel@petri.co.il.removeme> wrote in message
> news:%23vAz6JPtIHA.2292@TK2MSFTNGP03.phx.gbl...
>> Like the others said the moment you give someone enough rights they can
>> do whatever they want.
>>
>> But I wonder why one would go through all the trouble to disable the GPO
>> as you've described it. Isn't it much simpler to download the KillPol
>> tool from my site, and simply enter the right administrative username and
>> password? Running the tool again will bring back the GPO. Quite useful
>> for troubleshooting and management scenarios.
>>
>> www.petri.co.il/killpol.htm
>
> Daniel I just tried Kilpol.exe from your web site and while it looked
> promising, after I executed it, I immediately ran another RSOP.msc and all
> of the customized domain policies were showing still in place. What am I
> doing wrong?
>
>
 
Back
Top