Re: (RADIATOR) MaxSessions incorrect

2003-12-04 Thread Hugh Irvine
Hello Rodolfo -

If you specify "Simultaneous-Use" as a check item that Radiator is 
configured to use, it will give the sort of error you see if the number 
of sessions is exceeded according to the Radiator session database.

You haven't included your configuration file so I can't say for sure, 
but if you don't want Radiator to do simultaneous use checking at all 
you can specify a NULL session database:


.

regards

Hugh

On 05/12/2003, at 3:00 AM, Rodolfo Torrado López wrote:

Hi there.
 
I have the following case:
I'm using a SQL server stored procedure in order to check the max 
sessions for users.
Every user have a profile radius defined in my DB. In this profile I 
define the attribue "Simultaneous-Use".
Each time that the user try to log on, I verify, using some tables in 
my database, if the user have exceded his max simultaneous use value. 
In this case I return an error to the RAS and the access for this user 
is denied. This work fine.
 
I don't have difined parameters like MaxSessions or 
DefaultSimultaneousUse for any realm in my config file, but some times 
I get the following error:
11/4/2003 7:55:25 PM Access rejected [EMAIL PROTECTED]: MaxSessions 
exceeded
 
How can I tell to Radiator that don't verify the MaxSessions for my 
users?
Until now, my unique solution is restart the service or use radpwtst 
utility.
 
Thanks.
 
Rodolfo Torrado
Barranquilla-Colombia

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, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
===
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) MaxSessions incorrect

2003-12-04 Thread Rodolfo Torrado López



Hi there.
 
I have the following case:
I'm using a SQL server stored procedure in order to 
check the max sessions for users. 
Every user have a profile radius defined in my DB. 
In this profile I define the attribue "Simultaneous-Use". 
Each time that the user try to log on, I verify, using 
some tables in my database, if the user have exceded his max simultaneous use 
value. In this case I return an error to the RAS and the access for this user is 
denied. This work fine.
 
I don't have difined parameters like MaxSessions or 
DefaultSimultaneousUse for any realm in my config file, but some times I get the 
following error:
11/4/2003 7:55:25 PM Access rejected for [EMAIL PROTECTED]: MaxSessions exceeded
 
How can I tell to Radiator that don't verify the 
MaxSessions for my users? 
Until now, my unique solution is restart the service or 
use radpwtst utility.
 
Thanks.
 
Rodolfo Torrado
Barranquilla-Colombia


Re: (RADIATOR) MaxSessions

2003-09-21 Thread Hugh Irvine
Hello Andrea -

Yes this is always a problem if you don't get proper accounting stop 
records.

Radiator is written so that the session database is maintained firstly 
by the accounting starts (insert) and accounting stops (delete), but 
also by the initial access request which causes a delete on the session 
database by using just the NAS-Identifier (or NAS-IP-Address) and the 
NAS-Port. This is based on the "traditional" NAS model in which the 
NAS-Port is unique and can only support one single connection at a 
time. In addition, if your NAS equipement is supported by one of the 
"NasType" options in the  clause, you can configure that as 
well which will cause Radiator to query the NAS to determine whether or 
not a session marked in the session database is still actually 
connected (this may require additional Perl modules and/or NAS 
configuration - check the manual for details).

Hope that helps.

regards

Hugh



On Sunday, Sep 21, 2003, at 10:39 Australia/Melbourne, Andrea 
Brancatelli wrote:

