User authenticates as "nobody" on subsequent mounts despite having krb ticket

[Jake Carroll]

Hi all,

I have, what I think is a relatively simple kerberos problem that I am  
not seeing the obvious side to. I'll explain the scenario.

I have an OpenLDAP KDC. For the purposes of this conversation, it is  
the authentication server, and the bit that grants/hands out all the  
ticket information. I have a Solaris 10 system running the default Sun  
shipped Samba 3.0.28 (/usr/sfw/sbin/smbd).

This Solaris fileserver is connected via LDAP to the OpenLDAP master  
and has an appropriate /etc/krb5/krb5.conf and /etc/krb5/krb5.keytab  
installed.

In my /etc/sfw/smb.conf, I have the simple "magic lines" to connect my  
samba service to Kerberos as follows in the [global] section:

password server = somehost.somewhere.nowhere.interesting.here
workgroup = STAFF
realm = somehost.somewhere.nowhere.interesting.here
netbios name = somehost.somewhere.nowhere.interesting.here
netbios aliases = SUN SAM-FS HSM
security = SERVER
use kerberos keytab = yes
encrypt passwords = yes

So, once I have created some shares, all seems to go swimmingly. Users  
connect using their SSO credentials, they are passed a ticket through  
the TGT process and they are then allowed to write to the share/ 
directory/wherever I have specified.

The problem is, when my user decideds he/she/it has had enough of that  
network mounted volume, they eject it. No big deal there - however,  
when they REMOUNT the volume with their Kerberos ticket in-tact  
(default ticket time out is 10 hours in my policy), they for SOME  
reason authenticate as the "nobody" user - and as a result, get denied  
access:

Some logs. A "healthy" connection to the service:

[2008/08/09 09:43:18, 1, pid=3893] smbd/service.c:(1033)
   aaa.bb.ccc.ddd (aaa.bb.ccc.ddd) connect to service group_IT  
initially as user zebra (uid=1027, gid=1028) (pid 3893)

Now, lets disconnect the share on the desktop:

[2008/08/09 09:46:50, 1, pid=3893] smbd/service.c:(1230)
   aaa.bb.ccc.ddd (aaa.bb.ccc.ddd) closed connection to service group_IT

Now, lets try reconnecting with our kerberos ticket in-tact and see  
what happens:

[2008/08/09 09:53:16, 4, pid=3953] smbd/reply.c:(506)
   Client requested device type [A:] for share [GROUP_IT]
[2008/08/09 09:53:16, 5, pid=3953] smbd/service.c:(1205)
   making a connection to 'normal' service group_it
[2008/08/09 09:53:16, 2, pid=3953] smbd/service.c:(605)
   *guest user (from session setup) not permitted to access this share  
(group_IT)*
*[2008/08/09 09:53:16, 3, pid=3953] smbd/error.c:(106)*
   *error packet at smbd/reply.c(514) cmd=117 (SMBtconX)  
NT_STATUS_ACCESS_DENIED*
[2008/08/09 09:53:16, 5, pid=3953] lib/util.c:(484)
[2008/08/09 09:53:16, 5, pid=3953] lib/util.c:(494)
   size=35
   smb_com=0x75
   smb_rcls=34
   smb_reh=0
   smb_err=49152
   smb_flg=136
   smb_flg2=49153
   smb_tid=65535
   smb_pid=1
   smb_uid=100
   smb_mid=8
   smt_wct=0
   smb_bcc=0
[2008/08/09 09:53:20, 3, pid=3953] smbd/process.c:(1068)
   Transaction 9 of length 43
[2008/08/09 09:53:20, 5, pid=3953] lib/util.c:(484)
[2008/08/09 09:53:20, 5, pid=3953] lib/util.c:(494)
   size=39
   smb_com=0x74
   smb_rcls=0
   smb_reh=0
   smb_err=0
   smb_flg=8
   smb_flg2=49153
   smb_tid=65535
   smb_pid=1
   smb_uid=100
   smb_mid=9
   smt_wct=2
   smb_vwv[ 0]=  255 (0xFF)
   smb_vwv[ 1]=    0 (0x0)
   smb_bcc=0

What the? I've got a legit ticket:

zebra:~ zebra$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: zebra at somehost.somewhere.nowhere.interesting.here

Valid Starting     Expires            Service Principal
08/09/08 09:42:32  08/09/08 19:42:32  krbtgt/somehost.somewhere.nowhere.interesting.here at somehost.somewhere.nowhere.interesting.here
	renew until 08/16/08 09:42:32

Frustratingly, if I to a kdestroy on my ticket, then remount the share  
(and in the process, have to provide my SSO credentials again),  
everything is perfect - I am the correct user, and all goes according  
to plan again.

What on earth could be going wrong? Has anyone ever come up against  
such issues? Could it be specific to the client type, or is this a  
server side issue?

Thanks for your time.

JC