Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The problem:

Every 7 days, 2 Windows Servers are unable to access a SMB/CIFS share. It will start working after a handful of hours.

The environment:

OpenFiler Linux box joined to 2003 AD Domain

Foreground app on Win2003 server access the SMB/CIFS share with windows credentials

Another process on Win2008 access the share via SQL Server with windows credentials

The Samba version on the Linux box is 3.4.5.

Security is set to ADS

wbinfo and getent return back expected users and groups

Does not look to be a double hop issue as it's always the 2 accounts, regardless of the calling user.

There is a DNS entry in both forward and reverse lookup zone for the linux box

The linux box's computer object in active directory shows that it was modified around/at the same time that the two clients started failing to access the share

Trying to access the share via IP works when by name does not

Rebooting the Windows server takes care of it (it's production and only restarted it once)

Restarting smbd, winbind, nmbd had no effect

Error in samba log for the client in question: smbd/sesssetup.c:342(reply_spnego_kerberos) Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!

The Question:

Does this look like the machine account password is changing (hence the AD object showing the updated modified date) or are the two windows clients unable to request a new ticket that works against this linux box?

share|improve this question
add comment

1 Answer 1

Check the pwdLastSet attribute on the computer object to check whether the machine account password has changed; I would guess that it's simply an update to some other attribute (say, lastLogonTimestamp) that changed.

I bet that it's an issue with the Kerberos ticketing on the OpenFiler device; 7 days is the default maximum lifetime in Active Directory, and the OpenFiler seems to be be failing at successfully obtaining a new ticket in that error message.

Try changing the setting for the ticket lifetime, and see if that makes a difference. In your default domain policy, Computer > Windows Settings > Security > Account > Kerberos, the "Maximum lifetime for user ticket renewal" setting. Not sure off the top of my head, but I suspect that a restart of the KDC service is needed after the change.

share|improve this answer
    
Thanks for the response! After converting the pwdLastSet into a readable form, it matches the computer object's modified timestamp. –  Hassle2 Nov 8 '11 at 19:13
    
Strange - what's the Domain member: Maximum machine account password age set to? (Computer > Policies > Windows Settings > Security > Local > Security Options) –  Shane Madden Nov 8 '11 at 19:19
    
It isn't defined, so I'm going with the default 30 days.</p> I had hit enter on accident for my first response. I looked over the smb.conf and am not specifying the machine password length. The 7 day window does line up exactly with the kerberos and failure at requesting a new ticket. –  Hassle2 Nov 8 '11 at 19:31
    
By machine password length, I meant machine password timeout. –  Hassle2 Nov 8 '11 at 19:42
    
If it is of any consequence, the secrets.tdb has the same timestamp as the AD computer object as well as when things went south. –  Hassle2 Nov 8 '11 at 21:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.