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

Allow to forbid password changes on specific user accounts #3286

Closed
AhmedBenmoussa opened this issue Jan 18, 2018 · 9 comments · Fixed by #4015
Closed

Allow to forbid password changes on specific user accounts #3286

AhmedBenmoussa opened this issue Jan 18, 2018 · 9 comments · Fixed by #4015
Assignees
Labels
area/authentication Affects user authentication or authorization enhancement New feature or improvement
Milestone

Comments

@AhmedBenmoussa
Copy link

Hello everyone,

I installed icinga2 as our monitoring tool in my company. My configuration consists of some users with different permissions.
I want to give all the users the ability to change their passwords. How do I add this permission without giving them access to all the configuration menu. Cauz in the permission list there is only (config/*). I also read in the Documentation that there is also (config/modules).
Is there any other sub categories ? if yes, what are the children of the config category ?

I'm using

  • icinga2 v2.4.1
  • icingaweb2 v2.1.0

Thank you in advance.
With all my respects, Ahmed.

@nilmerg
Copy link
Member

nilmerg commented Jan 18, 2018

Hi Ahmed,

I highly recommend you to consider an upgrade of Icinga Web 2. The latest version is v2.5 and includes the feature you're asking for without the need to change anything. (There users have the possibility to change their password in the preferences.)

Best regards,
Johannes

@dnsmichi
Copy link
Contributor

The original question was to add a specific permission to allow/deny password changes for users.

https://monitoring-portal.org/t/separating-monitored-hosts-by-account-type/636/5?u=dnsmichi

@Al2Klimov
Copy link
Member

#3286 (comment)

@dnsmichi
Copy link
Contributor

@Al2Klimov this is a feature request to add such a fine granular permission. I've talked to @lippserd and it does not yet exist. So why did you close this issue?

@Al2Klimov
Copy link
Member

No, it's definitively not:

I want to give all the users the ability to change their passwords.

#3286 (comment)

This is a feature request to let all users change their passwords – and this is already possible:

The latest version is v2.5 and includes the feature you're asking for without the need to change anything.

#3286 (comment)

@dnsmichi
Copy link
Contributor

This issue is coming from the linked forum post which applies roles to users. The question was if one could give users the permission to change their password, or to explicitly forbid it.

I'm aware of the feature to globally enable/disable that.

@AhmedBenmoussa
all the users in a global fashion, or all the users assigned to specific role?

@Al2Klimov Al2Klimov added enhancement New feature or improvement needs-feedback We'll only proceed once we hear from you again labels Jan 18, 2018
@Al2Klimov Al2Klimov reopened this Jan 18, 2018
@AhmedBenmoussa
Copy link
Author

Hello everyone,

Sorry if I didn't explain well my request. @dnsmichi is right. I want to add the ability of changing passwords inside the definition of a role.

Let me explain more in details:

  • I want to create different roles for all our administrators (System Admins, DB Admins, ...). Each administrator will have a personal account assigned to a specific role. In the definition of these roles, users will have the ability to change their passwords and only their passwords.

  • And I also want to create other roles. these roles will be assigned to a "group account" (supervisors for exemple). All the supervisors share the same account. So the password of this account must remain the same (they don't have the permission to change it). This can be done my ommiting the (config/*) permission.

Thank you in advance.

@nilmerg nilmerg changed the title Giving Users the ability to change the password Allow to forbid password changes on specific user accounts Jan 19, 2018
@nilmerg
Copy link
Member

nilmerg commented Jan 19, 2018

Hi Ahmed,

thanks for the feedback! I've renamed the issue to reflect the actual requirement.

Regarding your two examples:

  • This is possible with version 2.5 of Icinga Web 2. Whether an account is assigned to a role or not, everyone is able to change his/her own password. (If authenticated using a database backend) No access to the configuration (config/*) is required for this since it's done in an account's preferences.

  • Locking the ability of accounts to change their own password is not possible, neither with version 2.5 of Icinga Web 2. That's what this issue is about.

To also answer your question about any sub categories of the config/* permission: There are none, one has either full or no access to the configuration of Icinga Web 2. Even if we'll introduce a specific permission to only allow access to a authentication backend's configuration, this would allow access to all accounts, not only the one a user is currently logged in with.

Best regards,
Johannes

@nilmerg nilmerg added area/authentication Affects user authentication or authorization and removed needs-feedback We'll only proceed once we hear from you again labels Jan 19, 2018
@AhmedBenmoussa
Copy link
Author

AhmedBenmoussa commented Jan 21, 2018

Hello. Sorry for my late answer.

Thank you @nilmerg for your answer. I am happy to see that I can propose a new feature :)
Thank you and the development team for all the hard work that you are doing to give us such a powerful tool.

Thank you @dnsmichi for your support.

Best Regards,
Ahmed.

@lippserd lippserd modified the milestones: 2.7.0, 2.8.0 Apr 8, 2019
@nilmerg nilmerg self-assigned this Dec 9, 2019
@nilmerg nilmerg modified the milestones: 2.8.0-rc1, 2.8.0 May 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/authentication Affects user authentication or authorization enhancement New feature or improvement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants