(RADIATOR) associating clients with handlers
Hugh Irvine
hugh at open.com.au
Thu Sep 7 23:50:02 CDT 2006
Hello Stuart -
I have cut and pasted what you show below and it works fine.
For testing I suggest you do the following:
Stop the Radiator service, then run radiusd directly from a terminal
window like this:
cd c:\Program Files\Radiator
perl radiusd -foreground -log_stdout -trace 4 -config_file radius-
mgmt.cfg
and just use something like this for the configuration file (this is
the file I used for testing).
Foreground
LogStdout
LogDir .
DbDir .
# User a lower trace level in production systems:
Trace 4
# You will probably want to add other Clients to suit your site,
# one for each NAS you want to work with
########## CLIENT DEFINITIONS ############
# APC devices -- list all UPSes and associated gear here
<Client localhost>
Secret foozle
Identifier ecs-apc
</Client>
##### ECS APC Gear (Symmetra, Silcon, ISX Manager) #######
# Describe how to handle authentication against ECS-managed APC gear
<Handler Client-Identifier=ecs-apc>
RejectHasReason
AuthByPolicy ContinueWhileIgnore
<AuthBy FILE>
Filename ./users
</AuthBy>
# Log accounting to a detail file
AcctLogFileName ./detail
</Handler>
then in a separate terminal window run radpwtst so you can see what
is happening.
hope that helps
regards
Hugh
On 8 Sep 2006, at 00:30, Stuart Kendrick wrote:
> hi hugh,
>
> -yes, i have stopped/started the Radiator service ... i've become
> adept at typing "net stop ..." and "net start ..." :)
>
> C:\temp>net stop "Radiator-MGMT Radius Server"
> The Radiator-MGMT Radius Server service is stopping.
> The Radiator-MGMT Radius Server service was stopped successfully.
>
>
> C:\temp>net start "Radiator-MGMT Radius Server"
> The Radiator-MGMT Radius Server service is starting.
> The Radiator-MGMT Radius Server service was started successfully.
>
>
> C:\temp>
>
> -i keep a 'tail -f logfile' going while i'm working on this sort of
> thing ... seems to me that Radiator is happy with my config file:
>
> Thu Sep 7 06:36:51 2006: DEBUG: Finished reading configuration
> file 'c:\Program Files\Radiator\radius-mgmt.cfg'
> Thu Sep 7 06:36:51 2006: DEBUG: Reading dictionary file 'C:/
> Program Files/Radiator/dictionary'
> Thu Sep 7 06:36:51 2006: DEBUG: Creating authentication port
> 0.0.0.0:1812
> Thu Sep 7 06:36:51 2006: DEBUG: Creating accounting port 0.0.0.0:1813
> Thu Sep 7 06:36:51 2006: NOTICE: Server started: Radiator 3.15 on
> vidal
>
> -and see below for my entire radius config file ... i only have one
> client definition in this file, the one for 140.107.6.12 [normally,
> i have more definitions and more 'stuff' ... but for the purposes
> of analyzing this problem, i've stripped the file down significantly]
>
> -do you see anything in my 'global' section which might be messing
> with what i'm trying to do?
>
> --sk
>
> stuart kendrick
> fhcrc
>
>
> ########## GLOBAL PARAMETERS ############
>
> # Misc
> PidFile C:/Program Files/Radiator/radius-mgmt.pid
> DbDir C:/Program Files/Radiator
>
> # Log error messages to the console [doesn't work --sk]
> Foreground
> LogStdout
>
> # This defines the %L token
> LogDir G:/Radiator/Logs
>
> # Default logfile for startup and other general messages.
> # [In theory, the <Log FILE> directive below disables this
> # ... but in practice, it does not --sk]
> LogFile %L/logfile
>
> # Set logging level
> Trace 4
>
> # Specify UDP ports
> AuthPort 1812
> AcctPort 1813
>
>
>
> ########## LOG FILE DEFINITIONS ##########
>
> <Log FILE>
> Identifier general-log
> Filename %L/General/%Y-%m-%d-general
> LogFormat %l: general: %1: %2: %U: %n: %c: %{NAS-Identifier}: %
> T: %{Calling-Station-Id}: %{Called-Station-Id}
> </Log>
>
> <AuthLog FILE>
> Identifier mgmt-authlog
> Filename %L/Mgmt/%Y-%m-%d-mgmt
> LogSuccess 1
> SuccessFormat %l: mgmt: OK: %U: %n: %c: %{NAS-
> Identifier}: %T: %{Calling-Station-Id}: %{Called-Station-Id}
> LogFailure 1
> FailureFormat %l: mgmt: FAIL: %U: %n: %c: %{NAS-
> Identifier}: %T: %{Calling-Station-Id}: %{Called-Station-Id}
> </AuthLog>
>
> <AuthLog FILE>
> Identifier rsa-authlog
> Filename %L/RSA/%Y-%m-%d-rsa
> LogSuccess 1
> SuccessFormat %l: rsa: OK: %U: %n: %c: %{NAS-Identifier}:
> %T: %{Calling-Station-Id}: %{Called-Station-Id}
> LogFailure 1
> FailureFormat %l: rsa: FAIL: %U: %n: %c: %{NAS-
> Identifier}: %T: %{Calling-Station-Id}: %{Called-Station-Id}
> </AuthLog>
>
>
>
>
> ########## CLIENT DEFINITIONS ############
>
> # APC devices -- list all UPSes and associated gear here
> <Client 140.107.6.12>
> Secret foozle
> Identifier ecs-apc
> </Client>
>
>
> ##### ECS APC Gear (Symmetra, Silcon, ISX Manager) #######
>
> # Describe how to handle authentication against ECS-managed APC gear
> <Handler Client-Identifier=ecs-apc>
> RejectHasReason
> AuthByPolicy ContinueWhileIgnore
>
> # Handle administrative users
> <AuthBy LSA>
> Domain FHCRC
> Group UPSMgmt
> AddToReply Service-Type = "Administrative-User"
> </AuthBy>
>
> # Log it
> AuthLog mgmt-authlog
> AcctLogFileName %L/Acct/%Y-%m-%d-acct
> </Handler>
>
>
>
>
> Hugh Irvine wrote:
>> Hello Stuart -
>> What you show below should work correctly, however a couple of
>> things to check:
>> - have you restarted radiusd to re-read the configuration file?
>> - is there a second definition for this Client later in the
>> configuration file?
>> - is there some other problem in the configuration file that is
>> confusing radiusd when it starts up?
>> In answer to your question below, the "Client" in Radiator is the
>> device that is sending the radius request(s).
>> In this case the Client is 140.107.6.12.
>> However the user who is attempting to connect is "skendrick" which
>> is what is contained in the User-Name attribute.
>> hope that helps
>> regards
>> Hugh
>> On 7 Sep 2006, at 02:18, Stuart Kendrick wrote:
>>> hi,
>>>
>>> i'm stumbling over how to associate clients with handlers
>>>
>>> i'm using Radiator 3.15 with patches under Windows 2003
>>>
>>> here's a snippet from my radius.cfg
>>>
>>> [... global parameters ...]
>>> [... log file stuff ... ]
>>>
>>> #### Client Definitions ####
>>> [...]
>>> <Client 140.107.6.12>
>>> Secret foozle
>>> Identifier apc-gear
>>> </Client>
>>>
>>>
>>> #### Handle APC gear ####
>>> <Handler Client-Identifier=apc-gear>
>>> RejectHasReason
>>> AuthByPolicy ContinueWhileIgnore
>>>
>>> # Handle administrative users
>>> <AuthBy LSA>
>>> Domain COMPANY
>>> Group UPSManagement
>>> AddToReply Service-Type = "Administrative-User"
>>> </AuthBy>
>>>
>>> # Log it
>>> AuthLog mgmt-authlog
>>> AcctLogFileName %L/Acct/%Y-%m-%d-acct
>>> </Handler>
>>> [...]
>>>
>>> i can see from a packet sniffer the Access-Request packets
>>> arriving at my Radiator server from the 140.107.6.12 ... but no
>>> response from Radiator
>>>
>>>
>>> setting Trace to 4, i can see in logfile:
>>>
>>> *** Received from 140.107.6.12 port 32813 ....
>>> Code: Access-Request
>>> Identifier: 34
>>> Authentic: [...]
>>> Attributes:
>>> User-Name = "skendric"
>>> User-Password = "[...]"
>>> NAS-Identifier = "foo.fhcrc.org"
>>>
>>> Wed Sep 6 09:07:17 2006: WARNING: Could not find a handler for
>>> skendric: request is ignored
>>>
>>>
>>> -so, why does Radiator think the *client* name is 'skendric'? to
>>> my way of thinking, the client's name is 'foo.fhcrc.org' ... or,
>>> at the very least, 140.107.6.12
>>>
>>> -what am i misunderstanding about how to use Client-Identifiers?
>>>
>>>
>>> insights appreciated,
>>>
>>> --sk
>>>
>>> stuart kendrick
>>> fhcrc
>>>
>>> --
>>> 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.
>> Includes support for reliable RADIUS transport (RadSec),
>> and DIAMETER translation agent.
>> -
>> 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.
>
> --
> 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.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
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