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.c1033)
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.c1230)
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.c506)
Client requested device type [A:] for share [GROUP_IT]
[2008/08/09 09:53:16, 5, pid=3953] smbd/service.c1205)
making a connection to 'normal' service group_it
[2008/08/09 09:53:16, 2, pid=3953] smbd/service.c605)
*guest user (from session setup) not permitted to access this share
(group_IT)*
*[2008/08/09 09:53:16, 3, pid=3953] smbd/error.c106)*
*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.c484)
[2008/08/09 09:53:16, 5, pid=3953] lib/util.c494)
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.c1068)
Transaction 9 of length 43
[2008/08/09 09:53:20, 5, pid=3953] lib/util.c484)
[2008/08/09 09:53:20, 5, pid=3953] lib/util.c494)
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@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@someho st.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