OK this is odd, I changed admincount to 0 and an hour later it was changed back to 1. How frustrating. What gives?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Wednesday, June 08, 2005 10:05 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Security permissions on user object In fact, yes it will, Russ. Looking back at the thread, I don't see any discussion about HOW these users came to have the admincount attribute set to 1. Do you have a root cause? The reason that I ask is because I've dealt with this before when someone (who I never caught) added a group to a Protected group. This effectively set the admincount attribute on about 200 techs, and it took a while to clean up and straighten out. If you don't know why it happened, you might be reliving this pretty soon. Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Wednesday, June 08, 2005 9:52 PM To: Robert Williams (RRE); ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Security permissions on user object Can I just use ADSIEDIT and go to individual users and set the admincount to 0? Will that stick? If that works, I could write a winbatch that will prompt for a username, and set their admincount to 0 automatically. ________________________________ From: Robert Williams (RRE) [mailto:[EMAIL PROTECTED] Sent: Wed 6/8/2005 8:34 PM To: Rimmerman, Russ; ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Security permissions on user object Well...I guess you can reset it for all of them and count on the AdminSDHolder thread to reset them to 1 in about an hour or so...other than that, the logic needed in a script to differentiate between users who are / are not currently in one of the 'protected groups' would be astounding. You shouldn't have a problem trusting the fact that it will happen to the accounts still in the "protected groups" since that's what got you there in the first place :-) Hopefully that was helpful...have a great night! Robert Williams, MCSE NT4/2K/2K3, Security+ Infrastructure Rapid Response Engineer Northeast Region Microsoft Corporation Global Solutions Support Center ________________________________ From: Rimmerman, Russ [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 8:38 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Security permissions on user object OK looks like ya'll are on the right track. I found the script in the KB article to reset all the admincounts to 0, but that sounds scary. Can't I selectively set admincounts to 0 on a user-by-user basis somehow? Or is it safe to reset all users' admincounts to 0? I see "Administrator" in there, so that vbscript in http://support.microsoft.com/default.aspx?scid=kb;en-us;817433 scares me. ________________________________ From: [EMAIL PROTECTED] on behalf of Robert Williams (RRE) Sent: Wed 6/8/2005 6:36 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Security permissions on user object Also keep in mind that if you were ever a member of one of these 'protected groups' that your inheritance will not be "turned on" again, nor will the admincount attribute be reset to 0....so you can change those back when you know the user isn't a member of one of the 'protected groups' (changing those values before ensuring this will result in the values being reset...as you are well aware by this point). AdminCount is just a 'book keeping' method to know that the ACL has been stamped by AdminSDHolder. I hope that helps. Robert Williams, MCSE NT4/2K/2K3, Security+ Infrastructure Rapid Response Engineer Northeast Region Microsoft Corporation Global Solutions Support Center ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Free, Bob Sent: Wednesday, June 08, 2005 4:00 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Security permissions on user object It ssounds like it's the adminSDHolder behavior that's getting you. Are the users members of any of the other protected groups? It varies across versions, IIRC 2003 added more groups. The articles below should help point in the right direction. http://support.microsoft.com/default.aspx?scid=kb;en-us;318180 http://support.microsoft.com/default.aspx?scid=kb;en-us;817433 ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Wednesday, June 08, 2005 12:26 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Security permissions on user object We migrated all our users from an NT4 domain to our AD domain. Anyone who was in "Domain Admins" on our NT4 domain got migrated into "Domain Admins" on our AD domain. We took them out of Domain Admins on our AD domain, but their accounts are inheriting the permissions like a normal user inherits. Whenever someone who is NOT a domain admin tries to reset a password or modify any properties of these migrated "Domain Admins" who are no longer Domain Admins, they are denied access. If I open up one of these users, they are not inheriting the permissions on their user object like every other normal user does. If I open their account and go to the object security the "Inherit from parent the permission entries that apply to child objects. Include these with entries explicity defined here." box is not checked like every other user. If I check the box, others are temporarily able to modify that former domain admins account, but eventually, the box is unchecked again and they inherit their old security on their user object and it's broken again. I know that I once read that this is by design, but how the heck do I fix these users once and for all? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
