Project

General

Profile

Actions

Bug #20396

closed

It's hard to understand which authentication backend failed when a fallback happens

Added by François ARMAND about 2 years ago. Updated 10 months ago.

Status:
Released
Priority:
N/A
Category:
Web - UI & UX
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
0
Name check:
To do
Fix check:
Checked
Regression:
No

Description

With current logs, it is quite hard to understand if and how an authentication backend failed, and if so, that a fallback was used (and failed).

Typically, when the default authentication is on LDAP and file second, if an user is missing from LDAP, we get logs like:

[2021-11-03 11:26:23+0100] ERROR application - Invalid password format: not a Bcrypt string
[2021-11-03 11:26:23+0100] WARN  application - Login authentication failed for user 'xxx' from IP '127.0.0.1|X-Forwarded-For:10.243.4.188': Bad credentials

We need at least DEBUG level to understand (with added comments starting by #)

# failing on one DaoAuthenticationProvider, likely built-in root users, of course login does not matches
[2021-11-05 10:39:40+0100] DEBUG org.springframework.security.authentication.dao.DaoAuthenticationProvider - User 'xxx' not found
# starting LDAP authentication
[2021-11-05 10:39:40+0100] DEBUG org.springframework.security.ldap.authentication.LdapAuthenticationProvider - Processing authentication request for user: xxx
[2021-11-05 10:39:40+0100] DEBUG org.springframework.security.ldap.search.FilterBasedLdapUserSearch - Searching for user 'xxx', with user search [ searchFilter: '(&(uid={0})(objectclass=posixAccount))', searchBase: '', scope: subtree, searchTimeLimit: 0, derefLinkFlag: false ]
[2021-11-05 10:39:40+0100] DEBUG org.springframework.security.ldap.SpringSecurityLdapTemplate - Searching for entry under DN 'ou=users,dc=foo,dc=fr', base = '', filter = '(&(uid={0})(objectclass=posixAccount))'
# here, LDAP didn't find anything, so we fallback on next backend: file based. 
# This one fails because the password is not a bcrypt one - of course, but the message is... cryptic.
[2021-11-05 10:39:41+0100] ERROR application - Invalid password format: not a Bcrypt string
# AH! only now we understand that we were trying a DaoAuthenticationProvider (ie file based list of user)
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.authentication.dao.DaoAuthenticationProvider - Authentication failed: password does not match stored value
# we tested all rudder auth backend, now debug is only for spring security other things.
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter - Authentication request failed: bootstrap.liftweb.RudderProviderManager$1: Bad credentials
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter - Updated SecurityContextHolder to contain null Authentication
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter - Delegating to authentication failure handler bootstrap.liftweb.RudderUrlAuthenticationFailureHandler@2d16f05
[2021-11-05 10:39:41+0100] WARN  application - Login authentication failed for user 'xxx' from IP '127.0.0.1|X-Forwarded-For:10.243.4.188': Bad credentials
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.web.DefaultRedirectStrategy - Redirecting to '/rudder/index.html?login_error=true'

So, we would like something like:

[info] authentication request for user 'xxx'
# no need to put a first message for the default auth, we know it will be tried
[info] 'xxx': failed authentication request on 'ldap' backend 
[info] 'xxx': failed authentication request on 'file' backend 
[warn] application - Login authentication failed for user 'xxx' from IP '127.0.0.1|X-Forwarded-For:10.243.4.188': Bad credentials

Tech note: unfortunately, the auth framework (spring security) does not allow these changes, and after 2h trying to understand how it could be done, I failed. It would need 1d of work to really understand what is going on and how to change it.

Actions #1

Updated by François ARMAND 11 months ago

  • Project changed from Authentication backends to Rudder
  • Target version set to 7.2.6
  • Regression set to No
Actions #2

Updated by François ARMAND 11 months ago

  • Status changed from New to In progress
  • Assignee set to François ARMAND
Actions #3

Updated by François ARMAND 11 months ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Vincent MEMBRÉ
  • Pull Request set to https://github.com/Normation/rudder/pull/4746
Actions #4

Updated by Anonymous 11 months ago

  • Status changed from Pending technical review to Pending release
Actions #5

Updated by Alexis Mousset 10 months ago

  • Subject changed from It's hard to understand what authentication backend failed when a fallback happens to It's hard to understand which authentication backend failed when a fallback happens
Actions #6

Updated by Alexis Mousset 10 months ago

  • Category set to Web - UI & UX
Actions #7

Updated by Vincent MEMBRÉ 10 months ago

  • Fix check changed from To do to Checked
Actions #8

Updated by Vincent MEMBRÉ 10 months ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 7.2.6 and 7.3.1 which were released today.

Actions

Also available in: Atom PDF