Error setting up ldap backend
I have an issue setting up an LDAP server in 2.1-BETA0 (amd64) built yesterday.
I filled in the form with exactly the same settings from 2.0 and saved, but after clicking on "Select" to pick up auth containers the GUI becomes unresponsive for some minutes then "Could not connect to the LDAP server. Please check your LDAP configuration.".
php: /system_usermanager_settings_ldapacpicker.php: ERROR! ldap_get_user_ous() could not bind to server .
eri-- last edited by
The user you have used to authenticate to LDAP is wrong.
Check the password of that user and it should behave correctly.
I wish the password was wrong, but I can connect w/o problem on pf 2.0 and also with an ldap browser using the same password.
Isn't something missing in that error, like the server name before the dot?
eri-- last edited by
Can you show the url used to open the window.
You even should have it shown on the opened window or can get it through developers tools in chrome under network settings.
Something is not getting field properly there and the request might be going and trying anon binding.
Here's the URL:
moh10ly last edited by
I had the same issue but I solved it and thought to share it with you guys. I would like just first to explain why this error persists!
When using special characters in passwords which authenticates to the Active Directory in order to retrieve the users unit, These passwords get transmitted html-encodedly.
So for example the password: abc1" becomes abc1&qout; which obviously leads to a failure.
It seems that this bug could be fixed by adding this code to the Active directory plugin " html_decode_entities($password)" according to similar issue I noticed in another forum, just to be honest I'm not good at all with HTML/PHP coding.
so in order to solve your problem, create a user on AD e.g. (Pfsense) and the password is plain simple e.g. (pfsense) no numbers of special characters involved.
test it by clicking Select next to Authentication containers.
The quoting there has other issues actually. If a user has international characters it needs a call to utf8_encode/utf8_decode in various places as well. I'm not sure why it's run through html encoded there, it probably shouldn't be done at that stage, only if the text needs transmitted back to the user in the GUI somewhere.