[RADIATOR] Differentiating multiple TunneledByXXXX handlers

[Hugh Irvine]

Hello Martin -

You will need to use a PreHandlerHook in the outer Handler to add whatever attributes you need to the inner request.

Here is a copy of another mail on this topic:

> 
> As you can see from the debug, the NAS-IP-Address is not passed in
> the inner request by default.
> 
> If you want to add any attribute to the inner request you need to use
> a PreHandlerHook in the outer AuthBy clause.
> 
> You can add the following in a file called "nas.pl" in your %D
> directory:
> 
> sub { my $p = ${$_[0]};
> my $outer = $p->{outerRequest};
> my $nas = $outer->get_attr('NAS-IP-Address');
> $p->add_attr('NAS-IP-Address', $nas);
> &main::log($main::LOG_DEBUG, "NAS-IP-Address = $nas");
> return; }
> 
> Then use this in your configuration file:
> 
> <AuthBy FILE>
> .....
> PreHandlerHook file:"nas.pl"
> .....
> </AuthBy>
> 
> I haven't tested the above, but you should get the idea.


You can add whatever is appropriate to the inner request.

hope that helps

regards

Hugh



On 13 Nov 2009, at 01:04, Martin Burton wrote:

> Hi Folks.
> 
> We're building a configuration for a secure wireless SSID to run
> alongside our current open (guest friendly!) wireless implementation.
> 
> We've had this running fine in testing using the following simple config:
> 
> ==== BEGIN CONFIG SNIP ====
> 
> <Handler TunnelledByTTLS=1>
>        RewriteUsername      s/^([^@]+).*/$1/
>        AuthByPolicy ContinueUntilAccept
> 
> 	# If the EAP inner request is PAP then it will work against the user's
> {crypt} password in LDAP
> 
>        <AuthBy LDAP2>
>                Host ldap.internal.sanger.ac.uk
>                BaseDN ou=people,dc=sanger,dc=ac,dc=uk
>                UsernameAttr uid
>                PasswordAttr userPassword
>                ServerChecksPassword
>        </AuthBy>
> 
> 	# Otherwise we need to provide a cleartext password field in the LDAP
> directory for things like CHAP/MSCHAP(v2) etc. to work against.  There
> is a webpage for users to add the roamingPassword attribute if their
> device does not support EAP-TTLS/PAP
>        <AuthBy LDAP2>
>                Host ldap.internal.sanger.ac.uk
>                BaseDN ou=people,dc=sanger,dc=ac,dc=uk
>                UsernameAttr uid
>                PasswordAttr roamingPassword
>        </AuthBy>
> </Handler>
> 
> <Handler NAS-Identifier="WTSI">
>        RewriteUsername      s/^([^@]+).*/$1/
>        <AuthBy FILE>
>                EAPType TTLS
>                EAPTLS_CAFile %D/cacert.pem
>                EAPTLS_CAPath
>                EAPTLS_CertificateFile
> %D/radiussrv3_internal_sanger_ac_uk-cert.pem
>                EAPTLS_CertificateType PEM
>                EAPTLS_PrivateKeyFile
> %D/radiussrv3_internal_sanger_ac_uk-key.pem
>                EAPTLS_PrivateKeyPassword ****REDACTED****
>                EAPTLS_MaxFragmentSize 1000
>                AutoMPPEKeys
>                Filename /opt/Radiator-4.4/eap_anon_user
>        </AuthBy>
> </handler>
> 
> ==== END CONFIG SNIP ====
> 
> This is fine in testing where we are working with an isolated
> development instance of Radiator.  However, when we move into production
> there will be multiple TunneledByTTLS handlers to deal with different
> NAS's (wireless and wired dot1x etc.)
> 
> I'd assumed that adding the NAS-Identifier to the EAP Inner Handler
> clause so that it read:
> 
> <Handler TunnelledByTTLS=1,NAS-Identifier="WTSI">
> 
> would resolve the issue, but it seems that when the inner request is
> redispatched to the handler code then the NAS-Identifier is not
> maintained within the request, and subsequently Radiator fails to find a
> handler for the EAP Inner request.
> 
> Is there some way to add some kind of identifying attribute to the inner
> request so that we can differentiate between the originating NAS's?
> 
> Cheers,
> 
> Martin.
> -- 
> Martin Burton
> Senior Systems Administrator               \\\|||///
> Special Projects Team                     \\  ^ ^  //
> Wellcome Trust Sanger Institute            (  6 6  )
> -----------------------------------------oOOo-(_)-oOOo---
> t: +44 (0)1223 496945             http://www.sanger.ac.uk
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



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?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
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.