Joe, Of a related topic, I'm curious if your OU structure breaks computer, user, and group objects each into their own for the various "groupings" of users/systems? One reason I ask is because of the authoritative restore "issue" where when restoring groups and users, the group memberships may be empty or inconsistent across DC's. The recommendation is to restore users first and then groups. Having the types of objects split into separate OU's simplifies this. However, it'll definitely result in OU bloat (whether for good or not) in any sizeable environment. The only way I see to prevent this OU bloat while still following the "separate OU's for each type of object" philosophy is to use group filtering.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Sunday, April 04, 2004 07:56 > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Testing other GPO's to DC's > > I think there is a typo in there where you are specifying the > permutations, you say OUs when you mean groups. However I > understand what you are saying. > > The reasoning is management and safety. Management in terms > of less confusion and having everyone that has power to > understand the implications and much more obvious what is > going on. Safety, well for safety and the partitioning mentioned. > > To set it up, we have centralized administration of userids > in terms of there is a provisioning system, we do not place > userids over a large OU structure, they previously went into > a single location and now can be in one of 8 locations (plus > a location for high level administrative IDs) per domain. > > We actually encountered an issue with group based management > a couple of years ago when we had all user GPOs managed via > group membership. During a fresh scripted import into > production (we do not manually modify/link GPOs in > production) some ACLs got reset and the reapplication of > removing authenticed users didn't occur properly. All users > on all machines locked down to full kiosk mode because they > had all GPOs applied to them up to and including the kiosk GPO. > > The reason for the failure wasn't immediately apparent as it > had worked fine in the lab and was a direct scripted process > so we had to backout. That backout was to unlink all GPOs > until we had the time to specifically go through and verify > everything, it was more important for the tens of thousands > of people around the world impacted to be able to do their > work again. Luckily it was in our "lull" time so impact was > relatively small. > > In the review we realized that doing things via group was > both confusing and dangerous. We had delegated to local site > admins the ability to add/remove people from their groups to > apply various GPOs. It was never considered previously that > someone could add authenticated users, domain admins, domain > users, everyone, etc to the groups they managed. > > Additonally the mindset of the local admins wasn't taken into > account. If you have an admin of a specific building, > everyone to them is the people in that building, not the > everyone that it truly is. Once we went looking for it we saw > it on security groups all over and again, it was the mindset > of the local admins, they wanted everyone in their building > to have the access. > Generally the farther you go down in a management chain for > admins the less overall understanding they have of the design > and the whys and hows. > Realistically we would never be able to properly train (and > get true understanding for) all of the admins that could > possibly have the ability to harm us using groups. To > continue to use group filtering would mean having both a > complicated OU and group layout versus just a basic OU setup. > > The larger the organization, I think, the less flexibility > you really want in your setup like this. The exception is > when you have the money to have a lot of very knowledgeable > admins working in a very decentralized "we like to manage > one-offs" way. Otherwise you have to lock down hard on a few > specific standards as any centralized knowledgeable group is > not going to be able manage all of the different permutations > of possible configurations. > Additionally trying to troubleshoot many permutations can be trying. > > If you can look at the OU a machine or user is in and then > know exactly based on that OU what they should have and not > then also have to go look at what groups they are in and > filter out or in the specific GPOs granted/denied by those > groups life is much easier in general. Again, while you could > most likely train top level admins and even medium level > admins how to do this, the turnover you get and the number of > low level admins in a large company as such that it would > still be confusing and difficult to manage any other way. > > Plus when building up new labs or rebuilding due to disaster, > the simpler the setup the easier it is to duplicate. Sure you > can have tools that can do this stuff for you, but in the > case where the tool for some reason doesn't work and you have > to fall back to a manual setup, much easier if you followed > KISS methodology the whole time. > > Anyone who likes to build one-offs in your organization > should be generally looked at with suspicion. Doing so > enhances their value to the company in a harmful way simply > because they are the only ones who understand the one offs > and the decisions behind it. Very often you can look at a one > off and try to figure out what is going on based on accepted > standards because, well, it is a one off. You have to look at > it from the ground up. When following accepted standards and > you are troubleshooting, you have a known good to start with > and go from there. Does it sacrifice flexibility? > Absolutely, however in general practice in ops it is more > important to be easily supportable and less confusing than it > is to be flexible. Flexibility is what people ask for before > they run into problems and confusion with it. > Once things are broken, they are complaining about how long > it took to fix or rebuild and you can't blame it on them > wanting flexibility unless they don't allow anything else. > > Don't get me wrong, I am not saying vendors should make their > products inflexible. Absolutely not the case. Vendors should > be very flexible because they don't know what standards the > company will standardize on and should support any > configuration the companies would like to go with. It is once > the product is deployed in the medium to large company that > flexibility should be restrained. Unless of course, the > company is willing to pay for a lot of good/strong admin > capability and keep it. > > For this specific case, and especially because it is a test, > I think that a separate OU is the way to go. Both because of > the reasons above and so that it is extremely obvious when > people do a casual look that a test is going on. The DC being > in a group could very easily be overlooked if the guy who did > it is fired, quits, or gets hit by a bus. If you have some > 80,000 groups in a domain, people aren't always going to go, > hey why is this DC in this group called TestGPO. In fact, how > many people know what groups their DCs (or any machines) are > in? That DC sitting in a special subou will be obvious when > people go to look at the domain controllers, irregardless of > the tool they are using to browse. > > > My final word I guess is that Group Policies are very > powerful. Very powerful in that they can make any changes you > want in a very easy quick way over a wide customer base. That > is how they are advertised right? My general rule is anything > that can make changes is dangerous and needs to be closely > controlled. By that general rule, group policies are very > dangerous and I wholeheartedly believe that. I am a cynical > person when it comes to systems management though. It has > saved my ass more than once. > > joe > > > ------------- > http://www.joeware.net (download joeware) > http://www.cafeshops.com/joewarenet (wear joeware) > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > SysPro Support > Sent: Sunday, April 04, 2004 5:32 AM > To: [EMAIL PROTECTED] > Subject: Re: [ActiveDir] Testing other GPO's to DC's > > I am interested in the comment that OU's are a better way to > manage Policies than using group based filtering. Is this for > performance reasons, management reasons or safety reasons? > > I could see a very small improvement in performance, using > OU's is a little easier to see what is going on and it is a > little safer since if you make a mistake it only messes up > the servers in that OU. In this case the main argument for > using a separate OU would seem safety but I wonder if I have > missed something? I personally would probably use group > filtering, especially since it is only for testing. > > We tend to use OU's to delegate management of the > workstations. We have a single domain managed centrally, but > delegate day to day management to staff in the region. If you > are in Eastern region, you go in the Eastern OU's and the > Eastern staff manage you. > > I find managing policies by OU much more of a headache than > using Group Filtering. If you have one policy, you only need > two OU's. However, if you have 5 policies, you need > (potentially) 32 groups to cover every permutation. 5 groups > can be used to manage 5 policies and if you use a name to > make clear it is only for Policy management, it is all pretty > easy to follow. > > > Alan Cuthbertson > > Policy Management Software:- > http://www.sysprosoft.com/pol_summary.shtml > ADM Template Editor:- http://www.sysprosoft.com/adm_summary.shtml > > ----- Original Message ----- > From: "joe" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, April 04, 2004 3:50 AM > Subject: RE: [ActiveDir] Testing other GPO's to DC's > > > Yes, this would be my preference as well. Avoid group based filtering. > > > ------------- > http://www.joeware.net (download joeware) > http://www.cafeshops.com/joewarenet (wear joeware) > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Grillenmeier, Guido > Sent: Wednesday, March 31, 2004 10:12 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Testing other GPO's to DC's > > or create a sub-ou underneath the domain controllers OU which > you link the GPO to. > then put those DCs into the sub-OU. not only good for > testing purposes... > > /Guido > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Darren Mar-Elia > Sent: Mittwoch, 31. M�rz 2004 19:36 > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Testing other GPO's to DC's > > Yes, that's exactly it. Grant those specific DCs the Read and > Apply Group Policy rights on the GPO. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Devan Pala > Sent: Wednesday, March 31, 2004 12:08 PM > To: [EMAIL PROTECTED] > Subject: [ActiveDir] Testing other GPO's to DC's > > Hi, > > I'm sure this has been covered in previous posts but how can > I create a GPO object and link it to the Domain Controllers > OU but only apply it to a couple of domain controllers for > testing purposes? > > Is it removing the authenticated users group and adding the > specific domain controllers to the ACL's? > > Thanks, > > _________________________________________________________________ > Check out MSN PC Safety & Security to help ensure your PC is > protected and safe. http://specials.msn.com/msn/security.asp > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
