Technical White Paper

Dell EMC Isilon OneFS: Authentication, Identity

Management, and Authorization
Multi-protocol data access and the Unified Permission Model

Abstract
This white paper details user and file access management in Dell EMC™ Isilon™
OneFS™ through the explanation of the Authentication, Identity Management, and
Authorization (AIMA) stack.

April 2019

H13115.2
Revisions

Revisions
Date Description
August 2016 Initial release
November 2018 Renamed from “Isilon OneFS Multi-Protocol Security” to “Isilon OneFS AIMA”; document
completely updated with new content
March 2019 Updated sections 13 and 14 to introduce new features in OneFS 8.2

Acknowledgements
This paper was produced by the following members of the Dell EMC storage engineering team:

Authors: Aqib Kazi, Lieven Lin

The information in this publication is provided “as is.” Dell Inc. makes no representations or warranties of any kind with respect to the information in this
publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.

Use, copying, and distribution of any software described in this publication requires an applicable software license.

Copyright © 2016–2019 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc. or its
subsidiaries. Other trademarks may be trademarks of their respective owners. [4/18/2019] [Technical White Paper] [H13115.2]

2 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Table of contents

Table of contents
Revisions.............................................................................................................................................................................2
Acknowledgements .............................................................................................................................................................2
Table of contents ................................................................................................................................................................3
Executive summary.............................................................................................................................................................5
Note to readers ...................................................................................................................................................................5
1 Legacy single-protocol environments ...........................................................................................................................6
1.1 UNIX Identifier ....................................................................................................................................................6
1.2 Microsoft Security Identifier (SID) .......................................................................................................................7
2 Multi-protocol NAS .......................................................................................................................................................8
3 OneFS Unified Permission Model ................................................................................................................................9
4 OneFS Authentication, Identity Management, and Authorization ..............................................................................10
4.1 Authentication ...................................................................................................................................................10
4.2 Identity management ........................................................................................................................................10
4.3 Authorization .....................................................................................................................................................10
4.4 AIMA access hierarchy .....................................................................................................................................11
5 Access zones and root-based paths ..........................................................................................................................13
6 Isilon OneFS tokens and file permissions infographic ...............................................................................................14
7 Isilon OneFS tokens ...................................................................................................................................................15
7.1 Token user mapping .........................................................................................................................................16
7.2 ID mapping database .......................................................................................................................................17
7.3 ID ranges cannot overlap .................................................................................................................................18
7.4 OneFS user-mapping options...........................................................................................................................18
7.5 Checking access tokens ...................................................................................................................................18
7.6 Importance of user mappings ...........................................................................................................................20
7.7 On-Disk Identity ................................................................................................................................................22
8 OneFS file permissions ..............................................................................................................................................24
8.1 NFS client file access .......................................................................................................................................24
8.2 SMB client file access sequence ......................................................................................................................25
8.3 How files are placed into a state.......................................................................................................................25
8.4 POSIX file state ................................................................................................................................................26
8.5 SMB file state....................................................................................................................................................26
8.6 Viewing file permissions ...................................................................................................................................26
8.7 POSIX file permission management.................................................................................................................28
8.8 ACL file permission management.....................................................................................................................29

3 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Table of contents

8.9 File state permission changes ..........................................................................................................................30

8.9.1 File state permission change example .............................................................................................................31
8.10 ACLs and OneFS..............................................................................................................................................32
9 SID history ..................................................................................................................................................................33
10 Access checks with tokens and file permissions ........................................................................................................34
11 OneFS ACL policies ...................................................................................................................................................35
12 OneFS permission repair ...........................................................................................................................................37
13 Role-Based Access Control .......................................................................................................................................38
13.1 Privileges available in non-System access zones ............................................................................................39
13.2 Authentication provider behavior between RBAC and ZRBAC ........................................................................40
13.3 Multi-instance Active Directory authentication provider....................................................................................41
14 SSH multi-factor authentication with Duo ...................................................................................................................43
15 Isilon migrations and permissions ..............................................................................................................................44
16 Troubleshooting and commands ................................................................................................................................45
16.1 Anatomy of a cross-platform access token ......................................................................................................45
16.2 Anatomy of a cross-platform file permission ....................................................................................................49
A Appendix .....................................................................................................................................................................50
A.1 Configuring Active Directory, LDAP, RFC 2307, and Kerberized NFS ............................................................50
A.1.1 Required fields for LDAP ..................................................................................................................................50
A.2 Microsoft Active Directory with RFC 2307 ........................................................................................................50
A.2.1 Required fields for Windows Services for Unix ................................................................................................51
A.3 Permission mapping .........................................................................................................................................51
A.3.1 Windows Access Rights to OneFS to Mode Bits ..............................................................................................51
A.3.2 Mapping Mode Bits to ACLs .............................................................................................................................52
A.3.3 OneFS permissions for file system objects ......................................................................................................53
B Additional resources ...................................................................................................................................................56

4 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Executive summary

Executive summary
This document provides design considerations for understanding, configuring, and troubleshooting user
access and file management with the Dell EMC™ Isilon™ scale-out NAS platform. In order to support multiple
protocols, a model is required for ensuring users are provided equal rights irrespective of the access protocol
and authentication providers. Additionally, the model must define file permission management. Further, to
provide consistent, flexible, and secure access across supported protocols, Isilon OneFS™ utilizes the Unified
Permission Model combined with the Authentication, Identity Management, and Authorization (AIMA) stack.
The Unified Permission Model and AIMA stack are dissected and explained in this document.

Traditionally, legacy NAS systems only provided support for a single protocol. However, Isilon provides
support for several protocols, introducing the challenges of multi-protocol support. While many vendors
support multi-protocol support on a single platform, it is imperative to understand that each vendor
implements a proprietary model to provide user access and file management in a multi-protocol environment.
Given that multi-protocol support is not governed by an RFC or an open-source model, each vendor provides
a different approach and implementation. The goal of this paper is to provide an understanding of Isilon’s
implementation of multi-protocol support, which differs from other vendors but is simple to apply once it is
ascertained.

Note to readers
Prior to making changes on a production cluster, extreme caution is recommended. The concepts explained
in this paper must be understood in its entirety before implementing significant file and permission updates.
As with any major infrastructure update, testing changes in a lab environment is best practice. Once updates
are confirmed in a lab environment a gradual roll-out to a production cluster may commence.

5 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Legacy single-protocol environments

1 Legacy single-protocol environments

In order to fully comprehend the implementation of a multi-protocol model, it is crucial to understand how user
access and file permissions are handled in a legacy single-protocol environment.

Conventionally, legacy single protocol environments supported either a Microsoft ® Windows® or Linux®
architecture. In these environments, a clear separation of protocol and authentication existed. Microsoft users
authenticated with Active Directory, while Linux users authenticated with LDAP. Microsoft users accessed
files through CIFS or SMB and Linux users through NFS. In a single-protocol environment, cross-platform
access was not an option as Microsoft users would not access files created through NFS and vice-versa, as
illustrated in the following figure:

Legacy single-protocol environments

1.1 UNIX Identifier

In a single-protocol environment, the Unix Identifier (UID) identifies a user with a positive integer assigned by
a Lightweight Directory Access Protocol (LDAP) server. The UID maps to several Group Identifiers (GID) to
determine access permissions. At login, the user ID is mapped to the matching UID and GID. The UID and
GID for a user are displayed with an LDAP query in the following figure:

UNIX Identifier UID and GID

6 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Legacy single-protocol environments

1.2 Microsoft Security Identifier (SID)

In a Microsoft environment, the Security Identifier (SID) is a unique value assigned to a user, group, and
accounts. The SID is issued by a security authority, which in most cases is the Domain Controller and is
pulled from the Active Directory database. At login, an Access Token is generated. It is composed of the SID
with group SIDs and a list of privileges as illustrated in the following figure:

Microsoft User Access Token

The SID is written in the following format: (SID)-(revision level)-(identifier-authority)-(subauthority1)-

(subauthority2)-(etc)

As an example, consider the following SID: S-1-5-21-1004336348-1177238915-682003330-512

• Revision level (1)

• Identifier authority (5, NT Authority)
• Domain identifier (21-1004336348-1177238915-682003330)
• Relative identifier (512, Domain Admins)

For more information on SIDs, refer to the following Microsoft article:

https://technet.microsoft.com/en-us/library/cc786606(v=ws.10).aspx

7 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Multi-protocol NAS

2 Multi-protocol NAS
In contrast to a single-protocol environment, a multi-protocol system introduces new challenges and requires
a planned approach to managing users and file permissions. One of the key facets of Isilon scale-out NAS is
the support of several protocols, leading to the elimination of silos, instead focusing on a single storage
platform.

In a multi-protocol environment, UNIX and Windows users access the same file through the same directory
structure, but through different protocols. The challenge is how are identities verified and what file
permissions are used for authorization. Previously, each set of users only had a single authentication
provider. A multi-protocol infrastructure may be composed of LDAP and AD, connected to a single NAS.
Additionally, the authentication provider may not be related to the client operating system. For example, a
UNIX user could authenticate with AD. Furthermore, users may have accounts in both AD and LDAP,
requiring mapping between those accounts, allowing OneFS to link the accounts.

Multi-protocol NAS environment

It is important to note that although Isilon OneFS supports many protocols, it may be configured as a single
protocol system. Access zones and directories may be limited to a single protocol, while other areas are
defined as multi-protocol.

8 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS Unified Permission Model

3 OneFS Unified Permission Model

Multi-protocol environments introduce new challenges for managing user access and file permissions. As
mentioned in an earlier section multi-protocol environments are not governed by an open standard or RFC.
Therefore, each vendor implements multi-protocol with a different approach.

Isilon OneFS developed the Unified Permission Model to implement multi-protocol support. Utilizing the
Unified Permission Model ensures that irrespective of the access protocol, the permission model remains
consistent. A single model simplifies multi-protocol integration, as the access protocol is not taken into
account when comparing users and permissions. From a purely administrative perspective, only a single
model has to be ascertained, rather than several protocol specific models.

Multi-protocol is not only limited to SMB and NFS, as OneFS also supports HTTP, HDFS, and FTP. It is
essential to ensure that the permission model remains consistent across all of these protocols. Further, the
Unified Permission Model accounts for users from different systems with different IDs that may be the same
or a different user.

Isilon OneFS Unified Permission Model

The Unified Permission Model ensures a common access token is generated for each user at login,
representing the user’s persona to the cluster. Once the token is generated, it is evaluated against File
Permissions to check for access.

Unified Permission Model overview

9 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS Authentication, Identity Management, and Authorization

4 OneFS Authentication, Identity Management, and

Authorization
At the core of the Unified Permission Model is the OneFS Authentication, Identity Management, and
Authorization (AIMA) model. Upon initial client connection to the cluster, information passes through the AIMA
stack, which includes Directory Services, User Mapping, ID Mapping, Tokens, OnDisk ID, File Permissions,
and ACL Policies, as illustrated in the figure below.

Isilon OneFS AIMA

All of the components of the AIMA stack work together to complete a user’s access experience and determine
if access is granted to a file. Understanding the AIMA stack provides the basis for the OneFS implementation
of multi-protocol. The AIMA stack is the focus of this paper.

4.1 Authentication
Authentication refers to confirming an identity. Upon login, a user states an identity and the authentication
process ensures the user is associated with the presented identity through a password. The authentication
process takes place through providers such as Active Directory (AD) or MIT KDC. OneFS also offers a local
provider, where users are manually added to OneFS, but are only available on the local cluster. Another local
option is file provider, where a file is uploaded with user information and could also contain UNIX user and
group information from other systems. The same file could be uploaded to other clusters, but the file has to be
manually updated on each cluster.

4.2 Identity management

Identity Management is the process of associating memberships with a user. Once the identity is confirmed,
OneFS identifies the user and checks for the access that the user has. Managing the identity typically takes
place through AD or LDAP, but could also be through the OneFS local for file providers.

4.3 Authorization
Once a user is authenticated, and memberships are associated with that user, OneFS can check if the user
has access to a specific file, based on the file permissions. At this step, the user is compared to the file
permissions.

10 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS Authentication, Identity Management, and Authorization

4.4 AIMA access hierarchy

Understanding AIMA as a whole requires an understanding of the OneFS network access hierarchy and how
the AIMA hierarchy ties into the network hierarchy. The Isilon OneFS network access hierarchy is illustrated in
the following diagram:

Isilon OneFS network access hierarchy

As illustrated above, each Groupnet has a specific DNS and supports multiple subnets. Each subnet supports
a SmartConnect Service IP (SSIP) with multiple pools associated with each subnet and SmartConnect Zone
Names. For more information on Isilon’s network access hierarchy, refer to the Isilon Network Design
Considerations White Paper.

11 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS Authentication, Identity Management, and Authorization

The AIMA hierarchy ties into the network hierarchy at different levels, as illustrated in the following figure:

Isilon OneFS AIMA hierarchy

When a client connects to an Isilon cluster, AIMA plays a role at each level of the network access hierarchy. It
is critical to recognize the level where each component resides. At the initial review, the terms below may
seem confusing, but once this paper is reviewed in its entirety, this image may be referenced as each topic is
explained. The AIMA access hierarchy is explained through the following steps:

1. The user connects to a SmartConnect Zone Name, which is tied to a subnet, and SSIP.
2. The SmartConnect Zone Name is mapped to an Access Zone. At the Access Zone level
authentication providers are defined. As the authentication providers are defined, this is where
Directory Services, User Mapping, ID mapping, and ultimately the user Token is generated.
3. For each Access Zone that is defined, a root-based path is required. The root-based path is where file
permissions and the user’s identity on disk are applicable.

At the overall cluster level, administrators define the OnDisk ID policy, and set ACL policies.

12 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Access zones and root-based paths

5 Access zones and root-based paths

When Access Zones are configured, a root-based path must be defined to segment data into the appropriate
Access Zone and enable the data to be compartmentalized. Access Zones carve out access to an Isilon
cluster creating boundaries for multi-tenancy or multi-protocol. They permit or deny access to areas of the
cluster. At the Access Zone level, authentication providers are also provisioned.

For more information on Access Zones best practices, please refer to the Access Zones section, in the Isilon
Network Design Considerations White Paper.

13 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens and file permissions infographic

6 Isilon OneFS tokens and file permissions infographic

The infographic below is referenced throughout this paper and should be reviewed as AIMA knowledge
increases through this paper. A high-level overview infographic of Tokens and File Permissions is illustrated
in the following figure:

Isilon OneFS token and file permissions

14 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

7 Isilon OneFS tokens

OneFS generates a token for each user upon initial connection to the cluster. In the Unified Permission
Model, a token could be thought of as an identification system like a passport, confirming a user’s identity
while a visa for each country grants specific access levels.

The token is generated based on the information provided by authentication providers. If an authentication
provider is not configured, OneFS locally generates a value, which is referred to as a ‘fake’ value throughout
this paper.

The Isilon OneFS Unified Permission Model has a core requirement that every entity, user or group, has a
UNIX component and a SID component. Hence, a token is composed of two parts, a UID with associated
GIDs, and a SID. In an earlier section, an introduction to UIDs and SIDs was provided. Similar to how
authentication occurs in a single-protocol environment, in Isilon’s AIMA model, OneFS reaches out to those
same providers, if configured, to collect the UID and SID. However, under the Unified Permission Model,
those UID and SID values are now combined into a single token, as shown in the following figure:

Isilon OneFS token

If authentication providers are not configured or unavailable, the ‘fake’ UID/GID value is assigned, which, by
default, is between 1 and 2 million. The default value is configurable, in the event those values create a
conflict in an existing environment.

During token generation, User Mapping occurs, which connects identities between LDAP and AD to a single
user. Mapping identities ensure a user’s token contains real values for both the UID and SID, as OneFS is
aware that it is the same user.

Once a token is generated, the OnDisk ID of a user or group is selected. The OnDisk ID is used when
creating a file, setting permissions, or changing ownership of a file. The OnDisk ID is explained in greater
depth, later in this paper.

Authentication providers configured in OneFS assist with token generation by responding with values for the
UID with associated GIDs and SIDs. Based on what an authentication provider supports, determines what is
provided, as summarized in the following table:

Authentication Providers Supported Identifiers

Authentication Provider UID / GIDs SID Ranking
Local Provider Fake Fake Poor
File Provider Fake Fake Poor
Active Directory Fake Real Good
LDAP Real Fake Good
AD mapping to LDAP Real Real Best
AD with RFC 2307* Real Real Best
*For more information on RFC 2307, see appendix A.

15 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

7.1 Token user mapping

User mapping allows OneFS to join identities across authentication providers. As multiple authentication
providers from different environments are added, for example, AD and LDAP, the challenges of a multi-
protocol environment start at identifying users across platforms. For example, is ‘Bob’ in AD the same as
‘Bob’ in LDAP, or is ‘Bob’ in AD actually the same as ‘BobS’ in LDAP? In some cases, ‘Bob’ in AD could be
‘UserSmith’ in LDAP. If user mapping is configured, a token with ‘real’ values is generated, as illustrated in the
following figure:

User mapping example

