I think I misunderstood this query: > What I verified is that, for any case (i.e. AD joined via SSSD or manual > kinit) the Apparmor denials happen every time I reload (without cache) the > page behind Kerberos > So I'm struggling to find a difference between them. Could you please clarify?
I didn't test AD joined via SSSD. I've only tested with our `/etc/krb5.conf.d/COMPANY.conf`. The issue I'm raising is that regardless of how Kerberos is configured on the host, the kerberos cache needs to be writable by the app sandbox so the ST can be added to the kerberos cache after it's retrieved so it doesn't have to be retrieved on subsequent requests for it. If no other app has retrieved the ST prior to signing in to the webpage Firefox/Chromium must retrieve an ST every time they are prompted for Kerberos authentication (any status 401 seems to trigger it) by a webpage. We have 3 servers and 4 websites (these are all I've found already) that I can reproduce this on relatively easy: * CM - Server1 - 2/ web requests require ST. 13128 and 12489 ms. Happens reliably with Ctrl+shift+r, happens intermittently with ctrl+r - done within short period it caches; done after loading GM it takes 12750ms. * GM - Server1 - 2/8 web requests require ST. 18276 and 5300 ms. Same as CM. * PM - Server2 - 4/21 web requests require ST. 13149, 12916, 15005, and 12752 ms. Same as CM. * HE - Server3 - This one has smarts where if the page is taking too long it uses a different auth mechanism... so it's harder. But from what I can see 9/27 requests require ST. And they range from 8934-23080 ms... All exhibit the same issue when using Firefox with the kerberos plug and `KRB5CCNAME=FILE:/tmp/krb5cc_1000 snap run firefox` (I removed the ENV variables that enable logging in case those were increasing the time) If I run `curl --negotiate $url` before opening Firefox for each site, and then load Firefox I never see these lengthy load times. (usually they're 100-500ms due to latency and page size) Server1 is running Windows Server 2022 Standard with IIS 10. Server1 System's Authentication settings: authPersistNonNTLM is set to True authPersistSingleRequest is set to False useAppPoolCredentials is False useKernelMode is True Server1 > CM's Authentication settings: authPersistNonNTLM is set to True authPersistSingleRequest is set to False useAppPoolCredentials is False useKernelMode is False Just in case this was due to config on our client-side end, I tried two other things to check if they are impacting the load time: 1. Set `rdns = False` 2. Remove the Authentication.Delegated settings from our policies.json Would it be helpful for me to create a private bug with a PCAP or HAR file showing the unobscured details? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2138268 Title: Kerberos authentication slow in Firefox (snap) and Chromium (snap) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2138268/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
