3

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?

Bart De Vos
  • 17,761
  • 6
  • 62
  • 81
Hassle2
  • 31
  • 1
  • 3

1 Answers1

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.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • Thanks for the response! After converting the pwdLastSet into a readable form, it matches the computer object's modified timestamp. – Hassle2 Nov 08 '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 08 '11 at 19:19
  • It isn't defined, so I'm going with the default 30 days. 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 08 '11 at 19:31
  • By machine password length, I meant machine password timeout. – Hassle2 Nov 08 '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 08 '11 at 21:34