Hi, What do you mean with "I will have to delegate him permissions at the top since he can't be an Account Operator anymore". And by the way... which top? Jorge
________________________________ From: [EMAIL PROTECTED] on behalf of Tony Murray Sent: Tue 12/20/2005 8:55 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] adminCount attribute That's correct. In Windows 2000 SP4 and in Windows Server 2003 the Account Operators group is protected. For a full list of protected groups and accounts, see the following KB article. http://support.microsoft.com/?kbid=907434 Tony ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Wednesday, 21 December 2005 8:24 a.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] adminCount attribute I did just find that he's a member of a group which is a member of Account Operators group. So I need to remove him from this group in order for his adminCount to stay <not set>? If that's true, then I will have to delegate him permissions at the top since he can't be an Account Operator anymore. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Tuesday, December 20, 2005 1:19 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] adminCount attribute The user was removed from all protected groups long ago. The problem is, his adminCount attribute is still getting set back to 1. I set it to <not set>, enable ACL inheritence and set his default permissions back, and an hour later I re-check his account and adminCount is set back to 1, and the security context on his account isn't correct anymore again. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Tuesday, December 20, 2005 9:10 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] adminCount attribute The adminsdholder process only looks at users and groups that are defined in AD as protected objects. As mentioned in MS-KBQ817433 - "Delegated permissions are not available and inheritance is automatically disabled" it is possible to include or exclude some of the default admin groups (account operators, print operators ,etc.) The process that checks object against the adminSDHolder object only looks at that definition of protected objects and in case of groups it will also look at its members. It resets the DACL to match the DACL of the adminSDHolder object and sets the admincount attribute to 1 and disables ACL inheritance on the protected object The group membership of a protected group is the criteria the process looks at, not the attribute value of 1. The admincount attribute is just an administrative measure for the process that says "been here", nothing else. So if you want the user not being protected anymore by adminsdholder, remove its membership from the protected groups (default MS admin groups). When that is done enable ACL inheritance, reset the default permissions and set adminCount=<not set> Cheers, jorge ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Tuesday, December 20, 2005 15:49 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] adminCount attribute I have a user that was migrated from our old NT4 domain into our AD domain as a domain admin. We removed him from domain admins on the AD side. I set his 'adminCount' attribute to <blank> from 1 so others could modify his account. Every time I blank out the 1 setting, I look the next day and it's set back to 1. I know there's some protection on these types of accounts set into AD, but how do I prevent this from auto-changing back to 1 each time I set it to <blank>? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<<winmail.dat>>