Actually I'm using the MaxSession statement to avoid duplicate login 
to the network. Unfortunately that means that if a client hangs (so he 
doesn't logoff) he cannot re-login until I manually delete the session 
from the RadOnline table.

Is it possible to configure Radiator so that the second connection can 
get trough but would kill the first connection?

Should I use the afterlogin hook? can I have any hint?

:D

Thanks

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


(RADIATOR) MaxSessions

2003-09-20 Thread Andrea Brancatelli




Actually I'm using the MaxSession statement to avoid duplicate login to
the network. Unfortunately that means that if a client hangs (so he
doesn't logoff) he cannot re-login until I manually delete the session
from the RadOnline table.

Is it possible to configure Radiator so that the second connection can
get trough but would kill the first connection?

Should I use the afterlogin hook? can I have any hint?

:D

Thanks




RE: (RADIATOR) MaxSessions per user and per domain

2002-11-20 Thread julio . prada
Forget my last question. I got it!!
It's working fine by now.

cheers,

Julio Prada López
BT Ignite
Isabel Colbrand, 8 2º 28050 Madrid SPAIN
telf: +34 91 270 6152
fax: +34 91 270 6161
mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 
 

-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: miércoles 20 de noviembre de 2002 10:23
Para: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Asunto: RE: (RADIATOR) MaxSessions per user and per domain


Nice! All this is aproaching to what we want to do!

Another question: how could I set a dynamic 'SessionLimit' in AuthBy 
PORTLIMITCHECK clause? Could it be done with a 'DynamicReply' obtained in
a previous Authby LDAP* clause and maped directly to SessionLimit?

cheers,
jules

Julio Prada López
BT Ignite
Isabel Colbrand, 8 2º 28050 Madrid SPAIN
telf: +34 91 270 6152
fax: +34 91 270 6161
mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 
 

-Mensaje original-
De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Enviado el: martes 19 de noviembre de 2002 21:05
Para: "Prada López, Julio" 
Cc: [EMAIL PROTECTED]
Asunto: Re: (RADIATOR) MaxSessions per user and per domain



Hello Julio -

Rather than two session databases, you would use the AuthBy 
PORTLIMITCHECK clause.

See section 6.41 in the Radiator 3.3.1 reference manual 
("doc/ref.html").

regards

Hugh


On Wednesday, Nov 20, 2002, at 01:23 Australia/Melbourne, Prada López, 
Julio wrote:

> Ok, great idea. But it is possible to have two 'sessions databases' in 
> the
> same .cfg with different 'CountQueries' (one for user maxsessionscheck 
> and
> the other for domain maxsessions-check)??
>
> regards,
> jules
>
> Julio Prada López
> BT Ignite
> Isabel Colbrand, 8 2º 28050 Madrid SPAIN
> telf: +34 91 270 6152
> fax: +34 91 270 6161
> mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
> -Mensaje original-
> De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Enviado el: lunes 18 de noviembre de 2002 22:41
> Para: "Prada López, Julio"
> Cc: [EMAIL PROTECTED]
> Asunto: Re: (RADIATOR) MaxSessions per user and per domain
>
>
>
> Hello Julio -
>
> The simplest way to do this is to define two AuthBy LDAP* clauses, one
> for each check.
>
> regards
>
> Hugh
>
>
> On Monday, Nov 18, 2002, at 22:30 Australia/Melbourne, Prada López,
> Julio wrote:
>
>> Hi all,
>>
>> I am trying to configure a Radiator instance to allow controlling both
>> the
>> maximum sessions per user and per domain.
>>
>> Nowadays I have implemented the 'Simultaneous-Use' check with a LDAP
>> atribute and the default query in CountQuery (default query uses
>> [...]where
>> USERNAME=%"u"). That works fine but I'm interested in adding another
>> extra
>> level of controlling sessions by domain (based in LDAP too). I'm
>> thinking in
>> doing some changes in CountQuery ([...]where USERNAME like '%%@%R')
>> but once
>> modified the CountQuery, I supose it will affect the way Radiator
>> check the
>> Simultaneous-Use per user.
>>
>> Any workaround in order to do dual control of sessions per user and 
>> per
>> domain basis?
>> Anyone has implemented this idea? In which way?
>>
>> regards,
>> jules
>>
>> Julio Prada López
>> BT Ignite
>> Isabel Colbrand, 8 2º 28050 Madrid SPAIN
>> telf: +34 91 270 6152
>> fax: +34 91 270 6161
>> mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>>
>> **
>> Noticia legal
>> Este mensaje electrónico contiene información de BT Ignite España
>> S.A.U. que
>> es privada y confidencial, siendo para el uso exclusivo de la persona
>> (s) o
>> entidades arriba mencionadas. Si usted no es el destinatario señalado,
>> le
>> informamos que cualquier divulgación, copia, distribución o uso de los
>> contenidos está prohibida. Si usted ha recibido este mensaje por
>> error, por
>> favor borre su contenido lo antes posible.
>> Gracias.
>> ===
>> 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.
>
> ===
> Archiv

RE: (RADIATOR) MaxSessions per user and per domain

2002-11-20 Thread julio . prada
Nice! All this is aproaching to what we want to do!

Another question: how could I set a dynamic 'SessionLimit' in AuthBy 
PORTLIMITCHECK clause? Could it be done with a 'DynamicReply' obtained in
a previous Authby LDAP* clause and maped directly to SessionLimit?

cheers,
jules

Julio Prada López
BT Ignite
Isabel Colbrand, 8 2º 28050 Madrid SPAIN
telf: +34 91 270 6152
fax: +34 91 270 6161
mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 
 

-Mensaje original-
De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Enviado el: martes 19 de noviembre de 2002 21:05
Para: "Prada López, Julio" 
Cc: [EMAIL PROTECTED]
Asunto: Re: (RADIATOR) MaxSessions per user and per domain



Hello Julio -

Rather than two session databases, you would use the AuthBy 
PORTLIMITCHECK clause.

See section 6.41 in the Radiator 3.3.1 reference manual 
("doc/ref.html").

regards

Hugh


On Wednesday, Nov 20, 2002, at 01:23 Australia/Melbourne, Prada López, 
Julio wrote:

> Ok, great idea. But it is possible to have two 'sessions databases' in 
> the
> same .cfg with different 'CountQueries' (one for user maxsessionscheck 
> and
> the other for domain maxsessions-check)??
>
> regards,
> jules
>
> Julio Prada López
> BT Ignite
> Isabel Colbrand, 8 2º 28050 Madrid SPAIN
> telf: +34 91 270 6152
> fax: +34 91 270 6161
> mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
> -Mensaje original-
> De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Enviado el: lunes 18 de noviembre de 2002 22:41
> Para: "Prada López, Julio"
> Cc: [EMAIL PROTECTED]
> Asunto: Re: (RADIATOR) MaxSessions per user and per domain
>
>
>
> Hello Julio -
>
> The simplest way to do this is to define two AuthBy LDAP* clauses, one
> for each check.
>
> regards
>
> Hugh
>
>
> On Monday, Nov 18, 2002, at 22:30 Australia/Melbourne, Prada López,
> Julio wrote:
>
>> Hi all,
>>
>> I am trying to configure a Radiator instance to allow controlling both
>> the
>> maximum sessions per user and per domain.
>>
>> Nowadays I have implemented the 'Simultaneous-Use' check with a LDAP
>> atribute and the default query in CountQuery (default query uses
>> [...]where
>> USERNAME=%"u"). That works fine but I'm interested in adding another
>> extra
>> level of controlling sessions by domain (based in LDAP too). I'm
>> thinking in
>> doing some changes in CountQuery ([...]where USERNAME like '%%@%R')
>> but once
>> modified the CountQuery, I supose it will affect the way Radiator
>> check the
>> Simultaneous-Use per user.
>>
>> Any workaround in order to do dual control of sessions per user and 
>> per
>> domain basis?
>> Anyone has implemented this idea? In which way?
>>
>> regards,
>> jules
>>
>> Julio Prada López
>> BT Ignite
>> Isabel Colbrand, 8 2º 28050 Madrid SPAIN
>> telf: +34 91 270 6152
>> fax: +34 91 270 6161
>> mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>>
>> **
>> Noticia legal
>> Este mensaje electrónico contiene información de BT Ignite España
>> S.A.U. que
>> es privada y confidencial, siendo para el uso exclusivo de la persona
>> (s) o
>> entidades arriba mencionadas. Si usted no es el destinatario señalado,
>> le
>> informamos que cualquier divulgación, copia, distribución o uso de los
>> contenidos está prohibida. Si usted ha recibido este mensaje por
>> error, por
>> favor borre su contenido lo antes posible.
>> Gracias.
>> ===
>> 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.
>
> ===
> 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.
>
> **
> Noticia legal
> Este mensaje electrónico contiene información de BT Ignite España 
> S.A.U. que
> es privada y confidencial, siendo para el uso exclusivo de la persona 
> (s) o
> entidades

Re: (RADIATOR) MaxSessions per user and per domain

2002-11-19 Thread Hugh Irvine

Hello Julio -

Rather than two session databases, you would use the AuthBy 
PORTLIMITCHECK clause.

See section 6.41 in the Radiator 3.3.1 reference manual 
("doc/ref.html").

regards

Hugh


On Wednesday, Nov 20, 2002, at 01:23 Australia/Melbourne, Prada López, 
Julio wrote:

Ok, great idea. But it is possible to have two 'sessions databases' in 
the
same .cfg with different 'CountQueries' (one for user maxsessionscheck 
and
the other for domain maxsessions-check)??

regards,
jules

Julio Prada López
BT Ignite
Isabel Colbrand, 8 2º 28050 Madrid SPAIN
telf: +34 91 270 6152
fax: +34 91 270 6161
mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>


-Mensaje original-
De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Enviado el: lunes 18 de noviembre de 2002 22:41
Para: "Prada López, Julio"
Cc: [EMAIL PROTECTED]
Asunto: Re: (RADIATOR) MaxSessions per user and per domain



Hello Julio -

The simplest way to do this is to define two AuthBy LDAP* clauses, one
for each check.

regards

Hugh


On Monday, Nov 18, 2002, at 22:30 Australia/Melbourne, Prada López,
Julio wrote:

Hi all,

I am trying to configure a Radiator instance to allow controlling both
the
maximum sessions per user and per domain.

Nowadays I have implemented the 'Simultaneous-Use' check with a LDAP
atribute and the default query in CountQuery (default query uses
[...]where
USERNAME=%"u"). That works fine but I'm interested in adding another
extra
level of controlling sessions by domain (based in LDAP too). I'm
thinking in
doing some changes in CountQuery ([...]where USERNAME like '%%@%R')
but once
modified the CountQuery, I supose it will affect the way Radiator
check the
Simultaneous-Use per user.

Any workaround in order to do dual control of sessions per user and 
per
domain basis?
Anyone has implemented this idea? In which way?

regards,
jules

Julio Prada López
BT Ignite
Isabel Colbrand, 8 2º 28050 Madrid SPAIN
telf: +34 91 270 6152
fax: +34 91 270 6161
mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

**
Noticia legal
Este mensaje electrónico contiene información de BT Ignite España
S.A.U. que
es privada y confidencial, siendo para el uso exclusivo de la persona
(s) o
entidades arriba mencionadas. Si usted no es el destinatario señalado,
le
informamos que cualquier divulgación, copia, distribución o uso de los
contenidos está prohibida. Si usted ha recibido este mensaje por
error, por
favor borre su contenido lo antes posible.
Gracias.
===
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.

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

**
Noticia legal
Este mensaje electrónico contiene información de BT Ignite España 
S.A.U. que
es privada y confidencial, siendo para el uso exclusivo de la persona 
(s) o
entidades arriba mencionadas. Si usted no es el destinatario señalado, 
le
informamos que cualquier divulgación, copia, distribución o uso de los
contenidos está prohibida. Si usted ha recibido este mensaje por 
error, por
favor borre su contenido lo antes posible.
Gracias.



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



RE: (RADIATOR) MaxSessions per user and per domain

2002-11-19 Thread "Prada López, Julio"
Ok, great idea. But it is possible to have two 'sessions databases' in the
same .cfg with different 'CountQueries' (one for user maxsessionscheck and
the other for domain maxsessions-check)??

regards,
jules

Julio Prada López
BT Ignite
Isabel Colbrand, 8 2º 28050 Madrid SPAIN
telf: +34 91 270 6152
fax: +34 91 270 6161
mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 
 

-Mensaje original-
De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Enviado el: lunes 18 de noviembre de 2002 22:41
Para: "Prada López, Julio"
Cc: [EMAIL PROTECTED]
Asunto: Re: (RADIATOR) MaxSessions per user and per domain



Hello Julio -

The simplest way to do this is to define two AuthBy LDAP* clauses, one 
for each check.

regards

Hugh


On Monday, Nov 18, 2002, at 22:30 Australia/Melbourne, Prada López, 
Julio wrote:

> Hi all,
>
> I am trying to configure a Radiator instance to allow controlling both 
> the
> maximum sessions per user and per domain.
>
> Nowadays I have implemented the 'Simultaneous-Use' check with a LDAP
> atribute and the default query in CountQuery (default query uses 
> [...]where
> USERNAME=%"u"). That works fine but I'm interested in adding another 
> extra
> level of controlling sessions by domain (based in LDAP too). I'm 
> thinking in
> doing some changes in CountQuery ([...]where USERNAME like '%%@%R') 
> but once
> modified the CountQuery, I supose it will affect the way Radiator 
> check the
> Simultaneous-Use per user.
>
> Any workaround in order to do dual control of sessions per user and per
> domain basis?
> Anyone has implemented this idea? In which way?
>
> regards,
> jules
>
> Julio Prada López
> BT Ignite
> Isabel Colbrand, 8 2º 28050 Madrid SPAIN
> telf: +34 91 270 6152
> fax: +34 91 270 6161
> mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
> **
> Noticia legal
> Este mensaje electrónico contiene información de BT Ignite España 
> S.A.U. que
> es privada y confidencial, siendo para el uso exclusivo de la persona 
> (s) o
> entidades arriba mencionadas. Si usted no es el destinatario señalado, 
> le
> informamos que cualquier divulgación, copia, distribución o uso de los
> contenidos está prohibida. Si usted ha recibido este mensaje por 
> error, por
> favor borre su contenido lo antes posible.
> Gracias.
> ===
> 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.

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

** 
Noticia legal 
Este mensaje electrónico contiene información de BT Ignite España S.A.U. que
es privada y confidencial, siendo para el uso exclusivo de la persona (s) o
entidades arriba mencionadas. Si usted no es el destinatario señalado, le
informamos que cualquier divulgación, copia, distribución o uso de los
contenidos está prohibida. Si usted ha recibido este mensaje por error, por
favor borre su contenido lo antes posible. 
Gracias.
===
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.



Re: (RADIATOR) MaxSessions per user and per domain

2002-11-18 Thread Hugh Irvine

Hello Julio -

The simplest way to do this is to define two AuthBy LDAP* clauses, one 
for each check.

regards

Hugh


On Monday, Nov 18, 2002, at 22:30 Australia/Melbourne, Prada López, 
Julio wrote:

Hi all,

I am trying to configure a Radiator instance to allow controlling both 
the
maximum sessions per user and per domain.

Nowadays I have implemented the 'Simultaneous-Use' check with a LDAP
atribute and the default query in CountQuery (default query uses 
[...]where
USERNAME=%"u"). That works fine but I'm interested in adding another 
extra
level of controlling sessions by domain (based in LDAP too). I'm 
thinking in
doing some changes in CountQuery ([...]where USERNAME like '%%@%R') 
but once
modified the CountQuery, I supose it will affect the way Radiator 
check the
Simultaneous-Use per user.

Any workaround in order to do dual control of sessions per user and per
domain basis?
Anyone has implemented this idea? In which way?

regards,
jules

Julio Prada López
BT Ignite
Isabel Colbrand, 8 2º 28050 Madrid SPAIN
telf: +34 91 270 6152
fax: +34 91 270 6161
mail: [EMAIL PROTECTED] 

**
Noticia legal
Este mensaje electrónico contiene información de BT Ignite España 
S.A.U. que
es privada y confidencial, siendo para el uso exclusivo de la persona 
(s) o
entidades arriba mencionadas. Si usted no es el destinatario señalado, 
le
informamos que cualquier divulgación, copia, distribución o uso de los
contenidos está prohibida. Si usted ha recibido este mensaje por 
error, por
favor borre su contenido lo antes posible.
Gracias.
===
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.

===
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) MaxSessions per user and per domain

2002-11-18 Thread "Prada López, Julio"
Hi all,

I am trying to configure a Radiator instance to allow controlling both the
maximum sessions per user and per domain.

Nowadays I have implemented the 'Simultaneous-Use' check with a LDAP
atribute and the default query in CountQuery (default query uses [...]where
USERNAME=%"u"). That works fine but I'm interested in adding another extra
level of controlling sessions by domain (based in LDAP too). I'm thinking in
doing some changes in CountQuery ([...]where USERNAME like '%%@%R') but once
modified the CountQuery, I supose it will affect the way Radiator check the
Simultaneous-Use per user.

Any workaround in order to do dual control of sessions per user and per
domain basis?
Anyone has implemented this idea? In which way?

regards,
jules

Julio Prada López
BT Ignite
Isabel Colbrand, 8 2º 28050 Madrid SPAIN
telf: +34 91 270 6152
fax: +34 91 270 6161
mail: [EMAIL PROTECTED]  

** 
Noticia legal 
Este mensaje electrónico contiene información de BT Ignite España S.A.U. que
es privada y confidencial, siendo para el uso exclusivo de la persona (s) o
entidades arriba mencionadas. Si usted no es el destinatario señalado, le
informamos que cualquier divulgación, copia, distribución o uso de los
contenidos está prohibida. Si usted ha recibido este mensaje por error, por
favor borre su contenido lo antes posible. 
Gracias.
===
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.



Re: (RADIATOR) MaxSessions

2002-02-03 Thread Hugh Irvine


Hello Robert -

Both the NAS and Radiator consider case differences as different usernames, 
so the answer to your question is no - the RewriteUsername has no bearing. As 
mentioned previously, the only way to deal with the problem is with a session 
database that stores both the original and the rewritten usernames. You can 
continue to use the original username for checking the NAS, and you can use 
the rewritten username to check simultaneous use.

regards

Hugh


On Sat, 2 Feb 2002 19:37, Robert wrote:
> Hugh,
>
> I assume that it won't allow the uppercase to log in if I don't use the
> rewrite username also?
>
> Thanks,
> Robert
>
> Hugh Irvine wrote:
> > Hello Robert -
> >
> > Radiator maintains the session database with the username as entered on
> > the NAS. If you want to do login limits based on the rewritten username,
> > you should use an SQL session database and redefine the queries to use
> > the rewritten username.
> >
> > regards
> >
> > Hugh
> >
> > On Sat, 2 Feb 2002 17:45, Robert wrote:
> > > Hello,
> > >
> > > I've recently started using the MaxSession clause in my default realm
> > > and see something strange.  It would appear that it's working properly
> > > and only allowing the user to login once unless the user uses a capital
> > > letter in their username (ie bert and Bert are being treated as
> > > different usernames).  I am using the following in my default realm:
> > >
> > > RewriteUsername tr/A-Z/a-z/
> > > RewriteUsername s/^([^@]+).*/$1/
> > >
> > > I assume this is the reason for the behaviour described above?  If it
> > > makes and difference, I'm running Radiator-2.14.1 on BSDI 4.01.
> > >
> > > Is there a way of disabling this?
> > >
> > > Thank you in advance,
> > > Robert
> > >
> > > ===
> > > 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.

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



Re: (RADIATOR) MaxSessions

2002-02-02 Thread Robert

Hugh,

I assume that it won't allow the uppercase to log in if I don't use the
rewrite username also?

Thanks,
Robert

Hugh Irvine wrote:
> 
> Hello Robert -
> 
> Radiator maintains the session database with the username as entered on the
> NAS. If you want to do login limits based on the rewritten username, you
> should use an SQL session database and redefine the queries to use the
> rewritten username.
> 
> regards
> 
> Hugh
> 
> On Sat, 2 Feb 2002 17:45, Robert wrote:
> > Hello,
> >
> > I've recently started using the MaxSession clause in my default realm
> > and see something strange.  It would appear that it's working properly
> > and only allowing the user to login once unless the user uses a capital
> > letter in their username (ie bert and Bert are being treated as
> > different usernames).  I am using the following in my default realm:
> >
> > RewriteUsername tr/A-Z/a-z/
> > RewriteUsername s/^([^@]+).*/$1/
> >
> > I assume this is the reason for the behaviour described above?  If it
> > makes and difference, I'm running Radiator-2.14.1 on BSDI 4.01.
> >
> > Is there a way of disabling this?
> >
> > Thank you in advance,
> > Robert
> >
> > ===
> > 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.

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



Re: (RADIATOR) MaxSessions

2002-02-02 Thread Hugh Irvine


Hello Robert -

Radiator maintains the session database with the username as entered on the 
NAS. If you want to do login limits based on the rewritten username, you 
should use an SQL session database and redefine the queries to use the 
rewritten username.

regards

Hugh

On Sat, 2 Feb 2002 17:45, Robert wrote:
> Hello,
>
> I've recently started using the MaxSession clause in my default realm
> and see something strange.  It would appear that it's working properly
> and only allowing the user to login once unless the user uses a capital
> letter in their username (ie bert and Bert are being treated as
> different usernames).  I am using the following in my default realm:
>
> RewriteUsername tr/A-Z/a-z/
> RewriteUsername s/^([^@]+).*/$1/
>
> I assume this is the reason for the behaviour described above?  If it
> makes and difference, I'm running Radiator-2.14.1 on BSDI 4.01.
>
> Is there a way of disabling this?
>
> Thank you in advance,
> Robert
>
> ===
> 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.
===
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) MaxSessions

