(RADIATOR) Using a "handler" where attributes are missing

[Hugh Irvine]

Hello Simon -

It is usually a much better idea to put Identifier's in your Client  
clauses and configure your Handlers to use them.

Here is an example:


<Client 1.1.1.1>
	Identifier SomeUsefulTag
	.....
</Client>

<Client 2.2.2.2>
	Identifier SomeUsefulTag
	.....
</Client>

<Client 3.3.3.3>
	Identifier AnotherTag
	.....
</Client>

.....

<Handler Client-Identifier = SomeUsefulTag>
	.....
</Handler>

<Handler Client-Identifier = AnotherTag>
	.....
</Handler>

.........

<Handler>
	.....
</Handler>


This is generally much easier to maintain than trying to use NAS-IP- 
Address's.

hope that helps

regards

Hugh


On 23 Jan 2006, at 10:33, MACKEY, Simon wrote:

>
> Hi
>
> We use different <handler> statements for different NAS's type so  
> as we
> can perform different forms of authentication, based on its  
> function (eg
> remote access device, wireless devices, internal switches/routers)
>
> The Handler statements use the <handler NAS-IP-Address=...> to  
> identify
> the relevant specific devices.  We also use a default handler for all
> our other "internal" routers/switches.
>
> However one of our external access devices does not seem to pass any
> useful attributes, making it hard to identifiy for its handler.
>
> This is what I do see in the debug:
>
> *** Received from 172.31.1.20 port 33658 ....
> Code:       Access-Request
> Identifier: 0
> Authentic:  <235>....
> Attributes:
>         User-Name = "myname"
>         User-Password = <248>.....
>         NAS-IP-Address = 0.0.0.0
>         NAS-Port = 0
>         NAS-Port-Type = Async
>
> Any ideas on how I can identify this default so that I use a  
> handler for
> it.
>
> Thanks
>
> Simon Mackey
> Senior Network Analyst
> Information & Communication Services
>
>
>
>
> ********************************************************************** 
> **
> WARNING
> This email and any attachment may contain confidential  
> information.  If you are not the intended recipient you are not  
> authorised to copy or disclose all or any part of it without the  
> prior written consent of the Metropolitan Fire and Emergency  
> Services Board.
> ********************************************************************** 
> **
>
> --
> 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:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

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