Reoccurring failure in accessing AD member samba shares

Issues related to applications and software problems
Post Reply
charlweed
Posts: 7
Joined: 2016/01/22 16:54:25

Reoccurring failure in accessing AD member samba shares

Post by charlweed » 2018/05/09 22:06:57

I have a Samba 4.6.2 samba ActiveDirectory member server. Every month or so, all clients lose the ability to connect to all the shares. I can work around the issue by leaving the domain, deleting the machine account, and re-joining the domain, but it is obviously wrong that I have to do this every few weeks.
I thought that it was a machine account password expiration issue, but running
adcli update does not help. I tried changing the Group Policy for machine password expiration, but that did not help either.

Centos 7.4.1708
Samba 4.6.2
sssd-krb5-1.15.2
SSSD 1.15.2-50
realmd-0.16.1-9

The error message on the client side is

Code: Select all

"\\cheetoes is not accessible. You might not have permissions to use this network resource. Contact the administrator of this server to find out if you have access permissions.
Login Failure: The target account name is incorrect"
On the server side, at startup, log.smbd contains:

Code: Select all

[2018/05/09 12:03:41.622878,  0] ../source3/libads/kerberos_util.c:74(ads_kinit_password)
  kerberos_kinit_password CHEETOES$@HYMESRUZICKA.ORG failed: Preauthentication failed
[2018/05/09 12:03:41.622923,  1] ../source3/libads/sasl.c:821(ads_sasl_spnego_bind)
  ads_sasl_spnego_gensec_bind(KRB5) failed for ldap/true-companion.hymesruzicka.org with user[CHEETOES$] realm=[HYMESRUZICKA.ORG]: Preauthentication failed
And the per-client log shows:

Code: Select all

[2018/05/09 12:06:58.259646,  1] ../source3/librpc/crypto/gse.c:646(gse_get_server_auth_token)
  gss_accept_sec_context failed with [Unspecified GSS failure.  Minor code may provide more information: Request ticket server cifs/CHEETOES.hymesruzicka.org@HYMESRUZICKA.ORG not found in keytab (ticket kvno 3)]
[2018/05/09 12:06:59.099902,  1] ../source3/librpc/crypto/gse.c:646(gse_get_server_auth_token)
  gss_accept_sec_context failed with [Unspecified GSS failure.  Minor code may provide more information: Request ticket server cifs/CHEETOES.hymesruzicka.org@HYMESRUZICKA.ORG not found in keytab (ticket kvno 3)]
Immediately after I rejoin, I do not get the client failures, nor the "Preauthentication failed" error in the log.smbd.
I'm particularly puzzled why rejoining works, but only for a while.

hunter86_bg
Posts: 1354
Joined: 2015/02/17 15:14:33
Location: Bulgaria
Contact:

Re: Reoccurring failure in accessing AD member samba shares

Post by hunter86_bg » 2018/05/15 04:52:23

Dis you find the reason?

charlweed
Posts: 7
Joined: 2016/01/22 16:54:25

Re: Reoccurring failure in accessing AD member samba shares

Post by charlweed » 2018/05/24 03:34:13

This is still a mystery.
I ended up writing two scripts to automate leaving and erasing all domain membership data, then rejoining.
Very painful.

hunter86_bg
Posts: 1354
Joined: 2015/02/17 15:14:33
Location: Bulgaria
Contact:

Re: Reoccurring failure in accessing AD member samba shares

Post by hunter86_bg » 2018/05/24 03:47:11

Can you check the options in this link and consider trying them ?Still you have to adjust the parameters in your config.

croth
Posts: 1
Joined: 2018/07/25 19:37:16

Re: Reoccurring failure in accessing AD member samba shares

Post by croth » 2018/07/25 19:54:22

Having the same issue here.

CentOS Linux release 7.5.1804 (Core)
Samba 4.7.1-6
sssd-krb5-1.15.2
SSSD 1.16.0-19
realmd-0.16.1-9

It seems like every month or so we need to remove the machine from the Active Directory domain and rejoin.

Is there any new information on this?

Authenticating to the Linux server using Active Directory credentials continues to work as expected, but users cannot access SAMBA shares hosted from the Linux server.

Thank you

ReinaldoGomes
Posts: 6
Joined: 2016/08/29 18:56:05

Re: Reoccurring failure in accessing AD member samba shares

Post by ReinaldoGomes » 2018/09/28 22:06:45

I've got the same problem over here, and I think I've (sort of) figured out what's going on.

It has to do with the keytab's KVNO. That's why you guys relate it to "after one month or so", which matches the average password renewal interval for an AD-member server, which increments the keytab's KVNO. In my case it happened earlier because I was doing a lot of re-joins with this server.

While having this problem, I found out that it only happened when I opened a windows explorer tab and typed in "\\server\share" directly (or if I type it inside a "run" text box). But it works fine if I use the "map network drive" feature with the "use different credentials" checkbox checked!

So I inspected the SMB traffic for both situations and I found out that:

1) When I try to access the share using the windows explorer tab, Windows, for some stupid reason, seems to try and "guess" what is the Samba server keytab current KVNO. On this situation, my Samba server would spit the following error:

gss_accept_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Request ticket server cifs/myserver@DOMAIN.LOCAL not found in keytab (ticket kvno 2)]
And that seems to be because Windows was sending 'KVNO 2' on its request to the Samba server (which simply didn't exist on my Samba server's keytab at the time!!), as shown to me by Wireshark.
Wireshark's sample: https://ibb.co/gmziBp

2) When I try to access the share using the "map network drive" feature with the "use different credentials" checkbox checked, Wireshark showed me that Windows was sending the correct KVNO on the SMB request (In my case, it was 35. Yes, I did a lot of re-joins.)

So when you guys completely wipe out the machine's account from the domain, then re-join it, you are basically creating a brand new keytab, whose initial KVNO matches Windows' "guess".

Unfortunately, that's as far as I could get, and I still couldn't find a way to solve this without creating a brand new keytab. Or telling the user to only access the share with the "map network drive" feature, which may also fail sometimes, (probably) due to some windows' weird caching.

Post Reply