Thanks, Andrei! I validated that setting wafl.default_nt_user does in fact resolve my issue.
I think I'm missing a few foundtational concepts here that will connect the rest of the dots for me...
With NFSv3+NIS access to an NFS share built on an ntfs-style security export off NetApp, I'm used to dealing with the following for identity and access control:
- Client UID/GID is sent in NFSv3 packet to NetApp. - NetApp takes UID and looks it up via NIS and gets a username (in theory this could be looked up via LDAP and AD SFU extensions I suppose though I've never tried setting it up on a NetApp). - NetApp takes the username and looks it up in AD (if there's no corresponding username in NIS for the given UID, access is denied or some other default action is defined by us via configuration). - If the AD user exists, that user is evaluated against the NTFS style permissions and access is granted or not. If the AD user doesn't exist, some other behvaior is taken (which we can tune via the default_nt_user setting, etc.).
(I think we can also use usermap.cfg here)
With NFSv4 + Kerberos, how is the flow different? From looking at the NFSv4 ACCESS request in my packet capture, I see nothing resembling a UID. My hope was that the username was somehow encaspulated in the RPCSEC_GSS stuff and that the NetApp would actually have essentially a real AD username to work with which would completely eliminate the need for any mapping of a numeric Unix UID to an AD username.
Ray
On Fri, Jul 29, 2016 at 02:12:32PM +0000, andrei.borzenkov@ts.fujitsu.com wrote:
You need to have valid Unix to Windows user mapping, otherwise filer does not know how to verify your credentials. You can quickly verify it by setting wafl.default_nt_user to valid NT user that has permissions to access this volume (you may want to clear WCC by "wcc -x").
Note that Kerberos integration has two parts - authentication and identity management. The former is simple and well documented and does not require any additional changes usually; it is trivial to obtain ticket for a valid NT user.
The latter is more challenging. You need to modify AD to support Unix user enumeration (i.e. you need to add Unix attributes to users in AD).
See e.g. TR-4073; while it is for cDOT, it describes steps necessary on AD side which remain valid for 7-Mode. It does not describe how to enable LDAP for user name lookup on 7-Mode, but presumably it should be known already :)
I just verified that
- adding filer to AD (cifs setup)
- enabling Kerberos for NFS (nfs setup)
- configuring filer for LDAP lookup
enables access to both ntfs and unix qtrees.
Step 3 is *NOT* performed by enabling Kerberos for NFS! At the minimum you need to
a) options ldap.ADdomain your.windows.domain b) options ldap.enable on
and of course verify that ldap is listed in /etc/nsswtch.conf
I also had to add c) options ldap.nssmap.objectClass.posixAccount user
after enabling Unix attribute as per TR-4073 on Windows 2012 R2 server. Otherwise user lookup failed and all accesses were as nobody.
HTH
With best regards
Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters- bounces@teaparty.net] On Behalf Of Ray Van Dolson Sent: Friday, July 29, 2016 10:24 AM To: toasters@teaparty.net Subject: Kerberized NFSv4 in 7-Mode (AD)
Need some guidance in getting this working.
Have an 8.2.2P1 7-mode filer, joined to AD (working fine w/ CIFS) and have used 'nfs setup' to enable Kerberized NFS. However, I noticed that no nfs/* entries are present when I run setspn -L <FILER> from a Windows box. I was under the impression that nfs setup should create these? Or, since we're joined to AD already, perhaps the established machine account is sufficient to obtain one on the fly...
I have the following export on a volume with ntfs security style:
/vol/raytest -sec=krb5:krb5i:krb5p,rw,anon=0,nosuid
On my client (RHEL7+SSSD), I'm fairly confident my setup for Kerberos is good. I can SSH in with a Kerberos login, do kinit, etc and connect to other Kerberized services (like doing an ldapearch do AD without being prompted for a password using -Y GSSAPI as long as I have a valid tgt).
I've tried my krb5.conf with and without the following:
default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
I also ran 'net ads keytab add nfs' on my client and see that I have a valid nfs/ entry in my machine's keytab file.
If I run the following (either as root or as a user -- below is as a user with a valid TGT):
$ sudo mount.nfs4 -o vers=4,sec=krb5 red-str-napc2- p12.esri.com:/vol/raytest /mnt/nfs
I get a successful mount and also see a valid nfs ticket in klist. However, when I try to cd to /mnt/nfs, I get a "Permission Denied" error.
I have rpc.gssd running in the foreground in verbose mode but don't really see anything odd.
Wireshark tells me I've asked for read, lookup, modify, extend and delete permissions but that access was denied and only delete was allowed. I can see that the RPC portion of the packets are speaking Kerberos, but I can't tell much more than that.
DNS, NTP, etc. is all set up and working on both sides. I've used sectrace on the /vol/raytest path above to try and catch issues, but get no hits making me think it's NFS on the NetApp rejecting things, not the file system layer... fsecurity shows that everything is wide open and from a CIFS client using the same user as on the Linux box, I can create files on the same path with no issues.
Kinda stumped at this point. Any suggestions?
Ray