On Jan 21, 2018, at 10:41 PM, Nathan Ward <lists+freeradius@daork.net> wrote:
On 22/01/2018, at 7:30 AM, Douglas C Ward <douglas@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@iacollaborative.com <mailto:cn=admin@iacollaborative.com>,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(uid=dward@iacollaborative.com <mailto:uid=dward@iacollaborative.com>)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree # filter: (uid=dward@iacollaborative.com <mailto:uid=dward@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@iacollaborative.com <mailto:cn=admin@iacollaborative.com><mailto:cn=admin@iacollaborative.com <mailto:cn=admin@iacollaborative.com>>,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' ‘(cn=dward@iacollaborative.com <mailto:cn=dward@iacollaborative.com> <mailto:cn=dward@iacollaborative.com <mailto:cn=dward@iacollaborative.com>>)’
testserver:~ testadmin$ ldapsearch -h ldap.us.onelogin.com <http://ldap.us.onelogin.com/> -x -D 'cn=admin@iacollaborative.com <mailto:cn=admin@iacollaborative.com>,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(cn=dward@iacollaborative.com <mailto:cn=dward@iacollaborative.com>)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree # filter: (cn=dward@iacollaborative.com <mailto:cn=dward@iacollaborative.com>) # requesting: ALL #
# dward@iacollaborative.com <mailto:dward@iacollaborative.com>, users, iacollaborative.onelogin.com <http://iacollaborative.onelogin.com/> dn: cn=dward@iacollaborative.com <mailto:cn=dward@iacollaborative.com>, ou=users, dc=iacollaborative, dc=onelogin, d c=com gidNumber: 113412 cn: dward@iacollaborative.com <mailto:dward@iacollaborative.com> mail: dward@iacollaborative.com <mailto:dward@iacollaborative.com> loginShell: /bin/bash homeDirectory: /Users/dward@iacollaborative.com <mailto:Users/dward@iacollaborative.com> givenName: Douglas uid: 35638419 surname: Ward username: dward@iacollaborative.com <mailto:dward@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@iacollaborative.com,ou=users,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(cn=dward@iacollaborative.com)’ dn
The result should have a success in there, and should say somewhere: dn: cn=dward@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.
testserver:~ testadmin$ ldapsearch -h ldap.us.onelogin.com -x -D 'cn=dward@iacollaborative.com,ou=users,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(cn=dward@iacollaborative.com)’ dn
<blah blah blah> ldapsearch -h ldap.us.onelogin.com -x -D 'cn=dward@iacollaborative.com,ou=users,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(cn=dward@iacollaborative.com)’ dn -bash: syntax error near unexpected token `(' testserver:~ testadmin$ ldapsearch -h ldap.us.onelogin.com -x -D 'cn=dward@iacollaborative.com,ou=users,dc=iacollaborative,dc=onelogin,dc=com' -W -s sub -b 'dc=iacollaborative,dc=onelogin,dc=com' '(cn=dward@iacollaborative.com)' dn Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=iacollaborative,dc=onelogin,dc=com> with scope subtree # filter: (cn=dward@iacollaborative.com) # requesting: dn #
# dward@iacollaborative.com, users, iacollaborative.onelogin.com dn: cn=dward@iacollaborative.com, ou=users, dc=iacollaborative, dc=onelogin, d c=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ————— So I see that the dn= result you anticipated is there, but the result still says “result: 0 success” . Let me know if I should try it with the ldap config edit. —Douglas
If it’s all OK..
In mods-enabled/ldap:
identity = 'cn=admin@iacollaborative.com <mailto:cn=admin@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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html