If the usernames across both authentication providers are the same, as the example of ‘Bob’ in AD and
LDAP, a general rule is added. In certain cases, the usernames have a similar variable, for example, ‘JaneS’
maps to ‘SJane’. In this case, a rule is created. OneFS provides rules to append, insert, or replace variables,
referred to as Operator Rules. For more information, on the Operator Rules and options, refer to the Isilon
OneFS User Mapping white paper. On the contrary, if the usernames do not have any common variables, a
user-specific rule is required for each user. A general rule applies to all users across both providers with a
single rule. The user-specific rule could become cumbersome to manage if an enterprise has several
thousand unique users, requiring a rule for each. Both the general and user-specific rules are highlighted in
the following figure:

16 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

General and user-specific rule mapping with the same name across providers

Other alternatives are available for enterprises with many users that do not have common explicit elements in
the username across authentication providers. RFC 2307 simplifies this process greatly, as every user is
already mapped with a SID and corresponding UID. Another option is to use a 3rd party directory service that
unifies the authentication providers and is placed in front of AD and LDAP, handling all communication with
OneFS. For more information on RFC 2307 with AD, please refer to the Appendix.

7.2 ID mapping database

Once a user has connected to the cluster, and the token is generated, OneFS requires the SID and the
corresponding UID with GID, be placed in the ID mapping database. Although it is easy to confuse user
mapping with ID mapping, user mapping is the process of identifying users across authentication providers for
the purpose of token generation. After the token is generated, the mappings of SID to UID are placed in the
ID mapping database. The ID mapping database also contains a reciprocal entry for each user. As Isilon is
zone aware, both the UID and SID are required for each user, regardless if the values are real or fake, as
displayed in the following figure:

ID mapping database

In the figure above, the 4th column delineates which of the values are real or fake. ’32’ indicates the left is
real; right is fake. ‘48’ indicates the right is real, left is fake. ‘128’ and ‘144’ indicate both the left and right
values are real.

17 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

The ID mapping database is listed by the command isi auth mapping list. The isi auth mapping
command allows for manually deleting or adding entries, for the possible commands listed, type isi auth
mapping --help.

7.3 ID ranges cannot overlap

In networks with multiple identity sources, ensure the UID, and GID ranges do not overlap. If UIDs and GIDs
overlap, certain users could gain access to directories or files that were not intended. Additionally, do not use
UIDs and GIDs below 1000 as these are reserved for system accounts.

7.4 OneFS user-mapping options

OneFS offers many options for configuring user mapping and ensuring tokens contain the appropriate
information reflecting the workflow and environment. For more information on the user mapping options, refer
to the Isilon OneFS User Mapping Service white paper.

7.5 Checking access tokens

An Access Token is checked by dumping the token on the Isilon CLI. A token can be viewed by username,
UID, GID, or Kerberos-principal, paired with an access zone. A token is displayed by username, with
corresponding SIDs, UID, and GIDs in the following figure:

Viewing an access token

18 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

In the token above a UID of a 1000000 is displayed signifying this is a fake value. The value of 1000000 is
assigned to the first user requiring a fake value and increments for each corresponding GID and as more
users join. Additionally, a GID is generated for each SID group that was pulled from Active Directory.

Another option to view an access token is ‘isi auth id’, which lists IDs, Privileges, and zone information for the
logged in user, as displayed in the following example:

Abridged example of ‘isi auth id’

19 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

7.6 Importance of user mappings

If user mappings are not available or are not configured correctly, asymmetrical tokens are created. An
asymmetrical token is where a user has access to a file from a certain protocol, but is denied access from the
other protocol. The inconsistent access is because the user’s access token is different when accessing the
file from each protocol, as illustrated in the example below:

Asymmetrical tokens

Asymmetrical tokens lead to asymmetrical access. In the example above, for illustration purposes, the file
permission is the ‘blue permission identity’ and requires the blue ID portion of the access token. The blue
portion is notating the UID with GIDs. When the same user tries to access the file from NFS and SMB, the
following occurs:

• NFS: The user logs in to access the file with the blue permission. At login, OneFS reaches out to
LDAP. The user is found, and the blue half of the token is generated with a real UID and associated
GIDs. Since mapping is not configured, a lookup in AD fails, and a fake green portion is assigned for
the SID. However, the file permission is based on the UID, and the user has a real UID in the token,
they are granted access.
• SMB: The user logs in to access the file with the blue permission. At login, OneFS reaches out to AD.
The user is found, and the red half, or SID, of the token, is generated with a real SID. Since mapping
is not configured, a lookup in LDAP fails, and a fake yellow portion is assigned for the UID and
corresponding GIDs. Since the file permission is based on the UID and the user has a fake UID in the
token, access is denied.

20 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

On the contrary, if user mapping is configured, this leads to symmetrical tokens, irrespective of the access
protocol. A symmetrical token grants equal access to the same user, which is the basis of the Unified
Permission Model. OneFS user mapping provides a consistent multi-protocol experience when accessing the
same file from NFS or SMB, as illustrated in the following figure:

Symmetrical tokens

Symmetrical tokens lead to symmetrical access. In the example above, the file permission is again the ‘blue
permission’ and requires the ‘blue ID’ portion of the access token. The blue is notating the UID with GIDs.
When the same user tries to access the file from NFS and SMB, the following occurs:

• NFS: The user logs in to access the file with the blue permission. At login, OneFS reaches out to
LDAP. The user is found, and the blue half of the token is generated with a real UID and associated
GIDs. Since mapping is configured, a lookup in AD completes, and a real red portion is assigned for
the SID. The file permission is based on the UID, and the user has a real UID and SID in the token.
Hence, permission is granted.
• SMB: The user logs in to access the file with the blue permission. At login, OneFS reaches out to AD.
The user is found, and the red half, or SID, of the token, is generated with a real SID. Since mapping
is configured, a lookup in LDAP completes, and a real blue portion is assigned for the UID and
corresponding GIDs. Since the file permission is based on the UID and the user has a real UID in the
token, access is granted.

21 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

7.7 On-Disk Identity

Once a token is generated for a user, OneFS uses the token’s contents to assign an On-Disk Identity. The
identity is used when the file is created or when ownership of file changes, impacting the file permissions. In a
single protocol environment, determining the On-Disk Identity is simple because Windows uses SIDs and
Linux uses UIDs. However, in a multi-protocol environment, only one identity is stored, and the challenge is
determining which one is stored.

By default, the policy configured for on-disk identity is ‘Native’ mode. Under ‘Native’ mode, OneFS selects the
real value between the SID and UID. If both the SID and UID are real values, OneFS selects UID. The On-
Disk policy is configurable from the user interface as illustrated in the following figure:

Configuring the On-Disk Identity policy

The On-Disk Identity should almost always remain in ‘Native’ mode as that is the best option for the majority
of environments. If a fake, locally generated value is used for a File Permission, once that file is sent to
another cluster, the original user will no longer have access to the file. On the contrary, another user will have
access to the file, as the fake tokens will be distributed again starting from 1 million. When the real value is
used for the On-Disk Identity, file access remains relative to the authentication provider, ensuring a file is
portable and providing a consistent experience.

Reverting to the previous example of viewing an Access Token, the On-Disk Identity is also visible, as
illustrated in the following figure:

On-Disk Identity example

In the example above, the UID is set to 100000, which is a fake, locally generated value. The SID contains a
full string and is a real value from AD. Since the policy is configured for ‘Native’ mode, the real value of the

22 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon OneFS tokens

UID and SID is used as the On-Disk, ensuring file portability and consistency as the file moves to another
cluster or system.

In ‘Native’ mode, the On-Disk Identity is listed for various authentication provider in the following table:

On-Disk Identity in Native Mode

Authentication Provider(s) SID UID On-Disk Identity
AD Real-AD Fake SID
LDAP Fake Real-LDAP UID
AD Mapping LDAP Real-AD Real-LDAP UID
AD with RFC 2307 Real-AD Real-LDAP UID

A file’s On-Disk Identity is confirmed using the Isilon CLI commands, ‘ls –le <filename>’, and ‘ls –len
<filename>. The ‘ls –le’ function lists the usernames, and ‘ls –len’ lists the actual On-Disk UID or SID
identities. An example of a UID On-Disk is displayed in the following figure:

UID On-Disk

An example of a SID On-Disk is displayed in the following figure:

SID On-Disk

23 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

8 OneFS file permissions

Once a user’s token is generated, the next step is to compare the token to the file permissions. Refer back to
the Isilon OneFS Tokens & File Permissions Infographic section for a summary. In a multi-protocol
environment, the Unified Permission Model is designed to support basic POSIX mode bits and ACLs.
Therefore, two file permission states are designated:

1. POSIX Mode Bit Authoritative with a Synthetic ACL

2. ACL

