Re: Possible to limit user access to different types of authentication?
Hi Alan, Thanks for the update. I have read through "man unlang" as well. Overlooked on the part on the additional "Cisco-AVPair" attribute as it was only available after authentication is done. I have worked around it using the proxy-inner-tunnel method to terminal the EAP on the front radius and then proxy MS-CHAP to an internal radius that will do an LDAP bind with an additional attribute. As the front radius will also handle EAP requests that will not be handled by the internal radius, will it just proxy the EAP request based on the domain or it will terminate and forward to my internal radius instead? Thanks/Regards, Ryan On Fri, Apr 18, 2008 at 4:44 PM, <freeradius-users-request@lists.freeradius.org> wrote:
Send Freeradius-Users mailing list submissions to freeradius-users@lists.freeradius.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeradius.org/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to Date: Fri, 18 Apr 2008 07:55:42 +0200 From: Alan DeKok <aland@deployingradius.com> Subject: Re: Possible to limit user access to different types of authentication? To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <480837DE.5010400@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1
Ryan wrote:
Did some further searching on the listing and noticed that it is possible to do a string compared in the authorize and authenticate sections.
$ man unlang
However running radius in debug mode will return the following error.
(Attribute Cisco-AVPair was not found)
Because the attribute isn't in the request. Go look at the packet that the server received. There is no such attribute in it.
I know that it is possible to match the Cisco-AVPair in the users file. Can we do the same in the authorize/authenticate sections as well?
Yes. This is documented in the "unlang" man page. But if the attribute isn't in the request, you can't compare it to anything.
Alan DeKok.
Ryan wrote:
I have worked around it using the proxy-inner-tunnel method to terminal the EAP on the front radius and then proxy MS-CHAP to an internal radius that will do an LDAP bind with an additional attribute.
Ok...
As the front radius will also handle EAP requests that will not be handled by the internal radius, will it just proxy the EAP request based on the domain or it will terminate and forward to my internal radius instead?
Huh? You said in the first paragraph that it will terminate & forward. Where's the confusion? Alan DeKok.
participants (2)
-
Alan DeKok -
Ryan