Hi, This problem has been resolved by manually removing the failing audit permission in the db, I created a new clearer mailing list thread, so the new thread can cleanly address the bug fix.
Thanks. - Tobias Sent with [Proton Mail](https://pr.tn/ref/BTTM5JG4EZEG) secure email. On Saturday, July 5th, 2025 at 16:49, [email protected] <[email protected]> wrote: > Hi Nick, > > Appreciate the reply! > > Seems like the SSO-Auth extension is indeed working, however I had a problem, > that my SSO-Issues mapped to the same username as guacamole was configured to > use the claim, so this one is on me. > > After being finally able to login via SSO im guacamole, I just see an empty > guacamole with a user that has no rights, logging in via my normal guacamole > admin(non-sso) and navigating to users tab does not show the new sso user > that should have been generated, so I could manage it, but I guess that is > expected since it's an external user? > > I went and configured a group on guacamole and gave it full admin rights, > went to authentik created a group with the same name and assigned my user to > that group on authentik. > > However after creating the group on guacamole, while it shows in the UI, I > cannot edit it anymore, there is just an infinite loading circle, here the > logs of that: > > https://pastebin.com/V8wTxwTb > > Thanks for the explanation, yes the above are tomcat catalina.out logs during > trying to access(edit) the group I created within guacamole, using my normal > guacamole admin account (non-sso-user) > > The second issue, after assigning my user on authentik side to the same group > as created on guacamole I cannot seem to log-in anymore at all, so there is > definitely something wrong with the group 'guacamole-admin' I created within > guacamole, since I cannot edit/remove it anymore nor can a sso-user sign in > when it has that group assigned via oidc-issuer. > > Here the log of the sign-in process via sso with the user that has the > guacamole-armin group assigned: > > https://pastebin.com/aUnFzgTR > > Hope this is clear, otherwise I happily provide more details. > > Thanks > - Tobias > > Sent with Proton Mail secure email. > > On Saturday, July 5th, 2025 at 13:43, Nick Couchman <[email protected]> wrote: > >> On Tue, Jul 1, 2025 at 3:34 AM <[email protected]> wrote: >> >>> Hi, >>> >>> When activating SSO and having set up TOPT for the admin account, >>> signing-in with SSO brings up a TOPT loginscreen from guacamole which >>> cannot be completed, due to the admin account although having TOPT, that's >>> a different user, so it did not work to complete TOPT for an SSO User. >> >> I don't quite understand the scenario, could you provide a bit more detail >> as to how the user is set up and what behavior you're seeing? >> >>> I already reported this problem a while ago and got confirmation that this >>> should already be fixed and released with 1.6.0 sadly it's still not >>> working :/ >>> >>> Looking further in jira it seems to be that only SAML has been fixed. >>> https://www.mail-archive.com/[email protected]/msg13233.html >>> >>> or am I missing any new config options, that I have overlooked in release >>> announcements? >> >> In my response on the previous thread I was not certain if those changes >> covered OpenID or not. Looking back at the pull request, I see that some of >> the changes are implemented at the SSO extension base, which would impact >> all of the modules; however, there are some SAML-specific ones. So it's >> possible that this didn't actually implement everything required for OpenID >> to function properly. I'll have to go back through and look at the changes >> more closely. >> >>> It would be really nice to be able to have the admin Account secured with >>> TOPT and still have SSO users. >>> >>> My guacamole properties for OIDC setup: >>> ``` >>> openid-authorization-endpoint: >>> https://auth.mydomain.dev/application/o/authorize/ >>> openid-client-id: XXXXX >>> openid-issuer: https://auth.mydomain.dev/application/o/guacamole/ >>> openid-jwks-endpoint: >>> https://auth.mydomain.dev/application/o/guacamole/jwks/ >>> openid-redirect-uri: https://guac.mydomain.dev/guacamole >>> openid-scope: openid email profile >>> openid-username-claim-type: preferred_usernameextension-priority: *, openid >>> ``` >>> I'd be happy to provide logs, but using >>> ``` >>> systemctl stop guacd >>> /usr/local/sbin/guacd -L debug -f >>> ``` >>> does not bring up any logs during sign-in. >> >> There are two components to Guacamole - guacd, which is the "proxy" service >> that translates between the remote protocols (SSH, RDP, etc.) and Guacamole, >> but has nothing whatsoever to do with the client logins or interface. The >> client interface is run by Tomcat (or, based on your previous post, the >> Docker "guacamole" container), so you'll need to gather logs from Tomcat or >> that Docker container in order to see the login details. >> >> -Nick >> >>>
