guide on configuring freeradius 3 LDAP

[Nathan Ward]

> On 19/01/2018, at 6:33 PM, Douglas C Ward <douglas at ugutech.com> wrote:
> 
> Answers below...
> 
>> On Jan 18, 2018, at 9:20 PM, Nathan Ward <lists+freeradius at daork.net> wrote:
>> 
>>> 
>>> On 19/01/2018, at 3:37 PM, Douglas C Ward <douglas at ugutech.com> wrote:
>>> 
>>> 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-Virtual-LDAP-Service#virtualdn <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.
>> 
>> I notice that you’re using 389 which is non-encrypted - once you get that working, probably a good idea to try ldaps if it’s over the Internet - first though, get 389 working before adding in that complexity..
> 
> With the LDAP Admin Tool, it works with port 636 doing SSL/TLS too. I will be making the production connection use that, as soon as I get the non SSL/TLS 389 to work.

Great.

>>> And I’ve been very careful to put those in correctly. I’ve also used the admin credentials with ldapsoft.com <http://ldapsoft.com/> <http://ldapsoft.com/ <http://ldapsoft.com/>> <http://ldapsoft.com/ <http://ldapsoft.com/> <http://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.
>> 
>> Can you try your manual client with the same filter? (uid=dward at iacollaborative.com <mailto:uid=dward at iacollaborative.com> <mailto:uid=dward at iacollaborative.com <mailto:uid=dward at iacollaborative.com>><mailto:uid=dward at iacollaborative.com <mailto:uid=dward at iacollaborative.com> <mailto:uid=dward at iacollaborative.com <mailto:uid=dward at iacollaborative.com>>>)?
>> 
>> They seem to want to use cn=username at domain rather than uid=username at domain. The uid attribute appears to be the same as uidNumber when I had a look at the OneLogin docs. I don’t know that that’s causing your problem - but it probably doesn’t help.
> 
> I tried with substituting uid= for cn= in LDAP Admin Tool, and it doesn’t like like it, saying the credentials are invalid.

I don’t really know what you’re putting in to that "LDAP Admin Tool” so I can’t say for sure, but it sounds like you’re changing the bind credentials rather than the filter, which is not what I said to do.

The admin binding is working fine - we can see this from your logs. This means that your cn=admin at whatever authentication is fine.

To avoid confusion, let’s avoid that LDAP Admin Tool thing as GUIs are terrible for communicating this sort of thing. Run these commands - they will prompt for the password for your *admin* user - NOT for the dward user:

$ ldapsearch -h ldap.us.onelogin.com -x -D 'cn=admin at iacollaborative.com,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(uid=dward at iacollaborative.com)’
$ ldapsearch -h ldap.us.onelogin.com -x -D 'cn=admin at iacollaborative.com,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' ‘(cn=dward at iacollaborative.com)'

What you are looking for here is a successful response - I suspect the second will return 1 result, the first will return 0 results (but not an error). Please paste the results of BOTH of these commands here.

>> If you can get the search to work with cn=, and uid= doesn’t work in your client, you want to update the “filter” parameter under “user” in mods-available/ldap.
> 
> and I tried changing the uid= for cn= in the filter section of the mods-available/ldap file, no dice.
> 
> On the OneLogin server, it shows a successful VLDAP login for the admin user admin at iacollaborative.com <mailto:admin at iacollaborative.com> <mailto:admin at iacollaborative.com <mailto:admin at iacollaborative.com>> every attempt, but nothing for the dward@ user.


What *should* happen, is the admin user will perform a search using the filter to find an appropriate DN. Then, that DN is used for a new bind (LDAP login) with the supplied password.
In your case, the search for that DN does not appear to be completing.

With the output of the above ldap search commands, you can do subsequent binds as the DN returned by the search - but let’s get the ldapsearches working first.

--
Nathan Ward