When using samba 3.5.3 ( 3.5.2 has this problem too ) joined with our domain, everyhting works, but during a few hours a number of servers trying to open a SMB connection to the server get an NT_STATUS_LOGON_FAILURE due to a ticket decryption failure ( ads_secrets_verify_ticket: enc type [23] failed to decrypt with error Decrypt integrity check failed ). This situation resolves itself after a few hours, without reloads or restarts of the server and client. The problem repeats itself almost every day ( i am trying to analyse the exact repeat period ). The problem does not affect all clients at once. The problem does not impact hosts the use NTLM as auth mechanism. Clients are Windows 2003 servers. Samba 3.5.3 is running on RHEL5 ( using the SerNet RPM's ). Samba 3.0.x does not have this issue. Further details in the log (log is slightly sanitized).
Created attachment 5800 [details] Samba log
This is the critical part of the log: ads_verify_ticket: krb5_rd_req with auth failed (Bad encryption type) What does your krb.conf look like ? Jeremy.
The krb.conf is autogenerated by samba ( create krb5 conf=Yes ) /var/lib/samba/smb_krb5/krb5.conf.DOM [libdefaults] default_realm = DOM default_tgs_enctypes = RC4-HMAC DES-CBC-CRC DES-CBC-MD5 default_tkt_enctypes = RC4-HMAC DES-CBC-CRC DES-CBC-MD5 preferred_enctypes = RC4-HMAC DES-CBC-CRC DES-CBC-MD5 [realms] DOM = { kdc = 1.2.3.4 kdc = 1.2.3.5 kdc = 1.2.3.6 kdc = 1.2.3.7 kdc = 1.2.3.8 } The systemwide krb5.conf ( /etc/krb5.conf ) [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = DOM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [realms] EXAMPLE.COM = { kdc = kerberos.example.com:88 admin_server = kerberos.example.com:749 default_domain = example.com } DOM = { } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
Additional analysis of the failure shows that it actually happens once a week for the test client ( predictably at the same moment each week, exactly 7 days appart). The systems try to connect every 15 minutes, and failures are noted between 10h00 and 12h30 ( 2h30 +- ). Could this be a key lifetime issue or similar ?
Ok, this is a bug (# 7099) we resolved for 3.5.4. Can you please verify ?
I can confirm 3.5.4 solves the issue. Thanks a lot ! *** This bug has been marked as a duplicate of bug 7099 ***
(In reply to comment #6) > I can confirm 3.5.4 solves the issue. Thanks a lot ! > > *** This bug has been marked as a duplicate of bug 7099 *** Thanks for verifying!