Moving to RFC2307bis UID mapping

[John Beranek - PA]

Hi,

We've had 2 Isilon clusters running for a while now, with a lot of data being written by (at least notionally) users in the company's Active Directory.

I've just managed to get the company's Active Directory updated to include the RFC2307bis attributes for "POSIX users", so that Active Directory can be the one source of truth for things like Unix/Linux UIDs/GIDs etc.

Does anyone have any experience of taking a running (OneFS 7.1.1.x in this case) Isilon cluster and updating the ID mapping to reflect the RFC2307bis mapping as supplied by AD?

I've tried a few operations regarding flushing mappings, but the tokens remain resolutely showing the old auto-calculated UIDs/GIDs.

Is there a reasonably simple way to manage this change, or does it necessitate scripted changes to mapping for each user/group?

Cheers,

John

[Rob Hersh]

I've been testing this with 7.2.1.2 simulator in preparation for the same cutover. I though i was going to have to recreate mappings as well but so far they have been auto-updating with the AD ones. Been a couple weeks since I've gone back to it but will let you know if that is still the case.

[John Beranek - PA]

Hmm, well I've not yet seen a change to the user mappings after the AD update, so I get something like the following (with SID obscured):

isi auth mapping token someuser

                   User

                       Name: someuser

                        UID: 1001131

                        SID: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-23544

                    On Disk: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-23544

                    ZID: 1

                   Zone: System

             Privileges: -

          Primary Group

                       Name: domain users

                        GID: 20513

                        SID: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-513

                    On Disk: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-513

Here you can see that the "domain users" group has the right GID, but I believe that is because that group had a gidNumber before the Isilon was installed. The user 'someuser' still has the auto-generated ID 1001131 instead of the correct 43544 (20000+last part of SID).

John 

[John Beranek - PA]

Looking at the "auth ads" settings, I'm not sure if the following is correct:

             Lookup Users: Yes

   Lookup Normalize Users: Yes

            Allocate UIDs: Yes

  Lookup Normalize Groups: Yes

            Allocate GIDs: Yes

           Lookup Domains: -

            Lookup Groups: Yes

Should the "Allocate UIDs/Allocate GIDs" settings be "No"?

John

[John Beranek - PA]

OK, so I figured it out, I did in fact need to do:

 isi auth modify example.com --sfu-support rfc2307

as our AD is using what the Isilon terms "SFU support is provided for Windows versions prior to Windows Server 2008", despite the domain controllers being 2012, with an older functionality level.

John

[Rob Hersh]

Yeah thats it, cluster needed to know to go look for those values.

There is also a setting you can use on the NFS export that might be beneficial. It has to do with using only the UID of the user over NFS, thus leveraging the token to determine which groups a given user belongs to. I don't know how to set it via the CLI but its under the advance settings when creating the export in the GUI. Its called Map Lookup UID, and you would set to Yes to have it do what I described.

[John Beranek - PA]

Mmm, interesting - for reference, on the CLI that would be:

isi nfs export modify <id>

--map-lookup-uid {yes | no}

  Specifies whether to look up incoming UNIX user identifiers (UIDs) locally.

--revert-map-lookup-uid

  Sets the value to the system default for --map-lookup-uid. 

I somehow assumed that to be the default case, so that is a user 'someuser' is in some groups, and a file has an ACE to allow one of those groups access, they'd get access appropriately. This is something which requires some testing...

John

[Rob Hersh]

Thanks for the syntax.

By default the client would continue to pass both its UID, primary GID and other GIDs it belongs to over NFS. Isilon would then base access on those values. My understanding and what I've experience via testing is that setting tells Isilon to ignore the GIDs being sent via NFS and leverage the token to determine group membership.

[John Beranek - PA]

That is indeed what my testing shows, with the setting ON, I can write to files/directories I'd expect to be able to according to those files' ACLs. I do end up with some deranged permission mapping though, which causes at least dislike from me:

$ touch test_file

$ ls -l test_file

-rwxrwx--- 1 johnb domain users 0 Apr  5 14:56 test_file*

$ chmod -x test_file

$ ls -l test_file

-rwxrwx--- 1 johnb domain users 0 Apr  5 14:56 test_file*

John

[Chris Pepper]

Map Lookup ID also enables users to have access to 16+ groups. The NFS protocol implementation only supports ~15 group memberships, so if any users have 16+ group memberships and need all that access, you need Map Lookup ID so the Isilon will determine access using their full group list.

Chris

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

[Adam Fox]

That is most likely due to an ACL on the file.  By default, if any group has access (even an inherited one like domain admins), it will show access on the POSIX bits.  You can alter that behavior cluster-wide to be more strict and only represent the user and group on the file in the POSIX bits although the ACL will still be enforced.

