Otdfbt

I've run into an odd problem with Samba 3.6.23. Right now I have a Windows 2008 R2 machine that has trouble accessing shares on a domained Samba box.

• 
  \example_servmy_share : Fails with LOGIN FAILURE


• 
  \172.16.102.19my_share : Works just fine.

When I set smbd to debug logging, I get this:

[2015/03/23 17:33:03.306499, 3] smbd/sesssetup.c:662(reply_spnego_negotiate)
 reply_spnego_negotiate: Got secblob of size 1840
[2015/03/23 17:33:03.306939, 10] libads/kerberos_verify.c:386(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:386: found previous password
[2015/03/23 17:33:03.315587, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [18] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.319930, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [17] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.320027, 3] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [23] failed to decrypt with error Decrypt integrity check failed
[2015/03/23 17:33:03.320101, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [1] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.320162, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [3] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.328693, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [18] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.332985, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [17] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.333065, 3] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [23] failed to decrypt with error Decrypt integrity check failed
[2015/03/23 17:33:03.333128, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [1] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.333192, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
 libads/kerberos_verify.c:435: enc type [3] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.333234, 3] libads/kerberos_verify.c:638(ads_verify_ticket)
 libads/kerberos_verify.c:638: krb5_rd_req with auth failed (Bad encryption type)
[2015/03/23 17:33:03.333264, 10] libads/kerberos_verify.c:648(ads_verify_ticket)
 libads/kerberos_verify.c:648: returning error NT_STATUS_LOGON_FAILURE

Which was enough to point me at something kerberos-y. So I did a bit of tcpdumping, and learned that different login methods are negotiated for machine-name and ip-only styles. When accessing via machine-name, it attempts a kerberos login and fails. When accessing via IP-address, it attempts NTLMv2, which works just fine.

Of interest, the Win 2008 R2 machine is in a child-domain of the one the Samba server is in. However, I have lots of examples of machines in the child domain correctly accessing the Samba machine.

Confoundingly, I have an identically configured samba system (testparm shows identical [global] settings) in another AD Site that is working just fine for this machine.

I'm at a loss over where to poke next.

• Something weird on the AD DC's in those two sites?


• Obscure Samba settings I'm not seeing?

I'm not sure where to go from here.

I witnessed same behavior which was caused by un-synchronized AD's (Active Directory) after the server running samba was re-joined to domain.

After reading https://en.wikipedia.org/wiki/Kerberos_(protocol) I concluded the error means that samba (the service) cannot decrypt the "client-to-service" Kerberos ticket received from client, because in my case it was encoded by service's old secret key. According to wikipedia, the service secret key is a hash of service password stored in AD. The re-joining to domain generated new password. Until this change was propagated to other AD's, clients were receiving from their TGS (running on unsynchronized ADs) tickets encoded with old service secret.