2002-02-01 Thread Robert

Hello,

I've recently started using the MaxSession clause in my default realm
and see something strange.  It would appear that it's working properly
and only allowing the user to login once unless the user uses a capital
letter in their username (ie bert and Bert are being treated as
different usernames).  I am using the following in my default realm:

RewriteUsername tr/A-Z/a-z/  
RewriteUsername s/^([^@]+).*/$1/

I assume this is the reason for the behaviour described above?  If it
makes and difference, I'm running Radiator-2.14.1 on BSDI 4.01.

Is there a way of disabling this?

Thank you in advance,
Robert

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



Re: (RADIATOR) MaxSessions Problem

2002-01-03 Thread Hugh Irvine


Hello Alejandro -

You have to be careful when using radpwtst to test simultaneous use because 
radpwtst uses the same NAS-Port and NAS-IP-Address by default for each 
request. This will cause the first session to be deleted before the second 
session is tested. Also note that radpwtst also sends both an accounting 
start and an accounting stop which will also clear the session.

If you still have problems, please send me a trace 4 debug from Radiator 
showing what is going on.

regards

Hugh


On Thu, 3 Jan 2002 23:46, Alejandro Secades Gomez wrote:
> I am trying to avoid any user to have more than one simultaneous session. I
> do it with:
>
> 
>...
> MaxSessions 1
>...
> 
>
> but it doesn't seem to work. It even does not work when I test it with
> radpwtst (sending an Access-Request and a Start Accounting-Request and then
> sending them again).
>
> We use a plain file (we are testing) to hold our users database, so we use
> a SQL database only to manage IP addresses. We have only one table RADPOOL.
> ¿Do we need any other accounting tables in our database to work with
> MaxSessions? Our real NAS is a 3COM one.
>
> Thanks a lot.
>
> P.D. our config file:
> #
> Foreground
>
> LogStdout
>
> LogDir  /perl/radiator/log
> LogFile /perl/radiator/log/radius.log
>
> AuthPort1645
> AcctPort1646
>
> DbDir   /perl/radiator/config
> DictionaryFile  /perl/radiator/config/diccionario.txt
>
> Trace   4
>
> 
> Secret  
> DupInterval 2
> 
>
> 
> Identifier dir_reales
> DefaultLeasePeriod  28800
>
> DBSourcedbi:ODBC:ip_internet
>
> #we don't care about Pool. They are all the same.
> FindQuery   select TIME_STAMP,YIADDR,SUBNETMASK,DNSSERVER \
> from RADPOOL where STATE=0 order by TIME_STAMP
>
> 
> Subnetmask 255.255.255.255
> DNSServer  195.55.30.16
> Range  195.55.30.100 195.55.31.255
> 
> 
> Subnetmask 255.255.255.255
> DNSServer  195.55.30.16
> Range  195.55.100.1 195.55.101.255
> 
> 
>
> 
> PasswordLogFileName /perl/radiator/log/passwd.log
> AcctLogFileName /perl/radiator/log/acct.log
>
> #permitir una sesión por usuario
> MaxSessions 1
> AuthByPolicy ContinueWhileAccept
> RewriteUsername s/^([^@]+)\@princast/$1/
>
> 
>   Filename  %D/usuinfovia.txt
>
>   AddToReply Service-Type=Framed-User,Framed-Protocol=PPP,\
>  Framed-Routing=None,Framed-Compression=None,\
>  Ascend-Idle-Limit=1,Ascend-Maximum-Time=0,\
>  User-Name=%u,Ascend-Metric=2
> 
>
> 
> Allocatordir_reales
> 
> 
>
>
>
>
> --
> Alejandro Secades Gómez.
> Administrador de Sistemas.
> Explotación y Sistemas. Gob. del  Principado  de Asturias.
> [EMAIL PROTECTED] / [EMAIL PROTECTED]
> 985105342 (int. 5342)
> móvil desde PA: ext. 7236
>
> ===
> 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.
===
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) MaxSessions Problem

2002-01-03 Thread Alejandro Secades Gomez

I am trying to avoid any user to have more than one simultaneous session. I do it with:


   ...
MaxSessions 1
   ...


but it doesn't seem to work. It even does not work when I test it with radpwtst 
(sending an Access-Request and a Start Accounting-Request and then sending them again).

We use a plain file (we are testing) to hold our users database, so we use a SQL 
database only to manage IP addresses. We have only one table RADPOOL. ¿Do we need any 
other accounting tables in our database to work with MaxSessions? Our real NAS is a 
3COM one.

Thanks a lot.

P.D. our config file:
#
Foreground

LogStdout

LogDir  /perl/radiator/log
LogFile /perl/radiator/log/radius.log

AuthPort1645
AcctPort1646

DbDir   /perl/radiator/config
DictionaryFile  /perl/radiator/config/diccionario.txt

Trace   4


Secret  
DupInterval 2



Identifier dir_reales
DefaultLeasePeriod  28800

DBSourcedbi:ODBC:ip_internet

#we don't care about Pool. They are all the same.
FindQuery   select TIME_STAMP,YIADDR,SUBNETMASK,DNSSERVER \
from RADPOOL where STATE=0 order by TIME_STAMP


Subnetmask 255.255.255.255
DNSServer  195.55.30.16
Range  195.55.30.100 195.55.31.255


Subnetmask 255.255.255.255
DNSServer  195.55.30.16
Range  195.55.100.1 195.55.101.255




PasswordLogFileName /perl/radiator/log/passwd.log
AcctLogFileName /perl/radiator/log/acct.log

#permitir una sesión por usuario
MaxSessions 1
AuthByPolicy ContinueWhileAccept
RewriteUsername s/^([^@]+)\@princast/$1/


  Filename  %D/usuinfovia.txt

  AddToReply Service-Type=Framed-User,Framed-Protocol=PPP,\
 Framed-Routing=None,Framed-Compression=None,\
 Ascend-Idle-Limit=1,Ascend-Maximum-Time=0,\
 User-Name=%u,Ascend-Metric=2



Allocatordir_reales






--
Alejandro Secades Gómez.
Administrador de Sistemas.
Explotación y Sistemas. Gob. del  Principado  de Asturias.
[EMAIL PROTECTED] / [EMAIL PROTECTED]
985105342 (int. 5342)
móvil desde PA: ext. 7236

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



Re: (RADIATOR) Maxsessions

2001-10-05 Thread Hugh Irvine


Hello Todd -

On Saturday 06 October 2001 02:32, Todd Dokey wrote:
> Is there a way to enforce MaxSessions across different Clients?
>
> I have a problem with people using the same login in San Francisco and Los
> Angeles.
>
> By and large, they both are dealt with by the Default Client and Default
> handler.. so I thought it would keep a database of this okay.
>
> Does Radiator keep a separate session list per client or handler?
>

MaxSessions are set on a per handler basis, so requests from different 
clients shouldn't pose a problem.

To say any more I will need to see a copy of the configuration file (no 
secrets) together with a trace 4 debug showing what is happening.

thanks

Hugh
===
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) Maxsessions

2001-10-05 Thread Todd Dokey

Is there a way to enforce MaxSessions across different Clients?

I have a problem with people using the same login in San Francisco and Los
Angeles.

By and large, they both are dealt with by the Default Client and Default
handler.. so I thought it would keep a database of this okay.

Does Radiator keep a separate session list per client or handler?


If you run, you'll only die tired...

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



Re: (RADIATOR) MaxSessions

2001-09-14 Thread Hugh Irvine


Hello Todd -

On Saturday 15 September 2001 03:04, Todd Dokey wrote:
> MaxSessions won't work under text right?
>
> Don't I need a master online calls table of somekind?
>

Radiator always uses an Internal session database in any case, even if an 
external session database is not specified.

> Can I use authby radius and authby text, but check accounting on Emerald's
> calls table?
>

Yes (although there is no AuthBy TEXT).

BTW - I strongly encourage you to read the rfc's and the reference manual 
included in the "doc" directory of the Radiator distribution (at least once).

hth

Hugh


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



(RADIATOR) MaxSessions

2001-09-14 Thread Todd Dokey

MaxSessions won't work under text right?

Don't I need a master online calls table of somekind?

Can I use authby radius and authby text, but check accounting on Emerald's
calls table?

-
"We sleep safe in our beds because rough men stand ready in the night to
visit violence on those who would do us harm."
George Orwell


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



Re: (RADIATOR) MaxSessions

2001-08-29 Thread Hugh Irvine


Hello Harrison -

What version of Radiator are you running?

This problem was fixed in Radiator 2.18.1:

>Fixed a problem with Handlers where a MaxSessions denial
   would still permit AuthBys to run and perhaps 2 replies to be
   returned. Reported by Frederic Gargula   

regards

Hugh


On Thursday 30 August 2001 12:05, Harrison Ng wrote:

> > Hello,
>
> Is it possible to prevent executing AuthBy clauses when MaxSessions exceeds
> (within a Handler).
>
> When radiator receives Access-Request, it determine an appropriate handler
> to process request.
> Then it checks whether the user has reach MaxSessions.
> In this case user has reach MaxSessions, therefore it should send
> Access-Reject to NAS and stop executing AuthBy clauses.
> However radiator still go through the clauses and eventually send out
> Access-Accept to NAS.
> At the same time, our NAS takes in Access-Accept and open a PPP session.
>
> Pls find attached trace 4 capture and extracts of our radius.cfg.
> Can anyone give us a hint.
>
> Harrison
> SmarTone BroadBand Services Limited
>
>
>
>
>  <>  <>


Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1"
Content-Transfer-Encoding: quoted-printable
Content-Description: 



