2014-07-22 03:47 AM
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:
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?
Solved! SEE THE SOLUTION
2014-07-22 03:57 AM
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.
2014-07-22 05:02 AM
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?
2014-07-22 05:31 AM
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.
2014-07-22 05:47 AM
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.
2014-07-22 06:50 AM
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
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.
you could also enable cifs auditing
Hope this helps.
2014-07-22 07:11 AM
NFSv4 uses string based by default for security purposes, such as firstname.lastname@example.org. 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.
2014-07-22 07:59 AM
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).