(RADIATOR) Problem with the username that is used for online confirmation

Vangelis Kyriakakis vkyriak at forthnet.gr
Thu Apr 6 04:17:07 CDT 2006


Hello Hugh,

       We upgraded to version 3.14 with latest patches. Unfortunately we 
get the same results:

Thu Apr  6 12:03:10 2006: DEBUG: Radius::AuthLDAP2 looks for match with 
biqiqo.ath.forthnet.gr [biqiqo.ath.forthnet.gr at forthnet.gr]
Thu Apr  6 12:03:10 2006: DEBUG: Query is: 'select NASIDENTIFIER, 
NASPORT, hextoint(ACCTSESSIONID) from netman..RADONLINE where 
USERNAME='biqiqo.ath.forthnet.gr'':
Thu Apr  6 12:03:10 2006: DEBUG: Checking if user is still online: 
CiscoDSL, biqiqo.ath.forthnet.gr at forthnet.gr, 194.219.252.148, 2056, 4203759
Thu Apr  6 12:03:10 2006: DEBUG: Cisco: Checking ADSL 4203759-> 
194.219.252.148:2056:biqiqo.ath.forthnet.gr at forthnet.gr
Thu Apr  6 12:03:10 2006: DEBUG: Running command 
`/opt/ucd-snmp/bin/snmpget -c "FORTHNET" 194.219.252.148 
.iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.4203759 2>&1`
Thu Apr  6 12:03:10 2006: DEBUG: Radius::AuthLDAP2 REJECT: 
DefaultSimultaneousUse of 1 exceeded: biqiqo.ath.forthnet.gr 
[biqiqo.ath.forthnet.gr at forthnet.gr]
Thu Apr  6 12:03:10 2006: DEBUG: AuthBy LDAP2 result: REJECT, 
DefaultSimultaneousUse of 1 exceeded

The line
Thu Apr  6 12:03:10 2006: DEBUG: Cisco: Checking ADSL 4203759-> 
194.219.252.148:2056:biqiqo.ath.forthnet.gr at forthnet.gr
is produced by a line we added to the Cisco.pm:

 &main::log($main::LOG_DEBUG, "Cisco: Checking ADSL $session_id-> 
$nas_id:$nas_port:$name" );

So, it seems that username that is passed to Cisco.pm is the original 
username with the realm, and not the one that %U should give.

          Regards
              Vangelis

Hugh Irvine wrote:

>
> Hello Vangelis -
>
> According to the history file this functionality was introduced in  
> Radiator 3.6.
>
> Could you download and install Radiator 3.14 on a clean test server  
> and test it?
>
> Please let me know what you discover.
>
> thanks and regards
>
> Hugh
>
>
> On 31 Mar 2006, at 18:06, Vangelis Kyriakakis wrote:
>
>> Hello Hugh,
>>
>>         We are running 3.7.1. We are a little behind from the  
>> current version. If it is something that was fixed in a later  
>> version we'll upgrade.
>>
>>                               Regards
>>                                   Vangelis
>>
>> Hugh Irvine wrote:
>>
>>>
>>> Hello Vangelis -
>>>
>>> What version of Radiator are you running?
>>>
>>> regards
>>>
>>> Hugh
>>>
>>>
>>> On 30 Mar 2006, at 21:56, Vangelis Kyriakakis wrote:
>>>
>>>> Hello Hugh,
>>>>
>>>>      Thanks for the answer. The username that I want to get back  
>>>> is  the rewritten one, that is the one I allready store in the   
>>>> RADONLINE. But What I get is the full original username. I guess   
>>>> what you told me to do will give me the original username, or am  
>>>> I  wrong?
>>>>
>>>>            Regards
>>>>                 Vangelis Kyriakakis
>>>>
>>>> Hugh Irvine wrote:
>>>>
>>>>>
>>>>> Hello Vangelis -
>>>>>
>>>>> You must extend the RADONLINE table to include a field to  
>>>>> contain  the  original username and modify the AddQuery so it  
>>>>> adds both  the  rewritten username and the original username to  
>>>>> the table.  Then the  fifth field in the CountQuery must be the  
>>>>> original  username.
>>>>>
>>>>> hope that helps
>>>>>
>>>>> regards
>>>>>
>>>>> Hugh
>>>>>
>>>>>
>>>>> On 30 Mar 2006, at 20:43, Vangelis Kyriakakis wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>     I see from the logfiles that Radiator always uses the  
>>>>>> whole   username that is being authenticated as the username  
>>>>>> that is  used  for online confirmation via SNMP.
>>>>>>     The manual says in CountQuery "If a user name is present  as  
>>>>>> the  fifth field returned by the query, that is the user  name  
>>>>>> that will  be used to confirm the user is still on line.".
>>>>>>     Using the following configuration:
>>>>>>
>>>>>> <Handler Client-Identifier=adsl>
>>>>>>        RejectHasReason
>>>>>>        RewriteUsername s/^([^@]+).*/$1/
>>>>>>        AuthBy adsl
>>>>>>        SessionDatabase Session-dsl
>>>>>>        AuthLog logger
>>>>>> </Handler>
>>>>>>
>>>>>> <SessionDatabase SQL>
>>>>>>        Identifier Session-dsl
>>>>>>        DBSource dbi:Sybase:RADIUS
>>>>>>        DBUsername tacacs
>>>>>>        DBAuth xxxxxxx
>>>>>>        Timeout 5
>>>>>>        FailureBackoffTime 5
>>>>>>        AddQuery insert into netman..RADONLINE    
>>>>>> (USERNAME,NASIDENTIFIER,NASPORT,\
>>>>>>                
>>>>>> ACCTSESSIONID,TIME_STAMP,FRAMEDIPADDRESS,NASPORTTYPE,\
>>>>>>               SERVICETYPE) values ('%U','%N',0%{NAS-Port},'%  
>>>>>> {Acct- Session-Id}',\
>>>>>>               %{Timestamp},'%{Framed-IP-Address}','%{NAS-Port-  
>>>>>> Type}',\
>>>>>>               '%{Service-Type}')
>>>>>>        DeleteQuery delete from netman..RADONLINE where    
>>>>>> NASIDENTIFIER='%1' and NASPORT=0%2
>>>>>>        ClearNasQuery delete from netman..RADONLINE where    
>>>>>> NASIDENTIFIER='%N'
>>>>>>        CountQuery select NASIDENTIFIER, NASPORT, hextoint   
>>>>>> (ACCTSESSIONID), FRAMEDIPADDRESS, USERNAME from  
>>>>>> netman..RADONLINE wh
>>>>>> ere USERNAME='%U'
>>>>>> </SessionDatabase>
>>>>>> If the user that is being authenticated is user at domain then    
>>>>>> Radiator always uses user at domain as the username that is  
>>>>>> checked   against the snmpget result although the RADONLINE  
>>>>>> database keeps   only user in the USERNAME field.
>>>>>>
>>>>>>     Am I doing something wrong, or is this a bug?
>>>>>>
>>>>>>                   Regards
>>>>>>                        Vangelis Kyriakakis
>>>>>>
>>>>>> -- 
>>>>>> 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?
>>>>>
>>>>
>>>> -- 
>>>> 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?
>>>
>>
>> -- 
>> 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?
>

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