Just upgraded to 25.1 and ran into this problem. LDAP bind error [; Can't contact LDAP server].
I have tested the LDAP connection prior to the update and it was still operational.
This happened on 2 machines, one after the other. Where #2 is for backup purposes.
Using the OPNSense tester results in:
The following input errors were detected:
Authentication failed.
error: User DN not found
I checked the connectivity from the console:
nc xx.xx.x.x 389 -v -w 10 and the response is:Connection to xx.xx.x.x 389 port [tcp/ldap] succeeded!
So what is wrong with the upgrade?
Added on Sunday 2-2-2025:
Forgot to mention that this is related to OpenVPN.
I've created for some users a local password, added local database to instance settings of OpenVPN and these users are now able to login.
Just bringing this problem again under attention since there has not been a response thus far.
Is this problem related to https://forum.opnsense.org/index.php?topic=45606.0 (https://forum.opnsense.org/index.php?topic=45606.0)?
It's clear from post 45606.0 that some changes were made regarding the LDAP implementation but possibly I have missed what the consequences are for already existing LDAP users. Do I need to re-create all the existing LDAP users?
Same here. Since upgrading to 25.1 LDAP users cannot login anymore with the error message given in this post.
I have already deleted an LDAP user and recreated it. But still cannot login with it.
Second small update published. So I don't have the feeling this issue is going to get fixed.
@gdur Were you able to solve this somehow?
i have the same issue...
What does your bind DN look like?
like that: `uid=testing-binder,ou=bindUsers,dc=somename,dc=net`
Try cn= instead of uid= ...
well thats wrong, since thats not the bind dn, why should that work, older opnsense versions work with exact same settings. thats not a fix.
I know of no directory that uses uid= in a distinguished name. What directory is this? Active Directory uses cn=xyz,ou=...,dc=domain,dc=com. Hence my suggestion.
The documentation (https://docs.opnsense.org/manual/how-tos/user-ldap.html) uses cn=
My ldap user is CN=LdapQuery,CN=Users,DC=my,DC=domain,DC=name. That's the same it was before the v25 upgrade. The directory behind is an Active Directory.
The same bind DN works perfectly with other applications authenticating against AD.
Quote from: Patrick M. Hausen on April 03, 2025, 04:21:40 PMI know of no directory that uses uid= in a distinguished name. What directory is this? Active Directory uses cn=xyz,ou=...,dc=domain,dc=com. Hence my suggestion.
Quote from: passeri on April 04, 2025, 12:16:23 AMThe documentation (https://docs.opnsense.org/manual/how-tos/user-ldap.html) uses cn=
its rfc2307bis openldap (slapd) and I think I know best which DN my binduser uses in LDAP, it's not as if opnsense is the first software to be connected via it.
No LDAP server was ever slap'd in the making of OPNsense.
If you can tolerate the "breach" of the password for a short amount of time, configure plain text LDAP over port 389 instead of LDAPS over 636 and use something like:
tcpdump -i <interface> -s0 -n -X port 389
to get a full trace of the conversation. That's what I do when new LDAP deployments don't work for obscure reasons.
As far as I understand the capture result the bind is successful, so the ldap user isn't the problem.
However I'm struggling to understand what happens after that other than the disconnect.
IP ending on 1 is Opnsense, 80 is a domain controller. There are more DCs, but for troubleshooting it's the only one I kept active on Opnsense.
The LDAP bind should be followed by an LDAP search request, which it did not in your screen shot. Did you try a full authentication or the "tester" in OPNsense?
Maybe something with base DN, LDAP filter or some such ...
Full authentication, so logged out of the web gui and tried to login with an ldap account.
I assume I can rule out a firewall rule anywhere blocking anything if the connection gets established in general. Between Opnsense there's only the packet filter of Opnsense itself and the personal firewall of the Domain controller (which allows LDAP of course).
Hmmm ... can you try the tester? There must be an LDAP search following the bind ...
No, I'm afraid not, used the tester here. I hope the images are still readable, had to resize them in order to attach them.
Not sure if frame nr. 2 is of any significance.
A note about the configuration page of the LDAP server: The "select" button next to "Authentication containers" works fine and shows me all the entries I'd expect.
I can only emphasize this worked flawlessly until the v25 upgrade. I was used to logging in only with my domain/ldap account, not the local root account. I initiated the upgrade to v25 and right after the reboot I couldn't login anymore.
There were also no changes to the domain controllers.
Just a note: There's also an Apache webserver in the same subnet using LDAP auth for some resources with equal settings - works fine.
That looks like some extra characters in the search string - to which the server probably correctly responds with "NO_OBJECT". Weird.
I'm sorry, I only run LDAP for OpenVPN without issues so I cannot reproduce it easily. I just happen to know LDAP a bit from years of experience with AD, so I chimed in.
I'd file a bug on github.
Thanks for trying to help!
Probably not a bad idea. I opened a bug report: https://github.com/opnsense/core/issues/8541
its not a new deployment, its already used in production on older 24.7 releases.
I planed to upgrade and thats the point where i cant because of an update that bricked something, and i am not alone.
With no encryption I cannot reproduce the problem with our test ldap, hopefully it is clear that you should not use it productively, the productive ldap is LDAPS only.
(https://i.imgur.com/gl0hr9U.png)
with LDAPS im getting exactly the same on our testing LDAP which speaks LDAPS as well as LDAP.
2025-04-14T10:46:48 Error opnsense LDAP bind error [; Can't contact LDAP server]
What do i need to provide so we can debug this more?
I got it to work by emptying the extended query field.
See the linked bug report. It's being further discussed there.
Now THAT's interesting ... thanks for keeping us informed.
I just had to check - I do use extended query and I do not experience your problem. I use it to limit access to a particular group by matching "memberOf". But I did not put an outer pair of parentheses in the field. Want to try using just "objectClass=person"?
Parenthesis shouldn't matter here as sooner or later the query parts are wrapped in extra parenthesis in order to construct the full search string. Apparently case also wasn't the issue so this remains a bit elusive...
Cheers,
Franco
Good ideas.
I did some further tests. Apparently whatever I enter in there will not work if there are outer parenthesis.
So this will not work:
(&(condition1)(condition2))
This does work:
&(condition1)(condition2)
If the OPNsense code adds another pair of outer parentheses, probably "(filter)" is valid while "((filter))" is not. I could not find a full spec, i.e. EBNF just right now. The LDAP RFC hand simply refers to X.500 and ASN.1, unfortunately, and I'm not going down that rabbit hole just now.
I made a note here because some claims regarding wrong defaults and unclear documentation were made... https://github.com/opnsense/core/issues/8541#issuecomment-2808614328
I added some explanation to what is probably going on.