That’s not really an error, that’s just the web server responding with 200 OK.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200
Do you have the ldaps:// prefix before the domain name in the LDAP Host field? Use TLS checkbox off? If so, might be an issue with the SSL certificate verification or the LDAP service account credentials.
Yeah I have:
ldaps://dc.domain.name:636
TLS Unchecked
Multiple Search Bases Defined on newlines:
DC=domain,DC=name
OU=admin,DC=domain,DC=name
OU=users,OU=users,DC=domain,DC=name
sAMAccountName
Using a domain admin account.
The cert is in trusted and has the following OIDs for eku:
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Hm, I can’t reproduce any issues with LDAP logins; I’m testing against an openldap server running on Ubuntu 16.04 LTS, with an SSL cert configured and using LDAPS on port 636.
ldaps://directory.example.edu:636
ubuntu@directory-1:~$ slapd -V
@(#) $OpenLDAP: slapd (Ubuntu) (Jul 26 2019 17:28:04) $
buildd@lgw01-amd64-011:/build/openldap-uwbnfG/openldap-2.4.42+dfsg/debian/build/servers/slapd
Where any changes made to your LDAP server? Can you try using all lowercase in your LDAP config fields in Authorizer?
If still not working, you can try tracing (either using xdebug, or inserting some error_log(print_r($variable,true)); statements) the ldap authentication routine in authorizer and let us know if you get further details:
https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/class-authentication.php#L501
I think the Windows admins ran updates. It’s working great with ldap to a different DC so I think I’ll stick with that for now. I’ll update after continuing to work on it. Thanks for your help.
As there has been no activity on this ticket, and it looks resolved, I am going to go ahead and mark it as such. Please let us know if further assistance is required!
