In 389 Directory Server, the "Directory Manager" user is an unrestricted user account that bypasses all resource limitations and access control. Currently, you cannot configure other user accounts with per resource limits, or to also bypass resource limits like the Directory Manager. Adding this feature would be helpful to administrators who want to allow certain users to administer the directory server without giving out (or having a separate) directory manager password, which may be used in places other than the directory server.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html
Does this do what you want? If not, can you please elaborate about what exactly you're looking for?
Yes, that does what I need. Is there a way to apply this to a group, so I can easily add/remove users without having to edit them individually? For example, I have 10 users and I need to increase their resource limits. The limits should be the same for each user, but I want to be able to easily add/remove accounts to the group to accommodate staffing changes. It's not a deal breaker if I can't, but it'd be easier if I could do it that way.
Use resource limits in conjunction with Class of Service for group/role based limits. http://port389.org/wiki/Howto:ClassOfService
closing since this isn't really a bug
Metadata Update from @rmeggins: - Issue set to the milestone: N/A
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/644
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Invalid)
Login to comment on this ticket.