Bug 13429 - kvno off by one after net ads changetrustpw
Summary: kvno off by one after net ads changetrustpw
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on:
Reported: 2018-05-10 16:43 UTC by David Mulder
Modified: 2021-07-28 14:44 UTC (History)
4 users (show)

See Also:

potential fix that calculates the kvno (8.96 KB, patch)
2018-05-10 16:46 UTC, David Mulder
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Mulder 2018-05-10 16:43:55 UTC
A customer first noticed this on 4.6.9.

The KVNO gets changed properly on the DC and increments one, however the local keytab did not increment.

Some details:
1. In smb.conf kerberos method = system keytab
2. klist -k shows KVNO 3
3. Perform net ads changetrustpw says it was successful
4. Querying ldap shows the KVNO as incremented to 4 (good)
5. klist -k still shows KVNO as 3 (bad)

If I try running net ads changetrustpw again, it increments the KVNO on the KDC to 5 AND now it increments the KVNO on the host to 4. In this state, now every time you run the changetrustpw after the first time, the KVNOs will be mismatched.

The problem is in net_ads_changetrustpw() between the call to ads_change_trust_account_password() and ads_keytab_create_default(). In ads_keytab_create_default() we call ads_get_machine_kvno() to request the kvno from the DC via ldap. In this customer's setup, the kerberos DC is *not* the same as the ldap DC. There's enough of a ldap replication delay, that the ldap DC returns the *old* kvno here, providing us with the wrong kvno when we store it in the keytab. This happens pretty consistently for this one customer.
Comment 1 David Mulder 2018-05-10 16:46:45 UTC
Created attachment 14193 [details]
potential fix that calculates the kvno

Here is a potential fix which calculates the kvno based on the kvno *before* the password change.
Comment 2 David Mulder 2018-05-10 16:53:49 UTC
Another potential fix would be to have the 'ldap replication sleep' smb.conf parameter apply to this situation, so that increasing the sleep would cause ads_get_kvno() to sleep briefly prior to making this call.
Comment 3 Andrew Bartlett 2018-05-10 18:15:22 UTC
I think this needs a careful test, and to handle a few more cases.

It needs to handle the case where, between when the keytab was last modified and now, the server-side had a password reset.  This would change the server-side kvno but not the keytab kvno, and so get things out of skew again.
Comment 4 David Mulder 2018-05-10 18:31:04 UTC
(In reply to Andrew Bartlett from comment #3)
I think my current patch already handles that situation, since it queries ldap for the kvno, resets the password, then sets the local kvno to the retrieved kvno+1.
I'm not sure how we'd test this, since it's caused by a race condition on the server side.
Comment 5 Stefan Metzmacher 2019-08-01 13:33:41 UTC
The kvno in our keytab should be completely ignored!

We need to check all keytab entries, there's no interaction with any KDC needed.
Comment 6 Samuel Cabrero 2021-07-28 14:44:29 UTC
We have another customer with the same problem.

Metze, could you please elaborate on your response? Is David's patch approach wrong?