(RADIATOR) postauthhook questions

[Wyman Miles]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's becoming evident from snoop and from the logs that auth requests are 
going to one RADIUS server and accounting requests to the other.  Go 
figure.  I'll assume it's a config problem or bug with the NAS unless 
circumstances prove otherwise.  Sorry for the confusion.

In any event, would it be syntactically correct to do the following:

<Handler TunnelledByTTLS=1,Client-Identifier=RRSec>
...gibberish from the TunnelledByTTLS config below...

</Handler>

to gain even more granularity as to when the postauthhook script is 
processed?


- --On Tuesday, January 24, 2006 6:42 AM +0800 Hugh Irvine
<hugh at open.com.au> 
wrote:

>
> Hello Wyman -
>
> Your PostAuthHook will only be executed for the inner request of an  EAP
> authentication.
>
> What is shown in the trace 4 debug?
>
> regards
>
> Hugh
>
>
> On 24 Jan 2006, at 05:24, Wyman Miles wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I recently changed our radiator config to break out certain
>> handlers by
>> Client-Identifier.
>>
>> In the previous config, our call to postauthhook worked fine.  The
>> current
>> config appears to ignore that handler entirely.
>>
>> Authentication works correctly, as does accounting and our
>> preprochook.
>>
>> Also, is it correct that if I want to add multiple identical
>> clients with
>> Client-Identifier=RRSec, they'll have to be broken into multiple
>> <Client>
>> clauses for <Handler Client-Identifier=RRSec> to continue to work?
>>
>> Our config, sanitized of IP and secrets is below.
>>
>> Any ideas?
>>
>> - ------------ Forwarded Message ------------
>> Date: Monday, January 23, 2006 1:30 PM -0500
>> From: Wyman Miles <wm63 at agate3.cit.cornell.edu>
>> To: wm63 at cornell.edu
>> Subject:
>>
>> # Cornell Radiator config for 802.1x wireless
>>
>> AuthPort 1645,1812
>> AcctPort 1646,1813
>>
>> # Foreground
>> # LogStdout
>> LogDir		 /var/log/radius
>>
>> DbDir		/etc/radiator
>> # User a lower trace level in production systems:
>> Trace	2
>>
>> # You will probably want to add other Clients to suit your site,
>> # one for each NAS you want to work with
>>
>> # not needed
>>
>> <Client a.b.c.d>
>> 	Identifier NetVigil
>> </Client>
>>
>> # RedRover-Secure NAS clients
>> # Why so many, instead of just using "IdenticalClients" clauses?
>> # because Radiator won't respect the Identifier clause, making
>> # subsequent handlers impossible to sort out
>> # *sigh*
>>
>> <Client e.f.g.3>
>> 	Identifier RRSec
>> 	DupInterval 0
>> </Client>
>> <Client e.f.g.4>
>> 	Identifier RRSec
>> 	DupInterval 0
>> </Client>
>>
>> # for netvigil monitoring
>> <Handler Client-Identifier=NetVigil>
>> 	<AuthBy FILE>
>> 		Filename	%D/netvigil
>> 	</AuthBy>
>> </Handler>
>>
>>
>> # inner authentication request.
>> # we'll pass this off to Kerberos for verification
>>
>> <Handler TunnelledByTTLS=1>
>> 	AcctLogFileName %L/detail
>>         <AuthBy KRB5>
>>                 Identifier cit.redrover.secure
>>                 KrbRealm REALM
>> 		AutoMPPEKeys
>>         </AuthBy>
>> 	AddToReply User-Name = %u
>> 	PostAuthHook file:"/opt/radiator/sbin/postauthhook"
>> </Handler>
>>
>>
>> # outer EAP authentication request
>>
>> <Handler Client-Identifier=RRSec>
>> 	AcctLogFileName %L/detail
>> 	PreProcessingHook file:"/opt/radiator/sbin/preprochook"
>> 	<AuthBy FILE>
>> 		Filename %D/users
>>
>> 		EAPType TTLS
>>
>> 		EAPTLS_CAFile %D/certificates/cacert.pem
>>
>> 		EAPTLS_CertificateFile %D/certificates/agate1.pem
>> 		EAPTLS_CertificateType PEM
>>
>> 		EAPTLS_PrivateKeyFile %D/certificates/agate1.key
>>
>> 		EAPTLS_MaxFragmentSize 1000
>>
>> 		AutoMPPEKeys
>> 	
>> #		EAPAnonymous %0
>>
>> 		SSLeayTrace 1
>> 	</AuthBy>
>> 	<AuthBy KRB5>
>> 		Identifier cit.redrover.secure
>> 		KrbRealm REALM
>> 		AutoMPPEKeys
>> 	</AuthBy>
>> </Handler>
>>
>>
>> - ---------- End Forwarded Message ----------
>>
>>
>>
>> Wyman Miles
>> Senior Security Engineer
>> Cornell University, Ithaca, NY
>> (607) 255-8421
>> -----BEGIN PGP SIGNATURE-----
>> Version: Mulberry PGP Plugin v3.0
>> Comment: processed by Mulberry PGP Plugin
>>
>> iQA/AwUBQ9VJm8RE6QfTb3V0EQKikQCgwA55x40GSh8mthPTzJ4eMJOzEPEAoIDY
>> Vuzi5gHJo7XFF+FR/WaPAAdB
>> =Ciyw
>> -----END PGP SIGNATURE-----
>>
>> --
>> 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.
>
>
> 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.
>
>



Wyman Miles
Senior Security Engineer
Cornell University, Ithaca, NY
(607) 255-8421
-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v3.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBQ9ZGR8RE6QfTb3V0EQLUCQCgh6cOJwl6XmQRDX29Q0IZrAf/1hMAniZh
Mz9CxYrDgSCLbp3yGmrCv1jT
=tx3Q
-----END PGP SIGNATURE-----

--
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.