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.
Tony
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Wednesday, 21 December 2005 8:24 a.m.
To: [email protected]
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: [email protected]
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: [email protected]
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: [email protected]
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
