Please be gentle with me. I'm new to Group Policies. I thought I was
following some cookbook instructions; and somehow, I've screwed them up
badly. Also, sorry that this description is kinda long...

The set-up instructions amounted to this (identifying details altered):

----------------------------------------------------------------

In Programs/Administrative Services, open Active Directory User and
Computers. Right click the domain name and choose Properties. On the
Properties screen, select the Group Policy tab.

Create a new Group Policy for each set of policies you want to enforce. Give
one the name XXX, one YYY, one ZZZ, and one AAA. Open the properties of the
new Group Policy and open the Security tab. Add the logon to which the group
policy applies. For example, for the x machines select the X logon and press
Add. Uncheck every option for this user except the one that says Apply Group
Policy.

XXX will contain the logon X, and so on.

Now 'Edit' the Group Policy. It will open a Management Console that shows
all of the options you can select. It shows you all of the control options
arrange hierarchically by topic. All of the options show as “Not configured”
when you create the policy. Double click each option that you want and select
“Enabled”. Once you do this, the Group Policy is set up.

Options to Use: (There follows a number of specific policies set under
Administrative Templates in the Group Editor.)

----------------------------------------------------------------

OK, I thought that was all pretty clear, so I set up four users -- call them
x, y, z, and a -- and four domain policies XXX, YYY, ZZZ, and AAA. And I
added each user to its matching group, and selected a set of restrictions for
each one. I can go into details on the restrictions if it matters, but they
included disabling the Task Bar context menu and disabling the Control Panel.
I did all this work from the Domain Controller console, logged in under the
Domain Administrator account.

Now I'm a security novice, so it made no sense to me that after I made these
changes, when I logged into a workstation as the Domain Controller, I had no
Task bar context menu and no Control Panel. I thought the reason I created
specific users in specific groups was to apply those restrictions to those
users. I didn't expect the Domain Administrator to be in those restricted
groups. But since I had followed the cookbook instructions, I decided that
must be the right behavior.

Then a supervisor tried to work on the workstation as Domain Administrator,
and he told me that was NOT what they expected. I explained that I didn't
know how it happened, and he said, "Oh, you probably need to remove the
Administrator from those Groups."

So I looked and checked, and yes, the Domain Administrator was in each of
the new Groups. So I removed it from all of them. I think I may have removed
some other sort as well: Enterprise Administrator, does that sound right? But
the restrictions were still there. I decided I must've followed the cookbook
incorrectly, and that it was probably a good idea to just delete the Groups
entirely until the guru gets back from break. And when the delete dialog came
up, I clicked the radio button for "Only delete from the list, but keep
around." I hoped that the guru -- not due back until Monday at the earliest
-- would have a simple magic answer, and I could retrieve these Groups that
had all the right policy restrictions already.

After deleting them, the Domain Administrator had full permissions on the
workstations again, which is good; but the problem that I've created is this:
I can no longer edit those hidden Groups, and I can't REALLY delete them now,
either. When I'm logged in at the Domain Controller console under the Domain
Administrator account, those options are just grayed out. When I try some
options that aren't grayed out, such as deleting them by hitting the DELETE
key from the list, I get a dialog saying, "Access denied."

So... Does anyone have a guess what I did wrong? And more important, does
anyone have any idea what I can do to fix this? I thought the whole point of
Domain Administrator was that that account can do ANYTHING.

Thanks in advance for any ideas or suggestions!

--
Martin L. Shoemaker
Microsoft MVP: Visual C#

I've tested deleting groups and I can't find a similar radio button to
remove from the list but not really delete...

If it's still there, you would be able to see it with ldp.exe or
adsiedit.msc, but that's like sending someone into the Registry of every
machine on the network. You may not want to poke around inside the Active
Directory too much...

I would be happy to help on Monday afternoon if you don't have a resolution
by then, but I'll be mostly offline this weekend.

--

Mike Shepperd
Sunfire Solutions LLC
Seattle, WA

[This posting is provided AS-IS, with no warranties and confers no rights]


