More details:

Mounting works fine (using the fsid=0 export /):

# mount -t nfs4 -o minorversion=1,sec=krb5  win12:/ /tmp/m

# ls /tmp/m
test1  test2

First "ls -l" also works and displays correct owner/group:

# ls /tmp/m -l
total 0
d--------- 2 nobody    domain users 64 Aug 29 17:47 test1
d--------- 2 user00001 domain users 64 Sep  2 14:23 test2

However, just one second later doing the very same thing,
I get this:

# ls /tmp/m -l
ls: cannot access /tmp/m/test1: Permission denied
ls: cannot access /tmp/m/test2: Permission denied
total 0
d????????? ? ? ? ?            ? test1
d????????? ? ? ? ?            ? test2

Windows Event Viewer:

One log entry looks nice (maybe the one leading to the first (successful) directory listing?):

-> Windows Logs
-> Security

----

An account was successfully logged on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Logon Type:			3

Impersonation Level:		Impersonation

New Logon:
	Security ID:		ANONYMOUS LOGON
	Account Name:		nfs/u1git.s5dom.test
	Account Domain:		S5DOM.TEST
	Logon ID:		0x5171EA
	Logon GUID:		{31b07c5b-966c-3ba2-1a6c-792412eab70d}

Process Information:
	Process ID:		0x0
	Process Name:		-

Network Information:
	Workstation Name:	
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		Kerberos
	Authentication Package:	Kerberos
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
	- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

----

However some seconds later those log entries appear (maybe the ones causing the "permission denied" / "??????"):


-> Application and Service Logs
-> Microsoft
-> Windows
-> ServiceForNFS-Server
-> IdentityMapping:

----
Server for NFS was unable to obtain security information for the GSS user account S5DOM.TEST\nfs/u1git.s5dom.test.

Check that the user account S5DOM.TEST\nfs/u1git.s5dom.test is valid and meets all configured security policies. There may be additional information in the Windows Security event log.

MSV Status: 0xC000009A, SubStatus: 0x0
S4U Status: 0xC000006D, SubStatus: 0x0
----

And two other failure reports in a different location:

-> Windows Logs
-> Security

----
An account failed to log on.

Subject:
	Security ID:		SYSTEM
	Account Name:		WIN12$
	Account Domain:		S5DOM
	Logon ID:		0x3E7

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		
	Account Domain:		

Failure Information:
	Failure Reason:		An Error occured during Logon.
	Status:			0xC000009A
	Sub Status:		0x0

Process Information:
	Caller Process ID:	0x4
	Caller Process Name:	

Network Information:
	Workstation Name:	WIN12
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		NfsSvr
	Authentication Package:	Kerberos
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
----

An account failed to log on.

Subject:
	Security ID:		SYSTEM
	Account Name:		WIN12$
	Account Domain:		S5DOM
	Logon ID:		0x3E7

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		nfs/u1git.s5dom.test
	Account Domain:		S5DOM.TEST

Failure Information:
	Failure Reason:		Unknown user name or bad password.
	Status:			0xC000006D
	Sub Status:		0xC0000064

Process Information:
	Caller Process ID:	0x4
	Caller Process Name:	

Network Information:
	Workstation Name:	
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		NfsSvr
	Authentication Package:	MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
----

General setup description:

Domain Controller:
   dcgit.s5dom.test
   IP: 192.168.122.70
   System: Ubuntu 14.04.3
   Samba: git-latest
     Domain s5dom.test
     Realm: S5DOM.TEST

Windows NFS Server (joined to domain):
   win12.s5dom.test
   IP: 192.168.122.33
   System: Windows 2012R2

Linux NFS client:
   u1git.s5dom.test
   IP: 192.168.122.71
   System: Ubuntu 14.04.3

Linux NFS server (only to make sure NFS+krb5 client setup is ok):
   nfsgit.s5dom.test
   IP: 192.168.122.72
   System: Ubuntu 14.04.3

Created attachment 11398 [details]
samba log file (debug level = 10)

Created attachment 11399 [details]
samba dc keytab

Created attachment 11400 [details]
samba dc network dump

Created attachment 11401 [details]
nfs client network dump

Created attachment 11402 [details]
nfs client keytab 1 (/etc/krb5.keytab for winbind / nss)

Created attachment 11403 [details]
nfs client keytab 2 (/etc/nfs.keytab for nfs)

Hope I got everything you need ... 


On Wed, Sep 02, 2015 at 12:52:39PM +0000, Ritter, Marcel (RRZE) wrote:
> Hi Jeremy,
> 
> I've opened bug 11485 on this topic.
> 
> What wireshark traces do you need?
> 
> I guess one from the dc and one from the nfs client, right?
> 
> And as some of this stuff is encrypted:
> What else do you need to decrypt it?
> (As I'm running an isolated testbed, I can provide the keytabs and or 
> SSL keys if required.)

dc <-> server, nfs <-> server + keytabs should help, thanks !

Hmm ... did something in the handling of krb5 PAC change between samba 4.1.6 and current git?

I'm seeing PAC verification errors on the DC when trying to access NFS krb5 mounted directories (Linux client and server).

Not sure if they are really related to this bug but at least they look suspicious to me:

Kerberos: Verify PAC failed for nfs/nfsgit.s5dom.test@S5DOM.TEST (user00001@S5DOM.TEST) from ipv4:192.168.122.71:46262 with <unknown error: 22>

(In reply to Marcel Ritter from comment #0)

Update:
My initial statement that Linux NFS clients + servers work fine is incorrect: (This was only true with my Ubuntu Samba 4.1.6 setup).
With samba (latest git) I can mount NFSv4, but when trying to access user owned directories all I get is "permission denied" (even if permissions are 777).
(at the same time I get the "Verify PAC failed" messages mentioned in comment #11).

Just an update on the PAC issue:

After applying my trivial patch from 2011 (!) access from Linux NFS clients to Linux NFS servers works again:

http://permalink.gmane.org/gmane.network.samba.internals/55484

Next step: Tests with Windows NFS server ...

Update:

After adding the trivial patch, behaviour of the Windows NFS server is still broken (as described).

(In reply to Marcel Ritter from comment #13)

Link to whole thread about the PAC issue:

http://thread.gmane.org/gmane.network.samba.internals/55484/focus=55486

Unfortunately there's no trace in the mailing list archive about further discussion/work on this topic.