[Samba] Krb5 + Samba auth problem on subsequent volume mounts
Jake Carroll
jake.carroll at uq.edu.au
Sat Aug 9 00:40:13 GMT 2008
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 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 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
More information about the samba
mailing list