(RADIATOR) returning attributes to a ras client when

[Alex Sharaz]

many thanks for that. I thought I'd already tried that .... but for some 
reason convinced myself that i should be using AddToRequest

Sigh!! mad... totally mad.

Regarding the second question, I take it i could have a hook at this point 
to which I could pass some parameters ( userid, client-id) and get a set of 
items to return to the client

--On 05 March 2005 11:53 +0100 Hugh Irvine <hugh at open.com.au> wrote:

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



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.