Implication of using the Manager attrib to the User Obj

I cannot find any documentation on the implication of adding a user to the
Manager attribute to the User object.

Thank you.

"Walter D''''Souza" <> wrote in
message news:F7F9CED6-68E5-4534-B6AD-...
>I cannot find any documentation on the implication of adding a user to the
> Manager attribute to the User object.

As I understand it, managedBy is a one-to-many relationship that can be used
to represent the hierarchical relationship of user accounts in an
organization. I do not know if this confers any sort of privilege on the
manager that would allow, for example, a manager to manage the accounts of
those reporting to him or her.

The manager of a distribution list can be allowed to modify the membership
of the list (typically using the email client). I tried this on a security
group and found that the manager account seemed to have no privileged
whatsoever as a result of being declared manager. I strongly suspect that
would be the same for managers of user accounts.

/Al

Al I greatly appreciate your response. I did test this to make sure that a
manager could not get to others mail or have privilidges. However, I just
wanted to be sure that there would be no security implications down the road.
It would have been nice if Microsoft had a matrix on what the various
attributes are and its role in either application or OS. I hope Microsoft
Engineers pick this up.

Thanks again Al.

....Walter

"Al Dunbar" wrote:

>
> "Walter D''''Souza" <> wrote in
> message news:F7F9CED6-68E5-4534-B6AD-...
> >I cannot find any documentation on the implication of adding a user to the
> > Manager attribute to the User object.
>
> As I understand it, managedBy is a one-to-many relationship that can be used
> to represent the hierarchical relationship of user accounts in an
> organization. I do not know if this confers any sort of privilege on the
> manager that would allow, for example, a manager to manage the accounts of
> those reporting to him or her.
>
> The manager of a distribution list can be allowed to modify the membership
> of the list (typically using the email client). I tried this on a security
> group and found that the manager account seemed to have no privileged
> whatsoever as a result of being declared manager. I strongly suspect that
> would be the same for managers of user accounts.
>
> /Al
>
>
>

ManagedBy is confusing because if you change it in the ADUC GUI, ADUC will
actually try to change the permissions on the object to allow the user
pointed to by the attribute value so that this user can modify the group
membership. However, this is only done by the GUI. If you change the value
programmatically, nothing happens (unless you also programmatically change
the ACL). Also, if you programmatically change the ACL but don't set the
managedBy, the user in the ACL change will have the permissions.

Essentially, managedBy has nothing to do with the actual directory
permission model.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Walter D''''Souza" <> wrote in
message newsECD6977-58A9-49B4-84FC-...
> Al I greatly appreciate your response. I did test this to make sure that
> a
> manager could not get to others mail or have privilidges. However, I
> just
> wanted to be sure that there would be no security implications down the
> road.
> It would have been nice if Microsoft had a matrix on what the various
> attributes are and its role in either application or OS. I hope Microsoft
> Engineers pick this up.
>
> Thanks again Al.
>
> ...Walter
>
> "Al Dunbar" wrote:
>
>>
>> "Walter D''''Souza" <> wrote in
>> message news:F7F9CED6-68E5-4534-B6AD-...
>> >I cannot find any documentation on the implication of adding a user to
>> >the
>> > Manager attribute to the User object.
>>
>> As I understand it, managedBy is a one-to-many relationship that can be
>> used
>> to represent the hierarchical relationship of user accounts in an
>> organization. I do not know if this confers any sort of privilege on the
>> manager that would allow, for example, a manager to manage the accounts
>> of
>> those reporting to him or her.
>>
>> The manager of a distribution list can be allowed to modify the
>> membership
>> of the list (typically using the email client). I tried this on a
>> security
>> group and found that the manager account seemed to have no privileged
>> whatsoever as a result of being declared manager. I strongly suspect that
>> would be the same for managers of user accounts.
>>
>> /Al
>>
>>
>>

Joe,
Thank you for your response. I agree with you it is confusing. I have
done that on the group objects and there is a checkbox to modify the list.
By first glance because it works on groups I would assume the behaviour is
the same on user objects.
But on the user objectI do not seem to be able to edit anything by the
manager. Which is what I am looking for.

...Walter

"Joe Kaplan" wrote:

