Share still accessible after Kerberos ticket has been destroyed

[Lewis Rosenthal]

Kerberos-authenticated share is still browseable and read/write permissions remain in force even after successful kdestroy operation.

Log after ticket destruction:

2016/06/24 13:47:11.13: 4 2: lewis/******** login failed, Error NT_STATUS_INTERNAL_ERROR
2016/06/24 13:47:11.13: 4 2: Anonymous login failed
2016/06/24 13:47:11.13: 9 2: NdpCreateConnection failed rc=6
2016/06/24 13:47:11.13: 9 2: NdpRsrcQueryInfo in
2016/06/24 13:47:11.13: 9 2: NdpRsrcQueryInfo rc=111, s = SMBFS64 \\kerberos.samba.arcanoae\shared@lewis
2016/06/24 13:47:11.13: 9 2: NdpRsrcQueryInfo in
2016/06/24 13:47:11.13: 9 2: NdpRsrcQueryInfo rc=111, s = SMBFS64 \\kerberos.samba.arcanoae\shared@lewis
2016/06/24 13:47:11.13: 9 2: NdpRsrcQueryInfo in
2016/06/24 13:47:11.13: 9 2: NdpRsrcQueryInfo rc=111, s = SMBFS64 \\kerberos.samba.arcanoae\shared@lewis
2016/06/24 13:47:11.13: 9 2: NdpRsrcQueryInfo in
2016/06/24 13:47:11.13: 9 2: NdpRsrcQueryInfo rc=111, s = SMBFS64 \\kerberos.samba.arcanoae\shared@lewis
2016/06/24 13:47:11.13: 9 2: NdpQueryPathInfo in [0x671fe0] <timestamp.cmd>
2016/06/24 13:47:11.13: 9 2: dircache_find_path [timestamp.cmd]
2016/06/24 13:47:11.13: 9 2: dcFindPath: [][timestamp.cmd]
2016/06/24 13:47:11.14: 9 2: dircache: FindPath timestamp.cmd not found
2016/06/24 13:47:11.14: 9 2: NdpQueryPathInfo pathparser for <\timestamp.cmd> rc=0
2016/06/24 13:47:11.14: 9 2: NdpQueryPathInfo smbwrp_getattr for <\timestamp.cmd>
2016/06/24 13:47:11.14: 4 2:  smbwrp_echo
2016/06/24 13:47:11.14: 4 2:  smbwrp_getattr
2016/06/24 13:47:11.14: 4 2: getattr 0 16 <\timestamp.cmd>
2016/06/24 13:47:11.14: 9 2: fname \timestamp.cmd
2016/06/24 13:47:11.14: 9 2: size 794
2016/06/24 13:47:11.14: 9 2: mtime 1435641799 Tue Jun 30 01:23:19 2015
2016/06/24 13:47:11.14: 9 2: ftimeLastAccess 01:23:18
2016/06/24 13:47:11.14: 9 2: NdpQueryPathInfo <timestamp.cmd> (\timestamp.cmd) rc=0
2016/06/24 13:47:11.14: 9 2: NdpEASize in [0x671fe0] <\timestamp.cmd> 
2016/06/24 13:47:11.15: 4 2:  smbwrp_listea
2016/06/24 13:47:11.15: 4 2: EAList for <\timestamp.cmd>
2016/06/24 13:47:11.15: 4 2: num_eas = 4
2016/06/24 13:47:11.15: 4 2: 0 Got EA <REXX.METACONTROL> with namelen 16, size 68. Gross 4. Buf 65536
2016/06/24 13:47:11.15: 4 2: 1 Got EA <REXX.LITERALPOOL> with namelen 16, size 314. Gross 93. Buf 65536
2016/06/24 13:47:11.15: 4 2: 2 Got EA <REXX.VARIABLEBUF> with namelen 16, size 142. Gross 428. Buf 65536
2016/06/24 13:47:11.15: 4 2: 3 Got EA <REXX.TOKENSIMAGE> with namelen 16, size 840. Gross 591. Buf 65536
2016/06/24 13:47:11.15: 4 2: ret size = 1452
2016/06/24 13:47:11.15: 9 2: NdpEASize <timestamp.cmd> 1452 rc=0
2016/06/24 13:47:11.15: 9 2: NdpRsrcQueryInfo in
2016/06/24 13:47:11.15: 9 2: NdpRsrcQueryInfo rc=111, s = SMBFS64 \\kerberos.samba.arcanoae\shared@lewis
2016/06/24 13:47:11.15: 9 2: NdpQueryPathInfo in [0x671fe0] <timestamp.cmd>
2016/06/24 13:47:11.15: 9 2: dircache_find_path [timestamp.cmd]
2016/06/24 13:47:11.15: 9 2: dcFindPath: [][timestamp.cmd]
2016/06/24 13:47:11.15: 9 2: dircache: FindPath timestamp.cmd not found
2016/06/24 13:47:11.15: 9 2: NdpQueryPathInfo pathparser for <\timestamp.cmd> rc=0
2016/06/24 13:47:11.16: 9 2: NdpQueryPathInfo smbwrp_getattr for <\timestamp.cmd>
2016/06/24 13:47:11.16: 4 2:  smbwrp_echo
2016/06/24 13:47:11.16: 4 2:  smbwrp_getattr
2016/06/24 13:47:11.16: 4 2: getattr 0 16 <\timestamp.cmd>
2016/06/24 13:47:11.16: 9 2: fname \timestamp.cmd
2016/06/24 13:47:11.16: 9 2: size 794
2016/06/24 13:47:11.16: 9 2: mtime 1435641799 Tue Jun 30 01:23:19 2015
2016/06/24 13:47:11.16: 9 2: ftimeLastAccess 01:23:18
2016/06/24 13:47:11.16: 9 2: NdpQueryPathInfo <timestamp.cmd> (\timestamp.cmd) rc=0
2016/06/24 13:47:11.16: 9 2: NdpEASize in [0x671fe0] <\timestamp.cmd> 
2016/06/24 13:47:11.16: 4 2:  smbwrp_listea
2016/06/24 13:47:11.16: 4 2: EAList for <\timestamp.cmd>
2016/06/24 13:47:11.17: 4 2: num_eas = 4
2016/06/24 13:47:11.17: 4 2: 0 Got EA <REXX.METACONTROL> with namelen 16, size 68. Gross 4. Buf 65536
2016/06/24 13:47:11.17: 4 2: 1 Got EA <REXX.LITERALPOOL> with namelen 16, size 314. Gross 93. Buf 65536
2016/06/24 13:47:11.17: 4 2: 2 Got EA <REXX.VARIABLEBUF> with namelen 16, size 142. Gross 428. Buf 65536
2016/06/24 13:47:11.17: 4 2: 3 Got EA <REXX.TOKENSIMAGE> with namelen 16, size 840. Gross 591. Buf 65536
2016/06/24 13:47:11.17: 4 2: ret size = 1452
2016/06/24 13:47:11.17: 9 2: NdpEASize <timestamp.cmd> 1452 rc=0

[Paul Smedley]

No time for testing this morning, but a possible fix is in ​http://smedley.id.au/tmp/ndpsmb.zip

If we get a failed connection, we call NdpFreeResource() to clear the resource for security reasons. There may be a better way of doing this, but I couldn't think of it with only one coffee.

[Lewis Rosenthal]

Confirmed that this build does indeed stop the resource from being accessed. Now, we just get the hang condition as described in issue #269.

[Paul Smedley]

Reopening. Whilst the above fix works, creating a new kerberos ticket, then trying a dir results in a crash in ndctl.exe - presumably as it's not expecting the resource to have been destroyed... time to find something a little less brute force....

[Paul Smedley]

​http://smedley.id.au/tmp/ndpsmb.zip seems to fix the crash after re-running kinit

[Lewis Rosenthal]

Sorry for reopening once again, but the above build in comment:4 still crashes upon ticket reaquisition and attempt to get a directory listing.

I can get a log if you need one, Paul.

Steps to reproduce:

1. Acquire ticket.
2. Start NDCTL.EXE (in my case, it was stopped sometime after boot; perhaps because I had a drive mapped and no valid ticket at the time of booting, but I'll need to do some further testing and will open appropriate tickets, if so).
3. Run dir against Kerberos-authenticated share (this works).
4. kdestroy
5. Run dir against Kerberos-authenticated share. Quickly (now) returns SYS0002 (as expected, and a change from ticket #269).
6. Acquire new ticket.
7. Run dir against Kerberos-authenticated share.

NDCTL.EXE exits with:

06-22-2016  10:50:37  SYS3170  PID 0147  TID 0002  Slot 0054
C:\NDFS\NDCTL.EXE
c0010002
1fbb0027
P1=00000003  P2=XXXXXXXX  P3=XXXXXXXX  P4=XXXXXXXX
EAX=00000000  EBX=20034c40  ECX=0285d52c  EDX=028570b8
ESI=0285723c  EDI=0285b52c
DS=0053  DSACC=f0f3  DSLIM=ffffffff
ES=0053  ESACC=f0f3  ESLIM=ffffffff
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:00000000  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:02856f4c  SSACC=f0f3  SSLIM=ffffffff
EBP=028570d4  FLG=00012202

TCPIP32.DLL 0001:00000027

Commands and responses, from the time of ticket destruction:

[j:\download\os2\samba]kdestroy -A

[j:\download\os2\samba]klist list
klist.exe: No ticket file: /tmp/krb5cc_0

[j:\download\os2\samba]dir o:

 Volume in drive O is NETDRIVE
SYS0002: The system cannot find the file specified. "O:\*"
               0 bytes in 0 files and 0 dirs
   1,073,741,824 bytes (1,024MB) free

[j:\download\os2\samba]kinit lewis
lewis@SAMBA.ARCANOAE's Password:

[j:\download\os2\samba]dir o:

 Volume in drive O is NETDRIVE

(Nothing is displayed after that, and we return to a prompt.)

In case it's of any consequence:

8-16-11 6:01 87,504 0 tcpip32.dll

[Paul Smedley]

Same behaviour with smbclient btw - if kdestroy is run, share is still available

[Paul Smedley]

Per the samba guys: "--- Comment #1 from Jeremy Allison <jra@…> --- That's a server policy, not a client one. The 'periodic check' you're looking for is the ticket lifetime, which is a policy set on the kdc. I'll check in the code what happens server-side once the ticket has timed out, but this isn't a Samba code bug."

After 10 minutes or so after running kdestroy, the connection to the kerberos service is N/A.

[Lewis Rosenthal]

Hmmm...

I can confirm that from a Linux box, if I request a service ticket from one session, open an smbclient session in another terminal, destroy the ticket in the first while the smbclient session is still active, I can indeed continue to access it. Once I exit that smbclient session, I cannot start a new one to that share without a fresh ticket.

I can't seem to test with a cifs mount right now, because I keep getting "host is down" messages.

I guess what we're seeing in NetDrive is the same as keeping an smbclient connection running after ticket destruction.

[Paul Smedley]

Correct. I found here that after approx 10 minutes, smbclient and/or ndpsmb would stop working - presumably once the server realises the ticket has expired.

[Lewis Rosenthal]

Indeed, this is a server-side credential caching issue.