(RADIATOR) Duplicate Logins

Hugh Irvine hugh at open.com.au
Sun May 13 18:45:23 CDT 2001 

Hello Anton -

The trick in controlling simultaneous use is making sure that the usernames 
are checked correctly. This means being very careful with your 
RewriteUsernames, and possibly altering the session database to hold the 
rewritten values.

The problem is as follows: the NAS merely forwards the string that the user 
enters as his username, with no checking whatsoever. By default, Radiator 
stores the usernames exactly as they arrived from the NAS, so that when a 
comparison is made between the session database and the online user list from 
the NAS, the strings match.

This leads to problems such as you note below - different strings entered on 
the NAS can map to the same user, but they appear different for the purposes 
of simultaneous use limits.

There is no easy solution, but the best approach is usually to store both the 
original string from the NAS *and* the rewritten username in the session 
database and then doing the limit checks with the rewritten version.

You will need to consider your overall strategy and develop a plan 
accordingly.

hth

Hugh


On Sunday 13 May 2001 05:57, Anton Krall wrote:
> Guys
>
> Ive  checked all about duplicate logins in the archives and I must say
> Im confused.
>
> Ive  seen  mails  saying that you have to code... others saying is not
> working...
>
> And  some  more  saying  that if you login as user at domain.com and then
> user at domain.com. the user WILL get in when in fact its the same user.
>
> But my questions is.
>
> Will  it  do the trick if I just put DefaultSimultaneousUse 1 in every
> AuthBy? or whats the trick with it..
>
> Ive  been  able to enable the time checks, and the reject:resaon check
> and some responses... but the Sim User.. no luck so far :(
>
> Any ideas?
>
> Thx
>
> Anton Krall
>
> AK> Will check the archives for this topic.
>
> AK> Thx a lot guys and I must say.. support here is quick :)
>
> AK> Keep up the good work.
>
> AK> Saludos
>
> AK> Anton Krall
> AK> Director de Tecnologia
> AK> Inter.net Mexico
> AK> (www.mx.inter.net)
> AK> Email: akrall at team.inter.net
> AK> Directo: 5-241-7609
> AK> Conmutador: 5-241-7600
> AK> Mobile: 044-5105-5160
>
> AK> Outside Mexico:
> AK> Office: (525)241-7609
> AK> PBX: (525)241-7600
> AK> Mobile: (525)105-5160
>
> AK> ______________________
>
> AK> Saturday, May 12, 2001, 3:32:51 AM, you wrote:
>
>
> HI>> Hello Anton -
>
> HI>> The reason Radiator does a delete when it receives an access request
> is HI>> because an accounting stop may have gone missing. Note that the
> delete is HI>> done on the NAS and NAS=Port combination reported in the
> request, because by HI>> definition there cannot already be a session
> there.
>
> HI>> Notice that your second request is the same as the first, so the first
> record HI>> is deleted, hence the second request is accepted. If you want
> to test HI>> simultaneous use you will have to use different values in your
> requests.
>
> HI>> This topic has been discussed *many* times, so don't forget to check
> the HI>> mailing list archive at www.starport.net/~radiator and do a
> search.
>
> HI>> regards
>
> HI>> Hugh
>
> HI>> On Saturday 12 May 2001 18:24, Anton Krall wrote:
> >>> Guys.
> >>>
> >>> Im trying to implement a no duplicate logins policy but so far no
> >>> luck. Here is my setup:
> >>>
> >>> <Realm akrall.inter.net>
> >>>         RewriteUsername        
> >>> s/^(.*)\@mcm.inter.net$/$1\@mx.inter.net/ RewriteUsername
> >>> s/^([^@]+).*/$1/
> >>>         AuthByPolicy ContinueUntilAccept
> >>>         <AuthBy SQL>
> >>>         DefaultSimultaneousUse 1
> >>>                 DBSource dbi:mysql:menu_mx:sql
> >>>                 DBUsername radius
> >>>                 DBAuth RaDiUs
> >>>                 AuthSelect
> >>>                 AuthColumnDef 0, Encrypted-Password, check
> >>>
> >>> As you can see.. I have DefaultSimultaneousUse 1 set up.
> >>>
> >>> now...
> >>>
> >>> mysql> select * from RADONLINE where username like "akrall%";
> >>> +-------------------------+---------------+---------+---------------+--
> >>>---- ------+-----------------+-------------+-------------+
> >>>
> >>> | USERNAME                | NASIDENTIFIER | NASPORT | ACCTSESSIONID |
> >>> | TIME_STAMP | FRAMEDIPADDRESS | NASPORTTYPE | SERVICETYPE |
> >>>
> >>> +-------------------------+---------------+---------+---------------+--
> >>>---- ------+-----------------+-------------+-------------+
> >>>
> >>> | akrall                  | 154.17.32.21  |    2189 | 331403079     |
> >>> | 989642092 | 200.53.13.161   | Async       |             |
> >>> | akrall at akrall.inter.net | 10.0.0.0      |    1234 | 00001234      |
> >>> | 989651829 |                 | Async       | Framed-User |
> >>>
> >>> +-------------------------+---------------+---------+---------------+--
> >>>---- ------+-----------------+-------------+-------------+
> >>>
> >>> As you can see.. akrall at akrall is already loggied in but when you try
> >>> to login twice:
> >>>
> >>>
> >>> Sat May 12 03:17:09 2001: DEBUG: Rewrote user name to
> >>> akrall at akrall.inter.net Sat May 12 03:17:09 2001: DEBUG: Rewrote user
> >>> name to akrall at akrall.inter.net Sat May 12 03:17:09 2001: DEBUG:
> >>> Handling request with Handler 'Realm=akrall.inter.net' Sat May 12
> >>> 03:17:09 2001: DEBUG: Rewrote user name to akrall at akrall.inter.net Sat
> >>> May 12 03:17:09 2001: DEBUG: Rewrote user name to akrall
> >>> Sat May 12 03:17:09 2001: DEBUG: SDBSQLdialup Deleting session for
> >>> akrall at akrall.inter.net, 10.0.0.0, 1234 Sat May 12 03:17:09 2001:
> >>> DEBUG: do query is: delete from RADONLINE where
> >>> NASIDENTIFIER='10.0.0.0' and NASPORT=01234
> >>>
> >>> Sat May 12 03:17:09 2001: DEBUG: Handling with Radius::AuthSQL
> >>> Sat May 12 03:17:09 2001: DEBUG: Handling with Radius::AuthDBFILE
> >>> Sat May 12 03:17:09 2001: DEBUG: Radius::AuthDBFILE looks for match
> >>> with akrall Sat May 12 03:17:09 2001: DEBUG: Query is: select
> >>> NASIDENTIFIER, NASPORT, ACCTSESSIONID, FRAMEDIPADDRESS from RADONLINE
> >>> where
> >>> USERNAME='akrall at akrall.inter.net'
> >>>
> >>> Sat May 12 03:17:09 2001: DEBUG: Radius::AuthDBFILE ACCEPT:
> >>> Sat May 12 03:17:09 2001: DEBUG: Access accepted for akrall
> >>> Sat May 12 03:17:09 2001: DEBUG: Packet dump:
> >>>
> >>> Why does it first do a Delete Session and then a select on radonline?
> >>>
> >>> The problem is that the second log is getting thru :(
> >>>
> >>> Any ideas?
> >>>
> >>> Thx
> >>>
> >>> Saludos
> >>>
> >>> Anton Krall
> >>> Director de Tecnologia
> >>> Inter.net Mexico
> >>> (www.mx.inter.net)
> >>> Email: akrall at team.inter.net
> >>> Directo: 5-241-7609
> >>> Conmutador: 5-241-7600
> >>> Mobile: 044-5105-5160
> >>>
> >>> Outside Mexico:
> >>> Office: (525)241-7609
> >>> PBX: (525)241-7600
> >>> Mobile: (525)105-5160
> >>>
> >>>
> >>> ===
> >>> 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.
>
> AK> ===
> AK> Archive at http://www.open.com.au/archives/radiator/
> AK> Announcements on radiator-announce at open.com.au
> AK> To unsubscribe, email 'majordomo at open.com.au' with
> AK> '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.
===
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