Hi joe, Just a notice: "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." This is also the case for the users belonging to those protected groups: they have no control to each of their users object. I have the case that some account operators could not reset passwords nor modify users informations (as sn, givenname,...) when those users belong to protected groups, in my case it was print op. It seems that domain admins have FC to those protected users Yann
________________________________ De: [EMAIL PROTECTED] de la part de joe Date: mar. 20/12/2005 21:58 À: [email protected] Objet : RE: [ActiveDir] adminCount attribute 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: [email protected] 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: [email protected] 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: [email protected] 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: [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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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>>
