Grant permission to edit a user when the initiatior DN is present in the SeeAlso attribute

Question

We are using the SeeAlso attribute to store who is responsible for specific accounts.

We do not wish to use the Manager field, because the Manager/Direct Report structure is reflected in org charts in many applications we use.

So we implemented the SeeAlso attribute to store the DN of the "Account Owner"

The only bit we are missing is to grant permissions to edit a user when the initiatior DN is present in the SeeAlso attribute. This way, if my DN is present in the SeeAlso attribute for a user, I have rights to, for example, extende the expiration date of an account.

Is that possible?

Answer 1

Hello Manuel,

Yes, it is possible using a dynamic Business Unit and a Security Role. For each user the Business Unit will contain only the accounts that have them specified in the See Also property and will be used to assign the Security Role. For information on how to create dynamic Business Units, have a look at the following tutorial: https://www.adaxes.com/tutorials_ActiveDirectoryManagement_CreateDynamicBusinessUnit.htm. On step 3 of the guide, select Query Results and enter the following LDAP filter into the corresponding field: (&(sAMAccountType=805306368)(seeAlso=%distinguishedName%)) The Security Role will look like the following: Additionally, you might consider using the Assistant or Secretary property to store managers. In this case, you will not need a Business Unit and the Security Role will look like the following:

Comments

Thank you very much, this solves it.

We wish to use the SeeAlso because it allows multiple values to be used (so that multiple users can have permissions over multiple objects).

This worked perfect as you suggested

---

Hello Manuel,

Thank you for the confirmation.

For you information, the Secretary property is also multi-valued, so you might consider using it to store multiple managers and avoid using the Business Unit.

---

I wasn't aware Secretary is also multi-valude. Great info, thanks!

---

After giving it some thoughts, using the Secretary field makes sense, considering that is also multi valued.

I am a little confused by the example you show, where the permissions show the Trustee to be "Assistant". Shouldn't it be "Secretary"?

---

Hello Manuel,

Yes, you are absolutely right. It was just an example on how you can use either of the security principals. According to your screenshot, the Security Role should work just fine.