[RADIATOR] Differentiating multiple TunneledByXXXX handlers
Hugh Irvine
hugh at open.com.au
Thu Nov 12 15:12:18 CST 2009
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.
More information about the radiator
mailing list