(RADIATOR) AuthLog AuthBy?

[Hugh Irvine]

Hello Jeremy -

AddToRequest is available in the AuthBy GROUP clause, so you could 
enclose your AuthBy clauses in AuthBy GROUP's and do it that way. BTW - 
you do not need to use an attribute from the dictionary - the request 
is just a scratch-pad area in memory that you can use however you like.

<Handler ....>
	AuthByPolicy .....
	<AuthBy GROUP>
		<AuthBy LDAP2>
			.....
		</AuthBy>
		AddToRequest AuthBy1 = LDAP2
	</AuthBy>
	<AuthBy GROUP>
		<AuthBy SQL>
			.....
		</AuthBy>
		AddToRequest AuthBy2 = SQL
	</AuthBy>
	.....
</Handler>


regards

Hugh


On Tuesday, Feb 25, 2003, at 04:47 Australia/Melbourne, Jeremy Hinton 
wrote:

> Hugh,
>
>         Thanks for the idea, but unfortunately the AddToRequest seems 
> to be out of scope (invalid) in an AuthBy clause. It recognizes it in 
> the Realm scope, and i tried sequencing them there:
>
>         AuthBy          Log_SQL
>         AddToRequest    NAS-Port-Id=LDAP2
>         AuthBy          CGate_via_LDAP
>         AddToRequest    NAS-Port-Id=SQL
>         AuthBy          Auth_SQL
>
> Note i used NAS-Port-Id as a simple test attribute, that was already 
> in the dictionary and i wasn't currently using it.But since the 
> AuthLog SQL gets processed at the end, NAS-Port-Id always got logged 
> as SQL, never LDAP.
>
> As i said below, i can put an AddToReply inside an AuthBy clause,  but 
> from what i can tell:
>
> 1) Attributes specified with an AddToReply in an AuthBy clause are not 
> added unless the AuthBy succeeds.
> 2) AuthLogSQL can't access attributes in the reply anyway. I tested 
> this adding NAS-Port-Id in the Realm scope, and it correctly showed up 
> in the NAK as seen by radpwtst -trace. However, when i tried to log 
> %{Reply:NAS-Port-Id} in my AuthLogSQL it logged the empty string.
>
> Any other suggestions?
>
> - jeremy
>
> At 06:32 PM 2/20/2003, you wrote:
>
>> Hello Jeremy -
>>
>> Interesting question.
>>
>> The only thing I can think of is to put an AddToRequest in each of 
>> the AuthBy clauses and logging the contents of both in your AuthLog.
>>
>> Something like this might work (please let me know if it does):
>>
>> <Handler ...>
>>         AuthByPolicy ....
>>         <AuthBy LDAP2>
>>                 .....
>>                 AddToRequest AuthBy1 = LDAP2
>>         </AuthBy>
>>         <AuthBy SQL>
>>                 ....
>>                 AddToRequest AuthBy2 = SQL
>>         </AuthBy>
>>         ....
>> </Handler>
>>
>> Your logging should include %{AuthBy1} and %{AuthBy2}.
>>
>> Please let me know how you get on.
>>
>> regards
>>
>> Hugh
>>
>>
>> On Friday, Feb 21, 2003, at 05:51 Australia/Melbourne, Jeremy Hinton 
>> wrote:
>>
>>> Greetings,
>>>
>>>         I'm trying to figure out of theres a way to log which AuthBy 
>>> clause issued the Request-Failed via AuthLogSQL.  I use a AuthBy 
>>> LDAP primarily, but if that times out i fall back to an AuthBy SQL. 
>>> When an auth attempt gets rejected, i'd like to know if the AuthBy 
>>> LDAP timed out and its the SQL backup thats rejecting them. I've 
>>> tried the following with no luck:
>>>
>>> - Setting GlobalVar's in the Authby clauses and then logging those. 
>>> Didn't work since GlobalVars are illegal outside of Global scope
>>> - Logging %{Handler:AuthBy}. This logged an array referrence.
>>> - Adding AuthBy specific reply items and logging those with 
>>> %{Reply:xx}. It doesn't appear you can add attributes to a > 
>>> Auth-Reject.
>>>
>>> I though about maybe a PostAuthHook, but that starts to get really 
>>> messy.
>>>
>>> Does anyone know of a way to do this? Thanks.
>>>
>>> - jeremy
>>>
>>> ===
>>> 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.
>>>
>>
>> --
>> 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.
>>
>
>

NB: 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 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

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