guide on configuring freeradius 3 LDAP

Nathan Ward lists+freeradius at
Mon Jan 22 05:41:17 CET 2018

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


> testserver:~ testadmin$ ldapsearch -h <> -x -D 'cn=admin at <mailto:cn=admin at>,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(uid=dward at <mailto:uid=dward at>)'
> Enter LDAP Password: 
> # extended LDIF
> #
> # LDAPv3
> # base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree
> # filter: (uid=dward at <mailto:uid=dward at>)
> # requesting: ALL
> #
> # search result
> search: 2
> result: 1 Operations error
> matchedDN: DC=OneLogin
> # numResponses: 1
>> $ ldapsearch -h <> < <>> -x -D 'cn=admin at <mailto:cn=admin at><mailto:cn=admin at <mailto:cn=admin at>>,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' ‘(cn=dward at <mailto:cn=dward at> <mailto:cn=dward at <mailto:cn=dward at>>)’
> testserver:~ testadmin$ ldapsearch -h <> -x -D 'cn=admin at <mailto:cn=admin at>,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(cn=dward at <mailto:cn=dward at>)'
> Enter LDAP Password: 
> # extended LDIF
> #
> # LDAPv3
> # base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree
> # filter: (cn=dward at <mailto:cn=dward at>)
> # requesting: ALL
> #
> # dward at <mailto:dward at>, users, <>
> dn: cn=dward at <mailto:cn=dward at>, ou=users, dc=iacollaborative, dc=onelogin, d
> c=com
> gidNumber: 113412
> cn: dward at <mailto:dward at>
> mail: dward at <mailto:dward at>
> loginShell: /bin/bash
> homeDirectory: /Users/dward at <mailto:Users/dward at>
> givenName: Douglas
> uid: 35638419
> surname: Ward
> username: dward at <mailto:dward at>
> 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 -x -D 'cn=dward at,ou=users,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(cn=dward at’ dn

The result should have a success in there, and should say somewhere:
dn: cn=dward at,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 <mailto:cn=admin at>,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

More information about the Freeradius-Users mailing list