Content-Type: text/plain; charset="iso-8859-1"; name="MaxSession.txt"
Content-Transfer-Encoding: quoted-printable
Content-Description: 



Content-Type: application/octet-stream; charset="iso-8859-1"; 
name="radius.cfg"
Content-Transfer-Encoding: quoted-printable
Content-Description: 


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



(RADIATOR) MaxSessions

2001-08-29 Thread Harrison Ng
Title: MaxSessions





Hello,


Is it possible to prevent executing AuthBy clauses when MaxSessions exceeds (within a Handler).


When radiator receives Access-Request, it determine an appropriate handler to process request.
Then it checks whether the user has reach MaxSessions.
In this case user has reach MaxSessions, therefore it should send Access-Reject to NAS and stop executing AuthBy clauses.

However radiator still go through the clauses and eventually send out Access-Accept to NAS.
At the same time, our NAS takes in Access-Accept and open a PPP session.


Pls find attached trace 4 capture and extracts of our radius.cfg.
Can anyone give us a hint.


Harrison
SmarTone BroadBand Services Limited





 <>  <> 




Wed Aug 29 16:19:49 2001: DEBUG: Packet dump:
*** Received from 202.140.97.153 port 1812 
Code:   Access-Request
Identifier: 0
Authentic:  )<222><174><255>o<233>6<245><137>.<163>:<215>6<225><244>
Attributes:
User-Name = "[EMAIL PROTECTED]"
User-Password = "<29>3FVW{V<30><27>5k<249><151><1><207>["
NAS-Identifier = "LAPB01"
NAS-IP-Address = 202.140.97.153
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port = 100663738

Wed Aug 29 16:19:49 2001: DEBUG: Check if Handler User-Name = /(?![\w\.\-@])+/ should 
be used to handle this request
Wed Aug 29 16:19:49 2001: DEBUG: Check if Handler Client-Id = 202.67.215.60 should be 
used to handle this request
Wed Aug 29 16:19:49 2001: DEBUG: Check if Handler Client-Id = 202.67.215.240 should be 
used to handle this request
Wed Aug 29 16:19:49 2001: DEBUG: Check if Handler Client-Id = 10.20.2.2 should be used 
to handle this request
Wed Aug 29 16:19:49 2001: DEBUG: Check if Handler Client-Id = 202.140.97.152 should be 
used to handle this request
Wed Aug 29 16:19:49 2001: DEBUG: Check if Handler Client-Id = 202.140.97.153 should be 
used to handle this request
Wed Aug 29 16:19:49 2001: DEBUG: Handling request with Handler 'Client-Id = 
202.140.97.153'
Wed Aug 29 16:19:49 2001: DEBUG: Rewrote user name to fieldsvc
Wed Aug 29 16:19:49 2001: DEBUG: bras Deleting session for 
[EMAIL PROTECTED], 202.140.97.153, 100663738
Wed Aug 29 16:19:49 2001: DEBUG: do query is: delete from BBONLINE where 
NASIDENTIFIER='202.140.97.153' and NASPORT=100663738

Wed Aug 29 16:19:49 2001: DEBUG: Query is: select NASIDENTIFIER,NASPORT from BBONLINE 
where USERNAME='[EMAIL PROTECTED]
'

Wed Aug 29 16:19:49 2001: DEBUG: Checking if user is still online: unknown, 
[EMAIL PROTECTED], 202.140.97.153, 10066400
0,
Wed Aug 29 16:19:49 2001: INFO: Access rejected for fieldsvc: MaxSessions exceeded
Wed Aug 29 16:19:49 2001: DEBUG: Packet dump:
*** Sending to 202.140.97.153 port 1812 
Code:   Access-Reject
Identifier: 0
Authentic:  )<222><174><255>o<233>6<245><137>.<163>:<215>6<225><244>
Attributes:
Reply-Message = "Request Denied"
Reply-Message = "MaxSessions exceeded"

Wed Aug 29 16:19:49 2001: DEBUG: Handling with Radius::AuthGROUP
Wed Aug 29 16:19:49 2001: DEBUG: Handling with Radius::AuthLDAPwOBJ
Wed Aug 29 16:19:49 2001: DEBUG: Connecting to 202.140.96.53, port 389
Wed Aug 29 16:19:49 2001: DEBUG: LDAP got result for 
cn=fieldsvc,ou=People,o=SmarTone,c=hk
Wed Aug 29 16:19:49 2001: DEBUG: LDAP got authserviceprotocol: Framed-User
Wed Aug 29 16:19:49 2001: DEBUG: LDAP got framedprotocol: PPP
Wed Aug 29 16:19:49 2001: DEBUG: LDAP got sessiontimeoutnumber: 86000
Wed Aug 29 16:19:49 2001: DEBUG: LDAP got userpassword: {crypt}vt3QIHUqVTcGE
Wed Aug 29 16:19:49 2001: DEBUG: Radius::AuthLDAPwOBJ looks for match with fieldsvc
Wed Aug 29 16:19:49 2001: DEBUG: Radius::AuthLDAPwOBJ ACCEPT:
Wed Aug 29 16:19:49 2001: DEBUG: Handling with Radius::AuthGROUP
Wed Aug 29 16:19:49 2001: DEBUG: Handling with Radius::AuthSQL
Wed Aug 29 16:19:49 2001: DEBUG: Handling with Radius::AuthSQL
Wed Aug 29 16:19:49 2001: DEBUG: Query is: select FRAMEDIPADDRESS from SUBSCRIBERS 
where USERNAME='fieldsvc'

Wed Aug 29 16:19:49 2001: DEBUG: Radius::AuthSQL looks for match with fieldsvc
Wed Aug 29 16:19:49 2001: DEBUG: Radius::AuthSQL ACCEPT:
Wed Aug 29 16:19:49 2001: DEBUG: Access accepted for fieldsvc
Wed Aug 29 16:19:49 2001: DEBUG: Packet dump:
*** Sending to 202.140.97.153 port 1812 
Code:   Access-Accept
Identifier: 0
Authentic:  )<222><174><255>o<233>6<245><137>.<163>:<215>6<225><244>
Attributes:
Reply-Message = "Request Denied"
Reply-Message = "MaxSessions exceeded"
Service-Type = Framed-User
Framed-Protocol = PPP
Session-Timeout = 86000
Framed-IP-Address = 203.133.144.3

Wed Aug 29 16:19:51 2001: DEBUG: Packet dump:
*** Received from 202.140.97.153 port 1812 
Code:   Accounting-Request
Identifier: 0
Authentic:  ?'<6><192>m?<193><16><4>?Op<255><206>s@
Attributes:
User-Name = "[EMAIL PROTECTED]"
NAS-Identifier = "LAPB01"
NAS-IP-Address = 202.140.97.153
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port =

Re: (RADIATOR) MaxSessions issue, still a problem

2001-07-16 Thread Hugh Irvine


Hello Dave, Hello Dmitry -

The problem is that Radiator does a delete on reception of an access request 
as well as when it gets an accounting stop. This in addition to the fact that 
by default, Radiator always uses the username string received from the NAS 
(which it must do if it is to do strict checking).

Hence my recommendation to either store both forms of the username in an SQL 
session database and use custom queries, or to rewrite the usernames prior to 
them getting to the instance of Radiator that is doing simultaneous use 
checking.

regards

Hugh


On Monday 16 July 2001 23:05, Kitabjian, Dave wrote:
> Hello,
>
> I didn't read the entire thread, but couldn't you just do this:
>
> 
>
>   # strip off realm:
>   RewriteUsername s/^([^@]+).*/$1/
>
> 
>
> ? If I neglected to read something, I apologize in advance.
>
> Dave
>
> > On Friday 13 July 2001 20:58, Dmitry Kopylov wrote:
> > > Hello,
> > >
> > > and the problem here is that NAS generates the
> >
> > Access-Request in form
> >
> > > "username@realm", proxy stripes off the the realmname and
> >
> > my Radiator
> >
> > > receives just "username". Whereas the accounting request approaches
> > > the Radiator in its original form e.g. "username@realm". So the
> > > session database is built up based on the "username@realm"
> >
> > and not on
> >
> > > the "username". The question here is if it's possible to
> >
> > rewrite the
> >
> > > User-Name in Accounting request?  Or maybe there is another
> >
> > solution?
> >
> > > regards,
> > > Dmitry Kopylov
>
> ===
> 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.
===
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.



RE: (RADIATOR) MaxSessions issue, still a problem

2001-07-16 Thread Kitabjian, Dave

Hello,

I didn't read the entire thread, but couldn't you just do this:



# strip off realm:
RewriteUsername s/^([^@]+).*/$1/



? If I neglected to read something, I apologize in advance.

Dave

> On Friday 13 July 2001 20:58, Dmitry Kopylov wrote:
> > Hello,
> >
> > and the problem here is that NAS generates the 
> Access-Request in form 
> > "username@realm", proxy stripes off the the realmname and 
> my Radiator 
> > receives just "username". Whereas the accounting request approaches 
> > the Radiator in its original form e.g. "username@realm". So the 
> > session database is built up based on the "username@realm" 
> and not on 
> > the "username". The question here is if it's possible to 
> rewrite the 
> > User-Name in Accounting request?  Or maybe there is another 
> solution?
> >
> > regards,
> > Dmitry Kopylov
===
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.



Re: (RADIATOR) MaxSessions issue, still a problem

2001-07-13 Thread Hugh Irvine


Hello Dmitry -

I see.

I think you have two choices: first (prefered) is to change the proxy so it 
sends you all requests with the realm intact, and second is to add an 
additional proxy in front of your Radiator that only rewrites the usernames. 
The only way that the session database is going to work reliably is if it 
always gets the usernames in the same format.

regards

Hugh


On Friday 13 July 2001 20:58, Dmitry Kopylov wrote:
> Hello,
>
> and the problem here is that NAS generates the Access-Request in form
> "username@realm", proxy stripes off the the realmname and my Radiator
> receives just "username". Whereas the accounting request approaches the
> Radiator in its original form e.g. "username@realm". So the session
> database is built up based on the "username@realm" and not on the
> "username". The question here is if it's possible to rewrite the User-Name
> in Accounting request?  Or maybe there is another solution?
>
> regards,
> Dmitry Kopylov
>
> -Original Message-
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 13, 2001 8:43 AM
> To: Vangelis Kyriakakis; [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) MaxSessions issue, still a problem
>
>
>
> Hello Vangelis -
>
> Actually, an internal session database is exactly that - a session database
> held entirely in memory. The username in each request is what is used, as
> follows: Access-Request - check current sessions and reject if limit
> exceeded, Accounting Start - add new record, Accounting Start - delete
> record.
>
> regards
>
> Hugh
>
> On Thursday 12 July 2001 22:33, Vangelis Kyriakakis wrote:
> > I think the problem when you use the Internal session database is that it
> > uses the username from the Accounting file to count the number of
>
> sessions.
>
> > When a new user logs in it checks the rewritten username against the
> > session database. So it checks with the name uunoc and not with the
> > [EMAIL PROTECTED] and sees that it hasn't logged in again. I had the same
> > problem with small and capital letters.
> >Maxsession 0 works always since it's no need to check the session
> > database...
> >
> >Vangelis
> >
> > Dmitry Kopylov wrote:
> > > Hi,
> > >
> > > I upgraded to the 18.2.2 but the problem with MaxSession still exists.
> > > Here is part of config and trace 4 output:
> > >
> > > 
> > > RewriteUsername s/^([^@]+).*/$1/
> > > MaxSessions 1
> > > 
> > > 
> > > AcctLogFileName %L/bbeyond/details
> > > PasswordLogFileName %L/bbeyond/uunet-passwords.log
> > > 
> > >
> > > If I set MaxSessions 0, it works and rejects all sessions, but when I
>
> set
>
> > > MaxSessions to 1 it allows the second connection with the same
> > > username.
> > >
> > > MaxSessions 0:
> > >
> > > Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
> > > /opt/radiator-2.18/raddb/users
> > > Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
> > > /opt/radiator-2.18/raddb/users
> > > Thu Jul 12 11:30:06 2001: INFO: Server started: Radiator 2.18.2 on
> > > bbyrad1.bbeyond.nl
> > > Thu Jul 12 11:30:25 2001: DEBUG: Packet dump:
> > > *** Received from 62.177.149.2 port 1645 
> > > Code:   Access-Request
> > > Identifier: 102
> > > Authentic:  z<211><178><22><170><220><204><200><219>w6<5>;<11>>:
> > > Attributes:
> > > User-Name = "[EMAIL PROTECTED]"
> > > User-Password = "_<178><219>A<0><201><238><192>3<130><183>
> > > <28>@q<228>"
> > > NAS-IP-Address = 213.116.1.14
> > > NAS-Port = 70
> > > NAS-Port-Type = Sync
> > > Service-Type = Framed-User
> > > Framed-Protocol = PPP
> > > State = ""
> > > Calling-Station-Id = "235652175"
> > > Called-Station-Id = "0107110035"
> > > Acct-Session-Id = "328619273"
> > > Ascend-Data-Rate = 64000
> > > Ascend-Xmit-Rate = 64000
> > > Proxy-State =
> > > PX01<0><0><*z<211><178><22><170><220><204><200><219>w6<5>;
>
> <11>>:<0><2><6><149>&l

RE: (RADIATOR) MaxSessions issue, still a problem

2001-07-13 Thread Dmitry Kopylov

Hello,

and the problem here is that NAS generates the Access-Request in form
"username@realm", proxy stripes off the the realmname and my Radiator
receives just "username". Whereas the accounting request approaches the
Radiator in its original form e.g. "username@realm". So the session database
is built up based on the "username@realm" and not on the "username". The
question here is if it's possible to rewrite the User-Name in Accounting
request?  Or maybe there is another solution?

regards,
Dmitry Kopylov

-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 13, 2001 8:43 AM
To: Vangelis Kyriakakis; [EMAIL PROTECTED]
Subject: Re: (RADIATOR) MaxSessions issue, still a problem



Hello Vangelis -

Actually, an internal session database is exactly that - a session database 
held entirely in memory. The username in each request is what is used, as 
follows: Access-Request - check current sessions and reject if limit 
exceeded, Accounting Start - add new record, Accounting Start - delete
record.

regards

Hugh


On Thursday 12 July 2001 22:33, Vangelis Kyriakakis wrote:
> I think the problem when you use the Internal session database is that it
> uses the username from the Accounting file to count the number of
sessions.
> When a new user logs in it checks the rewritten username against the
> session database. So it checks with the name uunoc and not with the
> [EMAIL PROTECTED] and sees that it hasn't logged in again. I had the same
> problem with small and capital letters.
>Maxsession 0 works always since it's no need to check the session
> database...
>
>Vangelis
>
> Dmitry Kopylov wrote:
> > Hi,
> >
> > I upgraded to the 18.2.2 but the problem with MaxSession still exists.
> > Here is part of config and trace 4 output:
> >
> > 
> > RewriteUsername s/^([^@]+).*/$1/
> > MaxSessions 1
> > 
> > 
> > AcctLogFileName %L/bbeyond/details
> > PasswordLogFileName %L/bbeyond/uunet-passwords.log
> > 
> >
> > If I set MaxSessions 0, it works and rejects all sessions, but when I
set
> > MaxSessions to 1 it allows the second connection with the same username.
> >
> > MaxSessions 0:
> >
> > Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
> > /opt/radiator-2.18/raddb/users
> > Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
> > /opt/radiator-2.18/raddb/users
> > Thu Jul 12 11:30:06 2001: INFO: Server started: Radiator 2.18.2 on
> > bbyrad1.bbeyond.nl
> > Thu Jul 12 11:30:25 2001: DEBUG: Packet dump:
> > *** Received from 62.177.149.2 port 1645 
> > Code:   Access-Request
> > Identifier: 102
> > Authentic:  z<211><178><22><170><220><204><200><219>w6<5>;<11>>:
> > Attributes:
> > User-Name = "[EMAIL PROTECTED]"
> > User-Password = "_<178><219>A<0><201><238><192>3<130><183>
> > <28>@q<228>"
> > NAS-IP-Address = 213.116.1.14
> > NAS-Port = 70
> > NAS-Port-Type = Sync
> > Service-Type = Framed-User
> > Framed-Protocol = PPP
> > State = ""
> > Calling-Station-Id = "235652175"
> > Called-Station-Id = "0107110035"
> > Acct-Session-Id = "328619273"
> > Ascend-Data-Rate = 64000
> > Ascend-Xmit-Rate = 64000
> > Proxy-State =
> > PX01<0><0><*z<211><178><22><170><220><204><200><219>w6<5>;
> >
<11>>:<0><2><6><149><213>t<1><14><0><0><0><0><0><0><0><0><0><0><0>F<0><2>
> ><7> <20>
> >
> >
><177><144><3><0><0><0><0><0><0><0><0><0><0><5><22><0><224><199><221>h<25
> > >1><
> >
> > 225>
> > <236>&<13>XA<188>NY<153>O
> >
> > Thu Jul 12 11:30:25 2001: DEBUG: Check if Handler Realm=bbeyond.nl
should
> > be use
> > d to handle this request
> > Thu Jul 12 11:30:25 2001: DEBUG: Handling request with Handler
> > 'Realm=bbeyond.nl
> > '
> > Thu Jul 12 11:30:25 2001: DEBUG: Rewrote user name to uunoc
> > Thu Jul 12 11:30:25 2001: DEBUG:  Deleting session for [EMAIL PROTECTED],
> 

Re: (RADIATOR) MaxSessions issue, still a problem

2001-07-12 Thread Hugh Irvine


Hello Dmitry -

Here is what I get with this configuration file (copied from your mail):

Foreground
Trace 4
 

Secret mysecret

 

  RewriteUsername s/^([^@]+).*/$1/
  MaxSessions 1
  
Filename ./bbeyond.users
  
  AcctLogFileName %L/bbeyond/details
  PasswordLogFileName %L/bbeyond/uunet-passwords.log
   


This is the debug:
 
Fri Jul 13 17:00:42 2001: DEBUG: Reading users file ./bbeyond.users
Fri Jul 13 17:00:42 2001: INFO: Server started: Radiator 2.18.2 on hugo

Fri Jul 13 17:02:35 2001: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 1050 
Code:   Access-Request
Identifier: 50
Authentic:  1234567890123456
Attributes:
User-Name = "[EMAIL PROTECTED]"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
NAS-Port-Type = Async
User-Password = 
"<141><238>,<217><175>\<4><246><188>8<9><160><216>}x<153>"

Fri Jul 13 17:02:35 2001: DEBUG: Check if Handler Realm=bbeyond.nl should be 
used to handle this request
Fri Jul 13 17:02:35 2001: DEBUG: Handling request with Handler 
'Realm=bbeyond.nl'
Fri Jul 13 17:02:35 2001: DEBUG: Rewrote user name to uunoc
Fri Jul 13 17:02:35 2001: DEBUG:  Deleting session for [EMAIL PROTECTED], 
203.63.154.1, 1234
Fri Jul 13 17:02:35 2001: DEBUG: Handling with Radius::AuthFILE
Fri Jul 13 17:02:35 2001: DEBUG: Radius::AuthFILE looks for match with uunoc
Fri Jul 13 17:02:35 2001: DEBUG: Radius::AuthFILE ACCEPT:
Fri Jul 13 17:02:35 2001: DEBUG: Access accepted for uunoc
Fri Jul 13 17:02:35 2001: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 1050 
Code:   Access-Accept
Identifier: 50
Authentic:  1234567890123456
Attributes:
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Netmask = 255.255.255.254

Fri Jul 13 17:02:35 2001: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 1050 
Code:   Accounting-Request
Identifier: 51
Authentic:  TW<196>5g<15><204>x<217>Y@>?+<189>9
Attributes:
User-Name = "[EMAIL PROTECTED]"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
NAS-Port-Type = Async
Acct-Session-Id = "1234"
Acct-Status-Type = Start

Fri Jul 13 17:02:35 2001: DEBUG: Check if Handler Realm=bbeyond.nl should be 
used to handle this request
Fri Jul 13 17:02:35 2001: DEBUG: Handling request with Handler 
'Realm=bbeyond.nl'
Fri Jul 13 17:02:35 2001: DEBUG: Rewrote user name to uunoc
Fri Jul 13 17:02:35 2001: DEBUG:  Adding session for [EMAIL PROTECTED], 
203.63.154.1, 1234
Fri Jul 13 17:02:35 2001: DEBUG: Handling with Radius::AuthFILE
Fri Jul 13 17:02:35 2001: DEBUG: Accounting accepted
Fri Jul 13 17:02:35 2001: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 1050 
Code:   Accounting-Response
Identifier: 51
Authentic:  TW<196>5g<15><204>x<217>Y@>?+<189>9
Attributes:

Fri Jul 13 17:03:42 2001: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 1050 
Code:   Access-Request
Identifier: 116
Authentic:  1234567890123456
Attributes:
User-Name = "[EMAIL PROTECTED]"
Service-Type = Framed-User
NAS-IP-Address = 213.116.1.14
NAS-Port = 1234
NAS-Port-Type = Async
User-Password = 
"<141><238>,<217><175>\<4><246><188>8<9><160><216>}x<153>"

Fri Jul 13 17:03:42 2001: DEBUG: Check if Handler Realm=bbeyond.nl should be 
used to handle this request
Fri Jul 13 17:03:42 2001: DEBUG: Handling request with Handler 
'Realm=bbeyond.nl'
Fri Jul 13 17:03:42 2001: DEBUG: Rewrote user name to uunoc
Fri Jul 13 17:03:42 2001: DEBUG:  Deleting session for [EMAIL PROTECTED], 
213.116.1.14, 1234
Fri Jul 13 17:03:42 2001: DEBUG: Checking if user is still online: unknown, 
[EMAIL PROTECTED], 203.63.154.1, 1234, 1234
Fri Jul 13 17:03:42 2001: INFO: Access rejected for uunoc: MaxSessions 
exceeded
Fri Jul 13 17:03:42 2001: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 1050 
Code:   Access-Reject
Identifier: 116
Authentic:  1234567890123456
Attributes:
Reply-Message = "Request Denied"

 
I can only think that you have set up the Client clauses differently - 
perhaps with a Nas-Type Ignore, which will not check the session database at 
all.

Have a look at section 6.5.5 in the Radiator 2.18.2 reference manual for a 
discussion of the various Nas-Type options.

regards

Hugh



