The first item I will respond to is full control over an OU. It is too much
power. It allows you to create any object under that OU that is allowed to be
created under an OU because you have the ability to manipulate the SD. I rarely
if ever recommend giving full control to anything in AD to anyone but full
domain admins, of which, I recommend you not have more than 5 or 6 of for an
entire forest regardless of company size.
AD has many security issues and while delegation is nice there are lots of
shortcomings in it including no business rules/triggers and painful/poor logging.
I highly recommend using vetted provisioning/metadata processes that incorporate
business rules/triggers and great logging such as Quests AR Server or MIIS or
HP's LDSU and not allowing admins to directly modify the directory. In my
discussions with MS about adding some functionality to help counter this the
responses from the highest levels of management of the development groups for
DS/IdM tell me the idea is that people should be using metadata/provisioning
products for all management of AD. MS, at least the current program managers
over Identity Management and Directory Services all indicate that AD is
basically a back end store at this point.
On the point of the TS policies, it has been several years since I have had to
work on that as I have since moved into consulting, but yes you can come up with
local policy templates and apply them. In fact, at the customer mentioned (go
hunt down my resume and the customer will be obvious) we put together a setup
where you specified the role of the server during the build process and the
appropriate security policy was stamped onto the machine at that point. The only
domain policy that was applied to the machines was the default domain policy
which only defined password policy and policy that applied specifically to users
in the domain. There is a lot of power there, I just recall it was documented
poorly because someone wanted to push using Domain based policy but that is
mostly due to workstation management, not server.
One of my concerns with domain based policy is that it gets out of control. You
start with one, you end up with 200 to meet any special little needs of every
little occasion. It becomes a train wreck to manage and I walk into customers
all of the time that have many policies that they have no idea is for, what they
do, whether or not they are actually being used, why certain things aren't
working, etc.
Another concern is that it is very easy to hurt many machines/users very quickly
with a single mistake in a domain based policy. I once saw some 200k users all
get locked down to kiosk mode in the space of 30-40 minutes because of one small
ACL issue on a policy. This was because it was using group based filtering which
I WAY don't recommend but the idea is the same, one small mistake becomes a huge
issue that may or may not be easy to back yourself out of.
Another concern is, as you indicated, hassle of dealing with it from a domain
admin level. Microsoft in its infinite wisdom chose to use two entirely
different replication engines to move GPOs around a domain. This means you have
two entirely different replication engines and sets of data to watch over for
convergence. If you use a very minimal set of policies that never change then
you can pretty much stop worrying about one of those replication mechanisms
except during the addition of new DCs. If you allow someone outside of the 3-4
domain admins to modify policy, you now have to track everytime they make a
modification and make sure that is replicating fine.
Another concern is for local admins. In my position I mentioned previously, I
dealt with literally thousands of local site admins, one of their main issues
with AD is the lack of control that they had when they had local resource
domains. Domain based group policy is a big part of that because it is something
that no longer impacts just them. Things they do now have more far reaching
impact on who has to deal with it and when troubleshooting, they often are not
self-sufficient and have to pull in people who generally really don't have time
to care about why one user logs on and doesn't get the proper policy. Pushing
the policy setting to the local machines allows the local admin to have
considerably more direct control over the user's experience on the given machine.
The times that I feel that Domain based policy is useful is for things like
corporate password policies or managing some basic settings on thousands of
workstations (but with a few fixed policies, no ad hoc crap) or possibly if you
have a group of server machines that you can not trust the admins for and even
then, if they are bright enough, they are going to counter anything you do with
the policy anyway. The system isn't that bulletproof and quite honestly Windows
was never designed to be bulletproof from the local admins or anyone who can
become a local admin (i.e. anyone with physical access). If you have a problem
with local admins, the issue is a policy issue alright. Just not a technical one
and you can not solve it with technical solutions including domain group policy.
Things like software delivery etc all have other better mechanisms for handling
and stacking all of this crap into a process that can impact user authentication
is a generally overall all around bad idea. That goes double for
complicated/complex logon scripts. I see these in the same light that I see
GPOs, people see a mechanism that looks like it will work and whether it is a
good idea or not jump right into using it and then wonder why things are shitty
later.
My overall goal when looking at Domains and Domain Controllers is to make the
environment as simple as possible. Far less items break that way and when they
do it is MUCH easier to troubleshoot meaning that people can focus on proactive
intelligent work versus troubleshooting and firefighting all of the time. The
company that I mentioned has probably the best running AD I have yet to
encounter in 6 years of working on AD and 2 years of consulting with one of the
larger technical service organizations on AD/Exchange issues. Their admins (4 of
them now because they picked up ADAM support as well as AD) manage some 400 DCs
across the world comprised of ~250k users and at least that many machines (and
an ADAM pool that will end up servicing probably a million or so users) out of
one site in the US and rarely have a pager go off because something is broken or
not working. I have lunch with them every couple of months and they are free to
comfortably and relaxingly take 2-3 hour lunches. They get to spend good time
looking at upcoming changes such as Schema updates, etc and make sure they are
good versus not having any real time to look at anything and just having to
trust that the people bringing it to them can be trusted. This wasn't always the
case, when I first joined them back initially in 1999 and returned in 2001 it
was a nightmare, pager going off at all hours, people screaming and hollaring
about this that and the other thing being broken, etc. It slowly got better as
the environment was simplified and locked down from people making modifications.
At this point there is a provisioning system that handles all userid updates
except to the 4 (5 if you include the manager who isn't allowed to change
anything but has a just in case DA ID) Domain/Enterprise Admins, all server
account creations are handled by the DAs, all group/OU creations are handled by
the DAs, workstations creations are handled by the workstation build process
though local site admins can manually create them if necessary though automated
scripts I wrote called jail scripts verify that they are done correctly and
actually are workstations instead of servers. If someone tries to do something
they aren't supposed to the object is jailed meaning that only DAs can do
anything with the object and the machine is dead in the water. Local site admins
are responsible for and can directly manage group membership but it is likely
they will even lose that direct capability and that will go into provisioning
because it is generally being handled poorly because they aren't auditing and
cleaning up membership as they should. Again, this is the best running most
efficient, least troublesome AD I have ever seen. Most DAs I meet are harried
and constantly fighting fires and chasing issues and barely have time for a 15
minute con call or to look at any proactive items like perf counters, etc.
MS does a lot of stuff with their OS, not all of it good for companies and just
because it works for very small numbers when some integrator is testing it
doesn't mean it should be deployed and used corporate wide. Can GPOs be used
effectively and well and not cause issues, yes, but in my experience that has
been in the minority of places I have spoken with people and usually only if the
whole thing is well tested in a lab and then rolled to production very carefully
and completely locked down from ad hoc updates at all points. Any time I walk
into a company and there are a large number of GPOs and/or non-DAs have the
ability to modify/create GPOs there is almost always some level of issues there
that people can't nail down.
As for best practices, they vary by company. Different companies do things in
different ways and see different issues. I take the best practices advocated by
MS with as much a grain a salt as those by any company until I have personally
proven out their benefit to myself in a given situation or several situations.
For instance the MS docs for building a domain controller talks about using
RAID-1 and doesn't really outline when that idea absolutely sucks and for the
most part in larger orgs using RAID-1 absolutely sucks because the disks can't
handle the Read Ops that are necessary but the docs from MS don't say anything
about that. If you talked to Dev or the folks in Enterprise Engineering they
will have completely different opinions than what MS officially documents for
many things.
I have one word I use to describe Microsoft (or anyone's for that matter)
documentation that I haven't personally vouched for and approved, propaganda.
Anyone who has taken any MOC course and then really worked in an environment
generally feels quiet similar. Even if you haven't taken a MOC course there is
enough docs out there that after you read them and visit the real world you see
they don't exactly align.
So anyway, if someone implements GPOs and everything works great for them and
they have a good handle on it that is great. I would however, not force anyone
to do it because Microsoft says it is the best practice for doing it. When I
walk into an environment I look to see how I can help the DAs, not force them to
take on more work and concern. You want DAs as friends, not as enemies. Discuss
with them what you would like and listen to what they respond with. No's that
are sent back will either be well thought out or they will be gut responses. If
well thought out, if they are willing to tell you why listen and see if you can
quell concerns. No's that are gut feelings also try to work out but understand
that they may not have a good clear reasoning YET. I have learned to trust my
gut because it often knows there is a problem before I do logically, gut
feelings is simply subconscious thinking or worries coming up and is worth
listening to but you should try to substantiate the gut with well thought out
logical thoughts as soon as possible. Obviously the registry corruption response
was silly. It could be you have a really bad admin on your hands, however, being
a bad admin doesn't mean everything they think of or do is wrong, they could
just be very poor at explaining what the problem is or what they think and grasp
onto anything they think will make someone go away. On the other hand it could
be a good admin that has a feeling you don't know what you are talking about and
is willing to just say things that he thinks will make you go away. DAs are the
target of lots of people in the company all who think they know better than the
DA what needs to be done. I used to hit this daily and unfortunately for most of
those people, many of whom were developers or integrators I usually knew far
more about the Domain and environment than they did and often more about what
they were trying to do than they did. Not all of them got better answers from me
than simply, no, that isn't going to happen. On the other hand in some cases I
would write whole programs to show them the error in their ways, it was my
judgment as the DA how much time I would spend on their problems.
Oh one thing that stuck out below also was the comment of something like "we are
talking about one OU and one GPO". As a former DA, that is how it always starts
out and then it starts growing. DAs have been trained to realize that the people
coming to ask them for things are probably lying or don't have a clue and they
need to try and figure out what will happen 2 months, 6 months, 2 years down the
road. Someone comes to me with a request for a single OU and single GPO and I
know that at some point, it will be a case of ok, we did that once, now we need
to do it again BUT this time... Even worse is the idea that it is a one off. One
offs are costly and people forget them. Why does anything built by hand cost
more than the same thing built on an assembly line? Labor. It is more intensive
to do things onesy-twosy than to produce a generic process. If you want to make
a change to an OU, make that the standard for all OUs. The company I did the
work for couldn't have been anywhere near as efficient for the AD stuff if there
wasn't a completed fixed OU structure for every site. You need a new site spun
up, one single script created all 10 or so OUs required for it and built all of
the new groups and set all of the delegated permissions. Total time, maybe 3-5
seconds. Total mistakes, 0. Doing that all by hand takes minutes at least and no
guarantee of accuracy or consistency.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net
---O'Reilly Active Directory Third Edition now available---
http://www.joeware.net/win/ad3e.htm