Snapdrive Role Basec Access

[peter1965]

Greets all,

I just used snapdrive for the first time on a Windows 2k8 server. I have to say very slick. Something I am concerned about was admins creating additional disk/lins. I was wondering what folks have done (step by step) to lock down snapdrive?

What I mean is that I have a concern that if someone logs onto the server with local admin rights or domain admin rights that they can go off and create disks unbeknowst to anyone and add more space to that server. How can I prevent this? Role Based? If so, how or what other method?

Thank you for reading.

[shaunjurr]

Hi,

There is a "TR" for this but it is incredibly hard to find, if it is public at all. One can setup a least privileged user for SD (the SD user), but it is a real PITA on the CLI because of command line length limits.  DFM lets you do it a bit nicer.  Perhaps one of the NetApp guys could get the TR published for us mere mortals, hehe... I just have a paper copy... and it's on my desk at work...

RBAC is a bit of a pain on NetApp still...

Good Luck

[shaunjurr]

That's TR-3864... I found it by accident... the search interface is really terribly broken...

[peter1965]

So I must use dfm for this.. sigh

That admin guide is not the friendliest.

[watan]

Hi Peter,

http://www.netapp.com/us/library/technical-reports/tr-3864.html   was written for users that wanted to give users the bare minimum for very high security sites.  The easiest way to implement RBAC would be to use the DFM solution as you can modify,create,delete the roles & users from within the DFM interface.  The method described in the TR is for manual lockdown of the roles and apis from the storage cli. 

@shaunjurr , yes the cli string limit is an extreme pita when the command gets lengthy!!!

[john_graham]

Thanks, for the pointer to TR-3864. That is helpful. However, I don't think it answer's the OP's concern:

Peter1965 wrote:
What I mean is that I have a concern that if someone logs onto the server with local admin rights or domain admin rights that they can go off and create disks unbeknowst to anyone and add more space to that server. How can I prevent this?

This is a concern of one of my client's as well. If I understand the "Least Privilege Role" detailed in TR-3865 correctly, it still provides a local administrator on the server with SnapDrive installed a number of powerful rights. For instance, the creation of new LUNs (presumably anywhere on the storage system), the ability to destroy LUNs and also a number of actions that could affect the availability of data such as snapshot creation/deletion, igroup manipulation and  restoration from Snapshot.

Those actions are why SnapDrive even exists of course. The concern is around "any old admin" being able to do it. What would be very helpful is if there were some way to restrict local server administrators from running SnapDrive at all so that authorized storage admins could authenticate and run SnapDrive when required.

If that's too much to ask, then at least restricting SnapDrive from being able to browse all volumes on a target controller and create LUNs there would be a great start.

[shaunjurr]

Hi,

TR-3864 pretty much does answer the necessary questions on the NetApp side.  There is really no way to get the current state of the storage system without the ability to list, for example, LUNs, licenses, volumes, host mappings, etc.  It seems like the concern here is what the local Windows administrator has access to.  This is a personnel issue on the one side and, of course, a configuration issue on the other.  Limiting who can start SnapDrive would seem to be a matter of creating the correct Windows administrator groupings and limiting execution of SnapDrive to those groups. The NetApp side does its job by limiting command execution to users in groups with the correct roles and capabilites. The snapdrive user on the NetApp needs to have a password known only to authorized admins (a personnel issue).

There's only so much one can do with roles, and for that matter, technology.  Limiting access from "random admins" is really beyond what NetApp can do for any organization.

S.