Access NTFS qtree via NFS and usermapping problem

[USER_2000]

Here is what I want to do:

I have a FAS2240 with NetApp Release 8.1.3 7-Mode.

I have a CIFS qtree and I want to access it with NFS. So I started NFS on the NetApp and created /etc/exportfs like this:

/vol/vol1/qtree_vol1    -sec=sys,rw

I can mount the filesystem from my Solaris box with NFSv4 without problems. I have set the NFSv4 domain on the NetApp

mount -o vers=4 netapp:/vol/vol1/qtree_vol1 /mnt

But when I try to access the share from Solaris, I get a permission denied as root as well as with a non-root user. The user has full rights on the exported folder in NTFS. On the Solaris box all users have the same username as they have in Active Directory. I thought, this would suffice to not have to use /etc/usermap.cfg and /etc/passwd on the Netapp. But obviously, the Solaris user does not get mapped to the Active Directory user. Can this be done? How?

[aborzenkov · Accepted solution]

NetApp must be able to a) map Unix user name to Unix user UID and b) map Unix user name to Windows user name. You said nothing about configuring user mapping, so I assume nothing is configured ☺

In practice that means that NetApp and Unix must use the same user database backend, most likely LDAP. And to ensure that Unix user means the same as Windows user, this LDAP backend usually must be AD.

Please see tr3490 for details on multiprotocol access and tr3458 for example of using AD as common backend.

[USER_2000]

You are probably right, but I wonder whether it is really necessary to use a common backend, which I do not have. (You gave me a lot to read and I admit I have not read everything yet)

In tr3580 it says:

"NFSv4 does not use UID/GID as the initial method of interaction between the client and the server by default. Instead there is string-based authentication between the client and the server."

And since the qtree is NTFS Style, it should not need any UID/GID from Unix, since they are not used anyway?

With the user name string from NFS the NetApp should be able to look up the user in AD directly?

Do you know why step a) is necessary and how step b) is done?

[aborzenkov]

UIDs/GIDs are still required at RPC level, which does not change with NFS v4. It could be that using NFS v4 with Kerberos bypasses this, but I do not have practical experience. IIRC your example explicitly used auth=sys which does need to know numerical IDs. Also NFS v4+ still allows pure numerical IDs as fallback, so storage still must be prepared to resolve them. Also for security style unix Data ONTAP stores numerical IDs internally and again must be able to resolve them. I doubt it has two different code paths.

User mapping rules are configured in /etc/usermap.cfg; you mentioned this file yourself.

It is possible to do without common backend; it is just that for any practical purposes it becomes unmanageable very fast unless you need to grant access to fixed number of users that change infrequently.

[USER_2000]

Most of my users are Windows users. That´s why I decided to use NTFS style on the qtrees. I have about 10 Unix hosts with less than 20 users. I have added my credentials to the passwd file on the NetApp and I can access the exported filesystem now. I think, for this small number of users it should be possible to use this approach. I don´t need a usermap.cfg file, since the NetApp automatically checks AD for my Unix user name, which is the same user name in AD. Thank you for pointing me to tr3490, which explains the mapping very detailed. Things are much clearer now.

It would be nice, if there would be an option to turn of usage of UID/GID, since its really not necessary in my environment and makes things just more complicated. May be one day it will be added?

Thank you for your help.

[VENKATA04]

I take it you are trying to map a UNIX user to Windows user but you get access denied message.

have you pasted full passd line in to \\filer\etc\passwd ?

I was once caughtup by passd line , I missed semi colon from passd line!

If you are still having issues please paste output of  wcc -u username

then try

options  cifs.trace_dc_connection   on

options  cifs.trace_login            on

After enabling above options, from the solaris client try accessing the nfs export in question as non-root user (su - user2000),  on the filer check for any authentication or mapping errors in /etc/messages.

or

you could also enable cifs auditing

cifs.audit.enable

cifs.audit.nfs.enable

