If all he needs to do is reset passwords you want to do
this anyway. Acc Ops have considerable rights over groups and users as well as
the capability to add groups/users as desired. Obviously delegate to a group
versus the person directly. You may want to delegate the ability to unlock
accounts (WP lockoutTime) and expire/unexpire accounts (WP pwdLastSet) as
well.
Note that this delegation will not impact any accounts
protected by adminSDHolder so he won't be able to reset any users in the native
admin groups.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Tuesday, December 20, 2005 3:43 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] adminCount attribute
Well he's a helpdesk guy that needs to be able to reset
passwords for everyone in the domain, so I would need to delegate him
permissions at the highest level OU, whereas right now he's in account operators
so he automatically can do it. Once I remove him from account operators,
I'll have to delegate him the permissions.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de
Sent: Tuesday, December 20, 2005 2:24 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] adminCount attribute
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.
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |