Bug #10493
closed
LDAP broken in 1.8 with $login in account name
Description
Upgrading from 1.7.4 to 1.8 breaks LDAP logins. It seems to be attributed to a new group feature. Logging in as an internal user, and setting credentials in the UI results in logins never completing.
Problem 1: Foreman should re-use the original bind from the logged in user when looking up groups (instead of relying on predefined credentials as config)
Problem 2: Group lookup is so slow / hangs until browser timeout (!)
Oops, we're sorry but something went wrong
Warning!
Could not bind to ActiveDirectory user DOMAIN\DOMAIN\$login
If you feel this is an error with Foreman itself, please open a new issue with Foreman ticketing system, You would probably need to attach the Full trace and relevant log entries.
LdapFluff::Generic::UnauthenticatedException
Could not bind to ActiveDirectory user DOMAIN\DOMAIN\$login
app/models/auth_sources/auth_source_ldap.rb:97:in `update_usergroups'
app/models/user.rb:193:in `block in try_to_login'
app/models/concerns/foreman/thread_session.rb:72:in `as'
app/models/concerns/foreman/thread_session.rb:78:in `as_anonymous_admin'
app/models/user.rb:191:in `try_to_login'
app/controllers/users_controller.rb:71:in `login'
app/controllers/concerns/application_shared.rb:13:in `set_timezone'
app/models/concerns/foreman/thread_session.rb:32:in `clear_thread'
lib/middleware/catch_json_parse_errors.rb:9:in `call'
Updated by Jon Skarpeteig almost 9 years ago
Having an option to simply turn off this groups feature could serve as a workaround
Updated by Dominic Cleal almost 9 years ago
- Subject changed from LDAP broken in 1.8 to LDAP broken in 1.8 with $login in account name
- Category set to Authentication
I had tried to deprecate use of $login in the Foreman 1.6 and 1.7 release notes (and 1.8 LDAP docs) as the group support just didn't work with it, we often don't have access to any user credentials. Plain logins continued to work in 1.7 as noted above.
In hindsight, the change in #7369 also makes plain logins dependent on group support, so this could be skipped if $login is in use. It probably should be optional and not mandatory due to the speed.
Updated by Dominic Cleal almost 9 years ago
- translation missing: en.field_release set to 50
Updated by Dominic Cleal almost 9 years ago
- Related to Bug #7369: External user groups should be updated on login added
Updated by Jon Skarpeteig almost 9 years ago
The problem currently is that there is no workaround. I have attempted to remove the $login var, and use a regular account instead - but this only results in login hanging forever. (And thus still not able to log in).
If you have an LDAP user logging in, it will first do a bind - and refuse login if credentials are invalid. If credentials are valid, it continues to do group lookup. At this point you would already have an authenticated ldap connection available to do the subsequent searches. If you need to look up LDAP groups for a non-ldap user I would argue that the feature is broken.
Updated by Dominic Cleal almost 9 years ago
- Related to Bug #10340: AD auth hangs while syncing user groups on login added
Updated by Dominic Cleal almost 9 years ago
- Status changed from New to Assigned
- Assignee set to Dominic Cleal
Updated by The Foreman Bot almost 9 years ago
- Status changed from Assigned to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/2384 added
- Pull request deleted (
)
Updated by Dominic Cleal almost 9 years ago
The PR I submitted will skip this update process when $login is used, so login should now work properly.
Jon Skarpeteig wrote:
The problem currently is that there is no workaround. I have attempted to remove the $login var, and use a regular account instead - but this only results in login hanging forever. (And thus still not able to log in).
I'll probably add a toggle into the auth source so the user group update feature can be disabled on login, which as you said earlier will give us a workaround for when it hangs. I'll do that under ticket #10340.
I don't know yet why it would hang, but it could be a bug in ldap_fluff. Nightly builds now have debug logging of LDAP operations (#10406) so we might soon be able to get to the bottom of that.
If you have an LDAP user logging in, it will first do a bind - and refuse login if credentials are invalid. If credentials are valid, it continues to do group lookup. At this point you would already have an authenticated ldap connection available to do the subsequent searches. If you need to look up LDAP groups for a non-ldap user I would argue that the feature is broken.
True, we would have an authed connection, but there are two other reasons for not supporting $login with group syncing:
- the user group pages rely on having an LDAP connection available to associate them to LDAP groups, so a service account is required for them to function
- the syncing isn't fine grained as it syncs all groups that the user is in, so if the user's account had limited visibility on the LDAP server then it could fail finding users in the group, or remove them etc.
It's probably possible to fix these if somebody was determined enough, but when we implemented it, we opted for supporting only one or the other.
Updated by Dominic Cleal almost 9 years ago
Dominic Cleal wrote:
I'll probably add a toggle into the auth source so the user group update feature can be disabled on login, which as you said earlier will give us a workaround for when it hangs. I'll do that under ticket #10340.
Correction, I'll use #10509 to add a toggle and #10340 can remain open for debugging that hang during login.
Updated by Dominic Cleal almost 9 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 7891164bffb6746b13dde15a2d38f3371d0abab7.