cifs.audit.nfs.filter.filename

cifs.audit.saveas

Hope this helps.

[USER_2000]

I wasn't aware of the logging options. I will certainly have a look into that. Thank you.

Yes, as stated before I have added the users to /etc/passwd and access is fine now.

[aborzenkov]

Thank you for your help.

It would be prudent to mark question as answered then (or at least answers as helpful )

[parisi]

NFSv4 uses string based by default for security purposes, such as username@nfsv4.domain. This can be bypassed from the storage via the nfs.v4.id.allow_numerics option.

That said, aborzenkov is correct - you need to be able to map UNIX users to Windows users when using NTFS style volumes.

The reason is this - NTFS style volumes will use NTFS style ACLs. The storage must be able to discern the user identity to properly grant or deny access to the requesting user.

If you are trying to access using "root" then one of four things must happen:

1) A user mapping rule must map root to a valid Windows user (ie DOMAIN\user <= root)

2) A user named "root" must exist in the AD domain to allow implicit 1:1 mapping

3) The option wafl.nt_admin_priv_map_to_root must be set

4) The option wafl.default_nt_user must be set

The most secure of the above would be #1 or 2.

It looks like you worked around the issue by adding users to the passwd file, so that's good. But there is, and will not be, a way to bypass UID/GID. It's a security hole. You don't want to allow anyone access to your data without needing a valid user.

[aborzenkov]

But there is, and will not be, a way to bypass UID/GID. It's a security hole. You don't want to allow anyone access to your data without needing a valid user.

I think what confuses OP here is that we both speak about UIDs. OP is right in that strictly speaking UID are not needed in described scenario. What really happens here is user validation on server side. NetApp gets client user name in NFSv4 request and it must verify that user with this name actually exists from server point of view. So it must perform Unix user name lookup first. That this lookup returns UID as side effect is irrelevant in this context. This validation likely happens even before NetApp tries to access file (and knows its security style).

[parisi]

If we're talking NFSv4 and bypassing the user string, then the aforementioned nfs.v4.id.allow_numerics set to "on" would achieve more NFSv3-like behavior.

[aborzenkov]

If we're talking NFSv4 and bypassing the user string,

No, we are talking about using user string in NFSv4 but bypassing Unix user lookup on NetApp side.

[parisi]

User lookup will happen for all NFS versions, regardless of options if the volume is NTFS security style. There is not any way to get around that, as there needs to be a way to discern the NTFS ACL for the user requesting access.

If the volume is UNIX security style, then there would be no need to look up a user name for NFSv4 (or map it to a Windows user) as long as the nfs.v4.id.allow_numerics is enabled. Instead, the UID/GID would be passed.

Windows access will always map to a UNIX user, however, no matter what security style is being used.

[aborzenkov]

User lookup will happen for all NFS versions, regardless of options if the volume is NTFS security style. There is not any way to get around that, as there needs to be a way to discern the NTFS ACL for the user requesting access.