On Thursday 12 July 2001 19:16, Dmitry Kopylov wrote:
> Hi,
>
> I upgraded to the 18.2.2 but the problem with MaxSession still exists. Here
> is part of config and trace 4 output:
>
> 
> RewriteUsername s/^([^@]+).*/$1/
> MaxSessions 1
> 
> 
> AcctLogFileName %L/bbeyond/details
> PasswordLogFileName %L/bbeyond/uunet-passwords.log
> 
>
>
> If I set MaxSessions 0, it works and rejects all sessions, but when I set
> MaxSessions to 1 it allows the second connection with the same username.
>
>
> MaxSessions 0:
>
> Thu Jul 12 11:30:06 2001: DEBUG: Reading user

Re: (RADIATOR) MaxSessions issue, still a problem

2001-07-12 Thread Hugh Irvine


Hello Vangelis -

Actually, an internal session database is exactly that - a session database 
held entirely in memory. The username in each request is what is used, as 
follows: Access-Request - check current sessions and reject if limit 
exceeded, Accounting Start - add new record, Accounting Start - delete record.

regards

Hugh


On Thursday 12 July 2001 22:33, Vangelis Kyriakakis wrote:
> I think the problem when you use the Internal session database is that it
> uses the username from the Accounting file to count the number of sessions.
> When a new user logs in it checks the rewritten username against the
> session database. So it checks with the name uunoc and not with the
> [EMAIL PROTECTED] and sees that it hasn't logged in again. I had the same
> problem with small and capital letters.
>Maxsession 0 works always since it's no need to check the session
> database...
>
>Vangelis
>
> Dmitry Kopylov wrote:
> > Hi,
> >
> > I upgraded to the 18.2.2 but the problem with MaxSession still exists.
> > Here is part of config and trace 4 output:
> >
> > 
> > RewriteUsername s/^([^@]+).*/$1/
> > MaxSessions 1
> > 
> > 
> > AcctLogFileName %L/bbeyond/details
> > PasswordLogFileName %L/bbeyond/uunet-passwords.log
> > 
> >
> > If I set MaxSessions 0, it works and rejects all sessions, but when I set
> > MaxSessions to 1 it allows the second connection with the same username.
> >
> > MaxSessions 0:
> >
> > Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
> > /opt/radiator-2.18/raddb/users
> > Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
> > /opt/radiator-2.18/raddb/users
> > Thu Jul 12 11:30:06 2001: INFO: Server started: Radiator 2.18.2 on
> > bbyrad1.bbeyond.nl
> > Thu Jul 12 11:30:25 2001: DEBUG: Packet dump:
> > *** Received from 62.177.149.2 port 1645 
> > Code:   Access-Request
> > Identifier: 102
> > Authentic:  z<211><178><22><170><220><204><200><219>w6<5>;<11>>:
> > Attributes:
> > User-Name = "[EMAIL PROTECTED]"
> > User-Password = "_<178><219>A<0><201><238><192>3<130><183>
> > <28>@q<228>"
> > NAS-IP-Address = 213.116.1.14
> > NAS-Port = 70
> > NAS-Port-Type = Sync
> > Service-Type = Framed-User
> > Framed-Protocol = PPP
> > State = ""
> > Calling-Station-Id = "235652175"
> > Called-Station-Id = "0107110035"
> > Acct-Session-Id = "328619273"
> > Ascend-Data-Rate = 64000
> > Ascend-Xmit-Rate = 64000
> > Proxy-State =
> > PX01<0><0><*z<211><178><22><170><220><204><200><219>w6<5>;
> > <11>>:<0><2><6><149><213>t<1><14><0><0><0><0><0><0><0><0><0><0><0>F<0><2>
> ><7> <20>
> >
> > ><177><144><3><0><0><0><0><0><0><0><0><0><0><5><22><0><224><199><221>h<25
> > >1><
> >
> > 225>
> > <236>&<13>XA<188>NY<153>O
> >
> > Thu Jul 12 11:30:25 2001: DEBUG: Check if Handler Realm=bbeyond.nl should
> > be use
> > d to handle this request
> > Thu Jul 12 11:30:25 2001: DEBUG: Handling request with Handler
> > 'Realm=bbeyond.nl
> > '
> > Thu Jul 12 11:30:25 2001: DEBUG: Rewrote user name to uunoc
> > Thu Jul 12 11:30:25 2001: DEBUG:  Deleting session for [EMAIL PROTECTED],
> > 213.116
> > .1.14, 70
> > Thu Jul 12 11:30:25 2001: INFO: Access rejected for uunoc: MaxSessions
> > exceeded
> > Thu Jul 12 11:30:25 2001: DEBUG: Packet dump:
> > *** Sending to 62.177.149.2 port 1645 
> > Code:   Access-Reject
> > Identifier: 102
> > Authentic:  z<211><178><22><170><220><204><200><219>w6<5>;<11>>:
> > Attributes:
> > Reply-Message = "Request Denied"
> >
> > MaxSessions 1:
> >
> > Thu Jul 12 11:31:26 2001: NOTICE: SIGTERM received: stopping
> > Thu Jul 12 11:31:28 2001: DEBUG: Reading users file
> > /opt/radiator-2.18/raddb/users
> > Thu Jul 12 11:31:28 2001: DEBUG: Reading users file
> > /opt/radiator-2.18/raddb/users
> > Thu Jul 12 11:31:29 2001: INFO: Server started: Radiator 2.18.2 on
> > bbyrad1.bbeyond.nl
> > Thu Jul 12 11:31:37 2001: DEBUG: Packet dump:
> > *** Received from 62.177.149.1 port 1645 
> > Code:   Access-Request
> > Identifier: 173
> > Authentic:  <242><12> <252>)<203>T<230><252><143>P<201><22>}9Y
> > Attributes:
> > User-Name = "[EMAIL PROTECTED]"
> > User-Password = "e<218><137><3>\<17><241><230>gi<150>q <208>cn"
> > NAS-IP-Address = 213.116.1.30
> > NAS-Port = 2054
> > NAS-Port-Type = Sync
> > Service-Type = Framed-User
> > Framed-Protocol = PPP
> > State = ""
> > Calling-Station-Id = "235652175"
> > Called-Station-Id = "0107110035"
> > Acct-Session-Id = "347654980"
> > Ascend-Data-Rate = 64000
> > Ascend-Xmit-Rate = 64000
> > Proxy-State = PX01<0><0><9><254><242><12>
> > <252>)<203>T<230><252><143>P<2
> > 01><22>}9Y<0><2><6><140><213>t<1><30><0><0><0><0><0><0><0><0><0><0><8><6>
> ><0> <2><
> > 7><20>><177><144><3><0><0><0><0><0><0><0><0><0><0><5><22><0>u<151><253>^<
> >30> H<18

Re: (RADIATOR) MaxSessions issue, still a problem

2001-07-12 Thread Vangelis Kyriakakis

   I think the problem when you use the Internal session database is that it
uses the username from the Accounting file to count the number of sessions. When
a new user logs in it checks the rewritten username against the session
database. So it checks with the name uunoc and not with the [EMAIL PROTECTED] and
sees that it hasn't logged in again. I had the same problem with small and
capital letters.
   Maxsession 0 works always since it's no need to check the session database...

   Vangelis

Dmitry Kopylov wrote:

> Hi,
>
> I upgraded to the 18.2.2 but the problem with MaxSession still exists. Here
> is part of config and trace 4 output:
>
> 
> RewriteUsername s/^([^@]+).*/$1/
> MaxSessions 1
> 
> 
> AcctLogFileName %L/bbeyond/details
> PasswordLogFileName %L/bbeyond/uunet-passwords.log
> 
>
> If I set MaxSessions 0, it works and rejects all sessions, but when I set
> MaxSessions to 1 it allows the second connection with the same username.
>
> MaxSessions 0:
>
> Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
> /opt/radiator-2.18/raddb/users
> Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
> /opt/radiator-2.18/raddb/users
> Thu Jul 12 11:30:06 2001: INFO: Server started: Radiator 2.18.2 on
> bbyrad1.bbeyond.nl
> Thu Jul 12 11:30:25 2001: DEBUG: Packet dump:
> *** Received from 62.177.149.2 port 1645 
> Code:   Access-Request
> Identifier: 102
> Authentic:  z<211><178><22><170><220><204><200><219>w6<5>;<11>>:
> Attributes:
> User-Name = "[EMAIL PROTECTED]"
> User-Password = "_<178><219>A<0><201><238><192>3<130><183>
> <28>@q<228>"
> NAS-IP-Address = 213.116.1.14
> NAS-Port = 70
> NAS-Port-Type = Sync
> Service-Type = Framed-User
> Framed-Protocol = PPP
> State = ""
> Calling-Station-Id = "235652175"
> Called-Station-Id = "0107110035"
> Acct-Session-Id = "328619273"
> Ascend-Data-Rate = 64000
> Ascend-Xmit-Rate = 64000
> Proxy-State =
> PX01<0><0><*z<211><178><22><170><220><204><200><219>w6<5>;
> <11>>:<0><2><6><149><213>t<1><14><0><0><0><0><0><0><0><0><0><0><0>F<0><2><7>
> <20>
> ><177><144><3><0><0><0><0><0><0><0><0><0><0><5><22><0><224><199><221>h<251><
> 225>
> <236>&<13>XA<188>NY<153>O
>
> Thu Jul 12 11:30:25 2001: DEBUG: Check if Handler Realm=bbeyond.nl should be
> use
> d to handle this request
> Thu Jul 12 11:30:25 2001: DEBUG: Handling request with Handler
> 'Realm=bbeyond.nl
> '
> Thu Jul 12 11:30:25 2001: DEBUG: Rewrote user name to uunoc
> Thu Jul 12 11:30:25 2001: DEBUG:  Deleting session for [EMAIL PROTECTED],
> 213.116
> .1.14, 70
> Thu Jul 12 11:30:25 2001: INFO: Access rejected for uunoc: MaxSessions
> exceeded
> Thu Jul 12 11:30:25 2001: DEBUG: Packet dump:
> *** Sending to 62.177.149.2 port 1645 
> Code:   Access-Reject
> Identifier: 102
> Authentic:  z<211><178><22><170><220><204><200><219>w6<5>;<11>>:
> Attributes:
> Reply-Message = "Request Denied"
>
> MaxSessions 1:
>
> Thu Jul 12 11:31:26 2001: NOTICE: SIGTERM received: stopping
> Thu Jul 12 11:31:28 2001: DEBUG: Reading users file
> /opt/radiator-2.18/raddb/users
> Thu Jul 12 11:31:28 2001: DEBUG: Reading users file
> /opt/radiator-2.18/raddb/users
> Thu Jul 12 11:31:29 2001: INFO: Server started: Radiator 2.18.2 on
> bbyrad1.bbeyond.nl
> Thu Jul 12 11:31:37 2001: DEBUG: Packet dump:
> *** Received from 62.177.149.1 port 1645 
> Code:   Access-Request
> Identifier: 173
> Authentic:  <242><12> <252>)<203>T<230><252><143>P<201><22>}9Y
> Attributes:
> User-Name = "[EMAIL PROTECTED]"
> User-Password = "e<218><137><3>\<17><241><230>gi<150>q <208>cn"
> NAS-IP-Address = 213.116.1.30
> NAS-Port = 2054
> NAS-Port-Type = Sync
> Service-Type = Framed-User
> Framed-Protocol = PPP
> State = ""
> Calling-Station-Id = "235652175"
> Called-Station-Id = "0107110035"
> Acct-Session-Id = "347654980"
> Ascend-Data-Rate = 64000
> Ascend-Xmit-Rate = 64000
> Proxy-State = PX01<0><0><9><254><242><12>
> <252>)<203>T<230><252><143>P<2
> 01><22>}9Y<0><2><6><140><213>t<1><30><0><0><0><0><0><0><0><0><0><0><8><6><0>
> <2><
> 7><20>><177><144><3><0><0><0><0><0><0><0><0><0><0><5><22><0>u<151><253>^<30>
> H<18
> 5><142><234><10>v\w<187><218>n
>
> Thu Jul 12 11:31:37 2001: DEBUG: Check if Handler Realm=bbeyond.nl should be
> use
> d to handle this request
> Thu Jul 12 11:31:37 2001: DEBUG: Handling request with Handler
> 'Realm=bbeyond.nl
> '
> Thu Jul 12 11:31:37 2001: DEBUG: Rewrote user name to uunoc
> Thu Jul 12 11:31:37 2001: DEBUG:  Deleting session for [EMAIL PROTECTED],
> 213.116
> .1.30, 2054
> Thu Jul 12 11:31:37 2001: DEBUG: Handling with Radius::AuthFILE
> Thu Jul 12 11:31:37 2001: DEBUG: Radius::AuthFILE looks for match with uunoc
> Thu Jul 12 11:31:37 2001: DEBUG: Radius::AuthFILE ACCEPT:
> Thu Jul 12 11:31:37 2001: DEBUG: Acc

(RADIATOR) MaxSessions issue, still a problem

2001-07-12 Thread Dmitry Kopylov

Hi,

I upgraded to the 18.2.2 but the problem with MaxSession still exists. Here
is part of config and trace 4 output:


RewriteUsername s/^([^@]+).*/$1/
MaxSessions 1


AcctLogFileName %L/bbeyond/details
PasswordLogFileName %L/bbeyond/uunet-passwords.log



If I set MaxSessions 0, it works and rejects all sessions, but when I set
MaxSessions to 1 it allows the second connection with the same username.


MaxSessions 0:

Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
/opt/radiator-2.18/raddb/users
Thu Jul 12 11:30:06 2001: DEBUG: Reading users file
/opt/radiator-2.18/raddb/users
Thu Jul 12 11:30:06 2001: INFO: Server started: Radiator 2.18.2 on
bbyrad1.bbeyond.nl
Thu Jul 12 11:30:25 2001: DEBUG: Packet dump:
*** Received from 62.177.149.2 port 1645 
Code:   Access-Request
Identifier: 102
Authentic:  z<211><178><22><170><220><204><200><219>w6<5>;<11>>:
Attributes:
User-Name = "[EMAIL PROTECTED]"
User-Password = "_<178><219>A<0><201><238><192>3<130><183>
<28>@q<228>"
NAS-IP-Address = 213.116.1.14
NAS-Port = 70
NAS-Port-Type = Sync
Service-Type = Framed-User
Framed-Protocol = PPP
State = ""
Calling-Station-Id = "235652175"
Called-Station-Id = "0107110035"
Acct-Session-Id = "328619273"
Ascend-Data-Rate = 64000
Ascend-Xmit-Rate = 64000
Proxy-State =
PX01<0><0><*z<211><178><22><170><220><204><200><219>w6<5>;
<11>>:<0><2><6><149><213>t<1><14><0><0><0><0><0><0><0><0><0><0><0>F<0><2><7>
<20>
><177><144><3><0><0><0><0><0><0><0><0><0><0><5><22><0><224><199><221>h<251><
225>
<236>&<13>XA<188>NY<153>O

Thu Jul 12 11:30:25 2001: DEBUG: Check if Handler Realm=bbeyond.nl should be
use
d to handle this request
Thu Jul 12 11:30:25 2001: DEBUG: Handling request with Handler
'Realm=bbeyond.nl
'
Thu Jul 12 11:30:25 2001: DEBUG: Rewrote user name to uunoc
Thu Jul 12 11:30:25 2001: DEBUG:  Deleting session for [EMAIL PROTECTED],
213.116
.1.14, 70
Thu Jul 12 11:30:25 2001: INFO: Access rejected for uunoc: MaxSessions
exceeded
Thu Jul 12 11:30:25 2001: DEBUG: Packet dump:
*** Sending to 62.177.149.2 port 1645 
Code:   Access-Reject
Identifier: 102
Authentic:  z<211><178><22><170><220><204><200><219>w6<5>;<11>>:
Attributes:
Reply-Message = "Request Denied"



MaxSessions 1:

Thu Jul 12 11:31:26 2001: NOTICE: SIGTERM received: stopping
Thu Jul 12 11:31:28 2001: DEBUG: Reading users file
/opt/radiator-2.18/raddb/users
Thu Jul 12 11:31:28 2001: DEBUG: Reading users file
/opt/radiator-2.18/raddb/users
Thu Jul 12 11:31:29 2001: INFO: Server started: Radiator 2.18.2 on
bbyrad1.bbeyond.nl
Thu Jul 12 11:31:37 2001: DEBUG: Packet dump:
*** Received from 62.177.149.1 port 1645 
Code:   Access-Request
Identifier: 173
Authentic:  <242><12> <252>)<203>T<230><252><143>P<201><22>}9Y
Attributes:
User-Name = "[EMAIL PROTECTED]"
User-Password = "e<218><137><3>\<17><241><230>gi<150>q <208>cn"
NAS-IP-Address = 213.116.1.30
NAS-Port = 2054
NAS-Port-Type = Sync
Service-Type = Framed-User
Framed-Protocol = PPP
State = ""
Calling-Station-Id = "235652175"
Called-Station-Id = "0107110035"
Acct-Session-Id = "347654980"
Ascend-Data-Rate = 64000
Ascend-Xmit-Rate = 64000
Proxy-State = PX01<0><0><9><254><242><12>
<252>)<203>T<230><252><143>P<2
01><22>}9Y<0><2><6><140><213>t<1><30><0><0><0><0><0><0><0><0><0><0><8><6><0>
<2><
7><20>><177><144><3><0><0><0><0><0><0><0><0><0><0><5><22><0>u<151><253>^<30>
H<18
5><142><234><10>v\w<187><218>n

Thu Jul 12 11:31:37 2001: DEBUG: Check if Handler Realm=bbeyond.nl should be
use
d to handle this request
Thu Jul 12 11:31:37 2001: DEBUG: Handling request with Handler
'Realm=bbeyond.nl
'
Thu Jul 12 11:31:37 2001: DEBUG: Rewrote user name to uunoc
Thu Jul 12 11:31:37 2001: DEBUG:  Deleting session for [EMAIL PROTECTED],
213.116
.1.30, 2054
Thu Jul 12 11:31:37 2001: DEBUG: Handling with Radius::AuthFILE
Thu Jul 12 11:31:37 2001: DEBUG: Radius::AuthFILE looks for match with uunoc
Thu Jul 12 11:31:37 2001: DEBUG: Radius::AuthFILE ACCEPT:
Thu Jul 12 11:31:37 2001: DEBUG: Access accepted for uunoc
Thu Jul 12 11:31:37 2001: DEBUG: Packet dump:
*** Sending to 62.177.149.1 port 1645 
Code:   Access-Accept
Identifier: 173
Authentic:  <242><12> <252>)<203>T<230><252><143>P<201><22>}9Y
Attributes:
Proxy-State = PX01<0><0><9><254><242><12>
<252>)<203>T<230><252><143>P<2
01><22>}9Y<0><2><6><140><213>t<1><30><0><0><0><0><0><0><0><0><0><0><8><6><0>
<2><
7><20>><177><144><3><0><0><0><0><0><0><0><0><0><0><5><22><0>u<151><253>^<30>
H<18
5><142><234><10>v\w<187><218>n
Service-Type = Framed-User
Framed-Protocol = PPP
Thu Jul 12 11:32:09 2001: DEBUG: Packet dump:
*** Received from 62.177.149.3 port 1645 
Code:   Access-Request
Identifier: 142
Authentic:  <169>}<237><131><201><239><13>BCw<255><205><14><128><2

Re: (RADIATOR) MaxSessions and Simultaneous-Use

2000-08-13 Thread Hugh Irvine


Hello Chris -

On Sun, 13 Aug 2000, Chris M wrote:
> username   Auth-Type = System
>  Service-Type = Framed-User,
>  Framed-Protocol = PPP,
>  Framed-IP-Address = 255.255.255.254,
>  Simultaneous-Use = 2,
>  Port-Limit = 2,
>  Framed-MTU = 1500
> 
> With this user profile in Radiator and MaxSessions set to 1 in the 
>  portion of the config I get these messages in the log at 
> Trace 4
> 
> Sun Aug 13 00:19:53 2000: DEBUG: Checking if user is still online: 
> Livingston, username, 207.174.103.7, 8, 46005EE2 199.165.157.1
> Sun Aug 13 00:19:53 2000: DEBUG: Running command `/usr/bin/snmpget 
> 207.174.103.7
>   username .iso.org.dod.internet.private.enterprises.307.3.2.1.1.1.2.5`
> 
> I'm using NasType of Livingston on Radiator 2.16.1
> 
> This seems like I have it set up right, but the second ISDN channel 
> does not want to come up and stay up.  What might I have mistaken here
> 

There are a couple of things wrong with your configuration.

First of all, MaxSessions will set a hard limit for the Realm, so you will need
to remove it. If you want to support different Simultaneous-Use limits for
different users you should use DefaultSimultaneousUse for the AuthBy clause.

Second, your user definition must have Simultaneous-Use as a check item:

username   Simultaneous-Use = 2, Auth-Type = System
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 255.255.255.254,
Port-Limit = 2,
Framed-MTU = 1500

hth

Hugh

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.



===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) MaxSessions and Simultaneous-Use

2000-08-12 Thread Chris M

username   Auth-Type = System
 Service-Type = Framed-User,
 Framed-Protocol = PPP,
 Framed-IP-Address = 255.255.255.254,
 Simultaneous-Use = 2,
 Port-Limit = 2,
 Framed-MTU = 1500

With this user profile in Radiator and MaxSessions set to 1 in the 
 portion of the config I get these messages in the log at 
Trace 4

Sun Aug 13 00:19:53 2000: DEBUG: Checking if user is still online: 
Livingston, username, 207.174.103.7, 8, 46005EE2 199.165.157.1
Sun Aug 13 00:19:53 2000: DEBUG: Running command `/usr/bin/snmpget 
207.174.103.7
  username .iso.org.dod.internet.private.enterprises.307.3.2.1.1.1.2.5`

I'm using NasType of Livingston on Radiator 2.16.1

This seems like I have it set up right, but the second ISDN channel 
does not want to come up and stay up.  What might I have mistaken here

Thanks,
Chris

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) MaxSessions is not running ((cont)

2000-06-09 Thread Hugh Irvine


Hello Jesus -

On Thu, 08 Jun 2000, Jesus M Diaz wrote:
> Hi all,
> 
> at last, i think i now why maxsessions seems wrong:
> 
> .iso.org.dod.internet.private.enterprises.9.2.9.2.1.18.X does NOT respond with vpdn 
>sessions.
> 
> that 'mib' says the user connected at line x, but, if the users are l2tp (or l2f) 
>sessions, that 'mib' 
> says us "", so, the user 'has gone'. ERROR.
> 
> solution, at client object DO NOT say the NasType (if ther client is cisco and we 
>are going to use vpdn 
> sessions), Radiator will believe what sessionsdatabase says.
> 
> any better idea?
> 

The latest version of Radiator (2.16) includes a Nas-Type of "Ping", which as
the name implies uses ping to test if a user is still there. This is not a
complete panacea if IP addresses are reallocated, but some customers are
finding it quite useful for this sort of situation.

hth

Hugh

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.



===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) MaxSessions is not running ((cont)

2000-06-09 Thread Jesus M Diaz

Hi all,

at last, i think i now why maxsessions seems wrong:

.iso.org.dod.internet.private.enterprises.9.2.9.2.1.18.X does NOT respond with vpdn 
sessions.

that 'mib' says the user connected at line x, but, if the users are l2tp (or l2f) 
sessions, that 'mib' 
says us "", so, the user 'has gone'. ERROR.

solution, at client object DO NOT say the NasType (if ther client is cisco and we are 
going to use vpdn 
sessions), Radiator will believe what sessionsdatabase says.

any better idea?

thank you



Jesus M Diaz <[EMAIL PROTECTED]>

Telia Iberia, S.A.
Planificación y Diseño de Red
Tfno: +34 91 623 2909
Fax: +34 91 623 2950



===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) MaxSessions is not running

