Issues with authentication

BRL · June 14, 2021, 3:15pm

Hello,

We’ve been finding some issues regarding internal authentication.
At one time I logged in with the browser-saved credentials and ended up being logged in with another user, whose credentials I did not know, were not saved, or have ever been used on this browser or machine. I could see that users name and all the information was pertaining to him. Logging out and logging back in would not replicate the issue again, this time I would log in with my own user.

Also related to this issue - We have a Bot to automate some tasks that replies/comments on our tickets dozens of times a day. We see that sometimes the Bot seems to authenticate as another internal user, as we will see its standard reply coming from another person.

We are using standard authentication, no integration with any tool.
Version 5.0.1 (has been happening on previous versions as well)

Any help figuring this out would be appreciated.

rtshouldberewritten · June 16, 2021, 6:01am

Standard authentication returns a cookie after successful login, well, in my experience it does. Is it possible the other user’s cookie was also in the same browser you used for accessing RT? If not, it would point towards a problem in session cookie mgmt within RT5, a possible collision of cookie values or the like.

Jeff_Voskamp · June 16, 2021, 11:08am

Apache’s mod_speling is known to cause problems with CSS loading.
Apache’s mod_cache is now to cause problems with ‘bouncing/musical sessions’.
See the ‘web_deployment’ pod document in the documents directory.

Disabling mod_cache should fix the wandering credentials.

Jeff

BRL · June 16, 2021, 2:08pm

HI,

Thanks you for the quick reply!
We’ve disabled mod_cache and we’ll see the following days if the issue has been resolved.

BRL · June 21, 2021, 10:40am

Hello,

We disabled mod_cache, however the bot once again replied using another internal account.
Anything else we can try?

elacour · September 3, 2021, 3:46pm

I answer here your remark on the bug report:

It occurred to me if it could be related to the rt-clean-sessions script.

Would this be possible?

a session of user A with id X is cleaned by rt-clean-sessions

the id X is given to a new session created by user B

user A uses the old cookie with id X and gets user B session

this isn’t likely to appear, having a same session hash within your 3 days of rt-clean-sessions shouldn’t be possible.

I run here several RT with several use cases. rt-clean-sessions is configured on every (with different values) and we do not face such problem.

Thought, I still did not installed one on Centos above 7 and I mostly use fcgi rather than mod_perl. To me it has something to do with your setup.

Can you share the result of apachectl -t -D DUMP_MODULES ?

pjs · September 3, 2021, 3:48pm

Hi,

This is the output you’ve asked:

# apachectl -t -D DUMP_MODULES
Loaded Modules:
 core_module (static)
 so_module (static)
 http_module (static)
 access_compat_module (shared)
 actions_module (shared)
 alias_module (shared)
 allowmethods_module (shared)
 auth_basic_module (shared)
 auth_digest_module (shared)
 authn_anon_module (shared)
 authn_core_module (shared)
 authn_dbd_module (shared)
 authn_dbm_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_dbd_module (shared)
 authz_dbm_module (shared)
 authz_groupfile_module (shared)
 authz_host_module (shared)
 authz_owner_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 brotli_module (shared)
 data_module (shared)
 dbd_module (shared)
 deflate_module (shared)
 dir_module (shared)
 dumpio_module (shared)
 echo_module (shared)
 env_module (shared)
 expires_module (shared)
 ext_filter_module (shared)
 filter_module (shared)
 headers_module (shared)
 include_module (shared)
 info_module (shared)
 log_config_module (shared)
 logio_module (shared)
 macro_module (shared)
 mime_magic_module (shared)
 mime_module (shared)
 negotiation_module (shared)
 remoteip_module (shared)
 reqtimeout_module (shared)
 request_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 slotmem_plain_module (shared)
 slotmem_shm_module (shared)
 status_module (shared)
 substitute_module (shared)
 suexec_module (shared)
 unique_id_module (shared)
 unixd_module (shared)
 userdir_module (shared)
 version_module (shared)
 vhost_alias_module (shared)
 watchdog_module (shared)
 dav_module (shared)
 dav_fs_module (shared)
 dav_lock_module (shared)
 lua_module (shared)
 mpm_event_module (shared)
 proxy_module (shared)
 lbmethod_bybusyness_module (shared)
 lbmethod_byrequests_module (shared)
 lbmethod_bytraffic_module (shared)
 lbmethod_heartbeat_module (shared)
 proxy_ajp_module (shared)
 proxy_balancer_module (shared)
 proxy_connect_module (shared)
 proxy_express_module (shared)
 proxy_fcgi_module (shared)
 proxy_fdpass_module (shared)
 proxy_ftp_module (shared)
 proxy_http_module (shared)
 proxy_hcheck_module (shared)
 proxy_scgi_module (shared)
 proxy_uwsgi_module (shared)
 proxy_wstunnel_module (shared)
 ssl_module (shared)
 systemd_module (shared)
 cgid_module (shared)
 perl_module (shared)
 http2_module (shared)
 security2_module (shared)
 proxy_http2_module (shared)

elacour · September 3, 2021, 3:58pm

See nothing wrong here Maybe mod_security (which I do not use on RT), but I do not understand why, can you try it?

Are you able to reproduce this as you want?

pjs · September 3, 2021, 5:12pm

We can’t reproduce it so far.

We have disabled mod_security, let’s see if it solves the problem.

Best regards

Jim_Brandt · September 3, 2021, 8:18pm

If you’re using the event mpm, that will definitely cause problems. I don’t know if it can account for the session question, but it can cause failed requests and other types of errors. For RT with Apache, you need to run the prefork MPM. There is a note here:

https://docs.bestpractical.com/rt/5.0.1/web_deployment.html#prefork-MPM