1

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_serv\my_share : Fails with LOGIN FAILURE
  • \\172.16.102.19\my_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.

chicks
  • 3,639
  • 10
  • 26
  • 36
Blue Warrior NFB
  • 611
  • 6
  • 17
  • 1.) Kerberos is DNS dependent. Are all servers in this scenario using same DNS, and are DNS entries there 100% accurate? 2.) How are you specifying login credentials? Sometimes SMB shares require full domain to be specified, i.e. "mydomain.local\myuser" – jlehtinen Mar 23 '15 at 18:57
  • @jlehtinen FQDN does work, though a bit less reliably than IP does. That's new data. – Blue Warrior NFB Mar 23 '15 at 19:16
  • Have you compared the encryptions (search for `enctypes` in `krb5.conf` and `kdc..conf`) being used in a working and a non-working samba environment? (`klist -k -e -K -F FILE`), also [this link](https://technet.microsoft.com/en-gb/library/dd560670(v=ws.10).aspx) might be of interest. – dawud Mar 23 '15 at 23:36
  • It took lots of time to understand the issue. AS you mentioned, it could be netbios issue. Please check you have correct host name in /etc/hosts on samba server. The FQDN of the samba should match with windows AD domain i.e domain part of hostname should be AD domain name. As windows admin to set correct hostname for your samba or correct your hostname(samba) –  Jan 05 '16 at 18:14

1 Answers1

0

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.

Petr Gajdůšek
  • 1
  • 1