Re: Local Machine vs. Domain Group Policy

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



mg wrote:
Joe, counter viewpoints may serve to teach us something. This is indeed counter to all the responses so far in the Terminal Services, Group Policy and Active Directory newsgroups and counter to what Microsoft recommends. That doesn't prove anything as to the validity of your view and your credentials are nothing to sneeze at either.

That being said, I can understand the advantages of the OU with linked domain GPO solution. A Citrix solution already deployed in our domain uses this approach. To understand your alternative approach it would help to clarify a couple of points.

I researched, installed, configured and tested this TS solution. I have admin rights to the server and I'm also the application administrator and DBA. The only thing remaining is to lock TS down before deployment. Our network admin does not have TS knowledge or experience. Being an understaffed IT shop, he also has little time to devote to this critical deployment.

I'm proposing that he give me control of a single GPO so I can build the lockdown policy. Once that is done, the network admin would review the GPO, create the OU, link the GPO move the TS computer into the OU, then we test. Once testing is completed and we're deployed I don't care who has control over the OU or GPO. He can have sole control of it all, although I will say this could slow us down if the policy requires post-deployment tweaking.

With that on the table, it would help me a lot if you would clarify a couple of points:

1. Using local policy, is there some easy way to copy it to other machines, or are you suggesting building and testing this complex lockdown policy 40 times (as in your 40 TS example)? Wouldn't future changes also have to be applied 40 times?

2. We're talking about one GPO and one OU. I'm responsible for the TS solution and applications that go into this OU. AD is designed to let the domain admin delegate permissions to a specific OU and GPO and the person delegated to cannot affect anything else in the domain right? Given that the domain admin will review everything before deployment and can always unlink or otherwise modify the GPO or revoke permissions, can you explain or provide any specific reason why you would still refuse to delegate permissions?

When I try to understand your viewpoint based on what's been said so far, it sounds like your motivation is to avoid hassle and potential problems (having to review the policies, make sure they replicate properly, etc.) for the AD admin by blocking use of AD altogether whenever possible. I can see where domain admins would love this approach. <g> Also, maybe replication was a bigger issue for this global client than it would be for us.

Please don't get upset with me if I'm way off base here. I'll be happy to learn from and humbly accept a methodical dismantling of my misperceptions. Thanks for your input on this interesting discussion.

.

Loading