Bug 12515 - create_local_private_krb5_conf_for_domain should generate entries for kpasswd_sever
Summary: create_local_private_krb5_conf_for_domain should generate entries for kpasswd...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.4.2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on:
Reported: 2017-01-13 05:29 UTC by Matthieu Patou
Modified: 2017-02-09 07:35 UTC (History)
3 users (show)

See Also:

Proposed fix (3.00 KB, patch)
2017-02-09 01:38 UTC, Matthieu Patou
no flags Details
Possible patches for master (5.23 KB, patch)
2017-02-09 07:35 UTC, Stefan Metzmacher
metze: review? (gd)
metze: review? (mat)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthieu Patou 2017-01-13 05:29:04 UTC
With commit 1d779bdbb21f50c1f638e1abfa732807d32d6887 Samba is not talking directly to the kpasswd server instead it is using the implementation of the kerberos library.

When using MIT kerberos (at least), MIT will use DNS SRV records to locate the kpasswd server, but MIT don't have a knowledge of site so it ends up doing DNS queries (when instructed to use the generated krb5.conf from Samba) that returns all the DCs in random order.
As a result the change/set password operation can be performed on a DC at the opposite location of Samba on the globe. Due to replication frequency between site it can take a lot of time for the DCs in the same site to get the password update.
If you use the net ads changetrustpw in a script and also net ads keytab create -P it can leads to serious problems as the second command will use DC in the site to generate keytab but generation will fail because the password used is the new one but the local DCs don't know it yet.

When Samba will generates those entries then MIT kerberos will use them and hence Samba can heavily influence which DC will be used (in site first, and then the others).
Comment 1 Stefan Metzmacher 2017-02-01 11:56:11 UTC
Why are you using "net ads changetrustpw"?

Winbindd changes the password each week by default,
if you want to force it 'wbinfo --change-secret' would also so it.
Comment 2 Matthieu Patou 2017-02-01 17:08:28 UTC
(In reply to Stefan Metzmacher from comment #1)
we are using net ads changetrustpw because it works :-), we can't use the automatic password change from winbindd because the keytab mode is external and hence we need to know when the password is changed.

As for wbinfo --change-secret, why not but wouldn't it at the end, end up calling the same API and have the same issues.
Comment 3 Matthieu Patou 2017-02-09 01:38:37 UTC
Created attachment 12909 [details]
Proposed fix
Comment 4 Stefan Metzmacher 2017-02-09 07:35:14 UTC
Created attachment 12910 [details]
Possible patches for master

Does these patches also fix your problem?

Günther can you have a look as you added the :88 for ipv6?