Fixing and Adding ACLs

[Eugene Lipsky]

Hi,

I'm trying to add a new admin AD group to a couple of our isilon shares in order to try to get a better control of the shares. Right now one of our shares is a bit of a mess where there is no single administrative group that has full access to everything, while it hasn't been much of an issue this is not by design and I'd like to change it in order to make it easier to delegate admin access to a new sys admins team.

Would the best approach here be to take ownership of the share via CLI and then use icacls to give full access to the new admin group?

Second share is a bit different in that the AD domain admins group has full access to it but we don't want to give domain admins rights to the new sys admins team while we do want them to have full admin access to the share.

In the case of the second share I tried to use icacls via the following command:

icacls "\\isilon\share2\*" /grant DOMAIN\SysAdmins:(OI)(CI)(F) /T

What happens is all the subfolders under share2 get proper permissions propagated but once you drill down deeper into say \\isilon\share2\subfolder1\ all folders underneath don't get new permissions added. Running the same icacls command one level down so:

icacls "\\isilon\share2\subfolder1\*" /grant DOMAIN\SysAdmins:(OI)(CI)(F) /T

works and everything propagates correctly all the way down to all of its sub folders and files.

Additionally back up at \\isilon\share2\ not all sub folders are experiencing this issue so something like \\isilon\share2\subfolder2\ gets everything propagated correctly to all of its sub folders and files.

Appreciate any suggestions.

Thanks,
Eugene

[Dan Pritts]

Our approach to this is to have a separate administrative share for each normal share, and give the admin team "run as root" privileges on it, and let nobody else connect to it; when we need to fix permissions on shared filesystems (shared between linux & windows, that is), we always do it from windows. 

We use this naming convention:

normal share:   foo
admin share:    fooAdmin$

If you're "running as root" you don't need to list the admin team in the acl.  Which might be good, or might be bad, depending on your business process. 

Eugene Lipsky

January 13, 2016 at 11:59 AM

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan
+1 (734) 615-9529

[Eugene Lipsky]

Thanks. I'll try to use "run as root" temporarily to fix these issues instead of using it permanently. Not sure if I want to leave a group with that type of access mainly because I can see this causing confusion with other members of my team in the future even if I document everything. Also I can see this becoming an issue during an access audit.

[Dan Pritts]

We have specific admin user ids that we don't use in our normal daily  work - so to do this, we have to explicitly log in somewhere as an admin, etc etc. 

I haven't actually checked, but I don't have any reason to believe that this bypasses smb access auditing. 

All that said, I can easily imagine an auditor disliking it.

Eugene Lipsky

January 13, 2016 at 4:31 PM

Thanks. I'll try to use "run as root" temporarily to fix these issues instead of using it permanently. Not sure if I want to leave a group with that type of access mainly because I can see this causing confusion with other members of my team in the future even if I document everything. Also I can see this becoming an issue during an access audit.

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Dan Pritts

January 13, 2016 at 1:06 PM