Multi-protocol issue UID/GID not matching

They can't take advantage of enabling RFC 2307 on the cluster I presume. The other resort is mapping AD SID to UNIX UID/GID.

Hi,

How can we map AD SID to Unix UID/GID? Can that be done on Isilon or has to

be done on AD?

Utkarsh

RFC2307 has to be done in AD, ID mapping on Isilon. Check out this white paper:

https://support.emc.com/docu53353_White_Paper:_OneFS_Multiprotocol_Security_Untangled.pdf?language=en_US

On page 8:

ID mapping

Although their names are similar, the ID mapping service differs from the user mapping service. The goal of the ID mapping service is to map Windows SIDs to UNIX UIDs and GIDs and vice versa in order to provide consistent access across protocols.

During authentication, the ID mapping service associates Windows identifiers with UNIX identifiers. When a user connects to an Isilon cluster over SMB, the ID mapping service maps the user’s SIDs to UIDs and GIDs for access to files that were stored over NFS. By default, the ID mapping service matches accounts with the same name.

In contrast to SMB, when a user connects to the cluster over NFS, the ID mapping service does not map the UID and GIDs to SIDs by default, because the default identity stored on disk is already in the form of a UID and GIDs. Thus, with NFS, mapping the UID and GIDs to SIDs is unnecessary.

Utkarsh,

First, there is no industry standard for how to gel together multiprotocol permissions (meaning POSIX & ACLs).  NetApp does it one way with mixed Qtrees, VNX a second, and Isilon a third (which of course we believe is superior ).  But ultimately keep in mind 2 things.

1. When doing a data migration the goal is the ensure the behavior of the target platform to the end users and applications is consistent with their expectations, or can be made to work with their workflow.   User Acceptence testing is key.  The permission structure looking the same is a separate item.  The goals of such testing are:

     a. If a user could get to data before the migration via SMB, then they can do so after, with the same level of access.

     b. If a user could get to data before the migration via NFS, then they can do so after, with the same level of access.

     c. If a user could not get to data before the migration via SMB, they cannot get to it after.

     d. If a user could not get to data before the migration via NFS, they cannot get to it after.

2. The true goal of any multiprotocol implementation is that a given user has the same access, to the same data irregardless of the data access protocol.  In our case that's a long list; SMB, NFS, HDFS, FTP, sFTP, FTPs, RAN, Swift, HTTP, etc.

Keeping those two design tenets in mind, multiprotocol data access comes down to 2 things.

1. Authentication

2. Access Control (filesystem permissions)

Where it sounds like you're really having problems is on the Authentications side of the equation.  As you've already discovered, if an SMB user connects, and we do not have a valid UID or GID for that user, we'll make one up with an internal usermapping daemon.  There's no mystery or secrecy here, everyone does this in some form.  Isilon's default range is 1 million to 2 million.  VNX uses 32K-64K.  NTAP has some options, but will map to a default user as you can read here:

https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-09C7812F-E6EA-47C6-AB79-EAB803E7A8EB.html

So what does that mean?  It means the Isilon cluster needs to know about all your auth providers, so that it can create a unified persona for any individual user.  Meaning it needs to be able to understand that mydomain\joe from AD and 'joe' from LDAP are the same person.  So how do you do that?  User Mapping rules.  Read up on them in the OneFS Web or CLI Admin guide for your release of OneFS.

Ultimately the goal should be that any when you map domain\joe to LDAP joe that regardless of how the user connects, the SID, UID, GID, and all supplemental identities (read secondary groups) are the same.

You can test this at the CLI like this:  (the double backslash is intentional

isi auth mapping token mydomain\\joe

isi auth mapping token joe

The results should match when you're at your desired state.  Look at the usrmap.cfg file on the NetApp for some similar logic.  Not that the wildcards require that the CN match between the providers.  Otherwise you can do 1 by 1 mappings, like domain\joe is jsmith from LDAP. 

The usermapping rules can be a bit difficult to understand at first syntactically, but keep in mind that they are basically SQL concepts, append, insert, join, replace.  And that usermapping rules need to be in both directions so not only is mydomain\joe equal to jsmith, but also jsmith is equal to mydomain\\joe

Hope this helps, I know it was a bit long winded, but I wanted to clear up any misconceptions,

~Chris Klosterman

Senior Solution Architect

EMC Isilon Offer & Enablement Team

chris.klosterman@emc.com

twitter: @croaking

Chris,

Thank you for explaining these concepts, i find multi-protocol so confusing. Maybe you can share some sample implementation examples ? Cluster talk episode   ?

We have had this issue on our clusters

AD + Sun Directory Service LDAP

when a new user gets created in our AD they do not automatically get an LDAP account.

The first time they access the cluster from windows, the Isilon checks a matching LDAP account, if it does not find one, it will generate a "unique" UID (starting at 1,000,000  believe).

If the user later gets an LDAP account, the Isilon does not correct the mapping. We need to go into the system and delete the mappings that point to the generated UID. (Speak with support about this)

The issue does not occur if the LDAP account is created before they first access the Cluster.

Out of curiosity, what on-disk identity are you using?

We run a multi-protocol, but we use a UNIX on disk identity with ACLs basically set up as UNIX, with some changes to make Windows actually function. We have AD and OpenLDAP, with the Isilon being really the only place those two meet up. We actually do not use the mapping rules; the Isilon has been quite good about keeping the two in sync, as long as the names between the two directories match. In the rare instances when they do not, we manually override using the isi auth mapping command. 

We even ran with two ADs and an LDAP for a time, although I had to run some custom scripts to edit identities to keep the auth working properly.

The downside (or upside, depending on how much administration you want to do) is that we do not allow Windows ACLs at all; our Windows/Mac users have to deal with the fact that all we provide is POSIX level permissions.

Thanks Chris,

I don't know about the output of isi auth mapping token, however after the users get their UNIX account the output of isi auth mapping list still shows the Generated UID.

all of our user accounts match between AD and LDAP.

I haven't had this issue with NTFS shares (Though as that is the windows SID I expect it will work as you describe)

We run our UNIX shares explicitly denying ACL's in the SMB share. What we see is the following:

Files that are created by the user in Windows show the Generated UID when viewing from UNIX.

After we delete the mapping for the SID <> Generated UID mappings it shows the correct details in UNIX.

Chris Klosterman wrote: So in that way the platform can be extremely flexible for this type of workflow.

I completely agree.

We Run our cluster With native On-Disk Identity carlilek.

It should also be noted that one has to be very concise about the type of ID mapping rule to use

in a given situation:

Append - Insert - Replace - Remove - Join

which are explained in "the other" white paper on AIMA

https://www.emc.com/collateral/white-papers/h12417-identities-access-tokens-isilon-onefs-user-mapping-service-wp.pdf

hth

-- Peter

Thank you All for your assistence.

I got it working.

AD was getting Isilon default SID and LDAP had a different UID/GID initially.

In Isilon GUI Access Management, AD settings I enabled the option Map user/group info to "Yes"  and that fixed the issue.

Thanks and Regards,

Utkarsh