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: [EMAIL PROTECTED] > > Valid Starting Expires Service Principal > 08/09/08 09:42:32 08/09/08 19:42:32 krbtgt/[EMAIL PROTECTED] > 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 [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
