On Jan 18, 2018, at 5:57 PM, Douglas C Ward <douglas@ugutech.com> wrote:
here’s the full debug, along with the results of my radtest (passwords removed to protect the innocent)…
...
# Loaded module rlm_ldap # Loading module "ldap" from file /usr/local/Cellar/freeradius-server/3.0.15/etc/raddb/mods-enabled/ldap ldap { server = "ldap.us.onelogin.com" identity = "cn=admin@iacollaborative.com,dc=iacollaborative,dc=onelogin,dc=com" password = <<< secret >>>
Does that account have permission to read the user entries in LDAP?
... (0) ldap: Performing search in "dc=iacollaborative,dc=onelogin,dc=com" with filter "(uid=dward@iacollaborative.com)", scope "sub" (0) ldap: Waiting for search result... (0) ldap: ERROR: Failed performing search: Please set 'chase_referrals=yes' and 'rebind=yes'. See the ldap module configuration for details.
That message has been cleaned up in 3.0.16. It only applies to Active Directory. So if you're not running Active Directory, the message indicates an error, but the wrong solution. What it really means is that FreeRADIUS queried LDAP for the user, and got a weird "operations error" in response. This has one meaning in Active Directory. It has a different meaning for other LDAP servers. So... the solution is to ensure that you're (a) using the right identity to query LDAP, and (b) you're querying the right part of the LDAP tree. While the error *is* being shown to you by FreeRADIUS, it's the LDAP server that is choosing to deny FreeRADIUS access. So you somehow have to convince FreeRADIUS to send LDAP the right magic so that LDAP lets you in. Alan DeKok.