| Author | Messages | |
y2k
Posts:28
 | | 02/09/2010 11:01 PM |
| Hi All
I'm trying to delegate permissions to a group to be able to modify
existing GPO objects but not create new ones. I went to the System >
Policies in ADUC (advanced view) and modified the permissions on it
to go give that group full control to all groupPolicyContainer
objects. But the permissions never flowed down to the GPO objects.
After alot of looking, I realized that all of our GPO's (there's over
250 of them) have the "allow inheritable permissions ..." check box
turned off. This is normal ? And if not, does anybody have any ideas
what can cause this ? For example, changing the security scope of a
policy perhaps ?
Thanks in advance
M
| | | |
| dmarelia
Posts:394
| | 02/10/2010 12:31 AM |
| Martin-
First off--very bad to try and modify GP permissions this way. Just modifying the ACLs on the GPC does not cover the GPT part of the GPO and ends up creating all kinds of messes. You need to use GPMC or its APIs to do this. So, also to answer your question, yes, GPCs don't inherit permissions by default. This allows you to have different delegation on each GPO, if desired.
So the "right" way to do this is to use GPMC to modify delegation on existing GPOs, and then, if you want to modify the rights that are applied to all GPOs going forward, you need to follow the instructions in this article:
http://support.microsoft.com/kb/321476
Darren
-----Original Message-----
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of martin
Sent: Tuesday, February 09, 2010 3:01 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] GPO inherited permissions
Hi All
I'm trying to delegate permissions to a group to be able to modify
existing GPO objects but not create new ones. I went to the System >
Policies in ADUC (advanced view) and modified the permissions on it
to go give that group full control to all groupPolicyContainer
objects. But the permissions never flowed down to the GPO objects.
After alot of looking, I realized that all of our GPO's (there's over
250 of them) have the "allow inheritable permissions ..." check box
turned off. This is normal ? And if not, does anybody have any ideas
what can cause this ? For example, changing the security scope of a
policy perhaps ?
Thanks in advance
M
| | | |
| y2k
Posts:28
| | 02/12/2010 4:49 PM |
| Hi Darren
Thanks for the info. Yea, after I done that, I done a bit more
investigations and discovered that if I turn on the "allow inheritable
permissions ... " checkbox and then click the "Default" button, it
reverts back to having the check box turned off again. Also, when I
modified the permissions to a test GPO object, and tried to edit it,
it said the permissions were inconsistent with SYSVOL ... which did
kind of get me thinking that maybe I wasn't taking quiet the right
route :-)
Anyway, thanks again for the clarification, much apprecaited
M
| | | |
| jeromelcruz
Posts:120
| | 02/12/2010 4:49 PM |
| Martin,
If you have a few GPOs, just go each GPO's Delegation tab and add the group to the GPO with Edit rights. If you have a lot pre-existing GPOs (say 20 or more) for which you want that group to have Edit rights for, then you might want to use a script. Microsoft has a set of downloadable GPMC scripts at:
http://www.microsoft.com/downloads/details.aspx?familyid=38c1a89b-a6d2-4f2a-a944-9236999aee65&displaylang=en
One script in particular may be of use when granting the group 'Edit' rights to many GPOs:
Grant Permissions for all GPOs in a Domain
==========================================
The GrantPermissionOnAllGPOs.wsf sample takes a particular domain and grants a user or group the specified level of permission for all GPOs in that domain regardless if those GPOs are linked to an OU or not. Use the Permission switch to specify a permission level of 'Read', 'Apply', 'Edit', 'FullEdit', or 'None' for the security principal specified in the GroupName parameter. Using the Replace switch removes existing permissions for the group or user before making the change. If a group or user is already granted a permission type higher than the new permission type, and you do not specify Replace, no change is made. For example, if the new permission type is 'Edit' and the user already has 'Full Edit', if you do not use the Replace switch, no change is made to the permissions granted to that group or user.
Usage: GrantPermissionOnAllGPOs.wsf <Group Name> /Permission: <Permission Level> [/Replace] [/Domain:<DNSDomainName>]
Example: GrantPermissionOnAllGPOs.wsf "Marketing Group Admins"/Permission:FullEdit /Replace
Example: GrantPermissionOnAllGPOs.wsf TestUser /Permission:Read
Two other scripts that may be of some use are:
Setting GPO Permissions
=======================
The SetGPOPermissions.wsf sample takes a GPO name or GPO ID, group or user name, and permission level and grants that level of permission on the GPO. Use the Permission switch to specify a permission level of 'Read', 'Apply', 'Edit', 'FullEdit', or 'None' for the security principal specified in the GroupName parameter. Using the Replace switch removes existing permissions for the group or user before making the change. Otherwise, the script ensures that the group or user has at least the permission level specified.
Usage: SetGPOPermissions.wsf:<GPOName><GroupName> /Permission:<PermissionLevel> [/Replace] [/Domain:<DNSDomainName>]
Example: SetGPOPermissions.wsf TestGPO TestGroup /Permission:Edit
Example: SetGPOPermissions.wsf TestGPO TestGroup /Permission:Edit
Example: SetGPOPermission.wsf {73624CC9-E8F2-4F05-88D2-193FAE8773CE}TestUser /Permission:FullEdit /Replace /Domain:testdomain.mycompany.com
Setting Permissions for All GPOs Linked to a Scope of Management
=================================================================
The SetGPOPermissionsBySOM.wsf sample takes a particular SOM (site, domain, OU) and grants a user or group the specified level of permission for all GPOs that are linked to that SOM. Use the Permission switch to specify a permission level of 'Read', 'Apply', 'Edit', 'FullEdit', or 'None' for the security principal specified in the GroupName parameter. Using the Replace switch removes existing permissions for the group or user before making the change. If a group or user is already granted a permission type higher than the new permission type, and you do not specify Replace, no change is made. For example, if the new permission type is 'Edit' and the user already has 'Full Edit', if you do not use the Replace switch, no change is made to the permissions granted to that group or user. Using the Recursive switch applies the change to all OUs that are children of the given SOM.
Usage: SetGPOPermissionsBySOM.wsf <SOM Name> <Group Name> /Permission: <PermissionLevel> [/Recursive] [/Replace] [/Domain:<DNSDomainName>]
Example: SetGPOPermissionsBySOM.wsf "Marketing Group Admins" "Marketing Group" /Permission:FullEdit /Recursive
Example: SetGPOPermissionsBySOM.wsf MarketingOU TestUser /Permission:Read /Replace
Good Luck,
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
-----Original Message-----
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Tuesday, February 09, 2010 4:26 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] GPO inherited permissions
Martin-
First off--very bad to try and modify GP permissions this way. Just modifying the ACLs on the GPC does not cover the GPT part of the GPO and ends up creating all kinds of messes. You need to use GPMC or its APIs to do this. So, also to answer your question, yes, GPCs don't inherit permissions by default. This allows you to have different delegation on each GPO, if desired.
So the "right" way to do this is to use GPMC to modify delegation on existing GPOs, and then, if you want to modify the rights that are applied to all GPOs going forward, you need to follow the instructions in this article:
http://support.microsoft.com/kb/321476
Darren
-----Original Message-----
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of martin
Sent: Tuesday, February 09, 2010 3:01 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] GPO inherited permissions
Hi All
I'm trying to delegate permissions to a group to be able to modify
existing GPO objects but not create new ones. I went to the System >
Policies in ADUC (advanced view) and modified the permissions on it
to go give that group full control to all groupPolicyContainer
objects. But the permissions never flowed down to the GPO objects.
After alot of looking, I realized that all of our GPO's (there's over
250 of them) have the "allow inheritable permissions ..." check box
turned off. This is normal ? And if not, does anybody have any ideas
what can cause this ? For example, changing the security scope of a
policy perhaps ?
Thanks in advance
M
| | | |
| y2k
Posts:28
| | 02/13/2010 9:51 AM |
| Thanks for the link Jerome, I've already started looking at the
scripts that come with GPMC, but the above will be useful too, so
thanks
Regarding changing the default permissions for new GPO's, can either
of you advise me on a few things ?
1. I know that this is a schema change, and therefore will initiate a
full replication of the entire schema. I've never done schema changes
before except for using adprep a few times, but that was a long time
ago. Are there any recommended dos/don'ts when making schema changes
? I know that I should ideally make the change on the schema master,
but are there any other recommendations ? eg, should I ensure all my
DC's are at the same patch level ? Should I ensure they all have the
very latest patches ? Should I make the change on friday night so
that it can replicate easily over the WAN without any additional user
traffic being present ?
2. I've got the basic jist of what I need to do to give my extra
group permissions, but is there a link anywhere that explains what
everything in the string stands for ?
Thanks again !
M
| | | |
| dmarelia
Posts:394
| | 02/13/2010 6:16 PM |
| Hi Martin-
Actually, this is not a schema change in the sense you're thinking of. You're thinking of a schema change where you extend the schema by adding new classes and attributes. In that case, all the rules you mention below apply. However, this is a change to the schema instance running in your live forest. Not the actual schema. So, its actually no different than changing an attribute on a user object.
As for understanding SDDL, I like Jorge's article here:
http://blogs.dirteam.com/blogs/jorge/archive/2008/03/26/parsing-sddl-strings.aspx
Darren
-----Original Message-----
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of martin
Sent: Saturday, February 13, 2010 1:50 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] GPO inherited permissions
Thanks for the link Jerome, I've already started looking at the
scripts that come with GPMC, but the above will be useful too, so
thanks
Regarding changing the default permissions for new GPO's, can either
of you advise me on a few things ?
1. I know that this is a schema change, and therefore will initiate a
full replication of the entire schema. I've never done schema changes
before except for using adprep a few times, but that was a long time
ago. Are there any recommended dos/don'ts when making schema changes
? I know that I should ideally make the change on the schema master,
but are there any other recommendations ? eg, should I ensure all my
DC's are at the same patch level ? Should I ensure they all have the
very latest patches ? Should I make the change on friday night so
that it can replicate easily over the WAN without any additional user
traffic being present ?
2. I've got the basic jist of what I need to do to give my extra
group permissions, but is there a link anywhere that explains what
everything in the string stands for ?
Thanks again !
M
| | | |
| y2k
Posts:28
| | 02/14/2010 12:45 PM |
| Hi Darren
Thanks for the link and the info. What you said makes sense because
like you said, I won't be extending the schema. However, the original
link you posted (http://support.microsoft.com/kb/321476) says that it
will iniitate a full replication to all GC's in the forest (second
line, paragraph 2 under "more information")
Am I mis-interpreting what they're trying to say ?
Thanks again !
M
| | | |
|
|