(RADIATOR) 2.16.3 error in decode_tunnel_password (Radius.pm:461)

2000-09-04 Thread Christophe Wolfhugel

Just gotcha an error here :

substr($password, $len) = '';

substr outside of string at /usr/local/lib/perl5/site_perl/5.005/Radius/Radius.pm line 
461.
Modification of a read-only value attempted at 
/usr/local/lib/perl5/site_perl/5.005/Radius/Radius.pm line 461.

Investigation under progress for now :(.

-- 
Christophe Wolfhugel  -+-  [EMAIL PROTECTED]  -+-  France Telecom Oleane

===
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) 2.16.3 error in decode_tunnel_password (Radius.pm:461)

2000-09-04 Thread Christophe Wolfhugel

Update to my previous report, I found the cause of this issue.

It might happen that a remote site sends an incorrectly encoded
tunnel password (or it might just be a wrong secret). As there is
no mechanism for verifying the correctness of the decoded block, and
typically the length field might have any value. The proposed
correction is following :

substr($password, $len) = '' if ($len  length($password));

This is just a hack, but is there a need to do something more
sophisticated, as if the decoded password is wrong, we really
don't care about what we are returning and we just need to
prevent Radiator from crashing.

Christophe Wolfhugel :
 Just gotcha an error here :
 
 substr($password, $len) = '';
 
 substr outside of string at /usr/local/lib/perl5/site_perl/5.005/Radius/Radius.pm 
line 461.
 Modification of a read-only value attempted at 
/usr/local/lib/perl5/site_perl/5.005/Radius/Radius.pm line 461.

===
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) LDAP2 AuthAttrDef Problem (IMPORTANT)

2000-09-04 Thread Hugh Irvine


Hello Richard -

On Mon, 04 Sep 2000, Richard Nagelmaeker wrote:
 Hi,
 
 We're having a problem with Radiator checking the LDAP server for an
 attribute with AuthAttrDef. 
 
 If I do the following request:
 (AuthBy LDAP2, Radiator 2.16.3)
 AuthAttrDef LDAP-Attribute, Radius-Attribute, check
 
 It responds fine if the LDAP-Attribute is in the record of the user. If the
 LDAP-Attribute is not in the users record, Radiator does no check on it and
 allows access to the user. Where I want the user to be denied access if the
 LDAP-Attribute is not in his record.
 
 Does someone know the solution for this problem?
 

You should use the SearchFilter parameter to define whatever search finlter you
require. Have a look at section 6.32.13 in the Radiator 2.16.3 reference manual.

 I know the answer might be in recent messages of the Radiator Archive, but
 the webserver seems to be unable to find the right pages for august and
 september. It works fine for earlier dates though.
 

I have sent a message to the maintainer of the archive site - thanks for
bringing the problem to our attention.

regards

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.



Re: (RADIATOR) chap encrypted password

2000-09-04 Thread Hugh Irvine


Hello Sek Chye -

On Mon, 04 Sep 2000, Goh Sek Chye wrote:
 Hi! Currently we encrypt our subscribers' password.  This means that we
 cannot support CHAP authentication.
 
 However, I am now under pressure to support CHAP as well.  To support
 CHAP, I need to store subscribers' password in clear text and I am not
 comfortable with that.
 
 Is there any solution to support CHAP and at the same time store the
 password encrypted?
 

Unfortunately no, as with CHAP only the encryption is sent for the password,
and you need to be able to perform the same encryption at the server end to be
able to compare the two encrypted passwords.

regards

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) Handler for a set of realms

2000-09-04 Thread Andrew Pollock

Hi,

Is it currently possible with Radiator to readily have a handler that checks
for the realm being in a set of realms? The reason I ask is we have a system
here that can theoretically add additional realms that require to be handled
at any point in time, and it would be ideal if Radiator could read this from
an external file.

Hope this makes sense.

Andrew


===
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) Handler for a set of realms

2000-09-04 Thread Hugh Irvine


Hello Andrew -

On Tue, 05 Sep 2000, Andrew Pollock wrote:
 Hi,
 
 Is it currently possible with Radiator to readily have a handler that checks
 for the realm being in a set of realms? The reason I ask is we have a system
 here that can theoretically add additional realms that require to be handled
 at any point in time, and it would be ideal if Radiator could read this from
 an external file.
 

I think you will have to use a PreHandlerHook to check your file, and perhaps
set a pseudo-attribute in the request packet that will be used to select the
Handler. There are some examples of hooks in the file "goodies/hooks.txt" in
the Radiator 2.16.3 release (also included in all recent releases).

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) Handlers and Realms (101)

2000-09-04 Thread Brian Morris

Hello All,

We would like to add a facility to our existing radiator install where a
user can dial-in to our access server using a different telephone number and
receive different access permissions  (eg: maximum session time)

As they will be connecting to the same access server I figure we need to
setup a handler based on the number they are dialling in to - as the default
realm for the access server is already being used.

My question is : can I setup a handler just for the called station ID and
keep the existing realm whatever or must I change everything to be handled
by a handler?

Thanks in advance.

Brian Morris




===
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) Handlers and Realms (101)

2000-09-04 Thread Hugh Irvine


Hello Brian -

On Tue, 05 Sep 2000, Brian Morris wrote:
 Hello All,
 
 We would like to add a facility to our existing radiator install where a
 user can dial-in to our access server using a different telephone number and
 receive different access permissions  (eg: maximum session time)
 
 As they will be connecting to the same access server I figure we need to
 setup a handler based on the number they are dialling in to - as the default
 realm for the access server is already being used.
 
 My question is : can I setup a handler just for the called station ID and
 keep the existing realm whatever or must I change everything to be handled
 by a handler?


You should convert everything to Handlers:

Handler Called-Station-Id = 
..
/Handler

Handler Called-Station-Id = 
..
/Handler

Handler Realm = foo.bar
..
/Handler



Handler Realm = DEFAULT
..
/Handler

Handler

/Handler

Note that Handlers are processed in the order they appear in the configuration
file, so the more specific must appear before the more general.

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.