Thanks Alan, good stuff. That user is the main admin user for the whole OneLogin account, so I assume that it has the authority to query the LDAP. I’m following the instructions at https://support.onelogin.com/hc/en-us/articles/206444116-Using-the-OneLogin-... <https://support.onelogin.com/hc/en-us/articles/206444116-Using-the-OneLogin-Virtual-LDAP-Service#virtualdn> where it specifies… Host name ldap.us.onelogin.com Port 389: Use for ldap://. For example, if you are not using SSL, use this port number. This port is primarily provided for your convenience for testing and debugging purposes. 636: Use for ldaps://. For example, if you are using SSL, use this port number. We recommend that you use this port for your production implementation. Base DN dc=<subdomain>,dc=onelogin,dc=com User's Virtual DN cn=<email>,ou=users,dc=<subdomain>,dc=onelogin,dc=com User's Password Password value. And I’ve been very careful to put those in correctly. I’ve also used the admin credentials with ldapsoft.com <http://ldapsoft.com/> ’s LDAP Admin Tool, and my credentials test correctly, and I get a full list of users in the table view. I’m not sure what else to try here. Just curious, what would the error message say if I was on 3.0.16? —Douglas
On Jan 18, 2018, at 7:11 PM, Alan DeKok <aland@deployingradius.com> wrote:
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.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html