"Martin L. Shoemaker" <(E-Mail Removed)> wrote in
message news:824400ED-E84B-461B-AF53-(E-Mail Removed)...
> Please be gentle with me. I'm new to Group Policies. I thought I was
> following some cookbook instructions; and somehow, I've screwed them up
> badly. Also, sorry that this description is kinda long...
>
> The set-up instructions amounted to this (identifying details altered):
>
> ----------------------------------------------------------------
>
> In Programs/Administrative Services, open Active Directory User and
> Computers. Right click the domain name and choose Properties. On the
> Properties screen, select the Group Policy tab.
>
> Create a new Group Policy for each set of policies you want to enforce.
> Give
> one the name XXX, one YYY, one ZZZ, and one AAA. Open the properties of
> the
> new Group Policy and open the Security tab. Add the logon to which the
> group
> policy applies. For example, for the x machines select the X logon and
> press
> Add. Uncheck every option for this user except the one that says Apply
> Group
> Policy.
>
> XXX will contain the logon X, and so on.
>
> Now 'Edit' the Group Policy. It will open a Management Console that shows
> all of the options you can select. It shows you all of the control options
> arrange hierarchically by topic. All of the options show as “Not
> configured”
> when you create the policy. Double click each option that you want and
> select
> “Enabled”. Once you do this, the Group Policy is set up.
>
> Options to Use: (There follows a number of specific policies set under
> Administrative Templates in the Group Editor.)
>
> ----------------------------------------------------------------
>
> OK, I thought that was all pretty clear, so I set up four users -- call
> them
> x, y, z, and a -- and four domain policies XXX, YYY, ZZZ, and AAA. And I
> added each user to its matching group, and selected a set of restrictions
> for
> each one. I can go into details on the restrictions if it matters, but
> they
> included disabling the Task Bar context menu and disabling the Control
> Panel.
> I did all this work from the Domain Controller console, logged in under
> the
> Domain Administrator account.
>
> Now I'm a security novice, so it made no sense to me that after I made
> these
> changes, when I logged into a workstation as the Domain Controller, I had
> no
> Task bar context menu and no Control Panel. I thought the reason I created
> specific users in specific groups was to apply those restrictions to those
> users. I didn't expect the Domain Administrator to be in those restricted
> groups. But since I had followed the cookbook instructions, I decided that
> must be the right behavior.
>
> Then a supervisor tried to work on the workstation as Domain
> Administrator,
> and he told me that was NOT what they expected. I explained that I didn't
> know how it happened, and he said, "Oh, you probably need to remove the
> Administrator from those Groups."
>
> So I looked and checked, and yes, the Domain Administrator was in each of
> the new Groups. So I removed it from all of them. I think I may have
> removed
> some other sort as well: Enterprise Administrator, does that sound right?
> But
> the restrictions were still there. I decided I must've followed the
> cookbook
> incorrectly, and that it was probably a good idea to just delete the
> Groups
> entirely until the guru gets back from break. And when the delete dialog
> came
> up, I clicked the radio button for "Only delete from the list, but keep
> around." I hoped that the guru -- not due back until Monday at the
> earliest
> -- would have a simple magic answer, and I could retrieve these Groups
> that
> had all the right policy restrictions already.
>
> After deleting them, the Domain Administrator had full permissions on the
> workstations again, which is good; but the problem that I've created is
> this:
> I can no longer edit those hidden Groups, and I can't REALLY delete them
> now,
> either. When I'm logged in at the Domain Controller console under the
> Domain
> Administrator account, those options are just grayed out. When I try some
> options that aren't grayed out, such as deleting them by hitting the
> DELETE
> key from the list, I get a dialog saying, "Access denied."
>
> So... Does anyone have a guess what I did wrong? And more important, does
> anyone have any idea what I can do to fix this? I thought the whole point
> of
> Domain Administrator was that that account can do ANYTHING.
>
> Thanks in advance for any ideas or suggestions!
>
> --
> Martin L. Shoemaker
> Microsoft MVP: Visual C#
>

