(RADIATOR) returning attributes to a ras client when

[Hugh Irvine]

Hello Alex -

You can do something like this:


#########################################
# Client
#########################################
#
#

<Client 150.237.74.254>
	Secret	<the key for this device>
	Identifier fe4802
	NasType unknown
</Client>

# proxy off to the existing SBR server
<AuthBy RADIUS>
   	Identifier radHull
   	Host <a.b.c.d
   	Secret <secret key>
   	AuthPort 1812
   	AcctPort 1813
   	LocalAddress d.c.b.a
</AuthBy>

########################################
# Handlers

<Handler Client-Identifier=fe4802, Realm=hull.ac.uk>
	<AuthBy GROUP>
		AuthBy radHull
		AddToReply ......, \
			......
	</AuthBy>
</Handler>

<Handler Client-Identifier=fe4802, Realm=>
	<AuthBy GROUP>
		AuthBy radHull
		AddToReply ......, \
			......
	</AuthBy>
</Handler>

<Handler Client-Identifier=fe4802>
	<AuthBy GROUP>
		AuthBy radHull
		AddToReply ......, \
			......
	</AuthBy>
</Handler>

#
# Anything else ditch it
#

<Handler>
	AuthLog authlog
	AuthLog  mySqlAuthLog
	RejectHasReason
	<AuthBy INTERNAL>
		DefaultResult REJECT
	</AuthBy>
</Handler>


hope that helps

regards

Hugh



On 4 Mar 2005, at 16:46, Alex Sharaz wrote:

>
> Chaps,
>
> Got a small problem here which I'm sure is quite trivial.
>
> I'm trying to migrate all devices that perform some form of radius 
> authentication/accounting off our Steel Belted Radius service onto 
> Radiator.
>
> What I'd like to do is have radiator do everything except the actual 
> authentication and have that proxied off to SBR. This way, I can move 
> all the ras clients onto radiator and not worry about the back end 
> database related stuff such as creating/deleting users and password 
> management functions - all that can be done with the procedures we've 
> got in place at the moment.
>
> At the moment, once a user is authenticated by the SBR server, it 
> passes back a set of attributes which are forwarded to the client.  
> I'd rather not add any client specific return attributes to the SBR 
> configuration but have them passed back by radiator.
> As an example, a foundry device   needs to have  the following 3 
> attributes passed back to the client in order to place the user in a 
> vlan identified by "Subnet_74"
>       Tunnel-Medium-Type = 802
>       Tunnel-Private-Group-ID = Subnet_74
>       Tunnel-Type = VLAN
> and I'm not sure how to config radiator to do this.
>
> If I define a client to use file based authentication then yes, i can 
> just add the attribute types into the appropriate user entry. If 
> however, you are proxying the actual authentication off to something 
> else,how can you specify a set of given parameters such as those 
> above.
>
> I suppose there are 2 questions:-
>
> 1. If a user connects through a specific radius client, how can I 
> define a (static) set of attributes I would like returned to the 
> client. e.g. in the case of the fastiron mentioned above
> I'd want all authenticated connections from the client have the 3 
> attributes defined above passed back to the client
>
> 2).As an extension to (1) how could you perform some form of  back end 
> database lookup so that you might say "for user U connecting through 
> client C return attribute set X". An example might be to drop a user 
> into a different vlan based upon their university status, so a student 
> connecting to a wired network port would have Tunnel-Private-Group-ID 
> = Subnet_74 whereas a member of staff would have it set to Subnet_75
>
> Below are some excerpts from my radius.cfg file for the aforementioned 
> Fastiron
>
> I want to do a proxy authentication back to the SBR server but have 
> radiator decide what attributes to pass back to the client.
>
>
> #########################################
> # Client
> #########################################
> #
> #
> <Client 150.237.74.254>
> 	Secret	<the key for this device>
> 	Identifier fe4802
> 	NasType unknown
> #
> # Adding AddToResponse <...,..,..,> in here sends the attributes to 
> the proxy server
> # and not back to the client.
>
> </Client>
> # proxy off to the existing SBR server
> <AuthBy RADIUS>
>   Identifier radHull
>   Host <a.b.c.d
>   Secret <secret key>
>   AuthPort 1812
>   AcctPort 1813
>   LocalAddress d.c.b.a
> </AuthBy>
> ########################################
> # Handlers
> <Handler Client-Identifier=fe4802, Realm=hull.ac.uk>
> AuthBy radHull
> </Handler>
>
> <Handler Client-Identifier=fe4802, Realm=>
> AuthBy radHull
> </Handler>
>
> <Handler Client-Identifier=fe4802>
> AuthBy radHull
> </Handler>
> #
> # Anything else ditch it
> #
> <Handler>
> AuthLog authlog
> AuthLog  mySqlAuthLog
> RejectHasReason
> </Handler>
>
>
> Sent using Mulberry 3.1.2
>
> --
> 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.