(RADIATOR) returning attributes to a ras client when

Hugh Irvine hugh at open.com.au
Sun Mar 6 11:02:26 CST 2005 

Hello Alex -

Yes you can use a hook for almost anything.

There are a number of examples in "goodies/hooks.txt".

regards

Hugh



On 6 Mar 2005, at 17:27, Alex Sharaz wrote:

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

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.

More information about the radiator mailing list