Martin L. Shoemaker wrote:
> Please be gentle with me. I'm new to Group Policies. I thought I was
> following some cookbook instructions; and somehow, I've screwed them up
> badly. Also, sorry that this description is kinda long...
>
> The set-up instructions amounted to this (identifying details altered):
>
> ----------------------------------------------------------------
>
> In Programs/Administrative Services, open Active Directory User and
> Computers. Right click the domain name and choose Properties. On the
> Properties screen, select the Group Policy tab.
>
> Create a new Group Policy for each set of policies you want to enforce. Give
> one the name XXX, one YYY, one ZZZ, and one AAA. Open the properties of the
> new Group Policy and open the Security tab. Add the logon to which the group
> policy applies. For example, for the x machines select the X logon and press
> Add. Uncheck every option for this user except the one that says Apply Group
> Policy.
>
> XXX will contain the logon X, and so on.
>
> Now 'Edit' the Group Policy. It will open a Management Console that shows
> all of the options you can select. It shows you all of the control options
> arrange hierarchically by topic. All of the options show as “Not configured”
> when you create the policy. Double click each option that you want and select
> “Enabled”. Once you do this, the Group Policy is set up.
>
> Options to Use: (There follows a number of specific policies set under
> Administrative Templates in the Group Editor.)
>
> ----------------------------------------------------------------
>
> OK, I thought that was all pretty clear, so I set up four users -- call them
> x, y, z, and a -- and four domain policies XXX, YYY, ZZZ, and AAA. And I
> added each user to its matching group, and selected a set of restrictions for
> each one. I can go into details on the restrictions if it matters, but they
> included disabling the Task Bar context menu and disabling the Control Panel.
> I did all this work from the Domain Controller console, logged in under the
> Domain Administrator account.
>
> Now I'm a security novice, so it made no sense to me that after I made these
> changes, when I logged into a workstation as the Domain Controller, I had no
> Task bar context menu and no Control Panel. I thought the reason I created
> specific users in specific groups was to apply those restrictions to those
> users. I didn't expect the Domain Administrator to be in those restricted
> groups. But since I had followed the cookbook instructions, I decided that
> must be the right behavior.
>
> Then a supervisor tried to work on the workstation as Domain Administrator,
> and he told me that was NOT what they expected. I explained that I didn't
> know how it happened, and he said, "Oh, you probably need to remove the
> Administrator from those Groups."
>
> So I looked and checked, and yes, the Domain Administrator was in each of
> the new Groups. So I removed it from all of them. I think I may have removed
> some other sort as well: Enterprise Administrator, does that sound right? But
> the restrictions were still there. I decided I must've followed the cookbook
> incorrectly, and that it was probably a good idea to just delete the Groups
> entirely until the guru gets back from break. And when the delete dialog came
> up, I clicked the radio button for "Only delete from the list, but keep
> around." I hoped that the guru -- not due back until Monday at the earliest
> -- would have a simple magic answer, and I could retrieve these Groups that
> had all the right policy restrictions already.
>
> After deleting them, the Domain Administrator had full permissions on the
> workstations again, which is good; but the problem that I've created is this:
> I can no longer edit those hidden Groups, and I can't REALLY delete them now,
> either. When I'm logged in at the Domain Controller console under the Domain
> Administrator account, those options are just grayed out. When I try some
> options that aren't grayed out, such as deleting them by hitting the DELETE
> key from the list, I get a dialog saying, "Access denied."
>
> So... Does anyone have a guess what I did wrong? And more important, does
> anyone have any idea what I can do to fix this? I thought the whole point of
> Domain Administrator was that that account can do ANYTHING.
>
> Thanks in advance for any ideas or suggestions!
>

Removing from the list but not deleting keeps the policies available but
no longer binds them to a container. In Windows 2000 those policies are
located in WINNT\SYSVOL\sysvol\domain-name\policies. The problem is in
the permissions. You specifically stated that you granted "apply group
policy" only to members of the groups. Administrators should be granted
all permissions EXCEPT "apply group policy". That allows administrators
to modify and delete policies, where it prevents the policies from being
applied to them.

Group policies are tricky. ALWAYS test them in an OU (NOT at the domain
level) with a set of test users before applying them to the general
population. ALWAYS exclude administrators from policy application
(unless specifically targeting the policy at administrators). Be EXTRA
careful in domain security policies and domain controller security
policies as you can easily lock yourself out of everything (permanently).


IF YOU READ NOTHING ELSE, READ THIS:
You got lucky in that the policies you defined are overridden by default
somewhere else (default domain policy). But many policies require an
explicit reversal. Simply removing those policies does not undo the damage!


If you need to apply policies to specific groups of people across OUs,
make a specific group for those people and permit the policy to be
applied only to members of that group. Also, rather than create a policy
that does everything, create multiple policies and name them according
to their function, i.e. "Remove Run Dialog From Start Menu". That might
not be possible for every policy if you want to apply them at various
levels to specific users/groups, but common policies that apply to
everyone are much easier to keep track of this way. Make sure you
document multi-faceted policies well for future reference.

....kurt

OK, Kurt, you've given me a good start.

