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).
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.
(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.
Created attachment 12909 [details] Proposed fix
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?