Say you set all of the admin groups (admins, domain admins, ent admins) as a restricted groups. You set membership of
builtin Admin userA userB userC userD That replicates out and works. Then at some point someone changes the restricted groups to be userA userB userC userD This (on 2K SP1 which I encountered it on) causes all sorts of fun and from what I have seen made replication work in a sporadic way and causes out of resource issues. At some later point you need to change that membership again and various parts of replication aren't working properly because of the above and other issues (This specifically occurred with me when I took over an AD previously). You break into a DC, you make the changes to that restricted group to be builtin Admin user1 user2 user3 user4 That replicates out and DCs that get it set it, that change starts to replicate out through AD Replication. Then some (or more than one which occurred to me) DC that has good AD replication but failing FRS replication gets the group change through AD replication, sees that it isn't right, changes the membership back to UserA/B/C/D and that replicates back out to the environment. So now you have your domain admin membership bouncing back and forth and some times you have access to do things and sometimes you don't. It is messy, took me several hours to get it straightened out when it did and in the meanwhile was a huge security hole because the people who were removed from access still had access to the network because they still supported other things in the environment but absolutely were not supposed to have domain access. I have seen on multiple occasions the same thing occur with lockout settings and password settings. That simply causes mass confusion because you tell people the lockout policy is 15 bads and occasionally someone locks out in less and you start to chase into it figuring something is sending multiple requests but in fact at the moment they were logging on, the previous lockout policy was in effect because of the bouncing policy. Our sysvol/dfs data is all replicated out through a single replication model, FRS. There are ties to AD in terms of linking data but not actual data so you wouldn't expect say a file to have different data at different points. With the above items, your GPO and AD are telling DCs to do entirely different things and each wins for a short period of time. In an environment with more than 50-60 DCs in a domain, this was, a couple of years ago for me, a time consuming issue to track down, especially since the issue was coming from multiple DCs with close to 100 or so in the domain. In the end, about 80% of the DCs in that domain had some form of replication issue that had to be straightened out and it is was one domain of 11 or 12 in the forest. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Patrick Sent: Monday, June 21, 2004 9:07 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Security How does this one relate specifically to restricted groups? This applies to a whole slew of items.. the worst offender IMO being a hub and spoke topo with file system permissions being pushed down to sysvol or dfs link\root which is replicated. -steve ----- Original Message ----- From: "joe" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 21, 2004 2:55 PM Subject: RE: [ActiveDir] Security > Guido's #1 can be a nightmare. Say you have a single DC that isn't playing > well with the FRS replication topology and you go to change the restricted > group you will get this great battle going on in AD as the change is made by > GPO on one machine, it will replicate through the environment, the GPO on > another machine won't agree and will change it to something else and that > will replicate through the environment. > > Actually I think MS is rather kooky for setting anything in GPO that changes > something that replicates in normal AD replication. Do it so that it is > replicated one way or the other. This goes for restricted AD groups as well > as lockout policies and things like that. > > Can't say I see how #2 could impact and don't see how restricted groups > could impact #3. > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido > Sent: Friday, June 11, 2004 5:12 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Security > > sure: > 1. replication of changes and applying the GPO will cause undesireable > results at times. > 2. the AdminSDholder process of the domain controlls the sensitive groups > in AD (e.g. Domain & Enterprise & Schema Admin, Account Operators, Server > Operators etc.) and periodically checks permissions on these groups and for > those accounts that need to be in this group have not been removed etc. > (could also be impacted negatively by the GPO) 3. there are a couple of > hidden group memberships in AD that you don't know about and thus not adding > them via restricted groups could cause replication problems: e.g. each DC is > a member of the local domain administrators group using the NT > Authority\Enterprise Domain Controllers group - but you don't see this group > as a member in the group. If this member is missing, DCs can't replicate > successfully. I don't have a complete list of hidden memberships (this one > could or could not be all), so that I wouldn't risk breaking things in AD > using this GPO on domain groups (mainly the administrative groups). > > \Guido > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Passo, Larry > Sent: Freitag, 11. Juni 2004 05:37 > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Security > > I'm curious, do you have any more details? > > -----Original Message----- > From: Grillenmeier, Guido [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 10, 2004 2:47 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Security > > > don't use the Restricted Groups feature on domain groups, especially domain > admins. This has caused various issues for companies and thus they've backed > away from this approach. However, using restricted groups on member servers > and clients works well. > > \Guido > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Passo, Larry > Sent: Donnerstag, 10. Juni 2004 19:38 > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Security > > If you want to make sure that no one is added to the group you could make > the group a Restricted Group via a GPO. > > If you want to know when a user is added to the group, you could use a GPO > to turn on auditing of "Account Management" but then you would have to > search the audit logs of all of the DCs in the domain to find the activity . > > Or you could write a script that looked at the group membership and compared > it with a pre-determined list. Then execute the script on a schedule of your > choice. > > -----Original Message----- > From: Aaron Visser [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 10, 2004 9:51 AM > To: [EMAIL PROTECTED] > Subject: [ActiveDir] Security > > I need to know when the Domain Admin Group has a user added to it or at > least have that operation audited, is there anyway to perform this with GPO > or something built into win2k server. > > Thanks, > Aaron Visser > > 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/ 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/
