Synology DSM (7.2.1) and Authelia (4.38.2) throws a "not privilege" (sic) error

[DJBenson]

I noticed by chance yesterday that my Authelia instance was down and on closer inspection this was due to a bug with the recent release. After I'd sorted out my config to fix the warnings and got Authelia back up and running, I tried out some apps and all worked with the exception of DSM which throws a rather ambiguous "not privilege" (sic) error after confirming the SSO login on the Authelia page.

I appreciate this is probably something on the DSM side but given it was working fine until the new Authelia release, and there hasn't been a DSM release recently, I wondered if anybody else had the same issue.

There are no logs in DSM to even show a login was attempted and I can log in via LDAP using the same credentials.

[glime-ai[bot]]

Please note this response was created using generative AI leveraging previously available information from the repository. This information may be helpful however it is our strong recommendation that you carefully consider the information before blindly applying it.

---

It sounds like the issue you're encountering with DSM following the Authelia update might be related to changes in the Authelia configuration or how Authelia interacts with DSM, especially considering that everything else is working as expected. Given that DSM hasn't had a recent release, the focus should indeed be on the changes introduced by the Authelia update.

First, ensure that your Authelia configuration aligns with the requirements for DSM integration, particularly regarding OpenID Connect and LDAP settings. Since DSM does not support automatically creating users via OpenID Connect, it's crucial that Authelia and DSM share the same LDAP server for user authentication, as mentioned in the provided context.

Here are a few steps and checks you can perform:

1. Review Authelia's OpenID Connect Configuration: Ensure that the OpenID Connect configuration for DSM in Authelia hasn't been altered in a way that would affect authentication. This includes verifying the client_id, client_secret, and redirect URIs. The client_secret should be securely stored and not exposed in plaintext, as recommended.

2. Check LDAP Configuration: Since you can log in via LDAP using the same credentials, it's unlikely the issue lies here, but it's worth double-checking that the Authelia and DSM configurations haven't been inadvertently changed during the update.

3. Examine Authelia Logs: While DSM might not show logs for the login attempt, Authelia's logs could provide insights into what's happening during the authentication process. Look for any errors or warnings that occur when you attempt to log in to DSM via SSO.

4. Review Breaking Changes: Carefully review the release notes of the Authelia version you've updated to for any breaking changes or migration steps that you might have missed. Sometimes, new versions introduce changes that require updates to the configuration files or adjustments in how Authelia is integrated with other services.

5. Test with a Minimal Configuration: If possible, test the DSM integration with a minimal Authelia configuration that's known to work (based on your previous setup before the update). This can help identify if the issue is with the configuration or elsewhere.

6. Community Feedback: Since you're curious if others have encountered the same issue, consider reaching out on Authelia's GitHub discussions or community forums. Other users might have faced similar problems and could offer solutions.

If after these checks and tests the issue persists, providing detailed logs from Authelia during a DSM login attempt could help further diagnose the problem.

This comment was generated by Glime.

[james-d-elliott]

There are no reported breaking changes in the latest release, all reported issues so far have been fixed as they were bugs.

As far as the errors we'd need (debug) log messages from both sides to diagnose it more.

[DJBenson]

@james-d-elliott I was about to edit how I described this as I knew it would be picked up. What I had last night was a failure due to the webauthn bug which was promptly fixed, however I also tacked all the config changes at the same time, so indeed there were technically no breaking changes, just a bug which took my system down.

I've just spotted the following in the Authelia logs when I attempt login;

Access to https://cloud.mydomain.uk/ (method GET) is not authorized to user anonymous, responding with status code 401" method=GET path=/api/verify remote_ip=xxx.xxx.xxx.xxx

https://cloud.mydomain.uk/ requires 2FA, cannot be redirected yet" method=POST path=/api/firstfactor remote_ip=xxx.xxx.xxx.xxx

[DJBenson]

Yeah I decided to sort out my config now rather than later as I can go months without having to touch Authelia as "it just works" so I leave it be, but then got caught by the webauthn bug - this is mostly just a backstory to "my system worked for months then broke" but the only bit now not working is the DSM integration.

cloud. is the domain name of my DSM box. It goes Cloudflare (DNS) -> NPM -> Authelia -> DSM.

Just to reiterate, everything else is working (and to quantify, that means Proxmox, Portainer, Wordpress and a handful of other OIDC clients as well as a tonne of other apps protected by Authelia).

[DJBenson]

OIDC config for this service;

• client_id: synology-dsm
  client_name: Synology DSM
  client_secret: $argon2id$v=redacted
  public: false
  authorization_policy: two_factor
  redirect_uris:
  • https://cloud.mydomain.uk
    scopes:
  • openid
  • profile
  • groups
  • email
    userinfo_signed_response_alg: none

[james-d-elliott]

Very strange. Those log messages appear like you're proxying DSM and have it included in the redirect / forward auth flow. I have to sleep, but it seems strange that you'd include that if you're using OIDC.

[DJBenson]

This might be a quirk of how I have it set up then (or it might be wrong, but not to drive this point too much, it was working previously).

If I hit cloud.mydomain.uk I get redirected to auth.mydomain.uk and can login successfully via the Authelia login page. I then get redirected to the DSM login page where I can either log in with local/LDAP credentials or using OIDC. Here I select OIDC and I get the Authelia confirmation, and then it redirects to this error whereas it previously redirected to my session in DSM.

My NPM config is the standard affair from the docs;

include /snippets/authelia-location.conf;

location / {
include /snippets/proxy.conf;
include /snippets/authelia-authrequest.conf;
proxy_pass $forward_scheme://$server:$port;
}

