User authenticates as "nobody" on subsequent mounts despite havingkrb ticket

[Vladimir Terziev]

This is a samba issue/behavior with certainty 100%. Check samba docs for
clues.

Regards,

   Vladimir


On Sun, 2008-08-10 at 20:28 +0930, Jake Carroll wrote:
> 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
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman-mit-edu.ezproxyberklee.flo.org/mailman/listinfo/kerberos