> Removing from the list but not deleting keeps the policies available but
> no longer binds them to a container. In Windows 2000 those policies are
> located in WINNT\SYSVOL\sysvol\domain-name\policies.

Does that mean they can be deleted by an Administrator via the file system?

> Group policies are tricky. ALWAYS test them in an OU (NOT at the domain
> level) with a set of test users before applying them to the general
> population.

Education, please. What's an OU?

> IF YOU READ NOTHING ELSE, READ THIS:
> You got lucky in that the policies you defined are overridden by default
> somewhere else (default domain policy). But many policies require an
> explicit reversal. Simply removing those policies does not undo the damage!

Thanks! I'm really not qualified for this work. I tried to tell them that
I'm not a SysAdmin; but they have no one else available, so they're putting a
programmer into this role. And of course, everything's on a rush schedule: no
time to learn it, just do it! (The Dilbert comic practically write itself...)

> If you need to apply policies to specific groups of people across OUs,
> make a specific group for those people and permit the policy to be
> applied only to members of that group. Also, rather than create a policy
> that does everything, create multiple policies and name them according
> to their function, i.e. "Remove Run Dialog From Start Menu". That might
> not be possible for every policy if you want to apply them at various
> levels to specific users/groups, but common policies that apply to
> everyone are much easier to keep track of this way. Make sure you
> document multi-faceted policies well for future reference.

That vaguely makes sense to my limited understanding; but these rules were
written by some authority somewhen in the past, and are not to be questioned
lightly. If I knew what I were doing, I might be able to make an intelligent
argument against them. It's not like the client is THAT hidebound. But in
order to argue against "the way we've always done it", I'm going to have to
understand why it's wrong. You've helped me to understand a bit better.

Thanks!

--
Martin L. Shoemaker
Microsoft MVP: Visual C#

> I've tested deleting groups and I can't find a similar radio button to
> remove from the list but not really delete...

Hmmm. I'm at home right now; but there was an unmissable dialog that had two
radio buttons, which can be summarized as "Unbind this" and "Unbind this and
delete it." I must have been on a different path.

> If it's still there, you would be able to see it with ldp.exe or
> adsiedit.msc, but that's like sending someone into the Registry of every
> machine on the network. You may not want to poke around inside the Active
> Directory too much...

Want to? No way. Expected to? It looks that way.

> I would be happy to help on Monday afternoon if you don't have a resolution
> by then, but I'll be mostly offline this weekend.

Thanks, Mike! I'm hoping Kurt has given me most of what I need. If I can
simply delete those Groups through the file system, then I'll consider the
problem solved.

Well, the immediate problem. The problem that I don't know how to do this
work is going to take a little longer.

--
Martin L. Shoemaker
Microsoft MVP: Visual C#

OH <slaps forehead> !!!

I thought you deleted security groups, not group policies. That makes much
more sense.

Yeah, Kurt's got you covered. Worst case if they policies all got totally
hosed, you could recreate the default policies. It's not good since you
have to rebuild any specific policies that had been previously in place but
it gets you back up and running...

If you're still stuck come Monday ping me offline and I'll help if I can.

--

Mike Shepperd
Sunfire Solutions LLC
Seattle, WA

[This posting is provided AS-IS, with no warranties and confers no rights]


"Martin L. Shoemaker" <(E-Mail Removed)> wrote in
message news:15F3DF88-AE2D-4762-BEAF-(E-Mail Removed)...
>> I've tested deleting groups and I can't find a similar radio button to
>> remove from the list but not really delete...
>
> Hmmm. I'm at home right now; but there was an unmissable dialog that had
> two
> radio buttons, which can be summarized as "Unbind this" and "Unbind this
> and
> delete it." I must have been on a different path.
>
>> If it's still there, you would be able to see it with ldp.exe or
>> adsiedit.msc, but that's like sending someone into the Registry of every
>> machine on the network. You may not want to poke around inside the
>> Active
>> Directory too much...
>
> Want to? No way. Expected to? It looks that way.
>
>> I would be happy to help on Monday afternoon if you don't have a
>> resolution
>> by then, but I'll be mostly offline this weekend.
>
> Thanks, Mike! I'm hoping Kurt has given me most of what I need. If I can
> simply delete those Groups through the file system, then I'll consider the
> problem solved.
>
> Well, the immediate problem. The problem that I don't know how to do this
> work is going to take a little longer.
>
> --
> Martin L. Shoemaker
> Microsoft MVP: Visual C#
>

