A Windows Server 2003 R2 IIS server that is accessing Samba CTDB is generating the following error. It happens at the same time every week (approx 11:08-11:15am every Thursday) it only happens within this specific time window.
Here is a loglevel 4 snippet.
[2010/02/04 11:13:55, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(1175)
Doing spnego session setup
[2010/02/04 11:13:55, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(1210)
NativeOS=[Windows Server 2003 R2 3790 Service Pack 2] NativeLanMan=
PrimaryDomain=[Windows Server 2003 R2 5.2]
[2010/02/04 11:13:55, 3] smbd/sesssetup.c:reply_spnego_negotiate(802)
reply_spnego_negotiate: Got secblob of size 1204
[2010/02/04 11:13:55, 3] libads/kerberos_verify.c:ads_secrets_verify_ticket(296)
ads_secrets_verify_ticket: enc type  failed to decrypt with error
Decrypt integrity check failed
[2010/02/04 11:13:55, 3] libads/kerberos_verify.c:ads_verify_ticket(471)
ads_verify_ticket: krb5_rd_req with auth failed (Bad encryption type)
[2010/02/04 11:13:55, 1] smbd/sesssetup.c:reply_spnego_kerberos(350)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2010/02/04 11:13:55, 3] smbd/error.c:error_packet_set(61)
error packet at smbd/sesssetup.c(352) cmd=115 (SMBsesssetupX)
[2010/02/04 11:13:55, 3] smbd/process.c:smbd_process(1930)
receive_message_or_smb failed: NT_STATUS_END_OF_FILE, exiting
[2010/02/04 11:13:55, 3] smbd/sec_ctx.c:set_sec_ctx(324)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2010/02/04 11:13:55, 3] smbd/connection.c:yield_connection(31)
Yielding connection to
[2010/02/04 11:13:55, 3] smbd/server.c:exit_server_common(971)
Server exit (normal exit)
The suspect is that the ADS Domain Member trust accounts for the Samba pCIFS cluster is leading to breakage. Is this trust password change cluster-aware?
Windows clients are reporting errors attached in separate files.
Created attachment 5273 [details]
Windows Server 2003 R2 IIS Eventviewer error log
Machine password changes have been disabled. The symptom has resurfaced for 2 months. This is a bug, but we have a work-around.
The work-around is to disable machine password changes. Not ideal, but it solves the immediate problem.
*** Bug 7178 has been marked as a duplicate of this bug. ***
This is not cluster-related.
Happened in standalone samba too (bug #7178 - metze said it's a duplicate).
Created attachment 5728 [details]
Patch for fixing this bug
Created attachment 5735 [details]
Second fix version
This patch has been tested against windows XP. The previous one was failing in case of mutual authentication.
In order to solve this issue, we need to keep around the old trust password for as long as tickets are valid in the domain.
We also need to make sure we have both old and new password used to accept kerberos credentials from clients.
If we used a keytab all we need to do would be to keep old and new keys in the keytab.
(In reply to comment #7)
> Created an attachment (id=5735) [details]
> Second fix version
> This patch has been tested against windows XP. The previous one was failing in
> case of mutual authentication.
Patch looks good to me.
Created attachment 5752 [details]
Patch for fixing the bug
Fix typos in previous patch
Created attachment 5758 [details]
v3-5-test patch (port from master)
Karolin, please pick for 3.5
Pushed to v3-5-test.
Closing out bug report.
*** Bug 7524 has been marked as a duplicate of this bug. ***