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.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
>
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos