action #169147
closed
Unable to login at Grafana (monitor.qa.suse.de or any other domain)
Added by livdywan 19 days ago.
Updated 11 days ago.
Category:
Regressions/Crashes
Description
Observation¶
I am logged in in my primary work browser but I can't login anymore.
From the journal:
error="[password-auth.failed] failed to authenticate identity: LDAP Result Code 200 \"Network Error\": TLS handshake failed (remote error: tls: handshake failure)\n[password-auth.invalid] invalid password"
Workaround¶
- Create users that don't rely on LDAP
Suggestions¶
- Investigate how TLS and password add up to a failed login
Related issues
1 (1 open — 0 closed)
- Copied from action #162518: Unable to consistently login at stats.openqa-monitor.qa.suse.de added
- Description updated (diff)
- Status changed from New to In Progress
- Assignee set to livdywan
Oct 31 12:35:50 monitor grafana[19625]: logger=authn.service t=2024-10-31T12:35:50.304099076+01:00 level=info msg="Failed to authenticate request" client=auth.client.form error="[password-auth.failed] failed to authenticate identity: LDAP Result Code 200 \"Network Error\": TLS handshake failed (remote error: tls: handshake failure)\n[password-auth.invalid] invalid password"
Oct 31 12:35:50 monitor grafana[19625]: logger=context userId=0 orgId=1 uname= t=2024-10-31T12:35:50.304283768+01:00 level=info msg=Unauthorized error="[password-auth.failed] failed to authenticate identity: LDAP Result Code 200 \"Network Error\": TLS handshake failed (remote error: tls: handshake failure)\n[password-auth.invalid] invalid password" remote_addr=@ traceID
I was wondering how we end up with userID=0 and uname= here. However this also happens in successful cases:
Oct 29 03:36:47 monitor grafana[16078]: logger=context userId=0 orgId=1 uname= t=2024-10-
29T03:36:47.499094531+01:00 level=info msg="Request Completed" method=GET path=/api/live/ws status=400 remote_addr=@ time_ms=1 duration=1.639635ms size=12 referer= handler=/api/live/ws
More importantly https://ldap.suse.de is not available. ldap.toml (salt-states) expects TLS.
- Description updated (diff)
- Status changed from In Progress to Blocked
- Priority changed from Urgent to High
Blocking on SD-171914. And reducing Priority because annoying as it is we can create new users without LDAP as a workaround.
- Status changed from Blocked to Feedback
- Assignee changed from livdywan to nicksinger
Taking over for now and created https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/1302 with a fix. Apparently ldap.suse.de changed and doesn't allow STARTTLS any longer (or it has to happen on the "correct" port). With that I was able to login myself and asked for verification of somebody else in the team in slack. I will mention my fix in the SD ticket and try to close it.
- Status changed from Feedback to Resolved
merged, deployed and several people confirmed working login - resolving.
Also available in: Atom
PDF