LDAP authentication error with 3rd party providers

[justinhschaaf]

What happened

Hello! I've gone ahead and configured authentication with LDAP as described in the documentation for Moonraker and Fluidd. Now, whenever I try to sign in using my LDAP credentials, Fluidd shows an "Invalid credentials" error message, and Moonraker's logs show an error 401 with the message "[No User]". I've manually updated Fluidd, Moonraker, and Klipper to the latest versions as described in Fluidd's documentation to no avail.

The LDAP server I'm trying to authenticate through is Authentik's LDAP outpost, which I've verified is working properly through manual queries with the ldapsearch command and by configuring it with another application (OPNsense). I can also see Moonraker properly querying the server in its logs.

Client

Fluidd

Browser

Chrome, Firefox

How to reproduce

Assuming you already have working Moonraker, Fluidd, and Authentik instances:

1. Setup an LDAP in provider as described here.

   • I personally use Authentik with authentik-nix, which you can view my full configuration for here. The environment file for authentik-ldap has the AUTHENTIK_HOST, AUTHENTIK_TOKEN, and AUTHENTIK_INSECURE variables provided when viewing the outpost in Authentik.

2. Update moonraker.conf, adding a [ldap] section pointing to the Authentik outpost and updating [authorization] to force logins and default to LDAP.

   • The user filter is optional. This should make it so users must have the iam-fluidd group to authenticate. The issue still occurs without this being declared.

   [ldap]
   ldap_host: [LDAP IP ADDRESS]
   ldap_port: 389
   ldap_secure: False
   base_dn: dc=ldap,dc=goauthentik,dc=io
   bind_dn: [SERVICE ACCOUNT USERNAME]
   bind_password: [SERVICE ACCOUNT PASSWORD]
   user_filter: (&(objectClass=user)(cn=USERNAME)(memberOf=cn=iam-fluidd,ou=groups,dc=ldap,dc=goauthentik,dc=io))
   
   [authorization]
   force_logins: True
   default_source: ldap
   cors_domains:
   ...

3. Restart Moonraker with systemctl restart moonraker. Navigate to your Fluidd instance in your web browser of choice and try signing in using your Authentik/LDAP account credentials.

Additional information

moonraker.log - The login attempts are at the very bottom of the file.

moonraker.conf

Relevant logs in the LDAP server

Error message as seen in Fluidd

[Arksine]

Most of the ldap functionality is contributed. Since I do not use ldap myself I only have a high level understanding of its inner workings. I'm willing to take a look at this, however it would be useful if you can reproduce the issue with verbose logging enabled. Presuming you are on a typical installation, this can be done by adding MOONRAKER_VERBOSE_LOGGING="y" to Moonraker's environment file (<data_folder>/systemd/moonraker.env). The documentation provides further detail. After making the modifications, restart the Moonraker service, reproduce the issue, and attach the log. Thanks.

[justinhschaaf]

Here's the updated log file with verbose logging enabled via the environment variable. I'm definitely not an expert with LDAP either, but I'll do my best to take another close look at this as well when I get some more free time. I really appreciate your help with this, thank you so much!

[Arksine]

After looking at the log I don't see anything that would suggest a bug in the ldap code, so I suspect there is a configuration issue. The group DN shouldn't be part of the user_filter, it should be set in the group_dn option. If it still doesn't work without removing that part I suspect the user_filter is missing something.

Edit:
From authentik's documentation:

All users and groups in authentik's database are searchable. Currently, there is limited support for filters (you can only search for objectClass), but this will be expanded in further releases.

This may be a problem if the ldap server can't filter by cn. In this case, authentik will need to extend its filter support to work with Moonraker.

[justinhschaaf]

I went ahead and removed the group DN from user_filter (using only (&(objectClass=user)(cn=USERNAME)), as per the docs) and kept the group_dn option unset, unfortunately still experiencing the issue.

I realized that error messages were only being sent along with the HTTP response instead of to the output logs, so I checked the browser console and saw the error was LDAP authentication failed, sent from here.