Martin L. Shoemaker wrote:
> Does that mean they can be deleted by an Administrator via the file system?

Yes, but they generally have names like "GOEIRUTOI03049Oiewoiru", so you
wouldn't know what you were deleting. Better to assign full control
permissions (except apply policy) to your admin account and delete them
uaing the group policy snap-in.


> Education, please. What's an OU?

An "Organizational Unit". To create one, go to Active Directory Users
and Computers, right-click on the domain, select New -> Organizational
Unit. You can create test users and put them in the OU. If you
right-click the OU and select properties, you'll have a group policy
tab. When you define a policy at the OU level, it only applies to users
(or computers) that are in the OU. Note that the standard containers
(Users, Computers, etc) are special and you cannot apply group policy on
those containers - create your own.

>> If you need to apply policies to specific groups of people across OUs,
>> make a specific group for those people and permit the policy to be
>> applied only to members of that group. Also, rather than create a policy
>> that does everything, create multiple policies and name them according
>> to their function, i.e. "Remove Run Dialog From Start Menu". That might
>> not be possible for every policy if you want to apply them at various
>> levels to specific users/groups, but common policies that apply to
>> everyone are much easier to keep track of this way. Make sure you
>> document multi-faceted policies well for future reference.
>
> That vaguely makes sense to my limited understanding; but these rules were
> written by some authority somewhen in the past, and are not to be questioned
> lightly. If I knew what I were doing, I might be able to make an intelligent
> argument against them. It's not like the client is THAT hidebound. But in
> order to argue against "the way we've always done it", I'm going to have to
> understand why it's wrong. You've helped me to understand a bit better.
>
> Thanks!
>

From your previous post, the instructions had you creating policies for
groups of users and applying the policies at the domain level. That
certainly works. If those users represented departments, say Marketing,
Accounting and Sales, the more widely accepted method would be to create
3 OUs (named "Marketing", "Accounting" and "Sales"), Placing the
appropriate users into those OUs, and creating policies there. You would
also likely create a global group for each of those sets of users named
similarly, and the same users in each OU would also be members of the
corresponding groups.

Just a caveat here - OUs are logical containers where POLICIES can be
applied and groups are entities to which you may assign PERMISSIONS.

You could start with a set of common policies and apply those policies
at the domain level, granting "read and apply policy" permissions to all
3 groups. In each OU, any policies unique to each division could be
created, applied and "Apply" permission granted to the group instead of
each user. It's hierarchical, logical, self documenting, and I think
you'd find that it is widely accepted as "best practices" .

....kurt

"Kurt" wrote:

> > Does that mean they can be deleted by an Administrator via the file system?
>
> Yes, but they generally have names like "GOEIRUTOI03049Oiewoiru", so you
> wouldn't know what you were deleting. Better to assign full control
> permissions (except apply policy) to your admin account and delete them
> uaing the group policy snap-in.

I'm still not at that machine, since it's not on the Internet yet; but I
seem to remember that I couldn't edit the Group Policies to add users to
them, because Administrator had no Group Policy editing rights on those. (It
did on newly created Group Policies.) Any guess why that would be?

> From your previous post, the instructions had you creating policies for
> groups of users and applying the policies at the domain level. That
> certainly works. If those users represented departments, say Marketing,
> Accounting and Sales, the more widely accepted method would be to create
> 3 OUs (named "Marketing", "Accounting" and "Sales"), Placing the
> appropriate users into those OUs, and creating policies there. You would
> also likely create a global group for each of those sets of users named
> similarly, and the same users in each OU would also be members of the
> corresponding groups.

I'll pass that suggestion along. It makes sense to me.

Thanks!

--
Martin L. Shoemaker
Microsoft MVP: Visual C#

Martin L. Shoemaker wrote:
> I'm still not at that machine, since it's not on the Internet yet; but I
> seem to remember that I couldn't edit the Group Policies to add users to
> them, because Administrator had no Group Policy editing rights on those. (It
> did on newly created Group Policies.) Any guess why that would be?
>

That would be because whoever created (or last edited) those policies
specifically set the permissions to edit or modify the policy to exclude
the account you are using. Administrators can usually at least view the
permissions, even if they can't change them. Once you see who has full
control permissions, you can log on as that user and grant permissions
to yourself.

....kurt