Now I became curious myself To discern NTFS ACL you need to know Windows user name (OK, you need Windows SID, but let's keep it simple); to get Windows user name you need to know Unix user name and with NFSv4 you get user Unix name from client already. So what is technical reason to perform user lookup at this point?

[USER_2000]

That's exactly what I mean. In my opinion, it is a security hole, no matter whether UIDs or names are used. It can be exploited easily, so why bother about UIDs? It does not add any extra security or am I missing something? Of course I will restrict access to the exported qtree to hosts I know. As long as users on these hosts have no root access to their host, its fairly safe. UIDs lookup would not make any difference, right?

[parisi]

USER_2000 wrote:
That's exactly what I mean. In my opinion, it is a security hole, no matter whether UIDs or names are used. It can be exploited easily, so why bother about UIDs? It does not add any extra security or am I missing something? Of course I will restrict access to the exported qtree to hosts I know. As long as users on these hosts have no root access to their host, its fairly safe. UIDs lookup would not make any difference, right? 

It cannot be exploited as easily in NFSv4 if the user string cannot resolve and gets squashed to nobody on the storage. If the mode bits or NFSv4 ACLs are set up properly, then access won't be allowed to users named "nobody."

If using NTFS security style, if the user cannot map to a valid Windows user, then access won't be allowed at all.

[aborzenkov]

In my opinion, it is a security hole, no matter whether UIDs or names are used.

Well ... traditional NFS authentication model is weak, there is nothing new. Use Kerberos if you need something more trustworthy.

It can be exploited easily, so why bother about UIDs?

Forget about UID. I apologize for causing this confusion. It is not about UID, it is about verifying that user name supplied by client actually exists.

It does not add any extra security or am I missing something?

In your specific case it prevents client from supplying user name Administrator (or any user name for that matter) and getting some more access than intended. By verifying user name NetApp can restrict access only to authorized users.

As long as users on these hosts have no root access to their host, its fairly safe.

Nothing precludes user space NFS client implementation ...

[USER_2000]

Agreed. I overlooked that. Good point.

[parisi]

The client may know the user name, but the storage does not. It needs  to look up the Windows user name based on the UNIX name/UID it receives  from the client when the volume is NTFS security style. This is true  for NFSv3 and NFSv4.

When a NFSv4 request comes in  to storage, the client knows the user as username@nfsv4id.domain. The  storage must also recognize that username@nfsv4id.domain, else the user  will get squashed to "nobody" (or the equivalent set in idmapd.conf).  Everything, including case, much match EXACTLY or the storage will not  consider the string valid. However, the client will not send the string;  it will send the numeric. Then the storage must figure the rest out.

The  v4id.domain is set via the storage option nfs.v4.id.domain in 7-mode  and -v4-id-domain in cDOT. On the client, the domain is set via the  idmapd.conf file.

When a NFSv3 ACCESS request  occurs, the client will send the following information to the storage:  UID, GID, client and auxiliary GIDs.

Example:

The  storage must then figure out who UID 10001 is in Windows to allow  access, due to NTFS permissions. To do that, it has to translate UID  10001 from a name service. In my case, I use LDAP. I'll use cDOT to  illustrate this, but the same logic applies to 7-mode.

parisi-cdot::*> diag secd authentication translate -node parisi-cdot-02 -vserver SVM -uid 10001

test

Once  the storage knows that UID 10001 is UNIX user "test," then the name  mapping occurs. Name mapping only occurs by name, not numeric.

parisi-cdot::*> diag secd name-mapping show -node parisi-cdot-02 -vserver SVM -direction unix-win -name test

test maps to DOMAIN\test

And creds are fetched (the above name mapping/translation are done all as a part of the credential fetching):

parisi-cdot::*>  diag secd authentication show-creds -node parisi-cdot-02 -vserver SVM  -uid 10001 -list-id true -list-name true

UNIX UID: 10001 (test) <> Windows User: S-1-5-21-3413584004-3312044262-250399859-1114 (DOMAIN\test (Domain User))

GID: 513 (Domain Users)

Supplementary GIDs:

  10011  (ldifde-group)

Windows Membership:

  S-1-5-21-3413584004-3312044262-250399859-1118     DOMAIN\testgroup (Domain group)

  S-1-5-21-3413584004-3312044262-250399859-513     DOMAIN\Domain Users (Domain group)

  S-1-5-32-545     BUILTIN\Users (Alias)

User is also a member of Everyone, Authenticated Users, and Network Users

Privileges (0x80):

In  the above, we see that the user "test" belongs to testgroup, Domain  Users and Users, as well as the normal Everyone, Authenticated Users,  and Network Users groups.

The volume is named "ntfs" and has the following ACLs:

parisi-cdot::*> vserver security file-directory show -vserver SVM -path /ntfs

                Vserver: SVM
              File Path: /ntfs
         Security Style: ntfs
        Effective Style: ntfs
         DOS Attributes: 10
DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
           Unix User Id: 0
          Unix Group Id: 0
         Unix Mode Bits: 777
Unix Mode Bits in Text: rwxrwxrwx
                   ACLs: NTFS Security Descriptor
                         Control:0x9504
                         Owner:BUILTIN\Administrators
                         Group:BUILTIN\Administrators
                         DACL - ACEs
                           ALLOW-DOMAIN\testgroup-0x1f01ff-OI|CI
                           ALLOW-DOMAIN\Administrator-0x1f01ff-OI|CI
                           ALLOW-Everyone-0x1200a9-OI|CI

So we know that user has access based on the ACLs.

When I mount the same volume via NFSv4, I see the same UID and GID information from the client - not the user name:

However, the storage doesn't use UID/GID for access; it uses it to discern what the user is from NTFS perspective. The difference in NFSv4 is in the ACCESS reply. The reply returns owner, group, etc as the string:

Everyone, Authenticated Users, and Network UsersEveryone, Authenticated Users, and Network UsersHowecver

If  I try to use a UNIX user that does not have a Windows user counterpart,  I won't even be able to cd to the mount via any version of NFS, as  initial authentication on the storage fails:

[root@centos64 /]# su nfs4
sh-4.1$ cd /unix
sh: cd: /unix: Permission denied

parisi-cdot::*> event log show
Time                Node             Severity      Event
------------------- ---------------- ------------- ---------------------------
7/22/2014  13:20:16  parisi-cdot-02   DEBUG         secd.nfsAuth.noUnixCreds:  vserver (SVM) Cannot determine UNIX identity. Error: Get user  credentials procedure failed
  [  5 ms] Using a cached connection to 10.228.225.120
  [    12] ID 9999 not found in UNIX authorization source LDAP
  [    12] ID 9999 not found in UNIX authorization source LOCAL
  [    12] Could not get credentials for ID 9999 using any NS-SWITCH authorization source
**[    12] FAILURE: Unable to retrieve credentials for UNIX user with UID 9999

If I use that same 9999 UID to access a UNIX style  volume, I will gain access based on the mode bits set on the volume(  i.e. 777):

[root@centos64 /]# mount sn1krb:/unix /unix
[root@centos64 /]# su nfs4
sh-4.1$ cd /unix
sh-4.1$ ls -la / | grep unix
drwxrwxrwx.  10 root root      4096 Jul 17 11:47 unix

If I write a file via NFSv4, the user will be "nobody" since the storage doesn't know who nfs4/UID 9999 is:

[root@centos64 /]# su nfs4
sh-4.1$ cd /unix
sh-4.1$ touch nfs4_newfile
sh-4.1$ ls -la | grep nfs4_newfile
-rw-r--r--.  1 nobody    root            0 Jul 22 13:29 nfs4_newfile

If I change the v4-numeric-ids option to "enabled" to allow for NFSv3-like functionality, the user shows up properly:

parisi-cdot::*> nfs server modify -vserver SVM -v4-numeric-ids enabled

[root@centos64 /]# su nfs4
sh-4.1$ cd /unix
sh-4.1$ touch nfs4_newfile_numerics
sh-4.1$ ls -la | grep numerics
-rw-r--r--.  1 nfs4      root            0 Jul 22 13:31 nfs4_newfile_numerics

In NFSv4, the user string matters on writes or when trying to translate the name/group on the file.

When I write as the 9999 user, the OPEN request comes from the client as UID 9999:

The reply from the storage is that the user is "nobody":

When I use a valid NFSv4 user, that string shows up properly:

Make sense?

[parisi]

Sigh. None of the attached traces made it to the post. Grr.

If needed, I can save them as images and upload.

[USER_2000]

Thanks for all the help. Things are quite clear for me now and I agree , it is necessary to verify the Unix user on the NetApp and also to get the UID. You guys saved me from reading 500 pages documentation.