However, a file can only be in one of the states at a time. It’s important to recognize that the actual
permissions on the file are the same, regardless of the state. File Permissions states and options are
summarized in the following figure:

OneFS file permissions

8.1 NFS client file access

When a file is requested for access from a client a sequence of events take place. The events vary depending
on the type of client and the state of file permissions. As an example, an NFS client connects to the cluster
and accesses a file in each state, in the following figure:

NFS client file access sequence

In the figure above, the NFSv3 client connects to the Isilon cluster and OneFS issues a token. It is assumed
that the token has the correct UID and SID. The NFS client accesses File 1, which is in a POSIX file state.

24 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

The NFS client understands POSIX bits natively, so the token is compared directly to the POSIX bits to
validate access, as in a standard UNIX environment.

Next, the NFS client accesses File 2, which is in a Real ACL file state. The NFS client doesn’t understand
ACL. A file with a Real ACL has a richer set of permissions, with several complicated DACLs and sub-
headings. OneFS has to respect the granularity of the ACL file permissions. Thus, the NFS client’s token is
compared directly to the Real ACL. However, if the NFS clients issues an ‘ls’ over an NFS export for File 2,
OneFS must return POSIX bits, but these bits are for representation only and are not indicative of the actual
file permission. In fact, the permissions may even look more permissive than they are, because OneFS must
approximate representing many ACLs into the six POSIX bits.

8.2 SMB client file access sequence

An SMB client connects to an Isilon cluster and accesses files in both states, as illustrated in the following
figure:

SMB client file access sequence

In the figure above, the SMB client connects to the Isilon cluster and OneFS issues a token. It is assumed
that the token has the correct UID and SID. The SMB client accesses File 1, which is in a POSIX file state.
The SMB client does not understand POSIX bits, but the token can still be evaluated against the bits as an
access check. In order to represent the POSIX bits for the SMB client to view File 1 permissions, OneFS
generates a synthetic ACL, which is a direct representation of the POSIX bits in ACL form. The synthetic ACL
is not saved by OneFS and is only generated when the SMB client accesses the POSIX file.

Next, the SMB client accesses File 2, which is in Real ACL state. The SMB client speaks ACLs and
understands the ACL permissions. In this case, OneFS makes a direct comparison of the SMB client’s token
with the Real ACL permissions, as would take place in a single protocol Microsoft environment.

8.3 How files are placed into a state

A file is placed in a state depending on how the file was created. For example, a file created in an NFS export
will likely be POSIX, while a file created in an SMB share will be in ACL. If a file was migrated to Isilon
OneFS, the migration tool will impact the file state. Additionally, configured policies also determine the file
state.

25 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

On the contrary, the file state is also based on the directory structure. For example, if the parent directory has
inherited ACL(+) and the file is created through NFS, the file will be in ACL state. The same also applies if the
parent directory is POSIX mode. If a file is created through SMB, the file state is POSIX mode.

Initially, the file state is dictated by how it is created or copied, but the directory structure may also impact the
file state. Thus, the file state is dependent on the workflow and directory structure.

8.4 POSIX file state

The POSIX file state is best for environments with heavy read and writes from NFS or HDFS clients. If SMB
clients are accessing the file, it is for read-only, and the synthetic ACL is created at access time. In the POSIX
file state, the limiting factor is DACLs, as only Owner, Group, and Everyone are available. Therefore, only a
maximum of 3 DACLs are supported in the POSIX file state.

8.5 SMB file state

On the contrary, the ACL file state offers granular access through extensive DACLs. The granular access may
be required for heavy read and write from NFS, HDFS and SMB clients. The token of all clients will be
compared to the ACL, taking into account the many DACLs in the file permission. An approximated POSIX
permission is created based on the ACL, only for display purposes when an NFS or HDFS client issues an ‘ls’
over an NFS export. The approximated POSIX is representation only and may look more permissive then the
ACL actually is.

8.6 Viewing file permissions

In order to check Isilon OneFS file permissions, from the Isilon CLI, the extended ‘ls’ commands are available,
as displayed in the following table:

OneFS file permission commands

Command Applicable to Filename or Directory Description
ls –le <filename> Filename Displays the file permission state, ACLs,
owner, and group information.
ls –len <filename> Filename Displays the file permission state, ACLs,
owner and group information numerically.
ls –led <directory> Directory Displays the directory permission state,
ACLs, owner, and group information.
ls –lend <directory> Directory Displays the directory permission state,
ACLs, owner and group information
numerically.

26 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

The output of ‘ls –le’ is displayed for a POSIX file in the following figure:

POSIX file ‘ls –le’ example

In the example above, the file permission state, ACLs, owner and group information are displayed. The
POSIX bits are used for access checks and can be returned to an NFS client correctly. Whereas the SMB
clients view the Synthetic ACL representation of those POSIX mode bits.

The output of ‘ls –len’ is displayed for a POSIX file in the following figure:

POSIX file ‘ls –len’ example

In the example above, with ‘ls –len’ the file permission state, ACLs, owner and group information are
displayed numerically. User ‘yarn’ maps to UID 507 and group ‘Hadoop’ maps to GID 500.

The output of ‘ls –le’ is displayed for an ACL file in the following figure:

In the example above, an ACL file with ‘ls –le’ is displayed, with a total of 2 DACLs associated. The ‘+’ sign,
indicates this file has a real ACL. This is only viewable through the Isilon CLI. The POSIX bits, are only for
representation and may seem more permissive than the actual permission, as they are a OneFS best
estimate of representing the ACLs in POSIX bits. As the file has a real ACL, all access checks for all clients
will be against the ACL.

The output of ‘ls –len’ is displayed for an ACL file in the following figure:

27 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

In the example above, the same ACL file as the previous example is displayed, now with ‘ls –len’. The user
and group are translated to numeric values, and the DACLs show the actual SID values.

8.7 POSIX file permission management

Managing file permissions for POSIX files is similar to a single protocol UNIX environment. A ‘chmod’ can be
executed over an NFS export or from the Isilon CLI with the same result. The ‘chmod’ options are the same
as a standard UNIX environment. As the POSIX permission changes after a ‘chmod’, the synthetic ACL
changes automatically, with a maximum of 3 DACLs, as illustrated in the following figure:

POSIX file permission management

In the figure above, after issuing the ‘chmod 755’ the POSIX permission and Synthetic ACL are updated as an
additional DACL is displayed.

28 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

8.8 ACL file permission management

ACL file permissions are managed through either an SMB share or the Isilon CLI. As a user connects through
an SMB share, the permissions can be updated via the file properties, by updating permissions in the
‘Security’ tab. However, from the Isilon CLI, a ‘chmod +a’ toggle is available replicating the options from the
file properties over an SMB share. The ‘chmod +a’ option changes a file’s mode bits to add a new ACE,
inserting the ACE into the ACL. A DACL is added to an existing ACL file, as illustrated in the following figure:

ACL file permission management

Note: It is important to recognize that if a file state is unknown or if an administrator does not understand how
Isilon implements multi-protocol, running ‘chmod’, ‘chown’, or updating file properties in Windows Explorer it
could lead to unexpected results. These results may be limited through OneFS ACL policies, which are
cluster-wide policies. A thorough understanding of changing file states is recommended before making
changes on a production cluster. Testing file state changes on the simulator is recommended for a better
understanding.

29 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

8.9 File state permission changes

As mentioned earlier in this paper, a file can only be in one state at a time. However, the file permission state
of the file may be flipped. If a file is in POSIX, it can be flipped to an ACL file by opening it in Windows
Explorer and modifying the permissions. If a file is in ACL, it can be flipped to a POSIX file, by using the
following command on the Isilon CLI: chmod –b XXX <filename>

The ‘XXX’ specifies the new POSIX permission. A bulk file state change from ACL to POSIX for all files and
directories requires a custom script. It is important to exercise extreme caution as this impacts all files and
directories.

Note: The following script has an impact across an entire cluster. Ensure the impact of the script is fully
understood prior to executing. As with any significant change to a production cluster, execute the following
script in a lab environment first, to completely understand the repercussions.

To convert every file and directory from ACL to POSIX, execute the following script:

find /ifs/path/to/change | while read FILENAME

do
PERM=$(stat -f "%OLp" "$FILENAME")
echo "$FILENAME: $PERM"
chmod -b "$PERM" "$FILENAME"
done

Another option for bulk file changes is the OneFS Permission Repair Job. For more information on permission
repair jobs, refer to the OneFS Permission Repair Job Whitepaper.

30 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

8.9.1 File state permission change example

The example below illustrates a file starting in POSIX mode with a Synthetic ACL, then flipping to an ACL file,
and finally back to a POSIX mode with a Synthetic ACL.

The figure below illustrates a file named ‘This_is_isilon.txt’ in POSIX mode with a Synthetic ACL. Throughout
the following steps, the file will change modes.

