(RADIATOR) returning attributes to a ras client when

[Alex Sharaz]

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.