when Samba was initially joined with the default unix charset UTF-8 (and the machine account has that password stored in that encoding in secrets.tdb), and if the unix charset is changed to iso-8859-1, then two issues pop up:

1)
the join is no longer valid because the machine secret is expected to be encoded in "unix charset", so utf-8 in this case. This is not ideal obviously. Shouldn't we store the password in a universal charset e.g. UTF-8 unconditionally of how unix charset is set?

2)
if problem 1) was recognized and if you try to join the machine once more, then the join fails because "net" tries to read the old password from the secrets tdb, which results in the following error:

# net ads join -U administrator
Enter administrator's password:
secrets_store_domain_info: convert_string_talloc(CH_UTF16MUNGED, CH_UNIX) failed for old_pw of SERNET - NT_STATUS_UNMAPPABLE_CHARACTER
secrets_store_JoinCtx: secrets_store_domain_info() failed for SERNET - NT_STATUS_UNMAPPABLE_CHARACTER
libnet_join_joindomain_store_secrets: secrets_store_JoinCtx() failed NT_STATUS_UNMAPPABLE_CHARACTER
Failed to join domain: This machine is not currently joined to a domain.

To work around the 2nd problem you will also have to move away the secrets tdb.

As non-ascii strings in UTF-8 encoding can reliably detected it would be possible to migrate passwords in the secrets tdb on systems that have the password in a legacy unix charset to UTF-8 and then start treating the machine password as UTF-8 consistently. That would fix problem 1) and 2) for the future.

In case we do not migrate the secrets passwords to UTF-8, then issue 2) should be address differently.