2000-06-09 Thread Jesus M Diaz

Hi all,

I have a 3Com TotalCotrol (TCH), and a Cisco 7500. The calls are sent against the TCH, 
ask Radiator and 
then it must establish a L2TP tunnel against the cisco. Then the cisco ask again 
Radiator (anthores 
proccess of Radius Server), who determines if the user can access or it can not. The 
second radius 
limits the sessions for each user to 1.

The problem is that, i do not why, the user DO establish the second connection. why?

Also, at sessionsdb only appears ONE time each users, when each user have more tahn 
one session active.

Configurations files for the two radius are below:

Radius NAS:

  radius.cfg


  Identifier   ASonline
  Filename /opt/radius/as-online


# NAS Moraleja

  Secret ***
  NasTypeTotalControl
  IdenticalClients   moras01-nmc
  IgnoreAcctSignature
  # pool para usuarios de teletrabajo
  FramedGroupBaseAddress 192.168.6.32
  FramedGroupBaseAddress 192.168.5.32


# vpn: maqueta

  AcctLogFileName %L/%Y/AS-acc-maqueta-%Y%m.log
  PasswordLogFileName %L/%Y/AS-aut-maqueta-%Y%m.log
  
Filename  %D/dominios-nas
  


  dominios-nas

parachi@maqueta Realm  = "maqueta"
Tunnel-Type= 3,
Tunnel-Medium-Type = 1,
Tunnel-Server-Endpoint = "213.201.16.1"


Second Radius:

  radius.cfg


  Identifier   ASonline
  Filename /opt/radius/ac-online


# Routers MAQUETA

  IdenticalClients213.201.16.2
  Secret  
  NasType Cisco
  SNMPCommunity   


# Dominio: maqueta

  AcctLogFileName %L/%Y/AC-acc-maqueta-%Y%m.log
  PasswordLogFileName %L/%Y/AC-aut-maqueta-%Y%m.log
  MaxSessions 1
  RewriteUsername s/^([^@]+).*/$1/
  
Filename  %D/usuarios-maqueta
  


  usuarios-maqueta
parachi   Password   = ""
  Service-Type   = Framed-User,
  Framed-Protocol= PPP,
  Framed-IP-Address  = 192.168.3.1,
  Framed-IP-Netmask  = 255.255.255.255,
  cisco-avpair   = "lcp:interface-config=ppp multilink 
interleave",
  cisco-avpair   = "lcp:interface-config=ip vrf forwarding 
vpn_maqueta\nip 
address 192.168.3.254 255.255.255.0"


SessionsDatabases contents:

  ASonline (first radius)

nas_MOR:275|vitar@maqueta  17957101 09-06-2000 09:39:06 0.0.0.0  Framed-User  ISDN 
 
nas_MOR:277|vitar@maqueta  18087987 09-06-2000 09:39:07 0.0.0.0  Framed-User  ISDN 
 

  AConline (second radius)

pe_MAQ:2   |vitar@maqueta  0004 09-06-2000 09:39:07  Framed-User  ISDN

log (second radius):

Fri Jun  9 09:39:06 2000: DEBUG: Rewrote user name to vitar@maqueta
Fri Jun  9 09:39:06 2000: DEBUG: Handling request with Handler 'Realm=maqueta'
Fri Jun  9 09:39:06 2000: DEBUG: Rewrote user name to vitar
Fri Jun  9 09:39:06 2000: DEBUG: AConline Deleting session for vitar@maqueta, 
213.201.16.1, 3
Fri Jun  9 09:39:06 2000: DEBUG: Handling with Radius::AuthFILE
Fri Jun  9 09:39:06 2000: DEBUG: Radius::AuthFILE looks for match with vitar
Fri Jun  9 09:39:06 2000: DEBUG: Radius::AuthFILE ACCEPT: 
Fri Jun  9 09:39:06 2000: DEBUG: Access accepted for vitar

Fri Jun  9 09:39:06 2000: DEBUG: Rewrote user name to vitar@maqueta
Fri Jun  9 09:39:06 2000: DEBUG: Handling request with Handler 'Realm=maqueta'
Fri Jun  9 09:39:06 2000: DEBUG: Rewrote user name to vitar
Fri Jun  9 09:39:06 2000: DEBUG: AConline Adding session for vitar@maqueta, 
213.201.16.1, 3
Fri Jun  9 09:39:06 2000: DEBUG: Handling with Radius::AuthFILE
Fri Jun  9 09:39:06 2000: DEBUG: Accounting accepted

Fri Jun  9 09:39:07 2000: DEBUG: Rewrote user name to vitar@maqueta
Fri Jun  9 09:39:07 2000: DEBUG: Handling request with Handler 'Realm=maqueta'
Fri Jun  9 09:39:07 2000: DEBUG: Rewrote user name to vitar
Fri Jun  9 09:39:07 2000: DEBUG: AConline Deleting session for vitar@maqueta, 
213.201.16.1, 2
Fri Jun  9 09:39:07 2000: DEBUG: Checking if user is still online: Cisco, 
vitar@maqueta, 213.201.16.1, 
3, 0003
Fri Jun  9 09:39:07 2000: DEBUG: Running command `/usr/bin/snmpget 213.201.16.1 
* 
.iso.org.dod.internet.private.enterprises.9.2.9.2.1.18.3`
Fri Jun  9 09:39:07 2000: NOTICE: AConline Session for vitar@maqueta at 213.201.16.1:3 
has gone away
Fri Jun  9 09:39:07 2000: DEBUG: AConline Deleting session for vitar@maqueta, 
213.201.16.1, 3
Fri Jun  9 09:39:07 2000: DEBUG: Handling with Radius::AuthFILE
Fri Jun  9 09:39:07 2000: DEBUG: Radius::AuthFILE looks for match with vitar
Fri Jun  9 09:39:07 2000: DEBUG: Radius::AuthFILE ACCEPT: 
Fri Jun  9 09:39:07 2000: DEBUG: Access accepted for vitar
Fri Jun  9 09:39:07 2000: DEBUG: Rewrote user name to vitar@maqueta
Fri Jun  9 09:39

Re: (RADIATOR) MaxSessions

1999-08-14 Thread Hugh Irvine


Hello David -

On Sat, 14 Aug 1999, David Booth wrote:
> Everything is working. But,
> 
> I want to enforce MaxSessions 1 for all users
> 
> Can someone run a critical eye over it?
> 
> Where does MaxSessions 1 go?
> 
> I have two NAS - Ascend and Bay4000. How do I get them both checked - with
> NasType?
> 
> Is DupInterval 0 for Client DEFAULT right?
> 
> David Booth
> Goulburn Internet
> 
> Here is my radius.cfg:
> 
> Foreground
> LogStdout
> LogDir  /var/log/radius
> DbDir   .
> Trace   4
> 
> 
> Secret  X
> DupInterval 0
> 
> 
> 
> AcctLogFileName /var/log/radius/detail
> PasswordLogFileName /var/log/radius/passwords
> AuthByPolicyContinueWhileAccept
> 
> Filename /var/log/radius/users
> 
> 
> DBSource dbi:mysql:host=X;database=X
> DBUsername X
> DBAuth X
> AuthSelect SELECT password FROM RealNames WHERE username =
> '%n'
> EncryptedPassword
> 
> AccountingTable logdata
> AccountingStopsOnly
> 
> AcctColumnDef status,Acct-Status-Type
> AcctColumnDef nas_ip,NAS-IP-Address
> AcctColumnDef username,User-Name
> AcctColumnDef tstamp,Timestamp,formatted-date,'%Y-%m-%e
> %H:%M:%S'
> AcctColumnDef bytes_in,Acct-Input-Octets,integer
> AcctColumnDef bytes_out,Acct-Output-Octets,integer
> AcctColumnDef sessionlength,Acct-Session-Time,integer
> AcctColumnDef ipaddr,Framed-IP-Address
> 
> 
> 

You will want to add a "MaxSession 1" to your  and also
configure a  to go with it. And to enable strict checking
you should probably define each Client seperately and set the NasType
accordingly. 

The default for DupInterval is 2 seconds - 0 seconds is usually
only used for testing. See Section 6.4.4 in the reference manual.

hth

Hugh

--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody

===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) MaxSessions

1999-08-13 Thread David Booth

Everything is working. But,

I want to enforce MaxSessions 1 for all users

Can someone run a critical eye over it?

Where does MaxSessions 1 go?

I have two NAS - Ascend and Bay4000. How do I get them both checked - with
NasType?

Is DupInterval 0 for Client DEFAULT right?

David Booth
Goulburn Internet

Here is my radius.cfg:

Foreground
LogStdout
LogDir  /var/log/radius
DbDir   .
Trace   4


Secret  X
DupInterval 0



AcctLogFileName /var/log/radius/detail
PasswordLogFileName /var/log/radius/passwords
AuthByPolicyContinueWhileAccept

Filename /var/log/radius/users


DBSource dbi:mysql:host=X;database=X
DBUsername X
DBAuth X
AuthSelect SELECT password FROM RealNames WHERE username =
'%n'
EncryptedPassword

AccountingTable logdata
AccountingStopsOnly

AcctColumnDef status,Acct-Status-Type
AcctColumnDef nas_ip,NAS-IP-Address
AcctColumnDef username,User-Name
AcctColumnDef tstamp,Timestamp,formatted-date,'%Y-%m-%e
%H:%M:%S'
AcctColumnDef bytes_in,Acct-Input-Octets,integer
AcctColumnDef bytes_out,Acct-Output-Octets,integer
AcctColumnDef sessionlength,Acct-Session-Time,integer
AcctColumnDef ipaddr,Framed-IP-Address







===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) MaxSessions override

1999-06-10 Thread Mike McCauley

Hi James.

On Jun 10, 10:00pm, James H. Thompson wrote:
> Subject: (RADIATOR) MaxSessions override
> If you specify:
>   MaxSessions 1
> for a realm, does a
>   Simultaneous-Use
> item for a particular user override this?
No. Of those 2, the _most_restrictive_ one applies.

The patched version of AuthGeneric.pm in the 2.13.1 patches area has a new
DefaultSimultaneousUse parameter. That one _does_ get overridden by a per user
Simultaneous-Use. You might want to try that?


Hope that helps.

Cheers.



>
>
> Jim
> [EMAIL PROTECTED]
>
>
> ===
> Archive at http://www.thesite.com.au/~radiator/
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
>-- End of excerpt from James H. Thompson



-- 
Mike McCauley   [EMAIL PROTECTED]
Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
Phone +61 3 9598-0985   Fax   +61 3 9598-0955

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, 
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) MaxSessions override

1999-06-10 Thread James H. Thompson

If you specify:
MaxSessions 1
for a realm, does a
Simultaneous-Use 
item for a particular user override this?


Jim
[EMAIL PROTECTED]


===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.