# isi auth settings acls modify --calcmode-owner=owner_only

# isi auth settings acls modify --calcmode-group=group_only

Now at have noticed that it takes effect once you have tweaked the permissions on the file/dir.  I wrote a python script to walk a tree and tweak the permissions, then set them back iff there is an ACL on the file/dir.

-- Adam Fox

adam...@yahoo.com

[John Beranek - PA]

Adam:

Ah, now that is interesting - those settings do indeed "improve" the behaviour, in my opinion. I now understand it, as there was an inherited group ACL on the files in question with Windows "Full Control" rights, which would indeed equate to (at some level) 770.

John

[Adam Fox]

Glad it's helpful.  If you want to see an example, here's one from my lab:

Before (default settings):

iptide1-1# ls -led swift

drwxrwx--- +  3 CAE\foxa3 Users  24 Feb  8 16:31 swift

OWNER: user:CAE\foxa3

GROUP: group:Users

CONTROL:dacl_auto_inherited

0: user:CAE\foxa3 allow dir_gen_all

1: group:CAE\domain admins allow dir_gen_all

 

Note in red how I have domain admins set to full control and so the bits are group bits are set even though if someone were only a member of the "Users" group, they would not get access.

Now after changing the settings and "pinging" the permissions, I get:

riptide1-1# ls -led swift

drwx------ +  3 CAE\foxa3 Users  24 Feb  8 16:31 swift

OWNER: user:CAE\foxa3

GROUP: group:Users

CONTROL:dacl_auto_inherited

0: user:CAE\foxa3 allow dir_gen_all

1: group:CAE\domain admins allow dir_gen_all

 

The actual access to the file is identical as the ACL will always be enforced, but the approximation of the ACL into POSIX bits has changed.

Hope this brings some clarity to anyone out there who finds this interesting.  

-- Adam Fox

adam...@yahoo.com

---

From: John Beranek - PA <john.b...@pressassociation.com>
To: Isilon Technical User Group <isilon-u...@googlegroups.com>
Sent: Thursday, April 7, 2016 12:04 PM
Subject: Re: Isilon-Users Re: Moving to RFC2307bis UID mapping

Adam:

Ah, now that is interesting - those settings do indeed "improve" the behaviour, in my opinion. I now understand it, as there was an inherited group ACL on the files in question with Windows "Full Control" rights, which would indeed equate to (at some level) 770.

John

On Thursday, 7 April 2016 03:35:15 UTC+1, Adam Fox wrote:

That is most likely due to an ACL on the file.  By default, if any group has access (even an inherited one like domain admins), it will show access on the POSIX bits.  You can alter that behavior cluster-wide to be more strict and only represent the user and group on the file in the POSIX bits although the ACL will still be enforced.

# isi auth settings acls modify --calcmode-owner=owner_only

# isi auth settings acls modify --calcmode-group=group_only

Now at have noticed that it takes effect once you have tweaked the permissions on the file/dir.  I wrote a python script to walk a tree and tweak the permissions, then set them back iff there is an ACL on the file/dir.

-- Adam Fox

adam...@yahoo.com

[John Beranek - PA]

and here's a different example from our system, where I've set "correct" POSIX permissions for a file from a Linux server, but still have the overriding Isilon ACLs in place:

$ ls -led test_file

-rw------- +  1 johnb  domain users  0 Apr  7 17:00 test_file

 OWNER: user:johnb

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: user:johnb allow file_gen_read,file_gen_write,std_write_dac

 1: group:domain users allow std_read_dac,std_synchronize,file_read_attr

 2: everyone allow std_read_dac,std_synchronize,file_read_attr

 3: group:dl_rba_smbroots-fullcontrol allow inherited file_gen_all,inherited_ace

John

[Peter Serocka]

John

the behavior when applying a POSIX chmod on a file with an ACL
is somewhat configurable on Isilon.

This is from the WebUI, under Protocols -> ACL -> ACL Policies:

chmod on files with existing ACLs:
Remove the existing ACL and set UNIX permissions instead
Remove the existing ACL and create an ACL equivalent to the UNIX permissions
Remove the existing ACL and create an ACL equivalent to the UNIX permissions, for all users/groups referenced in old ACL
Merge the new permissions with the existing ACL
Deny permission to modify the ACL
Ignore operation if file has an existing ACL

Plus a couple other choices; one of the rare places where
I prefer the WebUI over the CLI for better overview.

If you are struggling with the effect of chmod on ACLs,
this would be a starting place -- on virtual nodes of course,
as these setting are GLOBAL to the cluster.

Cheers

Peter