File with POSIX mode and Synthetic ACL

Next, the file, ‘This_is_isilon.txt’, is opened in Windows Explorer and the file permissions are modified. After
this action, the file state has changed to ACL, as displayed in the following figure.

File permissions are modified with Windows Explorer

In order to confirm the file state, ‘ls –le’ is executed, as displayed in the following figure:

File in ACL mode

31 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS file permissions

Now that the file is in ACL mode, flipping it back to POSIX mode with a Synthetic ACL requires utilizing the
‘chmod –b’ command. The file is flipped back to POSIX mode with a Synthetic ACL and a 755 permission,
by running the following command: chmod –b 755 This_is_isilon.txt

In order to confirm the file state, ‘ls –le’ is executed, as displayed in the following figure:

File in POSIX mode with a Synthetic ACL

Note: It is important to recognize that if a file state is unknown or if an administrator does not understand how
Isilon implements multi-protocol, running ‘chmod’, chown, or updating file properties in Windows Explorer it
could lead to unexpected results. These results may be limited through OneFS ACL policies, which are
cluster-wide policies. A thorough understanding of changing file states is recommended before making
changes on a production cluster. Testing file state changes on the simulator is recommended for a better
understanding. OneFS ACL policies impact this behavior as discussed in the later section.

8.10 ACLs and OneFS

For more information on ACLs refer to the Access Control Lists on Dell EMC Isilon OneFS white paper.

32 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
SID history

9 SID history
OneFS 8.0.1 introduced support for SID history. SID history is an Active Directory attribute that maintains a
history of previous SID values if an object is moved from another domain. SIDs are prefixed with a unique
domain identifier. If users and groups are migrated from one AD domain to a new domain, each migrated
object will have a new SID with a domain identifier of the new domain. When migrated users to the new
domain attempt to access older files, access would be denied as the file permission would have the new SID.
SID history retains the old SIDs, allowing them to be used for access checks.

Note: Historical SIDs cannot be used to add users to new groups or roles. Modifying users or adding them to
a role or group should only be performed through the current object SID as defined by the domain.

Prior to OneFS 8.0.1, historical SIDs were not included in the access token as they were not recognized. In
OneFS 8.0.1 and going forward, information from the AD PAC is no longer discarded. For LDAP, OneFS
queries the sIDHistory field to add the historical SIDs. If OneFS has a historical SID, then an RPC lookup is
performed to find the current SID. Next, another RPC lookup is performed for SID to name resolution.

Historical SIDs may be viewed with the following commands:

isi auth users view <user>

isi auth groups view <group>
isi auth mapping token <user>

From an administrative perspective, additional configuration is not required. The SID history attribute is now
recognized. Files which have historical SIDs can now be accessed by users with those historical SIDs. The
old domain users still have access to the file as the old SIDs are left on disk.

Note: It is important to note that a user will be able to access old files with their old domain as the old SIDs
are now on disk.

33 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Access checks with tokens and file permissions

10 Access checks with tokens and file permissions

When a user tries to access a file, OneFS compares the identities in the user’s access token with the file
permissions. OneFS grants access when the file permissions include an access control entry, or ACE, that
allows the identity in the token to access the file and does not include an ACE that denies the identity access.
As an example, the token and a file permission, are displayed in the following example:

isi auth mapping token --user=MAINE-UNO\jsmith

User
Name : MAINE-UNO\jsmith 
UID : 1000000
SID : S-1-5-21-3542649673-1571749849-686233814-1117
On Disk : S-1-5-21-3542649673-1571749849-686233814-1117
ZID: 1
Zone: System
Privileges: -
Primary Group
Name : MAINE-UNO\domain users
GID : 1000000
SID : SID:S-1-5-21-3542649673-1571749849-686233814-513
Supplemental Identities
Name : MAINE-UNO\marketing
GID : 1000001
SID : SID:S-1-5-21-3542649673-1571749849-686233814-1109
Name : Users
GID : 1545
SID : S-1-5-32-545
------------------

The file permission for a file on the cluster:

-rwxr--r-- + 1 MAINE-UNO\jsmith MAINE-UNO\marketing 2056 Feb 2 10:18

adocs.txt
OWNER: user:MAINE-UNO\jsmith
GROUP: group:MAINE-UNO\marketing
0: user:MAINE-UNO\jsmith allow
file_gen_read,file_gen_write,file_gen_execute,std_write_dac
1: group:MAINE-UNO\marketing allow file_gen_read
2: everyone allow file_gen_read

The key points to compare in the prior example correspond to the following numbers:

1. In the token, the user’s identity is MAINE-UNO\jsmith, which is an Active Directory account.
2. The token also shows that the user is a member of the marketing group.
3. In the file permission, an access control entry shows that MAINE-UNO\jsmith is allowed to access the
file. The ACE also lists the user’s permissions, such as file_gen_write, which is permission to write to
the file.
4. This ACE shows that members of the marketing group are allowed to read the file.

34 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS ACL policies

11 OneFS ACL policies

Isilon OneFS ACL Policies are cluster-wide policies for controlling how permissions are processed and
managed. Each policy provides an option to reflect a specific environment or workflow impacting permission
change interactions. In the previous sections, flipping a permission state was explained, and how an
unintended permission change could have unexpected results. The unexpected results are essentially where
ACL policies impact the behavior.

For example, the impacts of ACL policies control the use of ‘chmod’ for files and ‘chmod +a/-a’ for setting
DACLs. Settings are available for each environment, or the fine-tuning of each setting is also possible. As a
different environment is selected, the other ACL settings also change. For the majority of workflows,
‘Balanced’ is the best option. As the ACL policies are cluster-wide, ‘Balanced’ supports a multi-protocol
environment evenly taking into account both UNIX and Windows.

By default, the environment is set for ‘Balanced’ as displayed in the following figure:

OneFS ACL policy settings

The options within the top two fields under the ‘General ACL Settings’ change automatically to reflect the
environment option selected. For an explanation of each field, refer to the OneFS 8.1 Web Administration
Guide. The focus of this section is on the first two fields under ‘General ACL Settings’ as the environment
option changes, providing the following options:

• “ACL Creation Through SMB and NFSv4”

- Allow ACLs to be created through SMB and NFSv4: This option is pre-selected with the
‘Balanced’ and ‘Windows Only’ environment options. It allows ACL creation external to an Isilon
cluster. For SMB, this allows ACL creation through File Explorer in an SMB share. For NFSv4,
this allows ACL creation over an NFSv4 export, and is not applicable to NFSv3.
- Do not allow ACLS to be created through SMB and NFSv4: This option is pre-selected with
‘UNIX only’ environment option. It disallows any ACL creation over an SMB share or NFSv4
export.

35 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS ACL policies

• “Use the chmod Command On Files with Existing ACLs”

- Remove the existing ACL and set UNIX permissions instead: This option is pre-selected with
the ‘UNIX only’ environment option. If a file has an existing ACL on it, running a ‘chmod’ will
remove the existing ACL and set the new UNIX permissions specified.
- Merge the new permissions with the existing ACL: This option is pre-selected with the
‘Balanced’ environment option. If a ‘chmod’ is executed on a file with existing ACLs, the new
permissions are merged, creating additional ACLs for the file.
- Deny permission to modify the ACL: This option is pre-selected with the ‘Windows only’
environment option. If a ‘chmod’ is executed on a file with existing ACLs, the operation is denied.

Note: As with any major update on an Isilon cluster, practice extreme caution while updating these options as
they are cluster-wide and could lead to unexpected and undesired results. Prior to updating a production
cluster, configure a lab environment to learn how ACL policies would impact a specific workflow.

36 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
OneFS permission repair

12 OneFS permission repair

In order to support Isilon’s Unified Permission Model, OneFS provides options for permission and On-Disk
repairs. The permission repair supports three different modes: Clone, Convert and Inherit. As an alternative to
making changes through an NFS export or SMB share, the permission repair jobs run directly on the cluster
and across nodes. Jobs can be scheduled and are part of the OneFS job engine, providing reliable and
consistent results.

For more information on permission repair jobs, refer to the OneFS Permission Repair Job Whitepaper.

37 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Role-Based Access Control

13 Role-Based Access Control

Role-Based Access Control (RBAC) enables Isilon administrators to delegate administrative tasks to cluster-
authenticated users. Roles can be assigned to users and groups to control administrative access. By default,
only the user ‘root’ and ‘admin’ have access to the CLI and the web interface. The user ‘root’ and ‘admin’ can
add administrative privileges to other users or create custom roles. As the role of the cluster grows across
departments, it is imperative to ensure each additional user has the minimum required access levels to
enforce security to better maintain accountability.

