User Account

Archived from groups: microsoft.public.win2000.active_directory (More info?)

You should go to the ACL of that account and modify permissions appropriate
to your scenario.

--
Dmitry Korolyov [d__k@removethispart.mail.ru]
MVP: Windows Server - Directory Services


"vincent-nyc" <vincentnyc@discussions.microsoft.com> wrote in message
news:34DAF3A3-4554-4288-B7AC-C3047850EB1C@microsoft.com...
> Hi All,
>
> I have a user account that was originally part of the Account Operators
> group. This account was removed from the Account Operators group, but no
> one
> in the Account Operators group can modify this account. Only the Domain
> Admins can modify this account. Any reasons why the Account Operators
> can't
> modify the account?
>
> Thank You.

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Jorge,

Thanks for your reply. The information you provided was right-on the money
and very detailed! Thanks very again for your help.

"Jorge_de_Almeida_Pinto" wrote:

> "" wrote:
> > Hi All,
> >
> > I have a user account that was originally part of the Account
> > Operators
> > group. This account was removed from the Account Operators
> > group, but no one
> > in the Account Operators group can modify this account. Only
> > the Domain
> > Admins can modify this account. Any reasons why the Account
> > Operators can't
> > modify the account?
> >
> > Thank You.
>
> The operators group is a protected group. Every protected group and
> each member of that group is protected by the adminSDholder object in
> the domain and will have property admincount =1 and permissions
> inheritance will be disabled.
>
> for more info see:
> MS-KBQ232199_Description and Update of the Active Directory
> AdminSDHolder Object
>
> MS-KBQ817433_Delegated permissions are not available and inheritance
> is automatically disabled.
>
> And you don’t want to change the permissions of the adminsdholder
> object so that each account operators members can manage each other as
> those will then also have the possibility to manage other protected
> groups and its members.
>
>
> The best best is to delegate permissions and not use the default admin
> groups...
> A tip for delegation (per organization this may depend, but this
> should give you a hint how to do it):
> * create separate admin accounts to perform admin tasks
> * Define the admin roles in your organization
> * Define all the admin tasks performed by those roles in your
> organization
> * Create an OU for the Admin roles and the admin tasks
> * Do not delegate the management of the roles and the tasks to groups
> or persons other than the domain admins
> * Create an OU for the Admin accounts
> * Do not delegate the management of the admin accounts to groups or
> persons other than the domain admins
> * Create separate OUan OU for the Admin roles
> * Setup admin roles represented by a security groups in AD
> * Setup all kinds of tasks represented by a security groups in AD
> * Give the task groups the appropriate permissions in AD and on
> servers through the delegation of control wizard and through GPOs
> (restricted groups feature)
> * Make the role groups a member of the apropriate tasks
> * Make the admin accounts a member of the appropriate roles (most of
> the time 1 admin account only has one role assigned)
> * Protect the admin accounts OU, the admin roles and tasks OU
>
> For delegating tasks see the following white papers. They are very
> good!
> http://www.microsoft.com/downloads [...] layLang=en
> http://www.microsoft.com/downloads [...] layLang=en
>
> --
> Posted using the http://www.windowsforumz.com interface, at author's request
> Articles individually checked for conformance to usenet standards
> Topic URL: http://www.windowsforumz.com/Activ [...] 08008.html
> Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.windowsforumz.com/eform.php?p=1357331
>