[RADIATOR] AcctInsertQuery for Authby RADIUS

Jeffrey Lee jleefw at gmail.com
Thu Feb 17 19:25:14 CST 2011


see below for the <Handler> config

i have 2 RADIUS server setup here.... RADIUS A is this radiator,
RADIUS B is another RADIUS for testing proxy-realms.
On RADIUS A, here's the output on screen:

Fri Feb 18 12:18:18 2011: DEBUG: Handling request with Handler
'Realm=ABC', Identifier ''
Fri Feb 18 12:18:18 2011: DEBUG: Rewrote user name to jeff
Fri Feb 18 12:18:18 2011: DEBUG:  Adding session for jeff at ABC, 203.63.154.1,1234
Fri Feb 18 12:18:18 2011: DEBUG: Handling with Radius::AuthSQL:
Fri Feb 18 12:18:18 2011: DEBUG: Handling accounting with Radius::AuthSQL
Fri Feb 18 12:18:18 2011: DEBUG: AuthBy SQL result: ACCEPT,
Fri Feb 18 12:18:18 2011: DEBUG: Accounting accepted

     >> it seems as though the AcctInsertQuery was called but there's
no accounting record captured. if the stored procedure generated an
error, will radiator capture and display the error message on screen?


On RADIUS B, it seems that the proxy-forwarded authentication requests
is received but not the accounting requests.


On the database (configured for radiator), there are no accounting
records captured, and the sessiondatabase is not triggered.


... what is wrong with the config?



#########################################################################################################

<Handler Realm=ABC>
	AcctLogFileName %D/detail
	AuthByPolicy ContinueWhileIgnore
	RewriteUsername s/^([^@]+).*/$1/
	MaxSessions 1

	<AuthBy SQL>
		IgnoreAuthentication
		HandleAcctStatusTypes Start,Stop,Alive
		
		# i've created a database called radiator with username and password
as radiator
		DBAuth radiator
		DBSource dbi:ODBC:radiator
		DBUsername radiator

		# i'm using a sql server stored procedure to capture the accounting records
		AcctInsertQuery exec radiator_insert_accounting '%{User-Name}',
'%{Acct-Session-Id}', '%{Acct-Session-Time}', '%{Acct-Input-Octets}',
'%{Acct-Output-Octets}', '%{Framed-IP-Address}',
'%{Calling-Station-Id}', '%{Called-Station-Id}', '%{NAS-Identifier}',
'%{NAS-IP-Address}', '%{NAS-Port}', '', '%{Acct-Status-Type}',
'%{Acct-Terminate-Cause}', '%R'
	</AuthBy>

	<AuthBy RADIUS>
		AcctPort 1813
		AuthPort 1812
		CacheOnNoReply 1
		CachePasswordExpiry 86400
		LocalAddress 0.0.0.0
		MaxFailedGraceTime 0
		MaxFailedRequests 1
		OutPort 0
		PasswordPrompt password
		Retries 3
		RetryTimeout 5
		Secret mysecret

		<Host 192.168.10.103>
			AcctPort 1813
			AuthPort 1812
			BogoMips 1
			LocalAddress 0.0.0.0
			MaxFailedGraceTime 0
			MaxFailedRequests 1
			OutPort 0
			Retries 3
			RetryTimeout 15
			Secret mysecret
		</Host>
	</AuthBy>
		
    # all success/failed requests logs are captured
    <AuthLog SQL>
		DBAuth radiator
		DBSource dbi:ODBC:radiator
		DBUsername radiator

		LogSuccess 1
		SuccessQuery insert into radpostauth (user,pass,reply)
values(%2,%3,'Access-Accept')

		LogFailure 1
		FailureQuery insert into radpostauth (user,pass,reply)
values(%2,%3,'Access-Reject')
    </AuthLog>
</Handler>

#########################################################################################################






