Session Timeout is 4 weeks, but agents are logged out daily (Microsoft AzureAD SSO)

Technical assistance
1

TL;DR

Agents are being redirected back to the login page every morning, Zammad session timeout setting does not seem to be working. Looking for troubleshooting suggestions.

Info

  • Used Zammad version: 5.2.3-4
  • Used Zammad installation type: Docker Compose
  • Operating system: Rocky Linux 8.6
  • Browser + version: Windows 10 + 11 Edge 106.0.1370.42 and MacOS Safari Release 155
  • Note: email is configured via Microsoft 365 channel. Single sign on is configured using the “Microsoft” 3rd party integration. SSO is used by all agents to login
  • Note: Our Zammad is not accessible over the internet. The URL can only be reached over the corporate LAN
  • Note: Zammad is behind a traefik reverse proxy

Expected behaviour

  • Session timeout is set to 4 weeks. Agents should only be prompted to login every few weeks

Actual behaviour

  • Agents are being redirected back to the login page every morning
  • Sometimes, agents will be allowed to use the UI for a while, and only be redirected to the login page when they try to save changes to a ticket (!)

Steps to reproduce the behaviour

  • Put computer to sleep at the end of the workday
  • Wake computer from sleep next morning, login to windows
  • Sometimes Zammad is still open in a tab, sometimes the browser needs to be opened first and Zammad bookmark clicked
  • In all cases Zammad will have redirected to the login page rather than a logged in session

What have I tried

  • Been troubleshooting for about 20 days
  • Reviewed AzureAD conditional access policies, unable to find anything that would limit session length
  • Reviewed AzureAD sign in logs (whatever is wrong seems to be happening before it shows up in these logs)
  • Reviewed docker logs from each Zammad container (nginx, rails were most useful)
  • Able to view the points where an agent is redirected to the login page in rails log, but not sure what it means
  • Any troubleshooting suggestions appreciated

Here is an example showing some kind of failure to load content, followed by failure to auth and redirect to login page:

I, [2022-10-05T12:25:42.180360 #1-4793560]  INFO -- : Started GET "/app/itdesk/ui/requests" for 172.16.1.1 at 2022-10-05 12:25:42 +0000
E, [2022-10-05T12:25:42.196462 #1-4793560] ERROR -- : No route matches [GET] /app/itdesk/ui/requests (ActionController::RoutingError)
I, [2022-10-05T12:25:53.726443 #1-4793960]  INFO -- : Started GET "/auth/microsoft_office365/callback?code=[FILTERED]
I, [2022-10-05T12:25:53.792051 #1-4793960]  INFO -- : (microsoft_office365) Callback phase initiated.
[2022-10-05T12:25:59.525910 #1-4793800]  INFO -- : not allowed to show? this Ticket (Pundit::NotAuthorizedError)
2-10-05T12:25:54.764459 #1-4793960]  WARN -- : WARNING: cut string because of database length Authorization.token(2500 but is 2562)
I, [2022-10-05T12:25:54.881376 #1-4793960]  INFO -- : Redirected to https://helpdesk.spats.com/

And another example where an agent got booted back to the login page after an hour of work that morning:

I, [2022-10-05T12:52:17.828933 #1-4899700]  INFO -- : Started POST "/auth/microsoft_office365" for 172.16.1.1 at 2022-10-05 12:52:17 +0000
I, [2022-10-05T12:52:17.835008 #1-4899700]  INFO -- : (microsoft_office365) Request phase initiated.
I, [2022-10-05T12:52:18.587134 #1-4794080]  INFO -- : Started GET "/auth/microsoft_office365/callback?code=[FILTERED]&state=blablabla&session_state=bla-bla-bla" for 172.16.35.1 at 2022-10-05 12:52:18 +0000
I, [2022-10-05T12:52:18.593330 #1-4794080]  INFO -- : (microsoft_office365) Callback phase initiated.
I, [2022-10-05T12:52:19.845780 #1-4794080]  INFO -- : Processing by SessionsController#create_omniauth as HTML
I, [2022-10-05T12:52:19.845858 #1-4794080]  INFO -- :   Parameters: {"code"=>"[FILTERED]", "state"=>"blablabla", "session_state"=>"bla-bla-bla", "provider"=>"microsoft_office365"}
2

Quick update: I found a possible workaround by accident.

I had created an API token for a user. The token is used to run API queries for things like current number of unassigned tickets, and other similar KPIs, which are fed into another system.

After doing this, the user no longer gets logged out overnight. I’m assuming the API queries triggering a few times per hour are preventing whatever automatic timeout has been causing agents to be logged out.

So I suppose a possible solution for the session timeout issue would be to set up some dummy API queries for our agents and having them run on a schedule :thinking:

3

This is a normal behavior - because:
During the authentication against any 3rd party you cannot set the tick “remember me” (even if it doesn’t matter). This means you’re not authenticated with a permanent session.

If your account then is inactive for “too long”, the session will be invalidated automatically - well before the actual limit you set. The same would happen if you close and restart your browser. I would have to dig around in the code to say the exact limit. If I’d had to guess it would be something in between 4 to 12 hours.

Usually well enough for this kind of working use case.

1 Like
4

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.