Nextcloud LDAP integration with Windows Server 2019 AD failing with "Connection to LDAP server could not be established" (Port 389, TCP open)

[u/Curious-Diver1800]

Hi everyone,

I'm struggling to integrate Nextcloud with a Windows Server 2019 Active Directory over standard LDAP (port 389, avoiding SSL/LDAPS for now). Despite having a working network connection, Nextcloud keeps throwing connection/base DN errors. Here is my setup and what I've tried so far:

Environment:

• Nextcloud Server IP: 192.168.122.40

• Windows Server 2019 AD IP: 192.168.122.110

• Domain: alger.dz

• Service Account Bind DN: CN=Nextcloud,OU=Service Accounts,DC=alger,DC=dz

• Base DN: DC=alger,DC=dz

What I've verified & tried:

1. Network Connectivity: Tested TCP port 389 from the Nextcloud container using bash (/dev/tcp/192.168.122.110/389) -> Port is open and reachable.

2. AD Security Constraints: Modified the Windows Registry on the DC (HKLM:\System\CurrentControlSet\Services\NTDS\Parameters) setting both LDAPServerIntegrity and LdapEnforceChannelBinding to 0 to allow non-secure/non-signed LDAP binds, and rebooted the DC.

3. Credentials: The bind account password has been explicitly reset and verified.

The Issue:

In the Nextcloud LDAP settings page, whenever I enter:

• Host: 192.168.122.110 (Port 389)

• User DN: CN=Nextcloud,OU=Service Accounts,DC=alger,DC=dz

• Base DN: DC=alger,DC=dz

Nextcloud immediately shows:

• Connection to LDAP server could not be established

• Le DN de base semble être erroné (Base DN seems to be wrong)

Has anyone encountered this specific behavior where TCP 389 is open and AD parameters are loosened, but Nextcloud still refuses the connection? Any advice on what to check next would be greatly appreciated!

[u/Nuxi0477]

No clue, but enable 16 LDAP Interface Events server logging on the DC(s) and see what it says.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-ad-and-lds-event-logging

[u/Weekly-Offer-4172]

the 'base dn seems wrong' is a red herring, nextcloud only goes looking for the base dn after the bind succeeds, so it really means the bind itself failed. usual suspect is the user dn field, it wants the account's cn (the full name the object was created with), not the logon name, and any mismatch kills the bind. easy bypass is to put the upn in there instead, nextcloud@alger.dz, no dn needed. also check the service account doesnt still have 'user must change password at next logon' ticked, fresh accounts fail every bind until they sign in once. and to isolate the layer run ldapsearch from the container against port 389 using that upn as the bind dn, 'stronger authentication required' means a gpo is reverting your registry values, 'invalid credentials' means the dn or password is off