Prior to OneFS 8.2.0, roles and privileges can only be created and assigned from the System access zone.
All administrators, including those who own privileges by being a member of a role, must connect to the
System access zone to configure the cluster. When these administrators log in to the cluster through a
WebUI, SSH, or API interface, they can view and modify all access zones in the cluster based on the granted
privileges. For more information about RBAC, refer to the OneFS CLI Administration Guide.

Starting from OneFS 8.2.0, Zone-aware Role-Based Access Control (ZRBAC) is introduced to provide a more
granular cluster administration. Administrators may desire a way to delegate a user to perform administrative
tasks in a specific access zone only, but disallow the user have control over other access zones. ZRBAC
achieves this requirement by enabling roles and a subset of privileges to be assigned on a per-access-zone
level. A user in the System access zone still can view and modify all non-System access zones. There are
two built-in roles: ZoneAdmin and ZoneSecurityAdmin for zone-specific administration. Currently,
administrators from non-System access zones can only connect to cluster by WebUI or API interface. For the
details about supported access methods between RBAC and ZRBAC, refer to Table 4.

Supported access methods between RBAC and ZRBAC

Zones WebUI Access API Access SSH Access

RBAC System access zone √ √ √

(Prior to OneFS 8.2.0) Non-System access zone

ZRBAC System access zone √ √ √

(OneFS 8.2.0 and later) Non-System access zone √ √

38 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Role-Based Access Control

13.1 Privileges available in non-System access zones

Table 5 shows the privileges that are currently allowed in non-System access zone for ZRBAC, which are
also known as zone-based privileges. Refer to the OneFS CLI Administration Guide for all supported
privileges.

Privileges available in non-System access zones

Privilege Description
ISI_PRIV_AUDIT • Add/remove your zone from list of audited zones
• View/modify zone-specific audit settings for your zone
• View global audit settings
ISI_PRIV_AUTH • View/edit your access zone
• Create/modify/view users, groups, and local authentication providers
• View/modify auth mapping settings for your zone
• View global settings related to authentication
• View global authentication providers and add them to your zone

ISI_PRIV_FILE_FILTER • Configure file filtering settings in your own zone

ISI_PRIV_HDFS • Configure HDFS settings in your own zone

ISI_PRIV_NFS • View NFS global settings, but not modify them.

• Configure NFS zone settings and export settings in your own zone.
ISI_PRIV_SMB • View SMB global settings, but not modify them.
• Configure SMB zone settings and share settings in your own zone.

ISI_PRIV_SWIFT • Configure SWIFT settings in your own zone

ISI_PRIV_ROLE • Create new roles and assign privileges in your own zone
ISI_PRIV_VCENTER • Configure VMware® for vCenter® in your own zone
ISI_PRIV_LOGIN_PAPI • Login to the Platform API and the WebUI in your own zone
ISI_PRIV_IFS_BACKUP • Bypass file permission checks and grant all read permissions inside the
zone base path
ISI_PRIV_IFS_RESTORE • Bypass file permission checks and grant all write permissions inside the
zone base path
ISI_PRIV_NS_TRAVERSE • Traverse and view directory metadata inside the zone base path
ISI_PRIV_NS_IFS_ACCESS • Access directories inside the zone base path via RAN

39 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Role-Based Access Control

13.2 Authentication provider behavior between RBAC and ZRBAC

Before OneFS 8.2.0, authentication providers are created in System access zone and accessible by any
access zones in a cluster. Each non-System access zone only contains its own local provider and uses other
providers in the System access zone, shown as Figure 35. A local provider is created implicitly in each access
zone.

System access zone

AD Provider
LDAP Provider
NIS Provider
File Provider
Local Provider
MIT Kerberos Provider

Used by Viewable/modifiable Used by

Zone01 from System access Zone02
zone

Zone01 Zone02

Local Provider Local Provider

Authentication provider behavior in RBAC

Starting with ZRBAC in OneFS 8.2.0, when an authentication provider is created from an access zone, it is
implicitly associated with the access zone. As shown in Figure 36, an authentication provider has following
behavior based on that association:

• An authentication provider created from System access zone

▪ Can be viewed and used by all access zones.
▪ Can be modified/deleted only from System access zone.
• An authentication provider created from a non-System access zone
▪ Can only be used by that specific non-System access zone.
▪ Cannot be used by other access zones, including System access zone.
▪ Can be viewed/modified/deleted only from that specific access zone and System access
zone.

40 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Role-Based Access Control

• The MIT Kerberos provider can only be created from System access zone and used by all access
zones.
• A local provider in a non-System access zone
▪ Can only be used by that specific non-System access zone.
▪ Cannot be used by other access zones, including System access zone.
▪ Can be viewed/modified only from that specific access zone and System access zone.

Note: The name of an authentication provider must be unique globally. Thus, for example, you cannot create
an LDAP provider named “ldap01” in two different access zones.

System access zone

AD Provider
LDAP Provider
NIS Provider
File Provider
Local Provider
MIT Kerberos Provider

Viewable/modifiable/
Viewable/usable Viewable/usable
deletable from
from Zone01 from Zone02
System access zone
Viewable/modifiable Viewable/modifiable
from System access from System access
zone Zone01 Zone02 zone

AD Provider AD Provider
LDAP Provider LDAP Provider
NIS Provider NIS Provider
File Provider File Provider

Local Provider Local Provider

Authentication provider behavior in ZRBAC

13.3 Multi-instance Active Directory authentication provider

Previously, only one connection to a Microsoft Active Directory (AD) domain was allowed, and the name
of the AD provider had to be the same as the domain name. For the ZRBAC in OneFS 8.2, multi-
instance AD authentication provider is introduced to allow multiple connections to a same AD, so that
multiple access zones can create their own AD provider which connects to the same AD, but each
access zone can still only have at most one AD provider.

41 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Role-Based Access Control

To leverage the multi-instance AD provider, there are two options must be specified when configuring
AD provider from isi CLI command or WebUI:

▪ Create a new provider instance name for this provider.

▪ Create a new machine account in AD for this provider.

From isi CLI command, specify --instance and --machine-account options when using isi auth
ads create. An example shown as below:

# isi auth ads create --name=example.com --user=administrator

--instance=example01 --machine-account=ad-zone01

From WebUI, the options for instance name and machine account name are shown as Figure 37.

Multi-instance AD provider configuration

42 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
SSH multi-factor authentication with Duo

14 SSH multi-factor authentication with Duo

Duo is a vendor of cloud-based multi-factor authentication (MFA) services. MFA enables security to prevent a
hacker from masquerading as an authenticated user. Duo allows an administrator to require multiple options
for secondary authentication. With multi-factor authentication, even though a hacker steals the user name and
password, he cannot be authenticated to a network service easily without a user’s device.

Starting with OneFS 8.2.0, OneFS supports SSH MFA with the Duo service through SMS, phone callback,
and push notification through the Duo Mobile app. SSH MFA does not bypass any existing access-check
process on OneFS. A user must have a valid password or public-private key and the RBAC SSH privilege.
Currently, the SSH MFA configuration only supports CLI commands (no WebUI support). The following CLI
commands are introduced to view and configure related exposed settings.

• SSH access settings: isi ssh view/modify

• Duo service settings: isi auth duo view/modify

To use Duo with OneFS, an administrator must have a Duo account to configure following settings in the Duo
service.

• Create an “Unix Application” entry to represent the OneFS cluster. OneFS will use the information
contained in the “Unix Application”, including the Duo service API hostname, integration key, and
secret key.
• Create user accounts that use Duo. Duo does not have any access to data or configuration on the
cluster. All users in the OneFS cluster that will use SSH MFA with Duo must be added to the Duo
service.

Note: By default, the Duo username normalization is not AD aware. This means that it will alter
incoming usernames before trying to match them to a user account. For example,
"DOMAIN\username", "[email protected]", and "username" are treated as the same user.

Refer to article Configure SSH MFA on OneFS 8.2 Using Duo for details about configuration steps.

43 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Isilon migrations and permissions

15 Isilon migrations and permissions

It is essential to understand how a migrated file impacts the state of the file state. NFS based tools such as
rsync will provide POSIX permissions. SMB based tools such as emcopy create ACL permissions.

If SMB files from another vendor’s storage system are migrated to an Isilon cluster, the shares, file data,
security metadata, security identifiers, ACLs, ACEs, and inheritance attributes must all be migrated.

Datadobi simplifies migrations greatly by migrating all file permissions over to an Isilon cluster. For more
information, refer to the NetApp to OneFS Migration Tools Whitepaper.

44 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Troubleshooting and commands

16 Troubleshooting and commands

At a high level, when troubleshooting access issues, refer to the Token and File Permission infographic earlier
in this paper. Break down each component and confirm the contents, applying the following commands:

