Open pmcaulay opened 3 years ago
I tested this on icingaweb2 2.8.2 with three different LDAP resources: one which requires authentication (IBM Directory Server), another that does allow anonymous binds (OpenLDAP), and Windows Active Directory, and everything now works as expected.
Hi,
I also took a quick look at this, because I wondered why you come here with this now. That part of the code is ancient. :sweat_smile:
I know we had a reason for requiring an anonymous connection to be used for the capability query. Why we didn't had one for the ActiveDirectory connection.. I have no idea.
Is there maybe a chance that the user that's being entered into the form cannot access the root DSE albeit an anonymous connection can? There's an error case for that after all: https://github.com/Icinga/icingaweb2/blob/da950c8559c13deb6977dbee588ce3155ae9c522/library/Icinga/Protocol/Ldap/LdapCapabilities.php#L343
I agree it may be an edge case; I don't control the LDAP servers in question 😁 The bind user can access rootDSE but anonymous connections just return "Invalid credentials". Possibly related: https://www.ibm.com/support/pages/directory-server-does-not-return-rootdse-entries-anonymously
When setting up an LDAP user provider I came across this issue. Our LDAP servers disallow anonymous binds, and this makes the LDAP capability query fail. This means you can successfully configure and validate an LDAP resource (although it will say "Schema discovery not possible: Capability query failed") but not actually set up a user/group back-end using that resource.
Some debugging lead me to the following code in discoverCapabilities():
https://github.com/Icinga/icingaweb2/blob/da950c8559c13deb6977dbee588ce3155ae9c522/library/Icinga/Protocol/Ldap/LdapCapabilities.php#L310
I believe we should try to bind here like we do in discoverAdConfigOptions().