Authentication and Authorization
Hello- If I have both LDAP and Proxy configured will FreeRadius use both? What I am looking for is the FreeRadius server authorize a user in LDAP and if that passes forward the user to the upstream OTP radius server (via proxy.conf) for authentication. I believe its doing this now with the LDAP module, just authenticating locally, rather than proxied. Is this possible? Thanks, Alex
Yes, see this tutorial: https://www.wikidsystems.com/support/wikid-support-center/how-to/how-to-add-.... Note that you login with the username and OTP. No ldap password is needed. HTH, Nick On Tue, Sep 30, 2014 at 3:18 PM, Alex Gregory <alex@c2company.com> wrote:
Hello-
If I have both LDAP and Proxy configured will FreeRadius use both? What I am looking for is the FreeRadius server authorize a user in LDAP and if that passes forward the user to the upstream OTP radius server (via proxy.conf) for authentication. I believe its doing this now with the LDAP module, just authenticating locally, rather than proxied.
Is this possible?
Thanks,
Alex
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication
Thank you for the link. I have the OTP working on a test server now with proxying. The problem is the hosted OTP server does not supply any group or attribute information back yet like this Wikid server does. But I have two different user groups for two different networks (Corp and Dev users) that need to be differentiated. In production have two virtual radius servers each doing an LDAP lookup into a different group. If a user tries to access the incorrect network they are denied because they are not in that group. Works great. If I alter the server to proxy the request with the LDAP module configured will it handle things properly? Thanks, Alex On Sep 30, 2014, at 2:02 PM, Nick Owen <owen.nick@gmail.com> wrote:
Yes, see this tutorial: https://www.wikidsystems.com/support/wikid-support-center/how-to/how-to-add-.... Note that you login with the username and OTP. No ldap password is needed.
HTH,
Nick
On Tue, Sep 30, 2014 at 3:18 PM, Alex Gregory <alex@c2company.com> wrote:
Hello-
If I have both LDAP and Proxy configured will FreeRadius use both? What I am looking for is the FreeRadius server authorize a user in LDAP and if that passes forward the user to the upstream OTP radius server (via proxy.conf) for authentication. I believe its doing this now with the LDAP module, just authenticating locally, rather than proxied.
Is this possible?
Thanks,
Alex
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alex Gregory wrote:
Thank you for the link. I have the OTP working on a test server now with proxying. The problem is the hosted OTP server does not supply any group or attribute information back yet like this Wikid server does.
There are no standard RADIUS attributes which carry that information. If you need it, the OTP server may not even be able to send that information in RADIUS.
But I have two different user groups for two different networks (Corp and Dev users) that need to be differentiated.
In production have two virtual radius servers each doing an LDAP lookup into a different group. If a user tries to access the incorrect network they are denied because they are not in that group. Works great. If I alter the server to proxy the request with the LDAP module configured will it handle things properly?
LDAP lookups are completely independent of proxying. If configured correctly, it should work. Alan DeKok.
What might I need it to do to stop processing if a user is not found? Right now its looking in a specific LDAP group, not finding the user but continuing onto the proxy forward. At that point the user is allowed because they match there. I would like it to stop processing to keep users not in the proper LDAP group off the network. rlm_ldap (ldap): Reserved connection (4) (3) ldap : EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) (3) ldap : --> (uid=agregory) (3) ldap : EXPAND ou=corp,ou=Users,dc=team,dc=company,dc=com (3) ldap : --> ou=corp,ou=Users,dc=team,dc=company,dc=com (3) ldap : Performing search in 'ou=corp,ou=Users,dc=team,dc=company,dc=com' with filter '(uid=agregory)', scope 'sub' (3) ldap : Waiting for search result... (3) ldap : Search returned no results rlm_ldap (ldap): Released connection (4) rlm_ldap (ldap): Closing connection (3): Hit idle_timeout, was idle for 1154 seconds rlm_ldap (ldap): You probably need to lower "min" rlm_ldap (ldap): Closing connection (2): Hit idle_timeout, was idle for 1154 seconds rlm_ldap (ldap): You probably need to lower "min" rlm_ldap (ldap): Closing connection (1): Hit idle_timeout, was idle for 1154 seconds rlm_ldap (ldap): You probably need to lower "min" (3) [ldap] = notfound (3) [expiration] = noop (3) [logintime] = noop (3) [pap] = noop (3) } # authorize = updated (3) Proxying request to home server x.x.x.x port 1812 timeout 30.000000 (3) Sending Access-Request packet to host x.x.x.x port 1812, id=40, length=0 (3) Acct-Session-Id = '569705352865596948' (3) Called-Station-Id = '00-18-0A-32-AF-AA:company_Corp' (3) Calling-Station-Id = '80-BE-05-37-1D-7E' (3) Framed-IP-Address = 10.135.136.79 (3) NAS-Identifier = 'Cisco Meraki cloud RADIUS client' (3) NAS-IP-Address = 108.161.147.80 (3) NAS-Port = 0 (3) NAS-Port-Id = 'Wireless-802.11' (3) NAS-Port-Type = Wireless-802.11 (3) Service-Type = Login-User (3) User-Name = 'agregory' (3) User-Password = 'a0qf3g' (3) Event-Timestamp = 'Oct 6 2014 23:42:20 UTC' (3) Realm = 'DEFAULT' (3) Message-Authenticator := 0x00 (3) Proxy-State = 0x32 Sending Access-Request Id 40 from 0.0.0.0:60147 to x.x.x.x:1812 Acct-Session-Id = '569705352865596948' Called-Station-Id = '00-18-0A-32-AF-AA:company_Corp' Calling-Station-Id = '80-BE-05-37-1D-7E' Framed-IP-Address = 10.135.136.79 NAS-Identifier = 'Cisco Meraki cloud RADIUS client' NAS-IP-Address = 108.161.147.80 NAS-Port = 0 NAS-Port-Id = 'Wireless-802.11' NAS-Port-Type = Wireless-802.11 Service-Type = Login-User User-Name = 'agregory' User-Password = 'a0qf3g' Event-Timestamp = 'Oct 6 2014 23:42:20 UTC' Message-Authenticator := 0x00 Proxy-State = 0x32 Waking up in 0.3 seconds. Received Access-Accept Id 40 from x.x.x.x:1812 to 10.11.1.102:60147 length 38 Service-Type = Login-User Class = 0x44656661756c74 Proxy-State = 0x32 Thank you! Alex On Sep 30, 2014, at 6:26 PM, Alan DeKok <aland@deployingradius.com> wrote:
Alex Gregory wrote:
Thank you for the link. I have the OTP working on a test server now with proxying. The problem is the hosted OTP server does not supply any group or attribute information back yet like this Wikid server does.
There are no standard RADIUS attributes which carry that information. If you need it, the OTP server may not even be able to send that information in RADIUS.
But I have two different user groups for two different networks (Corp and Dev users) that need to be differentiated.
In production have two virtual radius servers each doing an LDAP lookup into a different group. If a user tries to access the incorrect network they are denied because they are not in that group. Works great. If I alter the server to proxy the request with the LDAP module configured will it handle things properly?
LDAP lookups are completely independent of proxying.
If configured correctly, it should work.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I assume I do this in the pre-proxy section of the default site? Something like: pre-proxy { ldap if (notfound) { reject } } Thanks again for the help. You guys have definitely gotten me past the last toughest 10% of my configuration dilemmas. Its much appreciated considering I assume you are all doing this in your free time. Thanks, Alex On Oct 7, 2014, at 7:42 AM, Alan DeKok <aland@deployingradius.com> wrote:
Alex Gregory wrote:
What might I need it to do to stop processing if a user is not found?
$ man unlang
You can check the return code of a module.
(3) [ldap] = notfound
Change:
ldap
To:
ldap if (notfound) { reject }
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I apologize… should have tried it first. Not allowed there. Looks like its done in the authorize section. Alex On Oct 7, 2014, at 9:10 AM, Alex Gregory <alex@c2company.com> wrote:
I assume I do this in the pre-proxy section of the default site?
Something like:
pre-proxy { ldap if (notfound) { reject } }
Thanks again for the help. You guys have definitely gotten me past the last toughest 10% of my configuration dilemmas. Its much appreciated considering I assume you are all doing this in your free time.
Thanks,
Alex
On Oct 7, 2014, at 7:42 AM, Alan DeKok <aland@deployingradius.com> wrote:
Alex Gregory wrote:
What might I need it to do to stop processing if a user is not found?
$ man unlang
You can check the return code of a module.
(3) [ldap] = notfound
Change:
ldap
To:
ldap if (notfound) { reject }
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alex Gregory wrote:
I apologize… should have tried it first. Not allowed there. Looks like its done in the authorize section.
Yes. Because that's where the LDAP module is being called. The point is to check the return code of the LDAP module. Not add "ldap" in another section, and then check that return code. Alan DeKok.
participants (3)
-
Alan DeKok -
Alex Gregory -
Nick Owen