Using AIMA - force GID for Windows users

Question

I am struggling with user/id mapping.  I have a variety of mapping rules but am missing one last piece. I have both OpenLDAP and Active Directory working correctly. I can successfully Export/Share a directory with both NFS and SMB I can successfully read/write/delete to that directory from both Linux and Windows The UID is correct from both Linux and Windows The GID is different between Linux and Windows An ls -al of the directory on the Isilon will return: isilonNAS-1# ls -al total 77 drwxrwxr-x +   4 root            wheel                119 Jul  8 10:20 . drwxrwxr-x +  11 root            wheel                213 Jul  7 15:15 .. drwxrwx--- +  2 linuxusername  CORP\domain users       0 Jul  8 10:17   aWindowsDir -rwxrwx--- +   1 linuxusername  CORP\domain users       0 Jul  8 10:12   aWindowsfile.txt -rwxrwx--- +   1 linuxusername         linuxusername         0 Jul  8 10:10   alinuxfile -rwxrwx--- +   2 linuxusername         linuxusername         0 Jul  8 13:20   aLinuxDir         UID's match up but GID's dont. So what is happening is when connecting from Windows, the Isilon is not using the On Disk GID but rather the first Supplemental identity from the CORP\linuxusername user.  So here is what I need to do I want to force the Isilon to use the On Disk GID always, or to map the Supplemental Identity to the Real GID or the On Disk GID. Doe anyone have any ideas? Thanks for any guidance!! more info below. I have tried inserting, merging and appending GID, I have also tried removing supplemental groups but that errors. isi auth mapping token examples isilonNAS-1# isi auth mapping token --user=linuxusername                    User                        Name: linuxusername                         UID: 99888                         SID: S-1-22-1-99888                     On Disk: 99888                     ZID: 1                    Zone: System              Privileges: -           Primary Group                        Name: linuxusername                         GID: 99888                         SID: S-1-22-2-99888                     On Disk: 99888 An isi auth mapping token --user=CORP\linuxusername isilonNAS-1# isi auth mapping token --user=CORP\linuxusername                    User                        Name: CORP\linuxusername                         UID: 1000102                         SID: S-1-5-21-2076390139-1363556362-999999998-888888                     On Disk: S-1-5-21-2076390139-1363556362-999999998-888888                     ZID: 1                    Zone: System              Privileges: -           Primary Group                        Name: linuxusername                         GID: 99888                         SID: S-1-22-2-99888                     On Disk: 99888 Supplemental Identities                        Name: CORP\domain users                         GID: 1000000                         SID: S-1-5-21-2076390139-1363556362--999999998--222

abqkawi1000 · Accepted Answer

Thank you all for your help. I was also working with support and we managed to come across the solution. While it is not ideal, it definitely works. After mapping the AD identity to the LDAP identity all that was needed was to change the ACL policy setting to use BSD semantics which forces the GID to be inherited from the parent folder.

The benefits - this drops the annoying primary group that is coming from AD. Coming in from Windows SMB works terrific. CIFS mount and NFS also behave as the Isilon now agrees the user is the same person.

The costs - A massive number of user joins will have to be scripted. Since the user inherits the parent folder owner, this works fine for /project space, but not so well for /home. I will have to script a user dir creation with a chgrp to the correct private GID.

I don't know if at load, the Isilon will struggle with 3000 mapping rules or not. The scripting is not awful once I get it correct but I do hear the API is dog slow so I will have to use a local script with a cron. Not perfect, but serviceable.

chughh27 · Answer

Hello, What is the sequence of creating the user ? Also if you can flush current mapping.. Thanks Chughh

sjones51 · Answer

Hi abqkawi1000,

I don't know that I can pinpoint the exact issue based on what you are describing, however I did find a document that may help you find what you are looking for.

Identities, Access-Tokens, and the Isilon OneFS User Mapping Service

https://support.emc.com/docu50075

If you don't find the answer you are looking for, Isilon Support may be able to help you dive deeper into this.

https://support.emc.com/servicecenter/createSR

Peter_Sero · Answer

How is the SMB share configured? isi smb shares view SHARENAME watch out for ==> Create Permissions:  .... -- Peter

sluetze · Answer

Instead of scripting a new owner for /home/ you could just modify the default permissions to 700 and the group can be whatever it will...

Peter_Sero · Answer

Can you share some more details on those mapping rules? Why can't wildcards be used?

abqkawi1000 · Answer

Good question! Since we are not at the deployment phase, I just explored user mapping within the web interface where I explicitly lookup a user from both authentication providers. If a wildcard rule that maps all users from AD to all users from LDAP could work, then I imagine any user accessing the box receives this mapping rule and all would be well.

Any ideas on what this would look like?

abqkawi1000 · Answer

I could see how that could work for user space, but not sure how that would work with project space where members of a group would need rwxrws--- permissions.  Can you elaborate on how this would behave coming from the same user on a Linux box, then connecting from a Windows box?

Peter_Sero · Answer

The ultimate reference is

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

without which any experimenting with user mappings is quite a challenge...

I also find working with mapping rules is easier on the command line (CLI)

than in the Web interface.

In particular, if you have found a working per-user mapping already,

viewing it in the CLI as plain text should immediately lead to the

correct general form using wildcards -- if in doubt, just share it here.

In the end the general rule might look like

CORP\* += * [group]

or

CORP\* &= *

but let's see what exact per-user mapping you have found to work already.

-- Peter

abqkawi1000 · Answer

Terrific!  Thank you for pointing me in this direction.  I will play with this and post my findings.

abqkawi1000 · Answer

I was successful using the OneFS UI to create the user mapping rule

User Mapping Tab

Create rule - Join two users together

Join this user (for the LDAP user)

*

With this user (for my AD side)

DOMAIN\*

Just that easy and it works with for us nicely with the BSD semantics enabled.

Isilon

Was this post helpful?