RBAC: Managing only(!) CIFS sessions via MMC?

[KOOPMANSABU]

Dear community,

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?

[KOOPMANSABU]

Nobody? Anybody? Come on guys & girls! Is there nobody out there who can help me out here?

[RichardSopp · Accepted solution]

Bjorn,

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.

[KOOPMANSABU]

Hi Richard,

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!

Bjorn

[RichardSopp]

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.

[KOOPMANSABU]

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.

[KOOPMANSABU]

Hm, I'm unable to set your reply as 'Answered'. Or any reply for that matter...

EDIT: and now I am... weird.

[NEILHOLMES]

Hi KOOPMANSABU,

did you ever come up with a satisfactory solution to this issue?. I'm in the same situation. I want to empower help desk staff to be able to clear locked files but not have more advanced access. We have AD joined, CIFS enabled NetApp filers. We can provide them with full access to the data (via AD permissions at the folder level) in order to be able to carry out file restores.

I want them to be able, for example to go to Computer Mangerment > System Tools > Shared Folders > Open Files on their Windows 7 desktops and clear file locks but I dont want them to be able to go to Computer Mangerment > System Tools > Shared Folders > Shares and Stop Sharing a CIFS share.

Any suggestions from your experience with this dilemma would be appreciated.

[adaikkap]

Hi Neils,

     Is there a specific reason that you are looking at WFA to automate this ?

Regards

adai

[NEILHOLMES]

Hi adai,

I'm looking for any way that I can achieve what I require. From what I have read previously, the suggestion is that you cannot clear connections or clear locked files on filer hosted CIFS unless your Active Directory account is listed as (at least) a Power User on the NetApp filer that is hosting the CIFS service. With this elevated permission, you can then use something like Windows Computer Management to view and clear file locks.

The problem is that I do not want to provide untrained staff with all of the additional filer management access that comes with being a Power User as this introduces a business risk. All I require is a way to give elevated permissions so that tier 1 support staff have more control over the management of CIFS. Do you know the best way of achieving this?.

Many thanks.

[whapuku]

Hi Neil/Adai,

We are in the same boat here (so to speak)! Were you able to get a satisfactory outcome to this?

We also want to allow the Desktop support team to close "locked" files using the Windows MMC but without allowing them unnecessary elevated rights to the filers/vfilers. Can you let me know please how you got around this?

WH

[KevinC]

I also need a solution to this problem... allowing Desktop Support group to close open files, preferrably through MMC.

I'm using OnTap 8.2.1 in Cluster Mode.

[amitr]

same problem here