Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delegated access to other members in AD organization #309

Closed
swamipurnamsha opened this issue Apr 18, 2024 · 6 comments
Closed

Delegated access to other members in AD organization #309

swamipurnamsha opened this issue Apr 18, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@swamipurnamsha
Copy link

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 jacobsen9026 added the enhancement New feature or request label Apr 21, 2024
@jacobsen9026 jacobsen9026 self-assigned this Apr 21, 2024
@jacobsen9026
Copy link
Contributor

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
Copy link

isha-arunnegi commented Apr 22, 2024

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.

createuser0
createuser1

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 jacobsen9026 added this to the v0.9.2 milestone Apr 23, 2024
@jacobsen9026
Copy link
Contributor

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.

githubanswer

@jacobsen9026
Copy link
Contributor

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

@isha-arunnegi
Copy link

isha-arunnegi commented Apr 30, 2024

> 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
Copy link
Contributor

> 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants