guide on configuring freeradius 3 LDAP

[Douglas C Ward]

Hi Nathan,

Results are posted below...

> On Jan 19, 2018, at 7:16 PM, Nathan Ward <lists+freeradius at daork.net> wrote:
> 
>> 
>> 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/>>> <http://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>>><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 <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 <http://ldap.us.onelogin.com/> -x -D 'cn=admin at iacollaborative.com <mailto: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 <mailto:uid=dward at iacollaborative.com>)’

testserver:~ testadmin$ 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)'
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree
# filter: (uid=dward at iacollaborative.com)
# requesting: ALL
#

# search result
search: 2
result: 1 Operations error
matchedDN: DC=OneLogin

# numResponses: 1

> $ ldapsearch -h ldap.us.onelogin.com <http://ldap.us.onelogin.com/> -x -D 'cn=admin at iacollaborative.com <mailto: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 <mailto:cn=dward at iacollaborative.com>)’


testserver:~ testadmin$ 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)'
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree
# filter: (cn=dward at iacollaborative.com)
# requesting: ALL
#

# dward at iacollaborative.com, users, iacollaborative.onelogin.com
dn: cn=dward at iacollaborative.com, ou=users, dc=iacollaborative, dc=onelogin, d
 c=com
gidNumber: 113412
cn: dward at iacollaborative.com
mail: dward at iacollaborative.com
loginShell: /bin/bash
homeDirectory: /Users/dward at iacollaborative.com
givenName: Douglas
uid: 35638419
surname: Ward
username: dward at iacollaborative.com
name: Douglas Ward
objectClass: top
objectClass: inetOrgPerson
objectClass: ldapsubentry
objectClass: subentry
uidNumber: 35638419
memberOf: cn=staff,cn=groups,dc=iacollaborative,dc=onelogin,dc=com
memberOf: cn=All Staff,cn=roles,dc=iacollaborative,dc=onelogin,dc=com
memberOf: cn=IA Employees,cn=roles,dc=iacollaborative,dc=onelogin,dc=com
samaccountname:

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

> 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>> <mailto: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
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <http://www.freeradius.org/list/users.html>