NFS mapping annon user to a known AD user - how?
750 views
Skip to first unread message
julian firminger
Feb 10, 2015, 5:56:43 AM2/10/15
to isilon-u...@googlegroups.com
What I want to do is the normal NFS equivalent of:
# share -o rw,anon=<AD-UID> /ifs/<export>or even# share -o rw,anon=0 /ifs/<export>As it's a very restricted point on a heavily acl'd network segment. I'm not worried about unauthorized access in that way, even as root.
In other words, I want a group of servers (Elemental transcoders), that are not LDAP systems, that are mounting our heavily ACL’d file system, to mount an export as anonymous and have the isilon map anonymous users to either a known AD user or to root.
What I cant find or figure out is the isi equivalent of the “anon=0” parameter from a normal NFS command.
THe CLI refernece lists:
isi nfs exports modify --map-root <id>
Which is the opposite of what I want to do. So is there a way of going the other way around?
julian firminger
Feb 13, 2015, 7:14:17 AM2/13/15
to isilon-u...@googlegroups.com
fwiw:
isi
nfs exports modify <export> --map-all <UID>
isi
nfs exports modify 7 --map-all 0
or better still, map to a UID of an AD user
Neproshennie
Feb 20, 2015, 11:11:46 AM2/20/15
to isilon-u...@googlegroups.com
If you want to create a mapping of a Unix UID to an AD user then you would want to create a specific mapping for that particular UID to an AD SID. Depending if the target AD user already has Unix attributes, or is already mapped to an identity in another authentication provider, would depend if you wanted to create a one-way or two-way mapping.
Keep in mind:
* You can create an ACL that affects the Unix UID without a name; the name is for aesthetics.
* Be careful if you don't have any kind of authentication provider for Unix systems because anyone could assume that uidNumber and get whatever permissions you set. This is where AD with Services For Unix (RFC2307 compliant schema), LDAP, or NIS can come in beneficial.
* Any UID that comes over NFS that does not have an explicit ACE in the ACL will full under "everyone" which can be your anonymous catch-all.
First thing, we're going to need to look at a few things for the AD user to see if said user already has Unix attributes
The UID is 1000010 which is a OneFS auto-generated UID so this user doesn't have Unix attributes pulled from AD, or mapped from another authentication provider, so we will go ahead and manipulate the mapping. Keep the SID for the user on-hand too, we'll need that.
Now for the fun of the mapping database.
When a user accesses data on the cluster and they authenticate as their AD user, OneFS will see the name and grab the SID. The SID will then point to an associated UID. If the On-Disk Identity is set to Native (default), the actual permissions could be based on SID or UID (use "ls -lend <file>" to see the non-name resolved entities); if the permission is UID based then this mapping will point the SID to the UID needed for that user to access said file.
Of course there is the inverse; if the token expires (after 15 minutes by default) and a user tries to access that same file but the On-Disk Identity has the actual permission based on the UID, then the mapping database says "hey, the ACE on this file has a UID of 1000010, who does that belong to?" so the mapper queries the authentication providers for that SID to finish building a token.
Forward and reverse mappings are important for that very reason. We plan on changing this BUT what happens if that AD user you have already has written data to the cluster and it has the old UID? Simple. Half of that equation is going to be a one-way mapping that points that UID to the SID using the old UID *but* references to that SID will point to the new UID -- so the old UID will point to the user but any changes/new writes will come across as the new UID number ego it gets updated!
So looking at the information above, let's create the mapping to the UID coming across from the Unix client. For this example, we'll assume the transcoder user has a UID of 1007.
This will create a mapping that points 1007 to S-1-5-21-3801086132-4088764512-2976279516-1130 and another that points S-1-5-21-3801086132-4088764512-2976279516-1130 to 1007. What about the old UID of 1000010?
That will create a one way mapping that points 1000010 to S-1-5-21-3801086132-4088764512-2976279516-1130.
To verify that, you can look for the SID in the mapping dump again and you should see something similar to:
This will preserve the old permissions with the old UID but also updated it to the new UID if data is changed. Please keep in mind that if the On-Disk Identity for the given path, or file, is using a SID then you will need "map-lookup-uid" enabled on the NFS exports so UIDs will be looked up and an authentication token gets built that has both the Unix and AD information. If the other UIDs you lookup are not associated with an AD account then you will be generating additional AD authentication traffic.
Some extra thoughts:
* Mapping all users on an export to 'root' can lead to security concerns.
* Mapping all users to a specific AD user can be problematic.
* You use host access controls for read/write users on specific machines to be mapped to a specific AD user then have a list of root machines that will be granted root to root mapping that bypasses read/write client mappings.
* You can create a specific user on the cluster, or in an auth provider, to map the specific user to. You do not want to map multiple UIDs to a single SID as the results can be unpredictable and probably undesirable. UID consistency across the Unix machines by use of a central authentication provider would be the best option.
* Manual UID mappings as described above have been used time and time again for similar situations.
Please feel free to ask any questions or provide more information so a more refined suggestion could be made.
Keep in mind:
* You can create an ACL that affects the Unix UID without a name; the name is for aesthetics.
* Be careful if you don't have any kind of authentication provider for Unix systems because anyone could assume that uidNumber and get whatever permissions you set. This is where AD with Services For Unix (RFC2307 compliant schema), LDAP, or NIS can come in beneficial.
* Any UID that comes over NFS that does not have an explicit ACE in the ACL will full under "everyone" which can be your anonymous catch-all.
First thing, we're going to need to look at a few things for the AD user to see if said user already has Unix attributes
DONT-REBOOT-ME-1# isi auth mapping token thematrix\jamie | head -n 20
User
Name : THEMATRIXjamie
UID : 1000010
SID : S-1-5-21-3801086132-4088764512-2976279516-1130
ZID: 1
Zone: System
Privileges: -
Primary Group
Name : THEMATRIXdomain users
GID : 1000000
SID : S-1-5-21-3801086132-4088764512-2976279516-513
Other Groups
Name : THEMATRIXsplunkadmins
GID : 1000149
SID : S-1-5-21-3801086132-4088764512-2976279516-5042
...The UID is 1000010 which is a OneFS auto-generated UID so this user doesn't have Unix attributes pulled from AD, or mapped from another authentication provider, so we will go ahead and manipulate the mapping. Keep the SID for the user on-hand too, we'll need that.
Now for the fun of the mapping database.
DONT-REBOOT-ME-1# isi auth mapping dump | egrep "SID:S-1-5-21-3801086132-4088764512-2976279516-1130"
["SID:S-1-5-21-3801086132-4088764512-2976279516-1130", [["UID:1000010", 32]]]
["UID:1000010", [["SID:S-1-5-21-3801086132-4088764512-2976279516-1130", 48]]]When a user accesses data on the cluster and they authenticate as their AD user, OneFS will see the name and grab the SID. The SID will then point to an associated UID. If the On-Disk Identity is set to Native (default), the actual permissions could be based on SID or UID (use "ls -lend <file>" to see the non-name resolved entities); if the permission is UID based then this mapping will point the SID to the UID needed for that user to access said file.
Of course there is the inverse; if the token expires (after 15 minutes by default) and a user tries to access that same file but the On-Disk Identity has the actual permission based on the UID, then the mapping database says "hey, the ACE on this file has a UID of 1000010, who does that belong to?" so the mapper queries the authentication providers for that SID to finish building a token.
Forward and reverse mappings are important for that very reason. We plan on changing this BUT what happens if that AD user you have already has written data to the cluster and it has the old UID? Simple. Half of that equation is going to be a one-way mapping that points that UID to the SID using the old UID *but* references to that SID will point to the new UID -- so the old UID will point to the user but any changes/new writes will come across as the new UID number ego it gets updated!
* WARNING *
With any manual changes to the user mapping database, it is recommended to create a backup. You can redirect the dump option to a file like:It can then be restored with:
So looking at the information above, let's create the mapping to the UID coming across from the Unix client. For this example, we'll assume the transcoder user has a UID of 1007.
DONT-REBOOT-ME-1# isi auth mapping modify --source-uid=1007 --target-sid=S-1-5-21-3801086132-4088764512-2976279516-1130 --2way --replace
This will create a mapping that points 1007 to S-1-5-21-3801086132-4088764512-2976279516-1130 and another that points S-1-5-21-3801086132-4088764512-2976279516-1130 to 1007. What about the old UID of 1000010?
DONT-REBOOT-ME-1# isi auth mapping modify --source-uid=1000010 --target-sid=S-1-5-21-3801086132-4088764512-2976279516-1130
That will create a one way mapping that points 1000010 to S-1-5-21-3801086132-4088764512-2976279516-1130.
To verify that, you can look for the SID in the mapping dump again and you should see something similar to:
DONT-REBOOT-ME-1# isi auth mapping dump | egrep "SID:S-1-5-21-3801086132-4088764512-2976279516-1130"
["SID:S-1-5-21-3801086132-4088764512-2976279516-1130", [["UID:1007", 0]]]
["UID:1007", [["SID:S-1-5-21-3801086132-4088764512-2976279516-1130", 0]]]
["UID:1000010", [["SID:S-1-5-21-3801086132-4088764512-2976279516-1130", 0]]]
This will preserve the old permissions with the old UID but also updated it to the new UID if data is changed. Please keep in mind that if the On-Disk Identity for the given path, or file, is using a SID then you will need "map-lookup-uid" enabled on the NFS exports so UIDs will be looked up and an authentication token gets built that has both the Unix and AD information. If the other UIDs you lookup are not associated with an AD account then you will be generating additional AD authentication traffic.
Some extra thoughts:
* Mapping all users on an export to 'root' can lead to security concerns.
* Mapping all users to a specific AD user can be problematic.
* You use host access controls for read/write users on specific machines to be mapped to a specific AD user then have a list of root machines that will be granted root to root mapping that bypasses read/write client mappings.
* You can create a specific user on the cluster, or in an auth provider, to map the specific user to. You do not want to map multiple UIDs to a single SID as the results can be unpredictable and probably undesirable. UID consistency across the Unix machines by use of a central authentication provider would be the best option.
* Manual UID mappings as described above have been used time and time again for similar situations.
Please feel free to ask any questions or provide more information so a more refined suggestion could be made.
Reply all
Reply to author
Forward
0 new messages