LDAP Authentication / GraphQL error: Cannot return null for non-nullable field ResponseStatus.slug

[flix318]

Hello,

I am encountering an issue when logging in using Active Directory/LDAP, where I receive the following error message:

GraphQL error: Cannot return null for non-nullable field ResponseStatus.slug

I am using Wiki.js version 2.5.303 with Node.js 18.20.2 and PostgreSQL 12.20. Both Wiki.js and PostgreSQL are running in Docker containers based on the images requarks/wiki:canary-2.5.303 and postgres:12.20-alpine3.20. I have also tested the requarks/wiki:canary-2.5.304 image. In the background, I am running additional Docker containers for Elasticsearch and NGINX. The error occurs even when I connect directly to Wiki.js without going through a proxy (NGINX).

I also performed a fresh installation of Wiki.js with only LDAP configured, but the result was the same.

The LDAP URL (ldap://:389), ‘Admin Bind DN’, credentials, search base, and search filter are correct. I have verified the settings using an LDAP browser, so I can rule out any issues with our AD server, especially since other services are successfully using it as well.

The configuration worked previously, but I am still in the evaluation phase of Wiki.js. I suspect the issue might be related to Docker. I can see the request on our firewall, so the connection seems to work, but in the network trace, I see the client receiving an RST, ACK from the LDAP server. However, there are no error messages logged on the LDAP server.

I suspect the problem is with my Docker installation, specifically that the return connection (ports) is being blocked by the Docker bridge. All containers are in the same network, using the ‘bridge’ driver on the Docker host. I am still searching for the corresponding error message on the Wiki.js server for the GraphQL error but haven’t found anything in the Docker logs.

Currently, I am unsure how to proceed in order to resolve the issue.

Thank you very much for your help.

[seba1204]

Hello,
I have the same issue with a new installation on a Linux server, without docker (and without reverse proxy, either).

I'm on latest node (22.9.0), wikiJS 2.5.304, Postgreql 16.4, Ubuntu 24.04

[floridop]

I get the same error in a rootless podman-compose container modified according to documentation

this happens only on with valid username, which is odd, seems that there is a query and the results are returned. It happens also with a wrong password, so my guess is that something is missing in GraphQL library or something is not returned by the LDAP query (maybe because FreeIPA does not have all the attributes that AD has?)

but podman-compose logs do not show anything relevant, is there any way to see what is happening when using LDAP? The instructions on the website do not do anything (https://docs.requarks.io/auth/ldap#troubleshooting) so I am guessing the problem is somewhere else in JS even before the query is sent via any ldap library, but since the error only happens on valid users it cannot be the case - some valid data has been returned somewhere, but no relevant logs.

OS: AlmaLinux release 10.2 (Lavender Lion)
podman: 5.8.2
podman-compose: 1.5.0
In the podman compose definition:
wikijs: image: ghcr.io/requarks/wiki:2 -> Wiki.js 2.5.314, Nodejs 24.15.0
postgresql: postgres:15-alpine -> 15.18
LDAP: FreeIPA (not native windows AD)

the configuration contains offline = yes because I don't really want the system to access the network unless is strictly needed. But I tried commenting out and the error is the same.
Local database login works as expected.

Connection credentials against the LDAP server should be fine, I tested on another machine, I do not have ways to install any ldapsearch tool inside the wikijs container as far as I can see without rebuilding it myself.

Network is working as it should (dns and firewall are ok as far as I can see, the machine itself can connect to ldap just fine via sssd and get all the users.

This is now a major showstopper for us to use this system. There is a chance to perform authentication via SAML or Oauth at some point, but not now.

Thanks for making this available for everyone anyway!

[floridop]

Update 1: I managed to authenticate a user:

• a better fine-grained search base dn:
  cn=users,cn=accounts,dn=my,dn=own,dn=domain
• by unchecking/disabling "Map Groups"
• by checking "Allow self registration" apparently this is how the system adds automatically new users (see LDAP Auth "You are not authorized to login" #7363)

After this the user could not access any page. So I went back and decided to assign the identity to the default group guests. After enabling that, the system stopped authenticating it. So I deleted the user, and now the system decided it does not want to authenticate it anymore. In the logs:

2026-07-28T14:33:02.333Z [MASTER] warn: Failed to refresh token for user undefined: Not found.
2026-07-28T14:33:02.333Z [MASTER] warn: An unexpected error occured during login.
2026-07-28T14:33:02.591Z [MASTER] warn: Failed to refresh token for user undefined: Not found.
2026-07-28T14:33:02.591Z [MASTER] warn: An unexpected error occured during login.
2026-07-28T14:33:26.364Z [MASTER] warn: Failed to refresh token for user undefined: Not found.
2026-07-28T14:33:26.364Z [MASTER] warn: An unexpected error occured during login.

somewhat looks like the database is corrupted. This happened also after a podman-compose down and podman-compose up -d

So now on to next debugging...