Delegated access to other members in AD organization

[swamipurnamsha]

Hi @jacobsen9026 definitely we would like to have blazam for an AD delegation for non IT members. Sharing the use case below:

Use Case 1:
The tasks we are currently doing in AD on daily basis:
Creating users, Enabling/Disabling users, Resetting passwords, Assigning/Unassigning users to groups, Mapping computers to users.
All these tasks are being done by a couple of people(lets call this group: helpdesk) and they do these taassks by accessing AD.

In order to make sure that AD data is not modified unintentionally by helpdesk, we need to stop anyone from accessing Active directory directly (except a couple of admins).

Blazam can help in this case where we need to provide these group of people a non-superuser access through Blazam and the above mentioned administrative tasks can be performed through Blazam. But currently due to a bug in Blazam, helpdesk members are not able to perform these tasks (but a blazam super user can perform just fine)

Use case 2:
We have different departments in our organization which are represented by different OUs in AD.
We want to delegate these administrative tasks to the respective departments.
In order for that to happen, we need a couple of persons from each OU/department(lets call these couple of people: dept_spoc group) to be given a non-superuser access to Blazam. Effectively, there will be 1 dept spoc group in each departmet/OU.
And they can login to Blazam and perform these tasks for members of their own departments.

The important thing here is that they should not be able to perform these actions on any OU/department, other than their own.

For this we need to set access permissions for each dept_spoc group in such a way that this group can not modify any property outside their own department/OU.
(Right now it is not possible in Blazam).

[jacobsen9026]

Thank you for this submission...

Use Case 1:

The use case you describe is exactly what I designed this app for, and I want it to be able to fulfil every aspect of your usage. Having said that, I'm a little confused, is there more than the create users that is not working for non-supers?

Please explains more if that is the case. I have my own colleagues using this for some of those other purposes without issue (namely assigning and un-assigning, there is a little confusion with group member and parent groups, thinking on how to clarify/separate the two).

Use Case 2:
I apologize but I am again not fully understanding the problem as this use case is again, exactly what Blazam is designed for, and seems to overlap quite a bit with Use Case 1, so can we just combine them.

Note: Blazam allows for delegating administrative permissions to groups -> for OU's (not groups).

If you have all your departments setup in separate OU's then Blazam is currently fully capable of fulfilling that use case. You also need a group, or an individual users in Blazam, to assign the permissions to perform said actions on said OU, and I'm unclear what would prevent any of the assigned privileges from being performed.

I want to point out one rule with group management, the delegate must have read permission to the group to be able to assign to it.

But other than that, you might have to get more specific with a specific function to help further.

At worst I may need to see the permissions and inherited permissions applied .

Thank you.

[isha-arunnegi]

Hi @jacobsen9026

Thanks for the response :)
[I am working with @swamipurnamsha on this]

Use Case1: Problem we faced was only in creating users from non-super users. Other functions for non-super users are working very fine.
Attaching the screenshot explaining the issue when creating user.

Use Case2: Here we need that a user from one department should not be able to edit the properties of a user from other departments.
Right now we see that a user from one department can edit the properties of users of a different department. Are we missing something here?

We have the Use case 1 as a higher priority right now, as it is a basic task we are handling on a daily basis.

Thanks :)

[jacobsen9026]

Good day,

Use Case 1: has been fixed in Dev branch, Stable update coming tomorrow or Monday.

Use Case 2: If each department has it's own OU, then it is possible with appropriate permission mapping. Create a cross-department edit access level, and map for the group containing approved department users the other departments OU with that access level.

[jacobsen9026]

Regarding the mapping computers to users, is that for VDI? If not, please elaborate. Thank you.

[isha-arunnegi]

> Regarding the mapping computers to users, is that for VDI? If not, please elaborate. Thank you.

Hi @jacobsen9026
It is not for VDI.
We just need a certain user to be able to log into only certain few computers in the domain.
In AD, when we go to a user details: there is "Log On To" button inside the tab: "Account". On clicking this button it opens up a text box where we can fill the computer names where this user is allowed to log in.
We are able to achieve this using Blazam, by adding the field "userWorkstations". It is working fine.

Thanks

[jacobsen9026]

> Regarding the mapping computers to users, is that for VDI? If not, please elaborate. Thank you.

Hi @jacobsen9026 It is not for VDI. We just need a certain user to be able to log into only certain few computers in the domain. In AD, when we go to a user details: there is "Log On To" button inside the tab: "Account". On clicking this button it opens up a text box where we can fill the computer names where this user is allowed to log in. We are able to achieve this using Blazam, by adding the field "userWorkstations". It is working fine.

Thanks

Thank you @isha-arunnegi,

I'm glad to hear that the custom fields allow you to do this, but I can understand the desire to have it pull the computer names from AD for you so you are not typing in workstation names manually.

I will add that to the list of features to be added to a future update. Possibly 0.9.3, probably 0.9.4

I've opened another issue #318 for this feature request. I will be closing this issue as it is mostly resolved by the update today.

If you haven't anything else you would like to add, please reply to issue #318

Thank you.