Admin console on PC

KJ

Distinguished
Apr 12, 2004
67
0
18,630
Archived from groups: microsoft.public.win2000.active_directory (More info?)

Users who are delegated permissions to OU might have problems with a couple
of grayed out accounts in certain OU's. Others do not. What would cause this?
Rights are set per group that is delegated permissions.
 
G

Guest

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

This is because these accounts are protected accounts. That is, they are
administrators, account operators, etc.

There is an object in the directory called the adminSDHolder object. The
PDCe compares and resets the permissions defined on this object against all
users who are members of protected groups every sixty minutes. Furthermore,
by default these groups are not set to inherit. Which is why they are still
grayed out even though you've granted write permissions.

There are a number of ways round this:

Modify the permissions on the adminSDHolder object
Remove these users from the protected groups.
Implement a hotfix from MS that changes this behaviour a little bit.

The reason for this (it's by design) is so that delegated users cannot
modify the permissions of administrative user objects.

If you search google or MS support for adminSDHolder you should find a
couple of helpful KBs.

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/


"KJ" wrote:

> Users who are delegated permissions to OU might have problems with a couple
> of grayed out accounts in certain OU's. Others do not. What would cause this?
> Rights are set per group that is delegated permissions.
 

KJ

Distinguished
Apr 12, 2004
67
0
18,630
Archived from groups: microsoft.public.win2000.active_directory (More info?)

One helpdesk person can see this, another cannot. They have same permissions,
it seems to have something to do with PC.

"ptwilliams" wrote:

> This is because these accounts are protected accounts. That is, they are
> administrators, account operators, etc.
>
> There is an object in the directory called the adminSDHolder object. The
> PDCe compares and resets the permissions defined on this object against all
> users who are members of protected groups every sixty minutes. Furthermore,
> by default these groups are not set to inherit. Which is why they are still
> grayed out even though you've granted write permissions.
>
> There are a number of ways round this:
>
> Modify the permissions on the adminSDHolder object
> Remove these users from the protected groups.
> Implement a hotfix from MS that changes this behaviour a little bit.
>
> The reason for this (it's by design) is so that delegated users cannot
> modify the permissions of administrative user objects.
>
> If you search google or MS support for adminSDHolder you should find a
> couple of helpful KBs.
>
> --
>
> Paul Williams
>
> http://www.msresource.net/
> http://forums.msresource.net/
>
>
> "KJ" wrote:
>
> > Users who are delegated permissions to OU might have problems with a couple
> > of grayed out accounts in certain OU's. Others do not. What would cause this?
> > Rights are set per group that is delegated permissions.
 
G

Guest

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

"KJ" <KJ@discussions.microsoft.com> wrote in message
news:CBA14DBB-748A-4C69-AEB9-7628D3B8628D@microsoft.com...
> Users who are delegated permissions to OU might have problems with a
couple
> of grayed out accounts in certain OU's. Others do not. What would cause
this?

Perhaps the permissions were changed separately
on those objects, or the OU was changed after their
creation (without propagation or the objects disable
inheritance.)

Check the permissions on the objects themselves.

> Rights are set per group that is delegated permissions.

Right are not permission, so this is probably permissions
you mention.

Granting permissions (or rights) to a group containing
a user should be precisely equivalent (if the user has
logged on SINCE becoming a member.)

Of course, negative permission (Deny) can remove such
directly from the user or through a group membership as
well.

--
Herb Martin


"KJ" <KJ@discussions.microsoft.com> wrote in message
news:CBA14DBB-748A-4C69-AEB9-7628D3B8628D@microsoft.com...
> Users who are delegated permissions to OU might have problems with a
couple
> of grayed out accounts in certain OU's. Others do not. What would cause
this?
> Rights are set per group that is delegated permissions.
 

KJ

Distinguished
Apr 12, 2004
67
0
18,630
Archived from groups: microsoft.public.win2000.active_directory (More info?)

It was a propagation of rights issue. Thanks,

"Herb Martin" wrote:

> "KJ" <KJ@discussions.microsoft.com> wrote in message
> news:CBA14DBB-748A-4C69-AEB9-7628D3B8628D@microsoft.com...
> > Users who are delegated permissions to OU might have problems with a
> couple
> > of grayed out accounts in certain OU's. Others do not. What would cause
> this?
>
> Perhaps the permissions were changed separately
> on those objects, or the OU was changed after their
> creation (without propagation or the objects disable
> inheritance.)
>
> Check the permissions on the objects themselves.
>
> > Rights are set per group that is delegated permissions.
>
> Right are not permission, so this is probably permissions
> you mention.
>
> Granting permissions (or rights) to a group containing
> a user should be precisely equivalent (if the user has
> logged on SINCE becoming a member.)
>
> Of course, negative permission (Deny) can remove such
> directly from the user or through a group membership as
> well.
>
> --
> Herb Martin
>
>
> "KJ" <KJ@discussions.microsoft.com> wrote in message
> news:CBA14DBB-748A-4C69-AEB9-7628D3B8628D@microsoft.com...
> > Users who are delegated permissions to OU might have problems with a
> couple
> > of grayed out accounts in certain OU's. Others do not. What would cause
> this?
> > Rights are set per group that is delegated permissions.
>
>
>