isi auth access --path=<path_to_file> --user=<user_to_view> -v

This command confirms the expected permission of a user based on a specific path to file.

isi auth id

This command lists privileges for the issuing user including memberships, On-Disk, RBAC, and currently
active sessions.

isi_auth_expert

This command checks authentication providers, confirming they are online and operational. A ‘-d’ is optional
for verbose output.

ls –le & ls –len

Confirm file permissions:

isi zone zones list –v

Review mapping rules:

isi auth mapping list | dump --zone

Review ID mapping:

16.1 Anatomy of a cross-platform access token

If user mapping rules are not configured, a user authenticating with one directory service receives full access
to the identity information in other directory services when the account names are the same. For example, a
user who authenticates with an Active Directory domain as york\jane automatically receives identities for the
corresponding UNIX user account for Jane from LDAP or NIS.

In the most common scenario, OneFS is connected to two directory services, Active Directory and LDAP. In
such a case, the default mapping provides a user with a UID from LDAP and a SID from the default group in
Active Directory. The user’s groups come from Active Directory and LDAP. The user’s home directory, gecos,
and shell come from Active Directory.

The following examples demonstrate how OneFS builds an access token for a Windows user who
authenticates with Active Directory but has a corresponding account with the same name in LDAP. User
mapping rules are not in place.

45 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Troubleshooting and commands

First, view a user’s token from only Active Directory by running the following command and targeting the
user’s Active Directory domain account. The output is abridged to remove some immaterial information.

isi auth users view --user=york\\stand --show-groups

Name: YORK\stand
DN: CN=stand,CN=Users,DC=york,DC=hull,DC=example,DC=com
DNS Domain: york.hull.example.com
Domain: YORK
Provider: lsa-activedirectory-provider:YORK.HULL.EXAMPLE.COM
Sam Account Name: stand
UID: 4326
SID: S-1-5-21-1195855716-1269722693-1240286574-591111
Primary Group
ID : GID:1000000
Name : YORK\york_sh_udg
Additional Groups: YORK\sd-york space group
YORK\york_sh_udg
YORK\sd-york-group
YORK\sd-group
YORK\domain users

Next, view a user’s token from only LDAP by running the following command and targeting the user’s LDAP
account. The output is abridged.

isi auth user view --user=stand --show-groups

Name: stand
DN:
uid=stand,ou=People,dc=colorado4,dc=hull,dc=example,dc=com
DNS Domain: -
Domain: LDAP_USERS
Provider: lsa-ldap-provider:Unix LDAP
Sam Account Name: stand
UID: 4326
SID: S-1-22-1-4326
Primary Group
ID : GID:7222
Name : stand
Additional Groups: stand
sd-group
sd-group2

When there are no mapping rules, and when the user logs in to the cluster over SMB, OneFS authenticates
the user with Active Directory and builds an access token that prioritizes the account information from Active
Directory, but appends the supplemental groups from the UNIX LDAP token to the end of the final token:

46 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Troubleshooting and commands

isi auth mapping token --user=york\\stand

User
Name : YORK\stand
UID : 4326
SID : S-1-5-21-1195855716-1269722693-1240286574-591111
On Disk : 4326
ZID: 1
Zone: System
Privileges: -
Primary Group
Name : YORK\york_sh_udg
GID : 1000000
SID : S-1-5-21-1195855716-1269722693-1240286574-66133
Supplemental Identities
Name : YORK\sd-york space group
GID : 1000002
SID : S-1-5-21-1195855716-1269722693-1240286574-579109
Name : YORK\sd-york-group
GID : 1000004
SID : S-1-5-21-1195855716-1269722693-1240286574-475739
Name : YORK\sd-workers
GID : 1000003
SID : S-1-5-21-1195855716-1269722693-1240286574-169779
Name : YORK\domain users
GID : 1000001
SID : S-1-5-21-1195855716-1269722693-1240286574-513
Name : Users
GID : 1545
SID : S-1-5-32-545
Name : sd-group
GID : 100001
SID : S-1-22-2-100001
Name : sd-group2
GID : 100002
SID : S-1-22-2-100002

The key points to compare in the prior example correspond to the following numbers:

1. The primary username is from Active Directory.

2. The user’s UID is from LDAP.
3. The user’s SID is from Active Directory.
4. The primary group is from Active Directory.
5. These supplemental identities are from Active Directory, as indicated by the name of the domain
before the name of the group.
6. The group named Users and its GID of 1545 is a built-in OneFS local group that comes from the
OneFS local provider; it appears in the token by default because the OneFS operating system adopts
the standard Microsoft Windows practice of adding the Domain Users group to the local users group
when the system is joined to an Active Directory domain.
7. These last two groups are appended to the token from the UNIX LDAP token.

47 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Troubleshooting and commands

The mapping service leaves out the user’s LDAP primary group. Add the primary group from LDAP to the final
token by creating a user mapping rule.

By default, when running the isi auth mapping command with a UNIX username, OneFS looks up the UNIX
user’s information from LDAP without mapping it to the UNIX user’s Active Directory account information.
Why? Because OneFS gives preference to using a UID to maximize NFS performance. If OneFS instead
showed the information from Active Directory as well, the results of the command would have visual
symmetry with the result of an isi auth mapping request for an AD user—which includes the information from
LDAP. However, the visual symmetry would come at the expense of NFS performance.

48 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Troubleshooting and commands

16.2 Anatomy of a cross-platform file permission

On an Isilon cluster, each ACE in a file permission is presented as a single line prefaced by an index number,
which starts at 0, and is followed by these parts:

• Identity: the identity to which the ACE applies

• Allow or deny: whether the ACE allows or denies the permissions listed in the ACE
• Permissions: a list of one or more permissions that are allowed or denied by the ACE
• Permission flags: flags that reflect the types of inheritance

The identity can be one of three types: user (listed as “user:”), group (listed as “group:”), or the special identity,
everyone. For directories, it can also be one of two special template identities: creator_owner or
creator_group. When present in the ACL of a containing directory, these template identities are replaced in
the ACL of a newly created file system object with the specific user and group of the respective creator.

An ACE can optionally contain flags that specify whether it is inherited by child folders and files. Inheritance
takes place when files and subdirectories are created; modifying an inherited rule affects only new files and
subdirectories, not existing ones. The following flags specify the types of inheritance for permissions in the
ACE:

• object_inherit: Only files in this directory and its descendants inherit the ACE.
• container_inherit: Only directories in this directory and its descendants inherit the ACE.
• no_prop_inherit: This ACE will not propagate to descendants (applies to object_inherit and
container_inherit ACEs).
• inherit_only: The ACE does not apply to this object, but will apply to descendants when inherited. For
example, when this flag is set on a directory, the ACE for the directory will not apply to the directory
but will apply to its subdirectories.
• inherited_ace: The ACE was inherited.

The following file permission shows some of these components. The listing was obtained by running the ls
command with an option (le) that Isilon added to show the ACL. The option is available only on the Isilon
cluster, not on a UNIX client that has mounted an export. See the OneFS man page for the ls command. The
plus sign that follows the POSIX mode bits indicates that the file contains an actual ACL, not a synthetic ACL.

ls -le bar.txt
-rw-r--r-- + 1 root wheel 0 Apr 22 17:23 bar.txt
OWNER: user:root
GROUP: group:wheel
0: group:Administrators allow
std_read_dac,std_synchronize,file_read_ext_attr,file_read_attr
1: user:root allow file_gen_read,file_gen_write,std_write_dac
2: group:wheel allow file_gen_read
3: everyone allow file_gen_read

49 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Appendix

A Appendix

A.1 Configuring Active Directory, LDAP, RFC 2307, and Kerberized NFS
For more information on configuring Microsoft Active Directory, LDAP or Kerberized NFS, refer to the
following documents:

• How to connect Isilon OneFS 7.x to LDAP and Active Directory:

https://support.emc.com/docu51637_How-to-connect-Isilon-OneFS-7.x-to-LDAP-and-Active-
Directory.pdf?
• Integrating EMC Isilon with Kerberized NFS and Windows Active Directory:
https://support.emc.com/docu59801_Integrating-Isilon-with-Kerberised-NFS-and-Windows-Active-
Directory.pdf?
• How to configure OneFS and Active Directory for RFC2307 compliance:
https://support.emc.com/kb/335338

Note: An active Dell EMC support account is required to access the links above.

A.1.1 Required fields for LDAP

If you are using an LDAP server, such as OpenLDAP, the following fields are required:

• ldap-uid
• ldap-user-filter
• ldap-group-filter
• ldap-loginshell
• ldap-homedirectory

A.2 Microsoft Active Directory with RFC 2307

