Works like a charm! One minor change, so i dont have to keep track of 2 attributes, i just use one as follows:
<AuthBy GROUP>
AuthBy CGate_via_LDAP
StripFromRequest Visi-AuthBy
AddToRequest Visi-AuthBy=LDAP
</AuthBy>
<AuthBy GROUP>
AuthBy Auth_SQL
StripFromRequest Visi-AuthBy
AddToRequest Visi-AuthBy=SQL
</AuthBy>I don't really need the first Strip request, but in case i add an earlier clause it will already be there. Then i use the following in my AuthLog SQL:
FailureQuery insert into RADAUTHLOG (TIME_STAMP, USERNAME, \
DOMAIN, REASON, RADSERVER, NASIDENTIFIER, \
CALLING_STATION_ID, CALLED_STATION_ID, \
ATTEMPTED_PASSWORD, AUTH_BY) \
values (%t, '%u', '%R', %1, '%h', '%c', \
'%{Calling-Station-Id}', '%{Called-Station-Id}', \
'%P', '%{Visi-AuthBy}')Thanks again!
- jeremy
At 04:37 PM 2/24/2003, you wrote:
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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
