samba - Dec 2021 - net ads join fail with Password exceeds maximum length allowed for crypt() hashing

Hi Samba-team,

I am try to join a machine to my samba4 domain, unfortunately there is 
no way to get it done:

net ads join --no-dns-updates -v -U domain_join_user
ads_print_error: AD LDAP ERROR: 1 (Operations error): 00002020: 
setup_primary_userPassword: generation of a CryptSHA512 password hash 
failed: (Password exceeds maximum length allowed for crypt() hashing)
Failed to join domain: Failed to set password for machine account 
(NT_STATUS_UNSUCCESSFUL)

This looks like a bug, should I file one?
Is there a way to workaround this issue?


As an additional "feature" the preprovisioned computer-account is 
removed and hence a next request always fails. I understand this happens 
when the join creates the account but it is illogical behavior with 
pre-provisioned accounts. Is there a way to avoid this?


- Kees

Forgot to add some info:

I am using Samba 4.15.3 on the DCs on Bullseye (from Louis' repo) and 
stock Bullseye (4.13.13) on the member-server (to be).

I found a bug: 14621 that seems cover this or a similar issue. It says 
to be fixed in 4.15
The question then is is this a client or a server issue (if the latter, 
is it a regression?)



-------- Forwarded Message --------
Subject: 	net ads join fail with Password exceeds maximum length allowed 
for crypt() hashing
Date: 	Fri, 31 Dec 2021 17:32:45 +0100
From: 	Kees van Vloten <keesvanvloten at gmail.com>
To: 	samba at lists.samba.org <samba at lists.samba.org>



Hi Samba-team,

I am try to join a machine to my samba4 domain, unfortunately there is 
no way to get it done:

net ads join --no-dns-updates -v -U domain_join_user
ads_print_error: AD LDAP ERROR: 1 (Operations error): 00002020: 
setup_primary_userPassword: generation of a CryptSHA512 password hash 
failed: (Password exceeds maximum length allowed for crypt() hashing)
Failed to join domain: Failed to set password for machine account 
(NT_STATUS_UNSUCCESSFUL)

This looks like a bug, should I file one?
Is there a way to workaround this issue?


As an additional "feature" the preprovisioned computer-account is 
removed and hence a next request always fails. I understand this happens 
when the join creates the account but it is illogical behavior with 
pre-provisioned accounts. Is there a way to avoid this?


- Kees