I think there are two parts to this:

Net::LDAP had a bug (until 0.17.0) that prevented passwords longer than 60 chars to work, fixed in https://github.com/ruby-ldap/ruby-net-ldap/commit/a07710c6446e2b1d00cdc3c6ae881bc60aa3a2f7

Foreman has a limit (maybe because of Net::LDAP?) for the account_password to be 60: https://github.com/theforeman/foreman/blob/ef8036152aefbdca9348b83870ecd7835520f11f/app/models/auth_sources/auth_source_ldap.rb#L35

Interestingly, the underlying DB field is 255 chars long, but given the PW is encrypted, the PW length and the DB entry length don't match.

We do ship net::ldap 0.17.0 in 6.10+, but the model validation still hits when you try to create a auth source with an authenticated bind.

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/36309 has been resolved.

This is present in foreman-3.7.0. The fix seems to be already present in last snap, so this is effectively ON_QA, but moving to ON_DEV to not mess up the automation in the hope that it will properly transition to ON_QA with the release on next snap.

Verified with Sat 6.14 snap 3.0, BUT a followup BZ filed.

I created users in Active Directory 2019: qwerty (with 78 characters password), qwerty66 (with 66 characters password), qwerty69 (with 69 characters password).

First, I tried them using AD enrollment ( https://access.redhat.com/documentation/en-us/red_hat_satellite/6.13/html/installing_satellite_server_in_a_connected_network_environment/configuring_external_authentication_satellite#Using_Active_Directory_satellite ) even though that's not what this BZ is about.
1) I gave the users Admin permissions
2) I followed the docs, replacing Administrator with qwerty66 (it's necessary to set `ad_gpo_map_service = +foreman`)
3) I was able to log in using any credentials from AD
=> OK

Then, I attempted to use these users as the bind users for LDAP auth source. This is not about logging in as those users, rather as using those users to login to the AD itself to verify a user being logged in.
1) In WebUI: Administration -> Authentication Sources -> LDAP -> Create
2) On the first tab fill in the necessary data, select Active Directory as type (make sure you have the right cert for LDAPS, use update-ca-trust workflow)
3) On the second tab, use login <DOMAIN>\<user>, in my case: AD2019\qwerty and fill in the rest
4) On the third tab, I had to set login mapping from uid to cn
5) Submit
=> Failure, second tab's Password field marked red with text "is too long (maximum is 69 characters)".
6) Repeat 3,4,5 for users qwerty66 and qwerty69
=> OK
7) Attempt to set 70-characters password
=> Failure as above
8) Finally, Submit with some account that works, I used qwerty69
9) Logout
10) Login using any <user>, I used qwerty66
=> OK
11) In hammer:
 hammer auth-source ldap update --id <id> --account-password <password_of_qwerty_user>
Could not update the Auth Source:
  Account password is too long (maximum is 69 characters)
=> OK

Note that the artificial, unnecessary limit of 60 characters has been changed to 69. However, 69 is a technical limit of the library for some reason: https://github.com/theforeman/foreman/pull/9687#issue-1671300114
It is a bug nonetheless, hence I'm reporting a followup BZ about this. I'm verifying this one since this particular issue has been fixed (although replaced by another) and I think it should satisfy this particular customer's requirements.

Followup: bug 2218132

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.14 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:6818