Boy, did I screw up some Group Policies!

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

Guest

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!
 
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 said:
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!
Click to expand...

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.
Click to expand...

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.
Click to expand...

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!
Click to expand...

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.
Click to expand...

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!
 
I've tested deleting groups and I can't find a similar radio button to
remove from the list but not really delete...
Click to expand...

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...
Click to expand...

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.
Click to expand...

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.
 
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 said:
Does that mean they can be deleted by an Administrator via the file system?
Click to expand...

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?
Click to expand...

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.
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!
Click to expand...

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 said:
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.
Click to expand...

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.
Click to expand...

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

Thanks!
 
Martin said:
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?
Click to expand...

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
 
Back
Top