On Thu, Feb 17, 2011 at 10:49 AM, Hugh Irvine <hugh at open.com.au> wrote:
>
> Hello Jeff -
>
> You should not mix Handlers and Realms in the same configuration file, as Realms are always evaluated before Handlers.
>
> If you are going to change from Realms to Handlers, I suggest you use separate Handlers for authentication and accounting:
>
> …..
>
> # accounting
>
> <Handler Request-Type = Accounting-Request, User-Name = /..../>
>
>        ……
>
> </Handler>
>
> # authentication
>
> <Handler User-Name = /.../>
>
>        …..
>
> </Handler>
>
> …..
>
> FYI - I also suggest you use "User-Name = /.../" instead of "Realm = /..../" as you then have greater control with the regexp.
>
> regards
>
> Hugh
>
>
> On 17 Feb 2011, at 10:03, Jeffrey Lee wrote:
>
>> hi Christian, thanks for the suggestion. You're right, your suggestion
>> is the simplest to implement, neat and easy to maintain.
>> whilst, the method suggested by Michael and Remo allows the AuthBy to
>> be reused by other realms that need the same processing policy.
>>
>> if i have a handler/realm tag that uses regex?
>> for example, i have <Realm ^abc(def)?\//i> (which should process any
>> incoming requests with abc/user or abcdef/user, how will this appear
>> in the handler tag? will it be <Handler realm=^abc(def)?\//i> , or
>> this is not possible and it must be for specific matches?
>>
>>
>>
>> On Thu, Feb 17, 2011 at 8:39 AM, Christian Kratzer <ck at cksoft.de> wrote:
>>> Hi,
>>>
>>> On Wed, 16 Feb 2011, Jeffrey Lee wrote:
>>>
>>>> I tried adding <AuthBy SQL> after <AuthBy RADIUS> but as soon as
>>>> <AuthBy RADIUS> is executed, <AuthBy SQL> will not be executed.
>>>
>>> <AuthBy RADIUS> will always return an ignore as it dispatches the
>>> radius request and processes the answer asyncronously.
>>>
>>>> Can you actually place <AuthBy SQL> within a <AuthBy RADIUS>?
>>>
>>> You can place both AuthBy below each other inside the handler
>>> and set the appropriate AuthByPolicy (Manual Section 5.24.1) to do
>>> what you want.
>>>
>>> You will not need an AuthBy GROUP for a simple case as a Handler already
>>> implements the same functionality as an AuthBy GROUP.
>>>
>>>> What I'm trying to achieve is to log the RADIUS accounting records
>>>> locally (start, stop & alive) for realms that need to be authenticated
>>>> by another RADIUS server. How can I achieve that?
>>>
>>> something like this should do the trick:
>>>
>>>        <Handler Realm=foo>
>>>                AuthByPolicy ContinueWhileIgnore
>>>
>>>                <AuthBy RADIUS>
>>>                        ...
>>>                </AuthBy>
>>>
>>>                <AuthBy SQL>
>>>                        IgnoreAuthentication
>>>                        ...
>>>                </AuthBy>
>>>
>>>        </Handler>
>>>
>>> The <AuthBy RADIUS> will always proxy your requests and will return ignore.
>>>
>>> The AuthBy SQL will be called but will only handle accounting as you have
>>> configured IgnoreAuthentication.
>>>
>>> There are many possible variations but I think above is the simplest.
>>>
>>> Greetings
>>> Christian
>>>
>>> --
>>> Christian Kratzer                      CK Software GmbH
>>> Email:   ck at cksoft.de                  Wildberger Weg 24/2
>>> Phone:   +49 7032 893 997 - 0          D-71126 Gaeufelden
>>> Fax:     +49 7032 893 997 - 9          HRB 245288, Amtsgericht Stuttgart
>>> Web:     http://www.cksoft.de/         Geschaeftsfuehrer: Christian Kratzer
>>>
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>
>


More information about the radiator mailing list