Sorry I was hopped up on headache medicine last night for the weather front moving through hear. Maybe I am incoherent.
Lockout polices, password policies, the restricted groups, that is all info that is stored in and replicated through AD and GPO's both... Consider these attributes that replicate through AD processes but are set through GPO which replicates on its own: lockoutDuration lockoutObservationWindow lockoutThreshold maxPwdAge minPwdAge minPwdLength pwdProperties pwdHistoryLength And then restricted groups obviously are simply modifying group membership and that replicates as well. So for example say you have a policy on one DC that sets a lockout threshhold of 5 bad and then that same policy hasn't replicated to another DC properly and has a value of 15. The one DC will keep switching the value in AD to 15 and the other will keep switching it to 5. Restricted groups you would see the same behavior. Now if all DCs are properly processing all of the same GPOs then I agree there shouldn't be an issue. The issues come in when GPOs aren't consistent or people start doing funky linking/blocking for DCs by putting them in different Ous and linking different policies to them for some of these attribs. It has always bothered me that you can set something that replicates through two different channels like that. In the early days I was actually threatening to turn off FRS because I was having so many problems with it due to this flipping as a policy change wouldn't make it around properly. Microsoft PSS was all over me like YOU CAN'T SHUT IT OFF, Don't do it!!! It is the number one issue I have had with AD in terms of having to get buddy drops and apply hotfixes for through the years. It seems that as soon as we went over about 50 domain controllers in an given domain FRS started to blow on us. The one following that was LSASS leaks. I do have to say that both are MUCH more stable now than they were. I still don't trust FRS though which is why everytime I make any change in sysvol I have to run a CRC checker program that checks CRCs of every SYSVOL on every DC. ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Tuesday, March 16, 2004 12:06 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Group Policy Joe- Not sure what you mean by that first sentence??? Most or all of those security settings aren't stored in AD so I'm surprised that they are seeing version numbers craziness. I can understand the issue where you have conflicting GPOs being delivered from both the domain and DC policies, but in general, they should be processed one after the other during foreground and backgrund processing and the "flipping" behavior shouldn't be a huge issue. Restricted Groups, however, is a dangerous business. Gotta keep that out of the kids hands :-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, March 15, 2004 5:01 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Group Policy It is a bad thing when the policies don't match up for different DCs that set AD attributes that replicate through AD replication. When I went back to where I am now the company that had been mismanaging in my absence had somehow gotten the default DC policies and default domain policies out of sync and you get battles in AD for the things that replicate with the GPO and also through AD, such as lockout settings, restricted groups, etc. You will see the values flipping back and forth as a DC realizes it doesn't match the local policy and corrects it. You will see your version numbers on those attributes really spike as well obviously. At one point we had a restricted group for administrators/domain admins and the new admins we put in would get kicked out and replaced with the old admins, wait a little while and then we were back. It ping ponged for a couple of hours until I traced it all down to which DCs were out of sync and got them corrected. They had also set the GPO to remove the builtin Admin ID from administrators from one domain which was REALLY screwing up that domain and causing resource errors like crazy on about 80% of the DCs of that domain. ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Monday, March 15, 2004 11:39 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Group Policy DCs get their Account Policy, and a couple of other security settings, from any GPO linked to the domain, not necessarily just the Default Domain Policy. If you have no domain-linked policy, then the DCs will just use the local policy they have by default, out of the box. A quick test with my VMWare-2003 DC shows this to be true. The question I would have is, if you set, for example, account policy on one DC to be different than another DC, and there is no domain-linked GPO or its disabled, what happens? Who wins? If I had more than one test DC at the moment, it would be an interesting test. Anyone interested in the experiment? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 14, 2004 9:57 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Group Policy Yes they do. The default domain policy is where your domain security policy is located at. What implications are there for blocking it... I am not sure, never tried... Let us know. :o) ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Shukovsky Jr Sent: Thursday, February 26, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Group Policy Do W2k domain controllers need to process default domain policy as well as default dc policy? If so and the DC's OU is set to block default domain policy what implications will/can this have? thanks in advance. This E-mail, including any attachments, may be intended solely for the personal and confidential use of the sender and recipient (s) named above. This message may include advisory, consultative and/or deliberative material and, as such, would be privileged and confidential and not a public document. Any Information in this e-mail identifying a client of the department of Human Services is confidential. If you have received this e-mail in error, you must not review, transmit, convert to hard copy, copy, use or disseminate this e-mail or any attachments to it and you must delete this message. You are requested to notify the sender by return e-mail. 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/