> ManagedBy is confusing because if you change it in the ADUC GUI, ADUC will
> actually try to change the permissions on the object to allow the user
> pointed to by the attribute value so that this user can modify the group
> membership. However, this is only done by the GUI. If you change the value
> programmatically, nothing happens (unless you also programmatically change
> the ACL). Also, if you programmatically change the ACL but don't set the
> managedBy, the user in the ACL change will have the permissions.
>
> Essentially, managedBy has nothing to do with the actual directory
> permission model.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> "Walter D''''Souza" <> wrote in
> message newsECD6977-58A9-49B4-84FC-...
> > Al I greatly appreciate your response. I did test this to make sure that
> > a
> > manager could not get to others mail or have privilidges. However, I
> > just
> > wanted to be sure that there would be no security implications down the
> > road.
> > It would have been nice if Microsoft had a matrix on what the various
> > attributes are and its role in either application or OS. I hope Microsoft
> > Engineers pick this up.
> >
> > Thanks again Al.
> >
> > ...Walter
> >
> > "Al Dunbar" wrote:
> >
> >>
> >> "Walter D''''Souza" <> wrote in
> >> message news:F7F9CED6-68E5-4534-B6AD-...
> >> >I cannot find any documentation on the implication of adding a user to
> >> >the
> >> > Manager attribute to the User object.
> >>
> >> As I understand it, managedBy is a one-to-many relationship that can be
> >> used
> >> to represent the hierarchical relationship of user accounts in an
> >> organization. I do not know if this confers any sort of privilege on the
> >> manager that would allow, for example, a manager to manage the accounts
> >> of
> >> those reporting to him or her.
> >>
> >> The manager of a distribution list can be allowed to modify the
> >> membership
> >> of the list (typically using the email client). I tried this on a
> >> security
> >> group and found that the manager account seemed to have no privileged
> >> whatsoever as a result of being declared manager. I strongly suspect that
> >> would be the same for managers of user accounts.
> >>
> >> /Al
> >>
> >>
> >>
>
>

Unfortunately, what you really need to be doing is delegating permissions.
This little piece of functionality in ADUC doesn't really apply to your use
case.

The key thing to decide is what you would want the user set up as manager to
actually be able to modify. There are many more options for users than with
groups, so this is a more difficult choice to make. For example, you could
allow changing of all sorts of account info or demographics details,
password reset, disable/enable, etc. If you decided exactly what you wanted
the manager person to be able to do, then you could script the changes to
the ACL. Alternately, if your delegation model permitted, you might
consider grouping users under OUs by manager so that you could delegate
inheritable permissions from the parent container.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Walter D''''Souza" <> wrote in
message news:BB79DCD2-C797-4972-AA97-...
> Joe,
> Thank you for your response. I agree with you it is confusing. I have
> done that on the group objects and there is a checkbox to modify the list.
> By first glance because it works on groups I would assume the behaviour is
> the same on user objects.
> But on the user objectI do not seem to be able to edit anything by the
> manager. Which is what I am looking for.
>
> ..Walter
>
> "Joe Kaplan" wrote:
>
>> ManagedBy is confusing because if you change it in the ADUC GUI, ADUC
>> will
>> actually try to change the permissions on the object to allow the user
>> pointed to by the attribute value so that this user can modify the group
>> membership. However, this is only done by the GUI. If you change the
>> value
>> programmatically, nothing happens (unless you also programmatically
>> change
>> the ACL). Also, if you programmatically change the ACL but don't set the
>> managedBy, the user in the ACL change will have the permissions.
>>
>> Essentially, managedBy has nothing to do with the actual directory
>> permission model.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> "Walter D''''Souza" <> wrote in
>> message newsECD6977-58A9-49B4-84FC-...
>> > Al I greatly appreciate your response. I did test this to make sure
>> > that
>> > a
>> > manager could not get to others mail or have privilidges. However, I
>> > just
>> > wanted to be sure that there would be no security implications down the
>> > road.
>> > It would have been nice if Microsoft had a matrix on what the various
>> > attributes are and its role in either application or OS. I hope
>> > Microsoft
>> > Engineers pick this up.
>> >
>> > Thanks again Al.
>> >
>> > ...Walter
>> >
>> > "Al Dunbar" wrote:
>> >
>> >>
>> >> "Walter D''''Souza" <> wrote in
>> >> message news:F7F9CED6-68E5-4534-B6AD-...
>> >> >I cannot find any documentation on the implication of adding a user
>> >> >to
>> >> >the
>> >> > Manager attribute to the User object.
>> >>
>> >> As I understand it, managedBy is a one-to-many relationship that can
>> >> be
>> >> used
>> >> to represent the hierarchical relationship of user accounts in an
>> >> organization. I do not know if this confers any sort of privilege on
>> >> the
>> >> manager that would allow, for example, a manager to manage the
>> >> accounts
>> >> of
>> >> those reporting to him or her.
>> >>
>> >> The manager of a distribution list can be allowed to modify the
>> >> membership
>> >> of the list (typically using the email client). I tried this on a
>> >> security
>> >> group and found that the manager account seemed to have no privileged
>> >> whatsoever as a result of being declared manager. I strongly suspect
>> >> that
>> >> would be the same for managers of user accounts.
>> >>
>> >> /Al
>> >>
>> >>
>> >>
>>
>>

