|
Thanks! I am pretty confident I understand why you
configure OUs. :)
I didn't say I wouldn't use group filtering but instead
that I am against that being a going in view, someone has to prove that
that is the way to go because it is more prone to confusion and failures. This
is what I mean by being a fan of setting up by hierarchy than filtering. The
fact is, I am against having many GPOs at all, I like a very simple GPO
structure preferably without having multiple GPOs impacting users as the more
you have the slower auth processing is and the more complex
troubleshooting is for issues. How many times have you been sitting there
looking at gpresult output trying to figure out why a machine got configured a
certain way, for me, the first 2-3 times was too many, I have better things to
do with my time and I dread anytime I hear someone saying, we have this GPO
and... and they start looking at me. I know I am not alone in this as I have had
decent conversations with several people who are big into GPOs and really know
that stuff backwards and forwards and in fact they can point out way more
inconsistencies and issues and problems than I could even start to. Anyone truly
being honest with themselves and understands the technology knows that GPOs
can be quite flakey or maybe I should call them "odd" and difficult to deal
with. They can be a great boon but they can also be a great
detriment.
I am against having ad hoc GPOs any time someone gets
a bug up their bum thinking there is some new great thing they can do with it
such as deliver software or make minor tweaks. For instance I feel there
are better solutions for software delivery. Plus I have yet to have
encountered any company that manages GPOs well when they have a large number of
them. Usually there are a bunch of unlinked GPOs or GPOs that are linked but
missing sysvol files, etc.
There is of course the folks who worry about logon speed
due to hierarchy which I hope has been sufficiently extinguished now, but if
someone truly has a concern, if they are sitting in an environment with a
thousand GPOs that are being filtered by group membership, having traced that
code path, I would expect a perf hit. If you have say 14 GPOs as a round number,
that is much more manageable and will be speedy whether handled through
filtering or hierarchy (barring some stupidly complex GPO with scripts or tons
of settings, etc).
Finally there are the fun issues you can encounter that are
completely an issue due to exposure gained by group filtering, say like
someone adds the everyone secprin to a group that has the kiosk
settings either on purpose because today is their last day or accidently because
some admin screwed up and gave them rights they didn't full comprehend, etc.
Possibly something resets the ACLs on the GPCs. I have seen these occur both in
person and through the grapevine and they can be quite fun to extract yourself
from. The hierarchy mechanism has built in protections against this kind of
wholesale nasty issue across an entire domain.
All in all GPOs are sort of like Domain Admins. You
should have very few (say two is a nice round number) but everyone has
an excuse why at least one more is needed for whatever they are doing. This
is an area you don't want to really get crazy in and you want to have it
sufficiently locked down and controlled because it can be an area of immense
pain for you when something goes pear shaped.
Possibly I am jaded in that I deal primarily with Fortune
25 or bigger companies and large military and government customers primarily and
it is the normal scaling issues MS has with tech and tech management. A smaller
company is almost surely going to have a smaller (and possibly less
complex) number of GPOs just from the fact that they are smaller.
On to delegation... I am slowly getting more and more of
the opinion that almost all people based[1] delegation should be pulled out of
AD and put into provisioning systems. People are getting more and
more complex with their delegation models and then asking questions like,
"hey what can people do and where can they do it" and the current native
toolsets do not answer those questions well. Plus the complete lack and no
desire by Microsoft to have the ability to have built in triggers and business
rules and the fact that we currently have poor auditing at best means a
provisioning system makes even more sense because you can easily add all of
those items at that layer. Also applications like Exchange/LCS are completely
screwing up the delegation model anyway. It is causing so much complexity
and confusion in the ACL structure that most companies are either granting too
many rights or duping up on permissions which causes bloat in older ADs and perf
issues in all ADs. The issues with how poorly property sets were
implemented add to the confusion and pain here. I won't even get into the point
about the first time some smart person decides to attack AD when they find some
other virus/worm vector to ride on. Most people have their flies down, nay,
their pants are at their knees in terms of protecting themselves against some
rougue process tearing through a company and having its true goal of attacking
AD. I am not saying AD is the propagation mechanism though GPOs certainly would
be a good way to propagate a virus, I am specifically saying here that things
aren't controlled monitored well enough to help when this
happens.
Oh as quick example of ACL sizing and its impact to
strike home the point... One company I helped out recently had so many ACEs
at their root NC level that it literally scrolled down the screen for
seconds when dumping with DSACLS. Once I convinced them to clean up the ACL
structure long running queries that previously ran and took 120+ minutes would
complete in under 90 minutes, you can't tell me that had an overall impact on
everything using AD and how busy the DCs were. Simply because of a
simple ACL cleanup and ripping people's native delegations out and pushing
them through a provisioning system. Since they were on 2K the reduction in DIT
size was measured in GBs as well. K3 certainly would have helped reduce the DIT
size with single instance store, but would not have helped the query speed very
much in relation to the time spent on enumerating permissions to determine what
could be seen and/or modified. Other enhancements in the QP and other subsystems
would have given a perf increase though all that additional perf gain from
cleaning up ACLs would have been hidden from view.
joe
[1]
I.E. Delegation to actual people instead of to service IDs.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Wade Sent: Thursday, April 13, 2006 3:22 AM To: [email protected] Subject: Re: [ActiveDir] OU's Structure Joe,
The problem is that, as some
one else mentioned your OU structure serveves two purposes:-
1) To delegate
authourity
2) To apply rights and restrictions
via GPO's
Now if you are going to delegate
authourity, as far as I can see, the only way to do that is via OU's. You could
apply specific rights to indivual users, but thats messy to manage and
impractical. On the other hand users get many rights already because of group
membership, so its (more?) natural to apply GPOs based on group membership
rather than having rights or restrictions "drop on you from above" because of
where you are in AD. Mind you of course NTFS rights may also descend from
above.
Dave.
|
