Description of problem: Satellite LDAP Authentication with AD does not allow bind password over 60 characters Version-Release number of selected component (if applicable): Satellite 6.9.8 How reproducible: 100% of the time Steps to Reproduce: 1. Set up AD Authentication for Satellite 2. Ensure the AD Bind Password has 61 Characters or more. 3. Error will be generated - LdapFluff::Generic::UnauthenticatedException (Could not bind to ActiveDirectory user DOMAIN\AD-User) Actual results: Error Message: LdapFluff::Generic::UnauthenticatedException (Could not bind to ActiveDirectory user DOMAIN\AD-User) Expected results: Authentication should work normally when the password is set to 61 or more characters Additional info: The customer Tested with their AD team and a bind password of 55 characters was ok, 59 was ok 60 was ok but not 61. Customer policy requires 64 characters or more.
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