(RADIATOR) Radiator setup for dual authentication

[Hugh Irvine]

Hello Jon -

You are correct - a ReplyHook is the best way to do what you describe.

regards

Hugh


On 6 Apr 2005, at 05:12, Jonathan K wrote:

> Hi,
>
> We've got a bit of a tricky setup here which we've solved by using a 
> ReplyHook but i'd like to run it by the list to see if it's the best 
> method for what we're trying to achieve.
>
> We run a managed platform that handles authentication via radiator and 
> a mysql backend, we have a new customer coming online who would like 
> to have control over their user base via proxied RADIUS requests. This 
> is all good, but because of the method that the client is using to 
> synchronise their data from us, we need to also authenticate the user 
> using our normal method (local sql database). The flow we are looking 
> for is as follows:
>
> 1. Receive Access-Request from client
> 2. Proxy request to downstream RADIUS server
> 3a. If downstream server responds with Access-Reject, send 
> Access-Reject to client
> 3b. If downstream server responds with Access-Accept, auth from local 
> sql server
> 4a. If local auth fails, send Access-Reject to client
> 4b. If local auth succeeds, send Access-Accept to client
>
>
> I thought this would be a simple matter of having a handler with 
> ContinueWhileAccept and two consecutive AuthBy's but what we've found 
> when using this method is that Radiator sends duplicate packets back 
> to the requesting NAS (in our testing, radpwtst). While radpwtst only 
> receives the one packet (tcpdump shows that two are being sent), we're 
> not sure (and don't want to test) how a NAS will respond to this, or 
> what will happen if the wrong AuthBy sends the first reply, which 
> doesn't have the correct info.
>
> Basically this is what happens:
>
> 1. Radiator gets Access-Request
> 2. First AuthBy (RADIUS) executes and proxies request to remote server
> 3. Second AuthBy (SQL) executes
> 4. Second AuthBy succeeds and sends Access-Accept back to client
> 5. Radiator receives reply from remote server and proxies 
> Access-Accept back to client
>
> We've managed to get the required behaviour by setting the Synchronous 
> flag but this isn't acceptable for our installation, we've also 
> experimented with  the Fork and Synchronous flags together which 
> produces the same duplicate reply problem.
>
> What we've done is written an external hook based on 
> "AllocateIPAddressOnReplyFromProxy" which evaluates the remote servers 
> response and goes off and runs our local AuthBy then allocates the IP 
> in the normal way or rejects the client. It does what we want.
>
> We have:
>
> <Handler /matches_for_customer/>
> 	AuthByPolicy    ContinueWhileReject
> 	AuthBy          CustomerAuth
> </Handler>
>
> <AuthBy RADIUS>
> 	Identifier CustomerAuth
> 	<Host 111.111.111.111>
> 		secret	foo
> 	</Host>
> 	# Reply hook evaluates response from remote server
> 	# if success then points to our regular AuthBy SQL
> 	# then assigns address
> 	ReplyHook file:"%D/customer.hook"
> </AuthBy>
>
>
> So my question is, is this an optimal way of dealing with this? Can 
> anyone see any room for improvement in our model? This customer has 
> about 15,000 clients and we are looking at this solution for another 
> client with a number of clients in the 1000's and need to know it 
> scales.
>
> Thanks in advance.
>
> Jon
>
> --
> 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: I am travelling this week, so there may be delays in our 
correspondence.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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.