Isilon and Permissions

At Datadobi, we do migrations between many different storage vendors and platforms. That experience has taught us that each network-attached storage (NAS) device can (and does) handle permissions differently. When migrating between two different NAS devices, it is good to understand how the different platforms manage access and authentication. After your migration is over, your access control lists (ACLs) may look slightly different but maintain the same effective permissions. This is due to how the NAS stores and presents that information differently. This blog post will cover how Dell EMC Isilon handles permissions and maintains security on the files that live on it.

For instance, a NAS device could keep all NTFS permissions in one place and separate from NFS (POSIX) permissions. Alternatively, you could maintain the user’s access to all the different protocols together in one place. This is what Isilon does. They use a Unified Permission Model, which is what we will discuss in this blog post. This will be part one of four blog posts discussing how different NAS devices handle permissions. Across the series we will discuss the methods used on Isilon, VNX, Unity, and NetApp (7-Mode/ONTAP 9).

Using the Unified Permission Model, an access token is generated for each user upon initial connection. That token will contain which level of access you have across all the different protocols. OneFS will build that token based on which authentication providers are configured. If you have LDAP for NFS perms and Active Directory for NTFS, Isilon will pull the user’s information from both these sources and store it in a token. The process is even easier if you have RFC 2307 configured. In that case, your NFS and NTFS permissions are both pulled from Active Directory. Once you have both your NFS permissions (UID/GID) and your NTFS permissions (SID), OneFS will store that information in a user token. That token will be used to determine which files and folders your user can access.

If you are an all-Windows shop or an all-Linux shop, you may not have both sets of permissions to completely build a token. A token must have a SID/UID/GID, even if you do not use them in your environment. If you are an all-Windows shop and do not have UIDs and GIDs, OneFS will create synthetic numbers to use instead. These numbers can range from one million to two million. The opposite is true as well. If you do not have any Windows in your environment, OneFS will create synthetic SIDs for your token in the same range.

This is good to know, because if a user connects before authentication providers for both protocols are configured, synthetic numbers may be generated and used when that user is supposed to have a real number. If that happens or you add the other protocol later, you may have some additional legwork to do in order to replace those fake values with real ones.

* In the next blog post, we will delve deeper into the ramifications of having synthetic numbers in your token and look at some examples where access can be impacted if not configured correctly.