[Samba] weekly samba kerberos failure

[Hong K Phooey]

----- Original Message -----
From: John H Terpstra <jht at samba.org>
Date: Monday, June 21, 2010 16:05
Subject: Re: [Samba] weekly samba kerberos failure
To: Hong K Phooey <hkp at insightbb.com>
Cc: Jeremy Allison <jra at samba.org>, samba at lists.samba.org

> On 06/21/2010 02:43 PM, Jeremy Allison wrote:
> > On Mon, Jun 21, 2010 at 12:39:09PM -0400, Hong K Phooey wrote:
> >> We have a service on our windows system that drops files onto 
> a samba share every 10 minutes.  This has worked fine, 
> except after one week, the system will fail.  We usually 
> restart samba and winbind on the linux side, and then restart 
> the service on the windows box to resolve the issue.
> >>
> >> This week we decieded to let it fail, and after an hour it 
> seemed to allow connections to the samba share.  Here is 
> the log file of the failures:
> >>
> >>   172.19.6.60 (172.19.6.60) closed connection to 
> service lorian
> >> [2010/06/21 09:40:03,  1] 
> smbd/sesssetup.c:342(reply_spnego_kerberos)>>   Failed 
> to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
> >>
> >> This repeats every minute until 10:33 am, when the service 
> was able to reconnect to the share.
> >>
> >> Is there a reason why this would fail every week at the same 
> time?  Do these settings have anything to do with the 
> issue?  
> >>
> >> Default: idmap cache time = 604800 (one week)
> >> Default: machine password timeout = 604800
> >>
> >> For the machine password timeout, is it necessary for it to 
> update this often.  Can it be set to only attempt once per 
> year, longer?
> > 
> > You can stop it updating the machine password by setting
> > "machine password timeout = 0".
> > 
> > This looks like an issue with the machine account
> > password being changed.
> > 
> > Jeremy
> 
> What version of samba are you using?  I believe that a 
> machine password
> renewal bug was fixed in 3.5.3.
> 
> - John T.

John,
We are using 3.4.7, so we are affected by the bug.

Jeremy,
Thanks very much for the update, after I sent the message this morning we dug into this a little further and did narrow it down to the "machine password timeout" setting.  Thanks for confirming we can disable that setting by setting it to 0.