Adding a quick debug message, the ldap3 module throws the error invalid attribute type createTimestamp (I've also seen it mention modifyTimestamp instead). Both are missing from the list of fields set for users in authentik's docs. This is also an issue when using Google's LDAP connector.

I didn't get the chance to look into exactly where ldap3 tries to validate it and runs into the issue; however, when inputting an invalid username, it does return the appropriate error.

I tried adding createTimestamp and modifyTimestamp to the list of attributes not checked by ldap3 (see cannatag/ldap3#557 (comment)) and setting return_empty_attributes in the connection arguments to False, both to no avail. Unless there's a way to have ldap3 not care about these core missing attributes, authentik will probably have to set them for users (or I'll have to see if there's a way to set them manually).

[BastelBaus]

Same error for me for another application (radicale) with authentik. What was the solution, who did you set the attributes in authentik LDAP provider?

[justinhschaaf]

Same error for me for another application (radicale) with authentik. What was the solution, who did you set the attributes in authentik LDAP provider?

Apologies for the slow response, I've been preoccupied with other projects these past couple weeks. I wasn't able to find any clear documentation on setting custom LDAP attributes for all users, As such, I tried modifying the user and adding the following to the Attributes section:

createTimestamp: 20250117114153Z
modifyTimestamp: 20250117114153Z

I also tried the date/time format described here; however, I ran into the same exact error both times. I was able to manually perform the LDAP query and saw the attributes were set though:

I'm absolutely not an expert in LDAP so take my word with a grain of salt, but my guess is that these attributes have an actual date/time type that ldap3 is expecting in addition to the attributes being present in the first place. As the Authentik LDAP Outpost likely can not/does not set the type simply based on what's set as the custom attributes, ldap3 fails in the same way as when they're not set. As per cannatag/ldap3#1017 (comment), these attributes are mandatory to the schema it expects, and you can't really work around it.

There's an open issue to try and get Authentik to support these attributes (goauthentik/authentik#10474), but there hasn't been much movement on it as of writing.

[DanAE111]

I've also been having issues that may be related to this issue i am using Active Directory as a backend provider though. I've done some tests with different configuration options enabled and disabled and it seems based on the Moonraker logs the LDAP authentication succeeds.

My ldap config:

ldap_host: ad.contoso.com
ldap_secure: true

base_dn: DC=ad,DC=contoso,DC=com

bind_dn: {secrets.ldap.credentials.bind_dn}
bind_password: {secrets.ldap_credentials.bind_password}

group_dn: CN=3D Printer Users,OU=Groups,DC=ad,DC=contoso,DC=com

is_active_directory: true

Logs with config as above:

2025-01-23 22:47:30,961 [application.py:_log_debug()] - HTTP Request::POST /access/login::{'username': '<sanitized>', 'password': '<sanitized>', 'source': '<sanitized>'}
2025-01-23 22:47:31,929 [ldap.py:_validate_group()] - LDAP User user group match success, login successful
2025-01-23 22:47:31,936 [application.py:log_request()] - 401 POST /access/login (192.168.7.195) [No User] 980.26ms

Logs with bad credentials:

2025-01-23 22:48:07,865 [application.py:_log_debug()] - HTTP Request::POST /access/login::{'username': '<sanitized>', 'password': '<sanitized>', 'source': '<sanitized>'}
2025-01-23 22:48:08,561 [ldap.py:_perform_ldap_auth()] - LDAP Rebind failed, attempting to validate credentials with new connection.
2025-01-23 22:48:08,883 [application.py:log_request()] - 401 POST /access/login (192.168.7.195) [No User] 1021.59ms

Logs with no group filter:

2025-01-23 22:49:09,237 [application.py:_log_debug()] - HTTP Request::POST /access/login::{'username': '<sanitized>', 'password': '<sanitized>', 'source': '<sanitized>'}
2025-01-23 22:49:10,265 [ldap.py:_validate_group()] - LDAP User user login successful
2025-01-23 22:49:10,278 [application.py:log_request()] - 401 POST /access/login (192.168.7.195) [No User] 1046.61ms

Seems a bit strange that this issue affects three different LDAP providers, something else change somewhere?

Happy to assist with any further testing and provide more logs if required.

[Arksine]

@DanAE111 Your issue does not appear to be the same as described by the OP. I changed the title as its misleading, the [No User] indicator in the log is not an error, it shows the currently logged in user making the request. Login requests typically don't originate from a logged in user, thus they will always indicate [No User] if authentication fails.

The original issue in this post seems to be caused by a third party LDAP provider not supporting the full LDAP spec, thus its an issue with the provider and not Moonraker. As mentioned by BastelBaus, the issue is not exclusive to Moonraker and affects other applications attempting to login with Authentik.

Your log snippets indicate that the provider successfully logs in the user, but authentication fails further downstream. My suspicion is that you are attempting to log in with an LDAP user that shares a username with a previously created local user. This would result in an authentication source mismatch and you will need to delete the local user if you want to login to an LDAP user of the same name.

I pushed a commit that logs the full exception traceback when verbose logging is enabled (as it appears to be in your snippets). You can update, reproduce the error, then attach the resulting log which should be helpful in further diagnosis.

[DanAE111]

@Arksine thanks for the advice you were indeed correct it was because i had an existing local user with the same username i just assumed that because i could select an authentication provider at login the user names clashing wouldn't be an issue.

Possibly worth making a note of that in the docs, would avoid silly people like me making similar mistakes in future.

I'm happy to submit a PR for updating the docs if you like?