RE: [ActiveDir] Security permissions on user object

[Robert Williams \(RRE\)]

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 J   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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~