guide on configuring freeradius 3 LDAP

[Nathan Ward]

> On 22/01/2018, at 7:30 AM, Douglas C Ward <douglas at ugutech.com> wrote:
> 
> Hi Nathan,
> 
> Results are posted below…

<blah>

> testserver:~ testadmin$ 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>)'
> Enter LDAP Password: 
> # extended LDIF
> #
> # LDAPv3
> # base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree
> # filter: (uid=dward at iacollaborative.com <mailto: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/> <http://ldap.us.onelogin.com/ <http://ldap.us.onelogin.com/>> -x -D 'cn=admin at iacollaborative.com <mailto:cn=admin at iacollaborative.com><mailto: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> <mailto:cn=dward at iacollaborative.com <mailto:cn=dward at iacollaborative.com>>)’
> 
> 
> testserver:~ testadmin$ 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>)'
> Enter LDAP Password: 
> # extended LDIF
> #
> # LDAPv3
> # base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree
> # filter: (cn=dward at iacollaborative.com <mailto:cn=dward at iacollaborative.com>)
> # requesting: ALL
> #
> 
> # dward at iacollaborative.com <mailto:dward at iacollaborative.com>, users, iacollaborative.onelogin.com <http://iacollaborative.onelogin.com/>
> dn: cn=dward at iacollaborative.com <mailto:cn=dward at iacollaborative.com>, ou=users, dc=iacollaborative, dc=onelogin, d
> c=com
> gidNumber: 113412
> cn: dward at iacollaborative.com <mailto:dward at iacollaborative.com>
> mail: dward at iacollaborative.com <mailto:dward at iacollaborative.com>
> loginShell: /bin/bash
> homeDirectory: /Users/dward at iacollaborative.com <mailto:Users/dward at iacollaborative.com>
> givenName: Douglas
> uid: 35638419
> surname: Ward
> username: dward at iacollaborative.com <mailto: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

OK, thanks for that.

So this tells us several things.
1) Your admin credentials are correct (though we can actually improve this, more later)
2) You need to use “cn=“ and not “uid=“ in the filter.
3) You must do user binds, rather than pull a userPassword attribute from LDAP, as the userPassword attribute is not visible even to the admin. This means that you can only use RADIUS for auth when you have a User-Password attribute - i.e. CHAP etc. will not work.
4) The OneLogin LDAP seems to work OK.. but one more test.

This time, type your “dward” password, *not* the admin password.
$ ldapsearch -h ldap.us.onelogin.com -x -D 'cn=dward at iacollaborative.com,ou=users,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(cn=dward at iacollaborative.com)’ dn

The result should have a success in there, and should say somewhere:
dn: cn=dward at iacollaborative.com,ou=users,dc=iacollaborative,dc=onelogin,dc=com

If so, we have done a successful "User Bind” - these are almost exactly the same protocol steps as FreeRADIUS will do (actually slightly more), which means OneLogin is working great.
If not, post the command and response as you did above, and don’t do anything else.



If it’s all OK..

In mods-enabled/ldap:

identity = 'cn=admin at iacollaborative.com <mailto:cn=admin at iacollaborative.com>,dc=iacollaborative,dc=onelogin,dc=com'
password = <cn=admin pass>
base_dn = 'dc=iacollaborative,dc=onelogin,dc=com’

user {
  filter = “(cn=%{%{Stripped-User-Name}:-%{User-Name}})”
  scope = sub
}


In your “authorize” section, probably at the end:
authorize {
<blah blah>
        if (User-Password) {
            update control {
                Auth-Type := ldap
            }
        }
}


Then every request, FreeRADIUS will:
1) As the cn=admin LDAP user do a search with the filter to find a DN matching the user, and return whatever attributes you configure LDAP to search for (i.e. radiusReplyItem etc.). It will not set control:Password-With-Header as there is no userPassword attribute returned from LDAP.
2) If there is a User-Password attribute set (i.e. in the Access-Request), then set Auth-Type to ldap. This will cause FreeRADIUS to do a new auth (bind) to the LDAP server, as the DN found in the above search, using the password that FreeRADIUS has in User-Password.
3) Return accept if the bind is successful.

Again - there are 2 LDAP binds here. One as admin & searching for the DN to bind as, another binding as that DN to test the password.

Have a crack at that, and if that doesn’t work still, give us a *full* radiusd -X again so we can see the config etc. - don’t just say “no dice” :-)




Further things - perhaps when you have the above working:

It’s probably not a good idea to use cn=admin. The “bind_dn” only really needs to be an LDAP user who can see the attributes you want to return from LDAP - it does not need to see passwords (and in OneLogin cn=admin can’t, anyway). If you don’t want any attributes, you only need an LDAP user which can search for DNs in the tree. I presume that cn=admin can modify users which is not a great thing to spread around.

It’d be ideal if you could create a new “radius” user which can search LDAP but *not* see attributes it shouldn’t need to, and then configure that in place of cn=admin.

--
Nathan Ward