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

Reply via email to