"Joe Kaplan" <> wrote in message
news:...
> Unfortunately, what you really need to be doing is delegating permissions.
> This little piece of functionality in ADUC doesn't really apply to your
> use case.
>
> The key thing to decide is what you would want the user set up as manager
> to actually be able to modify. There are many more options for users than
> with groups, so this is a more difficult choice to make. For example, you
> could allow changing of all sorts of account info or demographics details,
> password reset, disable/enable, etc. If you decided exactly what you
> wanted the manager person to be able to do, then you could script the
> changes to the ACL. Alternately, if your delegation model permitted, you
> might consider grouping users under OUs by manager so that you could
> delegate inheritable permissions from the parent container.

Structuring permissions by OU containership is, in my opinion, unmanageable.
And, depending on the technical background the managers have, it may be
foolish to even think that it would be reasonable for account management to
be based on organizational hierarchy. I know it would be in mine.

In those cases where management of a distribution list is delegated, we
often find out that the lists are not properly updated, and we receive
requests for changes anyway.

/Al

> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services
> Programming"
> http://www.directoryprogramming.net
> "Walter D''''Souza" <> wrote in
> message news:BB79DCD2-C797-4972-AA97-...
>> Joe,
>> Thank you for your response. I agree with you it is confusing. I have
>> done that on the group objects and there is a checkbox to modify the
>> list.
>> By first glance because it works on groups I would assume the behaviour
>> is
>> the same on user objects.
>> But on the user objectI do not seem to be able to edit anything by the
>> manager. Which is what I am looking for.
>>
>> ..Walter
>>
>> "Joe Kaplan" wrote:
>>
>>> ManagedBy is confusing because if you change it in the ADUC GUI, ADUC
>>> will
>>> actually try to change the permissions on the object to allow the user
>>> pointed to by the attribute value so that this user can modify the group
>>> membership. However, this is only done by the GUI. If you change the
>>> value
>>> programmatically, nothing happens (unless you also programmatically
>>> change
>>> the ACL). Also, if you programmatically change the ACL but don't set
>>> the
>>> managedBy, the user in the ACL change will have the permissions.
>>>
>>> Essentially, managedBy has nothing to do with the actual directory
>>> permission model.
>>>
>>> --
>>> Joe Kaplan-MS MVP Directory Services Programming
>>> Co-author of "The .NET Developer's Guide to Directory Services
>>> Programming"
>>> http://www.directoryprogramming.net
>>> "Walter D''''Souza" <> wrote in
>>> message newsECD6977-58A9-49B4-84FC-...
>>> > Al I greatly appreciate your response. I did test this to make sure
>>> > that
>>> > a
>>> > manager could not get to others mail or have privilidges. However, I
>>> > just
>>> > wanted to be sure that there would be no security implications down
>>> > the
>>> > road.
>>> > It would have been nice if Microsoft had a matrix on what the various
>>> > attributes are and its role in either application or OS. I hope
>>> > Microsoft
>>> > Engineers pick this up.
>>> >
>>> > Thanks again Al.
>>> >
>>> > ...Walter
>>> >
>>> > "Al Dunbar" wrote:
>>> >
>>> >>
>>> >> "Walter D''''Souza" <> wrote in
>>> >> message news:F7F9CED6-68E5-4534-B6AD-...
>>> >> >I cannot find any documentation on the implication of adding a user
>>> >> >to
>>> >> >the
>>> >> > Manager attribute to the User object.
>>> >>
>>> >> As I understand it, managedBy is a one-to-many relationship that can
>>> >> be
>>> >> used
>>> >> to represent the hierarchical relationship of user accounts in an
>>> >> organization. I do not know if this confers any sort of privilege on
>>> >> the
>>> >> manager that would allow, for example, a manager to manage the
>>> >> accounts
>>> >> of
>>> >> those reporting to him or her.
>>> >>
>>> >> The manager of a distribution list can be allowed to modify the
>>> >> membership
>>> >> of the list (typically using the email client). I tried this on a
>>> >> security
>>> >> group and found that the manager account seemed to have no privileged
>>> >> whatsoever as a result of being declared manager. I strongly suspect
>>> >> that
>>> >> would be the same for managers of user accounts.
>>> >>
>>> >> /Al
>>> >>
>>> >>
>>> >>
>>>
>>>
>

I take your point here Al, but I would also suggest that there really is no
good way to do what he wants in a manageable way. If he did not delegate
the permissions by container, he would instead be delegating permissions to
individual objects. That could potentially be done via some sort of script
or provisioning system and kept tidy, but it would likely be a mess
otherwise.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Al Dunbar" <> wrote in message
news:...
>
>
> Structuring permissions by OU containership is, in my opinion,
> unmanageable. And, depending on the technical background the managers
> have, it may be foolish to even think that it would be reasonable for
> account management to be based on organizational hierarchy. I know it
> would be in mine.
>
> In those cases where management of a distribution list is delegated, we
> often find out that the lists are not properly updated, and we receive
> requests for changes anyway.
>
> /Al
>