RFC 2307 was initially created to use LDAP as a Network Information Service. As enterprise requirements
have evolved, AD and RFC2307 have also evolved.

For more information on RFC 2307, refer to the official RFC: https://www.ietf.org/rfc/rfc2307.txt

RFC 2307 support for AD first launched with Windows Server 2003 and exists today in Windows Server 2016.
However the implementation has been through several variations. In the initial release of AD with RFC 2307 it
was referred to as ‘Services for Unix’, later this was renamed to ‘Identity Management for UNIX’. As the
implementation and naming have changed, RFC 2307 provides the following:

• Manage user accounts and passwords on Windows and UNIX systems by using Server for Network
Information Service (NIS)
• Automatically synchronize passwords between Windows and UNIX operating systems by using
Password Synchronization

From an OneFS perspective, integrating RFC 2307 with AD, simplifies the management of users in a multi-
protocol environment, as only a single authentication provider is required to collect the SID and UID with

50 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Appendix

associated GIDs. In this architecture, Active Directory stores the user credentials and RFC2307 stores UIDs
and GIDs. OneFS does not require the NIS authentication component, as only the UID/GIDs are used. AD
with RFC 2307 maps SIDs with UID/GIDs, eliminating the need for mapping in OneFS, simplifying
management further.

Through Windows Server 2003, 2008, 2012, and 2016 the RFC 2307 support has varied significantly, not only
from a cosmetic perspective, but the overall implementation. For more information on the changes throughout
the years, refer to this Microsoft Technet blog post. Although the RFC 2307 implementation has changed
throughout the releases, RFC2307 attributes (e.g., GID/UID, etc.) in Active Directory continue to exist, which,
is all that is required for simplifying a multi-protocol implementation with OneFS.

A.2.1 Required fields for Windows Services for Unix

If you use Microsoft Active Directory with Windows Services for UNIX and RFC 2307 attributes to manage
Linux, UNIX, and Windows systems, the following fields are required in Active Directory:

• uid
• uidNumber
• gidNumber
• loginShell
• UNIXHomeDirectory

A.3 Permission mapping

This section describes how OneFS maps for file and directory permissions across the SMB and NFS
protocols when OneFS is running with its default settings.

A.3.1 Windows Access Rights to OneFS to Mode Bits

Windows Access Rights to OneFS to Mode Bits
Windows Access Rights OneFS internal representation Mode Bits approximation
FILE_ADD_FILE add_file d-w-

FILE_ADD_SUBDIRECTORY add_subdir d-w-

FILE_ALL_ACCESS dir_gen_all, file_gen_all drwx or -rwx

FILE_APPEND_DATA append, add_subdir --w- or d-w-

FILE_DELETE_CHILD delete_child d-w-

FILE_EXECUTE execute ---x

FILE_LIST_DIRECTORY list dr--

FILE_READ_ATTRIBUTES file_read_attr -r--

FILE_READ_DATA file_read -r--

51 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Appendix

Windows Access Rights OneFS internal representation Mode Bits approximation

FILE_READ_EA file_read_ext_attr -r--

FILE_TRAVERSE traverse d--x

FILE_WRITE_ATTRIBUTES file_write_attr --w-

FILE_WRITE_DATA file_write --w-

FILE_WRITE_EA file_write_ext_attr --w-

DELETE std_delete d-w- or --w-

READ_CONTROL std_read_dac dr-- or -r--

WRITE_DAC std_write_dac drwx or -rwx

WRITE_OWNER std_write_owner drwx or -rwx

SYNCHRONIZE std_synchronize NA

A.3.2 Mapping Mode Bits to ACLs

Because mode bits are a subset of the richer Windows ACL model, mapping mode bits to ACLs is simpler.
OneFS processes mode bits to create a synthetic ACL when an SMB client attempts to access a file or a
directory with mode bits. Because the security model for ACLs is richer than that of mode bits, no information
is lost.

Mapping for UNIX Read

Description Permissions
UNIX Permission Read
OneFS file_gen_read
Windows Effective Permissions list folder/read data
Mapping to Windows Access Rights Constants FILE_LIST_DIRECTORY,
FILE_READ_ATTRIBUTES, FILE_READ_DATA,
FILE_READ_DATA, FILE_READ_EA

52 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Appendix

Mapping for UNIX Write

Description Permissions
UNIX Permission Write
OneFS file_gen_write
Windows Effective Permissions create files/write data; create folders/append Data;
delete subfolders and files
Mapping to Windows Access Rights Constants FILE_ADD_FILE, FILE_WRITE_DATA;
FILE_ADD_SUBDIRECTORY,
FILE_APPEND_DATA; DELETE,
FILE_DELETE_CHILD, FILE_WRITE_ATTRIBUTES,
FILE_READ_EA

Mapping for UNIX Execute

Description Permissions
UNIX Permission Execute
OneFS file_gen_write
Windows Effective Permissions traverse folder / execute file
Mapping to Windows Access Rights Constants FILE_TRAVERS, FILE_EXECUTE

In addition, the mode rwx is mapped to full control (FILE_ALL_ACCESS), which is represented on OneFS as
file_gen_all. As such, a user, a group, or everyone with the mode bit set to rwx includes the following
additional effective permissions: change permissions, take ownership, delete, and synchronize (WRITE_DAC,
WRITE_OWNER, DELETE, and SYNCHRONIZE).

A.3.3 OneFS permissions for file system objects

Similar to the Windows permissions model, the Isilon system of representing permissions divides permissions
into three related groups: standard permissions, which can apply to any object in the file system; generic
permissions, which are logical wrappers for a bundle of more specific permissions; and constants, each of
which is a specific type of permission. Also, certain permissions apply only to a directory; others apply only to
a non-directory file system object.

OneFS standard permissions

Permission Description
std_delete The right to delete the object

std_read_dac The right to read the security descriptor, not including the SACL. (In OneFS, a
superuser can list the SACL, but it is otherwise unsupported.)
std_write_dac The right to modify the DAC L in the object’s security descriptor

std_write_owner The right to change the owner in the object’s security descriptor

53 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Appendix

Permission Description
std_synchronize The right to use the object as a thread synchronization primitive. (On OneFS, this
right has no effect.)
std_required Maps to std_delete, std_read_dac, std_write_dac, and std_write_owner

OneFS directory permissions

Permission Description
dir_gen_all Read, write, and execute access

dir_gen_read Read access

dir_gen_write Write access

dir_gen_execute Execute access

list List entries

add_file The right to create a file in the directory

add_subdir The right to create a subdirectory

delete_child The right to delete children, including read-only files

traverse The right to traverse the directory

dir_read_attr The right to read directory attributes

dir_write_attr The right to write directory attributes

dir_read_ext_attr The right to read extended directory attributes

dir_write_ext_attr The right to write extended directory attributes

Specific permissions for directories

Permission Description
dir_gen_read list, dir_read_attr, dir_read_ext_attr, std_read_dac, and std_synchronize

dir_gen_write add_file, add_subdir, dir_write_attr, dir_write_ext_attr, std_read_dac, and

std_synchronize
dir_gen_execute traverse, std_read_dac, and std_synchronize

dir_gen_all dir_gen_read, dir_gen_write, dir_gen_execute, delete_child, and std_write_owner

54 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Appendix

OneFS permission for non-directory objects

Permission Description
file_gen_all Read, write, and execute access

file_gen_read Read access

file_gen_write Write access

file_gen_execute Execute access

file_read The right to read file data

file_write The right to write file data

append The right to append to a file

execute The right to execute a file

delete_child This permission is not used for a file but can be set for Windows compatibility.

file_read_attr The right to read file attributes

file_write_attr The right to write file attributes

file_read_ext_attr The right to read extended file attributes

file_write_ext_attr The right to write extended file attributes

Specific permissions for non-directory objects

Permission Description
file_gen_read file_read, file_read_attr, file_read_ext_attr, std_read_dac, and std_synchronize

file_gen_write file_write, file_write_attr, file_write_ext_attr, append, std_read_dac, and

std_synchronize
file_gen_execute execute, std_read_dac, and std_synchronize

file_gen_all file_gen_read, file_gen_write, file_gen_execute, delete, std_write_dac, and

std_write_owner

55 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2
Additional resources

B Additional resources
See the following resources for more information:

OneFS 8.1.0 Documentation - Isilon Info Hub

OneFS 8.1 Web Administration Guide

OneFS 8.1 CLI Administration Guide

OneFS 8.1 API Reference

EMC Isilon SmartConnect White Paper

EMC Isilon OneFS and IsilonSD 8.1 Technical Specifications Guide

OneFS 8.1 Security Configuration Guide

Isilon Network Design Considerations

Isilon OneFS User Mapping

56 Dell EMC Isilon OneFS: Authentication, Identity Management, and Authorization | H13115.2