(RADIATOR) How to pass Reply-Message from inside to outside of PEAP tunnel?

[Hugh Irvine]

Hello Robin -

What version of Radiator are you running?

There have been some patches for Radiator 3.14 which may be relevant.

You should be running Radiator 3.14 plus the latest patches.

And from what you show below I would have expected you to use

	${$_[0]}->{outerRequest}->add_attr()

as far as I know, set_attr() does not exist.

You should also be able to use AddToRequest as well as normal  
AuthColumnDef's and so on.

regards

Hugh


On 26 May 2006, at 18:52, Robin Breathe wrote:

> Hugh Irvine wrote:
>> I suggest you move the AUTHORIZE clause to the outer Handler:
>>
>> ...snip...
>>
>> Please let me know how you get on.
>
> Hugh,
>
> I had considered that option (and I have just tried it), but
> unfortunately AUTHORIZE depends upon pseudo-attributes of the inner
> request which are generated by hooks within the inner handler, so
> basically the question again becomes how can I set a property of the
> outer request within the inner request?
>
> I've tried pushing attributes out using
> ${$_[0]}->{outerRequest}->set_attr() with (Pre|Post)AuthHooks in the
> TunnelledByPEAP handler, but the attributes don't seem to be there  
> when
> I return to the outer handler.
>
> If I can get inner to outer attribute passing working, then pushing
> AUTHORIZE to the outer Handler is certainly the way to go!
>
> Regards,
> Robin
>
>> On 26 May 2006, at 00:24, Robin Breathe wrote:
>>
>>> Hi,
>>>
>>> We're using Radiator for wireless 802.1X AAA with PEAP/EAP-MSCHAPv2.
>>> Following authentication, we have an AuthBy SQL performing
>>> authorization. One of our returned check items is an Auth-Type  
>>> with the
>>> column containing either "Accept" or "Reject:(reason)". We want to
>>> return the (reason) to the client in the Reply-Message, but the
>>> RejectHasReason option only seems to affect the inner handler.  
>>> The outer
>>> handler simply replying with the generic "PEAP Authentication  
>>> Failure"
>>> when RejectHasReason is set, and with "Request Denied" otherwise.
>>>
>>> Is there any way around this?
>>>
>>> The relevant section of our configuration:
>>>
>>> <AuthBy FILE>
>>>     Identifier Tunnel-Outer
>>>     EAPType PEAP,TTLS
>>>     EAPTLS_CAFile %{GlobalVar:oxCertDir}/cacert.crt
>>>     EAPTLS_CertificateFile  %{GlobalVar:oxCertDir}/radius.crt
>>>     EAPTLS_CertificateType PEM
>>>     EAPTLS_PrivateKeyFile   %{GlobalVar:oxCertDir}/radius.key
>>>     EAPTLS_MaxFragmentSize 1000
>>>     EAPTLS_PEAPVersion 1
>>>     # The following seems to fix Airport client with PEAP on 3com
>>>     EAPTLS_PEAPBrokenV1Label
>>>     EAPAnonymous anonymous@%R
>>>     AutoMPPEKeys
>>> </AuthBy>
>>> <Handler TunnelledByPEAP=1>
>>>     AuthByPolicy ContinueWhileAccept
>>>     AuthBy AUTHENTICATE
>>>     AuthBy AUTHORIZE
>>>     RejectHasReason
>>> </Handler>
>>> <Handler>
>>>     AuthBy Tunnel-Outer
>>>     RejectHasReason
>>> </Handler>
>
>
> -- 
> Robin Breathe, Computer Services, Oxford Brookes University,  
> Oxford, UK
> rbreathe at brookes.ac.uk       Tel: +44 1865 483685  Fax: +44 1865  
> 483073
>


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.