Isilon supporting Mixed Provider Environment (Permission Issues & Best Practice)

Question

Community,

Our cluster has been upgraded to OneFS 7.1.0.6. We have a 12 node Isilon cluster.

4 nodes are connected to the production network. (Mixed OS Environment)
6 nodes are connected to the private HPC network. (LINUX Environment)
3 subnets the Isilon cluster is connected to.
4 different Providers that reside under the same Zone (System)
Those 4 different Providers are Active Directory, LDAP, Local, and File.

Please note that the nodes that are connected to the production network do not have network connectivity to the private HPC network. So when we run commands like “isi auth ldap list” on a node that has not physical network connectivity to the private HPC network the status will show that the provider is “offline.” This is not the problem I am coming to you with unless this is a problem? What I am coming to you with is what would be the recommended process for configuring permissions on a file system that users need to be able to access the data from both an LDAP Provider and the Active Directory Provider?

i.e. /ifs/HPC

The HPC directory needs to be able to be access by users on both LDAP and Active Directory. In the past when there was just the Active Directory Provider in place I was configuring all permissions via the Isilon CLi using the chmod command, until I got to thinking why am I making my life so hard then I starting using the regular Windows GUI to configure permissions on directories except when I had to configure local accounts to the directories I would perform those using the CLi. Now that we have Dual provider environment we are starting to discover some permission inconsistences or some weird scenarios where permissions that was thought to have been configured on /ifs/HPC is not present, then magically it is??!! Personally I am not handling this permissions configuration and its being performed by the HPC admins, but we need to come up with a process that is going to be fail proof regardless of what environment we need access to this data from.

Note… We have Varonis configured in our environment and would like to have

Note… Please note that our Active Directory Provider was in place before we configured our LDAP Provider if that makes a difference.

Note… We also configured LDAP prior to upgrading to OneFS 7.1.0.6.

Let me know your thoughts…

Thank you,

Anonymous User · Answer

I haven't yet seen a mixed permission model that works well. Maybe they're out there, but the problem is just hard. It's easy to set yourself up such that you have conflicting permissions. Can/should you allow a Windows user to be able to write the file from Windows yet deny access via NFS? I can see some environments where that might be desirable (you might want to give your Windows read-only access to HPC data yet not allow a virus to corrupt the data) and others where that's going to drive users nuts.

I've been going under the impression that you just have to pick one model per file and never mix them. With AD having a decent ACL model and LDAP/NFS3 not having one at all, the problem does get ugly and I rarely see Unix admins asking to switch to AD.

chjatwork · Answer

Ed,

I sort of agree with you on the statement of keeping data between the two environments separated if we are going to configure the Isilon to support mixed environments. I sort of figured that this would create a bit of a permissions management and process nightmare. I will make the recommendation that we keep data between the 2 environments separate unless I hear from someone who has successfully accomplished this mix.

peglarr · Answer

My 2 cents (full disclosure; former Isilon CTO Americas)

In my experience, Ed is right - it's hard. But it's not hard strictly from the filesystem's POV, really. The method of generating either 'Unix' or 'Windows' permissions from the other is straightforward. ACLs are the definitive way to control access to directories and files, regardless of the protocol or OS used to access them.

What is hard is the world of authentication providers - AD and LDAP, and the 'worlds' they grew up in, to use a phrase. They use two completely different methods to provide authentication - proving "you are who you claim to be". This, in my opinion, is the root cause of "permission problems" that users of filesystems encounter - and not just with Isilon.

Then there are the companies that literally give (or worse yet, assume) the same person different 'roles' or 'authority', depending on which provider he or she authenticates through...literally the classic 'multiple personality' syndrome. As you can imagine, this can be exceedingly difficult to manage while trying to leverage the efficiencies of a single namespace with a single set of directory and file permissions. That's one reason why the concept of access zones and tying a given provider to them is helpful; in this manner, even with a single ACL set on a given file, there is a control point where the same person (or groups of people) can access that file in different ways, arbitrated through the different authentication providers.

I apologize if I have only raised the confusion level to a higher state :-)

My point is this - don't blame the filesystem for "permission problems". It's doing what you tell it to do. Go back and study the way your business authenticates its users...from there the path to smooth operation in a mixed authentication/role/authority world becomes much easier.

Cheers

Rob

Isilon

Isilon supporting Mixed Provider Environment (Permission Issues & Best Practice)

Was this post helpful?