I'm happy to be told it's been wrong all this time if I can learn how to do it correctly - the idea behind the current method is that I do not expose DSM's login system directly to the internet without going through Authelia first - I just don't trust it (DSM), whether that's right or rational is for another day 😉

Enjoy the sleep, thanks for the help and kudos for the latest release, I was so happy to get credential management!

[DJBenson]

I temporarily removed the NPM config so DSM was exposed directly and it still throws the same error so possibly a red herring (all done in incognito mode to avoid cached results).

[james-d-elliott]

Can't recall if I asked you to try this adjustment to the server config. If you're not using caddy/traefik please let me know and give this a shot if you are.

server:
  endpoints:
    authz:
      forward-auth:
        implementation: 'ForwardAuth'
        authn_strategies:
          - name: 'HeaderProxyAuthorization'
            schemes:
              - 'Basic'
          - name: 'CookieSession'

[DJBenson]

I'm using nginxproxymanager. There's a couple of comments in the thread where I post my config but also disabled it and it made no difference.

[james-d-elliott]

Are you using the new /api/authz endpoint?

[DJBenson]

Almost certainly not if it's a recent change. Let me RTFM and come back if I still have issues.

[james-d-elliott]

Instead of /api/verify I meant.

[DJBenson]

I'll be honest, I'm a bit lost now. I've put the endpoints in my Authelia config file and updated my npm snippet to use the /api/authz endpoint but I now get a 500 error.

[lbalogh]

I'm interested if you find a solution, because I have the same issue.

It may have stopped working after a specific 4.38 beta update of Authelia, but as I recently did several changes to my environment (Authelia beta updates then 4.38 official update, DSM update, some DNS changes) it's nearly impossible for me to track when it stopped working. As DSM "remembered" me I didn't see the issue immediately.

Fact is, I completed Authelia 4.38 migration (I started from a fresh DB, all warnings in the config file corrected, adjusted the config file for authz / session multi domain, etc.)

[DJBenson]

If you open the logs on DSM and search for SSO you will see when you last successfully authenticated. In my case it was 03/03 so about two weeks ago so I'm 99% sure something in Authelia changed as I've not applied any updates to DSM in my environment.

Still looking into it.

[lbalogh]

Unfortunately my DSM logs were purged so I have no history. I'm also also looking into it and I'll update this post with my findings, if any

[DJBenson]

So I didn't have the endpoints in my Authelia configuration. I've added them as per the docs and, aside from getting a "dangerous site" alert from Chrome, the result is the same, the "not privilege" error. Proxmox and Portainer (both using OIDC) work still.

[james-d-elliott]

If there is a logged error that indicates that is the fix then yes.

[lbalogh]

Sure here is the error I get without the token_endpoint_auth_method: client_secret_post option :

app-1    | time="2024-03-26T19:45:57+01:00" level=error msg="Access Request failed with error: Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The request was determined to be using 'token_endpoint_auth_method' method 'client_secret_post', however the OAuth 2.0 client registration does not allow this method. The registered client with id 'synology-dsm' is configured to only support 'token_endpoint_auth_method' method 'client_secret_basic'. Either the Authorization Server client registration will need to have the 'token_endpoint_auth_method' updated to 'client_secret_post' or the Relying Party will need to be configured to use 'client_secret_basic'." method=POST path=/api/oidc/token remote_ip=192.x.x.x stack="github.com/authelia/authelia/v4/internal/handlers/handler_oidc_token.go:25                   OpenIDConnectTokenPOST\ngithub.com/authelia/authelia/v4/internal/middlewares/http_to_authelia_handler_adaptor.go:114 handleRouter.NewHTTPToAutheliaHandlerAdaptor.func25\ngithub.com/authelia/authelia/v4/internal/middlewares/bridge.go:54                            handleRouter.(*BridgeBuilder).Build.func16.1\ngithub.com/authelia/authelia/v4/internal/middlewares/headers.go:91                           SecurityHeadersNoStore.func1\ngithub.com/valyala/fasthttp@v1.52.0/userdata.go:57                                           (*userData).Get\ngithub.com/authelia/authelia/v4/internal/middlewares/headers.go:30                           SecurityHeadersBase.func1\ngithub.com/authelia/authelia/v4/internal/middlewares/cors.go:216                             handleRouter.(*CORSPolicy).Middleware.func26\ngithub.com/fasthttp/router@v1.5.0/router.go:441                                              (*Router).Handler\ngithub.com/authelia/authelia/v4/internal/middlewares/log_request.go:14                       handleRouter.LogRequest.func40\ngithub.com/authelia/authelia/v4/internal/middlewares/errors.go:38                            RecoverPanic.func1\ngithub.com/valyala/fasthttp@v1.52.0/server.go:2374                                           (*Server).serveConn\ngithub.com/valyala/fasthttp@v1.52.0/workerpool.go:224                                        (*workerPool).workerFunc\ngithub.com/valyala/fasthttp@v1.52.0/workerpool.go:196                                        (*workerPool).getCh.func1\nruntime/asm_amd64.s:1695                                                                     goexit"

[james-d-elliott]

Yeah it makes sense to add it, welcome to make a PR or I'll get to it at some stage too. Had planned to do some reorganization in that area later this week.

[lbalogh]

Thanks @james-d-elliott I tried to make a PR

[DJBenson]

I've reported the issue to Google and it's already been resolved, I'm no longer getting the error.

Thanks for identifying the cause of the error logging in.

[myevit]

I have same issue with Azure