LDAP and SAML User after Timeout Re-Login blocked

Lndskr0n · January 14, 2025, 9:12am

Infos:

Used Zammad version: 6.4.1-1736834696.3cb558f4.bookworm
Used Zammad installation type: package
Operating system: Debian 12
Browser + version: Firefox + Edge latest

Expected behavior:

After Logout and Re-Login normal Authentication

Actual behavior:

Users imported from LDAP or SAML (Keycloak) Re-Login after Session timeout (invalid_session) are blocked. Message came up:

Anmeldung fehlgeschlagen. Haben Sie Ihre Anmeldedaten überprüft und den E-Mail-Verifizierungsschritt abgeschlossen?

English

Login failed. Have you double-checked your credentials and completed the email verification step?

Steps to reproduce the behavior:

After 20 Minutes Timout from Session Url-String: #SessionInvalid
Login-Screen
Login with correct Credentials
Message Below appears
User can only be Re-Activate from admin-User, all Settings and Group-Ownership has gone

Found this in production.log:

E, [2025-01-14T09:45:53.773721#16144-210860] ERROR -- : Validation failed: Email address 'user@mail.de' is already used for another user. (ActiveRecord::RecordInvalid)

It seems to be the Import-Process for LDAP-Users. It keeps trying to import existing users, then realizes that the email already exists and ends the session.

How can i fix it?

Lndskr0n · January 14, 2025, 9:57am

Ok, i have dug further:

Directly after Timeout in production.log

I, [2025-01-14T10:50:52.162739#16136-188140]  INFO -- : Completed 401 Unauthorized in 3ms (Views: 0.1ms | ActiveRecord: 0.3ms | Allocations: 2069)
I, [2025-01-14T10:51:00.595953#16144-183500]  INFO -- : ProcessScheduledJobs running...
I, [2025-01-14T10:51:00.597068#16144-183500]  INFO -- : Running job thread for 'Generate 'Session' data.' (Sessions.jobs) status is: sleep
I, [2025-01-14T10:51:00.597111#16144-183500]  INFO -- : Running job thread for 'Check 'Channel' streams.' (Channel.stream) status is: sleep
I, [2025-01-14T10:51:00.597270#16144-183500]  INFO -- : Running job thread for 'Process ticket escalations.' (Ticket.process_escalation) status is: sleep
I, [2025-01-14T10:51:00.597298#16144-183500]  INFO -- : Running job thread for 'Check channels.' (Channel.fetch) status is: sleep
I, [2025-01-14T10:51:00.598854#16144-183500]  INFO -- : Running job thread for 'Execute planned jobs.' (Job.run) status is: sleep
I, [2025-01-14T10:51:02.188064#16136-186180]  INFO -- : Started POST "/api/v1/message_send" for 10.10.10.254 at 2025-01-14 10:51:02 +0100
I, [2025-01-14T10:51:02.191373#16136-186180]  INFO -- : Processing by LongPollingController#message_send as JSON
I, [2025-01-14T10:51:02.191410#16136-186180]  INFO -- :   Parameters: {"data"=>{"event"=>"login"}}
I, [2025-01-14T10:51:02.193877#16136-186180]  INFO -- : CSRF token verification failed
I, [2025-01-14T10:51:02.193968#16136-186180]  INFO -- : CSRF token verification failed! (Exceptions::NotAuthorized)

It seems that my proxy config is not working because my proxy IP appears here. At least there seems to be a problem with the x-forwarded. I am using HAProxy.

My HAProxy Backend Config…

# Backend: zammad_backend ()
backend zammad_backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m  
    stick on src
    http-reuse safe
    option forwarded proto host for
    option forwardfor
    server zammad_1 10.10.10.1:443 ssl alpn h2,http/1.1 verify none

Any suggestions?

Lndskr0n · January 14, 2025, 11:43am

The Problems beginning with the change from http to https. I have already edit the nginx conf after documention:

proxy_set_header X-Forwarded-Proto https;

But, the problem still exists.

Lndskr0n · January 15, 2025, 7:29am

After new Installation without SSL, the problem still exist.

In production.log i can see the real IP from users, but after time i became Session Invalid. Re-Login doesnt work. Only with SAML and LDAP imported Users.

derForest · January 15, 2025, 10:22am

Hi Lndskr0n,
I had a similar issue after switching to https mode.
I’m not 100% sure anymore, but I’ve in mind that my apache had issues with the https redirect from port 80 so in addtion to the x-forward I needed to correct that.

MrGeneration · January 15, 2025, 10:39am

This has to do zero with the used web server.
OP actually gives the key hint here:

The LDAP configuration is fucked up.

MrGeneration · January 15, 2025, 10:51am

Kindly don’t hijack other threads with your issue. Thank you very much. Different topics mate.

Lndskr0n · January 15, 2025, 11:15am

Thanks for Reply.

I can reproduce the Issue: When LDAP-Sync starts, he found an double entry for the imported user. After that, he set the User to inactive.

The question is why? No other user in Zammad has the email. However, another user with the same settings works again without any problems. I don’t understand what is different about this user.

Lndskr0n · January 15, 2025, 3:43pm

In the meantime, I am working on the problem with a colleague. He has found out via the debug mode of the LDAP import that there is a second user session in the database. The same user, but with a 1 appended. So instead of “user” there was a “user1”. We deleted both users and started a re-import. The original user was then available, but I cannot log in with it. The LDAP integration shows the following error:

At this point, we don’t know what to do.

Lndskr0n · January 15, 2025, 3:54pm

Ok, that was hard. The password from this user was in meantime expired. After renew the login works. I will continue to observe.