I am looking for a way to enable a few AD users to manage (close) CIFS sessions and files, preferably via an MMC console. But I can't seem to find it!
Situation: FAS 3240, DOT 8.1.2 7-Mode, Windows 2003 AD domain.
I created a role and a group on the vfiler and assigned a domainuser to the group. However, no matter how many capabilities I assign to this new role (even ' * ' ! ), I keep getting the error "Error 5: Access denied" when I click either 'Sessions", "Shares", or "Open Files" in the MMC console (connected to the vfiler). If I assign the same domainuser to the group "Power Users", it works perfectly. But I don't want to give these users all capabilities that "Power Users" offers.
If I modify the "Power Users" group to assign only the role "None" to it, users in this group are still able to manage shares/sessions! So it doesn't seem to matter what role (and thus capabilities) are assigned to "Power Users". It still provides all the access!
It seems that the group "Power Users" has rights/capabilities that are obtained outside the default associated role "power".
I checked the Administration Guide for DOT 8.2.1, but it doesn't mention anything about these 'hidden' capabilities. It does state that the MMC console is only accessible to (domain)users in the "Administrators" group, but that doesn't seem to be true, since members of "Power Users" also have this ability.
More importanty (for me): I don't seem to be able to use custom groups for administrative purposes. It least in this speific case.
Anyone has any suggestions?
There is a WIN32 RPC capability hidden as part of the "Power Users" group. This capability is outside of the role "power" and is embedded in the 'Power Users' group itself.
You can neither remove or add this hidden capability to the 'Power Users' group - it's just there. This is one of the short comings of the RBAC implementation in 7-mode in my opinion.as it clutters storage infrastructure administration and data administrator roles. Clustered ONTAP does a much better job of segregating these roles within a SVM albeit for you use case it currently does not support share/lock management via the MMC.
If you feel the role 'Power' gives too much in the way of privileges you could always modify the capabilities assigned to it to suit your needs BUT I would strongly recommend you test such changes in a non production environment first. If I recall the default privileges for the "Power Users" group are - Allowed Capabilities: cli-cifs*,cli-exportfs*,cli-nfs*,cli-useradmin*,api-cifs-*,api-nfs-*,login-telnet,login-http-admin,login-rsh,login-ssh (which may vary by ONTAP release) which stretches way beyond the least privilege approach I would consider for simple CIFS share and lock management.
Thanks for this explanation! It seems to concur with my findings.
If you ask me, this is indeed a ridiculous 'feature' in DOT. Especially since it's not documented (AFAIK), but even more so because it partly defeats the purpose of RBAC! The admin guide does state that only users in the Administrator group can access via the MMC, but not why. And more importantly: it's just not true, since this apparently also applies to the Power Users group.
In any case, it leaves me with three options: a) allow these users far more rights than necessary, b) modify the 'power' role, or c) learn these users how to use the cli! None of them great options...
Thanks again for this info Richard!
There's a fourth option you may wish to consider, WFA - Work flow automation.
If you're considering moving to a service model for your IT infrastructure this may be a good fit.
You can bypass the RBAC issues in ONTAP by leveraging controls in WFA and not have to teach folks to use a CLI (which also has a limited concurrent session count in 7-mode).
The time to setup and implement WFA will vary depending on the size, scale and complexity of your environment; and may be a very big hammer to crack this relatively small nut but at least you may want to consider it as an option. Just a thought.
Good suggestion, thank you. Problem is however that I'm unable to configure WFA for our DFM server, because I keep running into this bug, but the suggested solutions don't work for me.