samba - Aug 2008 - Krb5 + Samba auth problem on subsequent volume mounts

Hi all,

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

I have an OpenLDAP KDC or Directory Master. 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-fact  
(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:

MacbookPro:~ zebra$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: zebra@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@somehost.somewhere.nowhere.interesting.here
	renew until 08/16/08 09:42:32

Frustratingly, if I to a kdestroy on my ticket on the client desktop,  
then remount the share, everything is perfect - I am the correct user,  
and all goes according to plan again.

Has anyone ever come up against such issues? I am not sure if this is  
*too* Kerberos oriented for the samba list, or it is something you see  
all the time. Hopefully it is simply rectified.

Thanks for your time.

JC