So, "access denied" doesn't mean you have a Kerberos issue necessarily. If it were Kerberos, I'd expect an error in the trace on the ticket exchange.
Does klist -e show you got a ticket from the storage?
What does the export look like for that volume? What about "fsecurity show /vol/volname"?
-----Original Message----- From: Ray Van Dolson [mailto:rvandolson@esri.com] Sent: Friday, July 29, 2016 10:10 AM To: Parisi, Justin Cc: toasters@teaparty.net Subject: Re: Kerberized NFSv4 in 7-Mode (AD)
Here you go (setspn for the filer):
C:\windows\system32>setspn -L REDSTRNAPC2P12 Registered ServicePrincipalNames for CN=REDSTRNAPC2P12,OU=XXX,DC=esri,DC=com: nfs/red-str-napc2-p12.esri.com host/red-str-napc2-p12.esri.com host/red-str-napc2-p12 HOST/redstrnapc2p12.esri.com HOST/redstrnapc2p12
Note, I ended up manually adding the nfs entry as I was seeing errors in rpc.gssd which disappeared once I did so.
The exact error from the Wireshark capture (client perspective) is:
V4 Reply (Call in 1) ACCESS, [Access Denied: RD LU MD XT], [Allowed: DL]
Details:
Network File System, Ops(3): PUTFH ACCESS GETATTR [Program Version: 4] [V4 Procedure: COMPOUND (1)] Status: NFS4_OK (0) Tag: <EMPTY> length: 0 contents: <EMPTY> Operations (count: 3) Opcode: PUTFH (22) Status: NFS4_OK (0) Opcode: ACCESS (3), [Access Denied: RD LU MD XT], [Allowed: DL] Status: NFS4_OK (0) Supported types (of requested): 0x1f .... ...1 = 0x01 READ: supported .... ..1. = 0x02 LOOKUP: supported .... .1.. = 0x04 MODIFY: supported .... 1... = 0x08 EXTEND: supported ...1 .... = 0x10 DELETE: supported Access rights (of requested): 0x10 .... ...0 = 0x01 READ: *Access Denied* .... ..0. = 0x02 LOOKUP: *Access Denied* .... .0.. = 0x04 MODIFY: *Access Denied* .... 0... = 0x08 EXTEND: *Access Denied* ...1 .... = 0x10 DELETE: allowed Opcode: GETATTR (9) Status: NFS4_OK (0) Attr mask[0]: 0x00000018 (CHANGE, SIZE) reqd_attr: CHANGE (3) changeid: 1578161353901524080 reqd_attr: SIZE (4) size: 4096 Attr mask[1]: 0x00300000 (TIME_METADATA, TIME_MODIFY) reco_attr: TIME_METADATA (52) seconds: 1469777295 nseconds: 294438000 reco_attr: TIME_MODIFY (53) seconds: 1469777295 nseconds: 294438000 [Main Opcode: ACCESS (3)]
Ray
On Fri, Jul 29, 2016 at 01:39:44PM +0000, Parisi, Justin wrote:
Can you show me the setspn -L output for that account?
Generally, yes, the filer adds those nfs/ entries and it doesn't matter if the account exists or not.
I'd also recommend getting a packet trace during the failure to see what the exact error is.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Ray Van Dolson Sent: Friday, July 29, 2016 3: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