Network and Storage Protocols
Network and Storage Protocols
We've recently migrated our Shared drives to CIFS shares on our filers, and everything has been working great, except allowing our Helpdesk and Network Admins to admins to close open files. I don't want to give rights to fully administor shares on the filers, just be able to view and close open files on the existing shares. I also have multiple AD Groups I need to give rights to, so I'd like to link AD Groups to a local group on the filer with proper rights. Whatever works though.
Not sure I can offer you a full solution.
You can link AD groups to the filer for administration once it is joined to the domain, however for these users to be able to authenticate, they need to exist on the filers local user database (although all authentication is done against AD). I believe you can assign additional user groups that can administer the filer when you run a CIFS setup, but I've never actually had to do this myself as domain admins have always been enough. You may be able to give additional groups admin rights so that they can use Computer Manager to manage the filer, but not logon to it.
As for allowing certain users access to close open files, I'm not sure you can be that granular. You can certainly limit users to specific commands (role based access control), and you can have admin users that don't have command line access to the system at all. But if they administer the filer through Computer Manager, I'm not sure you can restrict them enough. They may still have access to create / delete CIFS shares and change permissions, which you probably wouldn't want.
I think you could achieve fairly close to what you want, but I don't think it would be a fully granular solution. You'd need to put it through some tests and trials.
Sorry, not a perfect answer for you, but hopefully puts you on the right direction.
You can link AD groups to the filer for administration once it is joined to the domain, however for these users to be able to authenticate, they need to exist on the filers local user database (although all authentication is done against AD).
No, that's not correct. You can add domain group to local group and any user belonging to domain group will have whatever rights local group has. There is no need to create local accounts for it.
Sorry, I meant for CLI admin access.
I don't want to give rights to fully administor shares on the filers, just be able to view and close open files on the existing shares.
Could you explain or give reference to how to do it on Windows? It may give hints how to implement the same on filer. At this point I am not aware of any way to it on Windows either.
In Windows, it would be done through Computer Management --> Shared Folders --> Open Files. This is the only access they need, nothing on the filer in regards to creating the shares. Ideally, I could create a group on the filer, assign it the proper rights, and add my domain groups into this local group on the filer.
Thanks for the replies guys, hopefully can get this sorted out.
And you can do exactly the same technique with the NetApp.
But in Windows, how would you limit those users from doing other admin tasks on that system (such as editing shares) through the same interface?
We gave them Power User access on the server, which was still alright as far as what they were allowed to do. The problem is that on the Filer, it appears the Power User group will have access to create shares and potentially link to volumes that we don't want for CIFS. I'm very comfortable how the CIFS Shares work, I just need to basically assign them rights that the Power Users have, minus a few options. I'm not sure how to accomplish this.
I was looking into this answer myself and seems this is not resolved on this thread. I have basically allowed only rsh login on a role I assigned to a local group that has the Domain Users for which I want to close open files. Seems to be working...
i'm looking for the same thing , i want to give the helpdesk the option to close open files on a netapp cifs share. i'm looking for a group role/RBAC to create on the netapp storage, since they need permissions on the NetApp storage side.