Solved!
Go to SolutionA
abqkawi1000
7 Posts
0
3316
July 8th, 2016 12:00
Using AIMA - force GID for Windows users
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
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.
Peter_Sero
6 Operator
•
1169 Posts
1591
0
Posted July 13th, 2016 02:00
How is the SMB share configured?
isi smb shares view SHARENAME
watch out for ==> Create Permissions: ....
-- Peter
Peter_Sero
6 Operator
•
1169 Posts
1591
1
Posted July 14th, 2016 05:00
Can you share some more details on those mapping rules? Why can't wildcards be used?
abqkawi1000
7 Posts
1591
0
Posted July 14th, 2016 09:00
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
7 Posts
1591
0
Posted July 14th, 2016 09:00
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
6 Operator
•
1169 Posts
1591
1
Posted July 15th, 2016 02:00
The ultimate reference is
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
7 Posts
247
0
Posted July 15th, 2016 13:00
Terrific! Thank you for pointing me in this direction. I will play with this and post my findings.
abqkawi1000
7 Posts
1591
1
Posted July 13th, 2016 06:00
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.