(RADIATOR) MacOS X

2001-04-04 Thread Bennie Warren
Title: MacOS X



I am trying to find anyone using this with MacOSX. I am looking to move away from MacRadius and would appreciate any info on moving to Radiator.

Thanks
Bennie

-- 
**
Bennie Warren 
LemooreNet  
320 West D Street 
Lemoore, CA  93245 
Phone:  559.924.5909 
Fax  559.924.9578  
[EMAIL PROTECTED]  
http://www.lemoorenet.com 
**







Re: (RADIATOR) SNMPAgent patch: access restrictions now available

2001-04-04 Thread Michael Audet

I haven't configured SNMP yet.. but from what I read it sounds good

-Michael Audet
Network Services
Chubb & Son

- Original Message -
From: "Karl Gaissmaier" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2001 5:51 PM
Subject: (RADIATOR) SNMPAgent patch: access restrictions now available


> Hi all and Mike,
>
> I wrote a patch to SNMPAgent to restrict the acces to the Radius
> SNMP vars, especially to disallow unauthorized resets.
>
> You can now spend two separate communities for read-only
> and read-write and you can define a Managers list for allowed hosts.
>
> I would appreciate if the community decides this stuff
> useful. Please raise your hands if yes so Mike gets perhaps convinced
> to add this to one of the next patches/releases.
>
> I wrote this backward compatible to old config files with
> Community defined. If you don't define a managers list all hosts
> has access. The following parameters are new to the SNMPAgent clause:
>
> -
> 6.13.3 Community
> deprecated but allowed for backward compatibility
>
> 6.13.5 ROCommunity
>
> SNMP V1 provides a weak method of authenticating SNMP requests, using
> the "community name". This optional parameter allows you to specify
> the SNMP V1 community name that will be honored by SNMPAgent for
> read-only
> access. Defaults to nothing, you have to define one by yourself.
> We strongly recommend that you choose a community name and keep it
> secret.
>
>
> # Use a secret community.
> ROCommunity mysnmprosecret
>
> 6.13.6 RWCommunity
>
> This optional parameter allows you to specify the SNMP V1 community name
> that will be honored by SNMPAgent for read-write access. Knowing this
> secret you are able to reset Radiator via SNMP. Defaults to nothing.
> If you don't need resetting via SNMP use only ROCommunity.
>
> # only necessary for resetting via SNMP
> RWCommunity extremelysecure
>
> 6.13.7 Managers
>
> This optional parameter specifies a list of SNMP managers that have
> access to SNMPAgent. The value is a list of host names or addresses,
> separated by white space or comma. You can have any number of Managers
> lines. Defaults to nothing with all hosts allowed.
>
> # allowed SNMP managers
> Managersfoo.bar.edu 192.168.1.11, noc.rz.uni-ulm.de
> Managersbaz.bar.com,10.1.1.254
>
> --
--
>
>
>
> TODO:
> Documentation should be rewritten by a native speaker :-(
>
>
> Have fun with it.
>
> Regards
> Charly Gaissmaier


===
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) Problems with an NT4.0 host and Radiator 2.18

2001-04-04 Thread Eli Klein

I'm assuming this is an NT 4.0 problem, but maybe someone's seen this
before.

The host connects (via dialup) and gets the correct IP address, but the
netmask is always set to 255.0.0.0, no matter what.  The NT box cannot get
out at all (tcp/icmp/etc).

Here's a level 4 trace:

Wed Apr  4 16:00:01 2001: INFO: Server started: Radiator 2.18 on radius1
Wed Apr  4 16:00:36 2001: DEBUG: Packet dump:
*** Received from 192.168.143.2 port 1645 
Code:   Access-Request
Identifier: 23
Authentic:  <186>cN<148><204>+<132>BmW<167><246>SZ<2><169>
Attributes:
NAS-IP-Address = 192.168.143.2
NAS-Port = 5
NAS-Port-Type = Async
User-Name = "telesis"
Called-Station-Id = "3032359063"
Calling-Station-Id = "3039309813"
User-Password =
"i4<209>F<26><200><135><144><170><154><130>F<234><198>i<28>"
Service-Type = Framed-User
Framed-Protocol = PPP

Wed Apr  4 16:00:36 2001: DEBUG: Handling request with Handler
'Realm=denveronline.net'
Wed Apr  4 16:00:36 2001: DEBUG:  Deleting session for telesis,
192.168.143.2, 5
Wed Apr  4 16:00:36 2001: DEBUG: Handling with Radius::AuthFILE
Wed Apr  4 16:00:36 2001: DEBUG: Radius::AuthFILE looks for match with
[EMAIL PROTECTED]
Wed Apr  4 16:00:36 2001: DEBUG: Radius::AuthFILE ACCEPT: 
Wed Apr  4 16:00:36 2001: DEBUG: Access accepted for
[EMAIL PROTECTED]
Wed Apr  4 16:00:36 2001: DEBUG: Packet dump:
*** Sending to 192.168.143.2 port 1645 
Code:   Access-Accept
Identifier: 23
Authentic:  <186>cN<148><204>+<132>BmW<167><246>SZ<2><169>
Attributes:
Framed-IP-Address = 192.168.139.31
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Netmask = 255.255.255.255
Framed-Routing = None
Framed-MTU = 1500
Framed-Compression = Van-Jacobson-TCP-IP

Wed Apr  4 16:00:36 2001: ERR: Attribute number 90 (vendor ) is not
defined in your dictionary
Wed Apr  4 16:00:36 2001: ERR: Attribute number 91 (vendor ) is not
defined in your dictionary
Wed Apr  4 16:00:36 2001: DEBUG: Packet dump:
*** Received from 192.168.143.2 port 1646 
Code:   Accounting-Request
Identifier: 24
Authentic:  <230><207><246><224>T<197><207><2><198><30><8><9>w
Attributes:
NAS-IP-Address = 192.168.143.2
NAS-Port = 5
NAS-Port-Type = Async
User-Name = "telesis"
Called-Station-Id = "3032359063"
Calling-Station-Id = "3039309813"
Acct-Status-Type = Start
Acct-Authentic = RADIUS
Service-Type = Framed-User
Acct-Session-Id = "0083"
Framed-Protocol = PPP
Tunnel-Client-Endpoint = "10.227.12.2"
Tunnel-ID = "12941"
Acct-Delay-Time = 0

Wed Apr  4 16:00:36 2001: DEBUG: Handling request with Handler
'Realm=denveronline.net'
Wed Apr  4 16:00:36 2001: DEBUG:  Adding session for telesis,
192.168.143.2,
5
Wed Apr  4 16:00:36 2001: DEBUG: Handling with Radius::AuthFILE
Wed Apr  4 16:00:36 2001: DEBUG: Accounting accepted
Wed Apr  4 16:00:36 2001: DEBUG: Packet dump:
*** Sending to 192.168.143.2 port 1646 
Code:   Accounting-Response
Identifier: 24
Authentic:  <230><207><246><224>T<197><207><2><198><30><8><9>w
Attributes:

Wed Apr  4 16:01:04 2001: ERR: Attribute number 90 (vendor ) is not
defined in your dictionary
Wed Apr  4 16:01:04 2001: ERR: Attribute number 91 (vendor ) is not
defined in your dictionary
Wed Apr  4 16:01:04 2001: DEBUG: Packet dump:
*** Received from 192.168.143.2 port 1646 
Code:   Accounting-Request
Identifier: 25
Authentic:  <207><189><250><152><212><197><18>b8<243><159><190><5><156><212>[
Attributes:
NAS-IP-Address = 192.168.143.2
NAS-Port = 5
NAS-Port-Type = Async
User-Name = "telesis"
Called-Station-Id = "3032359063"
Calling-Station-Id = "3039309813"
Acct-Status-Type = Stop
Acct-Authentic = RADIUS
Service-Type = Framed-User
Acct-Session-Id = "0083"
Framed-Protocol = PPP
Tunnel-Client-Endpoint = "10.227.12.2"
Tunnel-ID = "12941"
Framed-IP-Address = 192.168.139.31
Acct-Terminate-Cause = Host-Request
Acct-Input-Octets = 394
Acct-Output-Octets = 441
Acct-Input-Packets = 24
Acct-Output-Packets = 26
Acct-Session-Time = 27
Acct-Delay-Time = 0

Wed Apr  4 16:01:04 2001: DEBUG: Handling request with Handler
'Realm=denveronline.net'
Wed Apr  4 16:01:04 2001: DEBUG:  Deleting session for telesis,
192.168.143.2, 5
Wed Apr  4 16:01:04 2001: DEBUG: Handling with Radius::AuthFILE
Wed Apr  4 16:01:04 2001: DEBUG: Accounting accepted


Any help is greatly appreciated..

Thanks!

-Eli
[EMAIL PROTECTED]


===
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) Detecting login with prefixes

2001-04-04 Thread Elias
Title: Re: (RADIATOR) Detecting login with prefixes



Hi Hugh,
 
As you suggested, I tried using a handler to detect 
logins with specific prefixes, but it doesn't seem to work. My guess here 
is that there's probably something wrong with my regexp. I'm trying to detect 
logins such as IPASS/login@domain. Any 
ideas on what the corerct regexp should be? Man, I definately need to get myself 
a copy of the Camel book!
 
AuthBy 
iPassProxy
 
Regards,
Elias
 
- Original Message - 
 
From: Hugh 
Irvine 
To: Elias ; [EMAIL PROTECTED] 
Sent: Saturday, March 31, 2001 4:11 PM
Subject: Re: (RADIATOR) Detecting login with prefixes
Hello Elias -

  

At 13:12 +0700 28/3/31, Elias wrote:
Hi,
 
Is there a way to 
  detect login prefixes with radiator? I want to detect logins such 
  as [EMAIL PROTECTED] 
  [prefix/login@domain] and proxy the request 
  to another radius server. Can this be done? Thanks.
 
 

This is very easily done with Handlers and Perl regexp's:

# configure AuthBy RADIUS clause for proxy


    Identifier 
ProxyTo
    .


# special Handler for prefix and proxy
# where "prefix" is the string you want to match


    
RewriteUsername ..
    AuthBy 
ProxyTo


You will need to consult the Camel book (Perl reference) for the exact 
syntax of the regexp for what you want to do.

hth

Hugh


    


-- 

NB: I am 
  travelling this week, so there may be delays in our 
correspondence.
Radiator: the 
  most portable, flexible and configurable RADIUS serveranywhere. 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.


(RADIATOR) accounting flat file to CSV ?

2001-04-04 Thread Neale Banks

Greetings all,

Not exclusively Radiator-relevant, but probably RADIUS+Perl relevant...

Does anyone have any pointer to anything to convert flat-file accounting
records to comma-separated format?

Alternatively, any other solutions to the need to tabulate a user's STOP
records to run some elementary stats over their sessions times and
disconnect reasons?

Thanks,
Neale.


===
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) SNMPAgent patch: access restrictions now available

2001-04-04 Thread Carl Litt


Yes, this is a good idea.  I was a little concerned about leaving
security up to a community string.

Thanks for sharing,

Carl Litt
Network Administrator
Execulink Internet


On Wed, 4 Apr 2001, Karl Gaissmaier wrote:

> Hi all and Mike,
>
> I wrote a patch to SNMPAgent to restrict the acces to the Radius
> SNMP vars, especially to disallow unauthorized resets.
>
> You can now spend two separate communities for read-only
> and read-write and you can define a Managers list for allowed hosts.
>
> I would appreciate if the community decides this stuff
> useful. Please raise your hands if yes so Mike gets perhaps convinced
> to add this to one of the next patches/releases.
>
> I wrote this backward compatible to old config files with
> Community defined. If you don't define a managers list all hosts
> has access. The following parameters are new to the SNMPAgent clause:
>
> -
> 6.13.3 Community
> deprecated but allowed for backward compatibility
>
> 6.13.5 ROCommunity
>
> SNMP V1 provides a weak method of authenticating SNMP requests, using
> the "community name". This optional parameter allows you to specify
> the SNMP V1 community name that will be honored by SNMPAgent for
> read-only
> access. Defaults to nothing, you have to define one by yourself.
> We strongly recommend that you choose a community name and keep it
> secret.
>
>
> # Use a secret community.
> ROCommunity mysnmprosecret
>
> 6.13.6 RWCommunity
>
> This optional parameter allows you to specify the SNMP V1 community name
> that will be honored by SNMPAgent for read-write access. Knowing this
> secret you are able to reset Radiator via SNMP. Defaults to nothing.
> If you don't need resetting via SNMP use only ROCommunity.
>
> # only necessary for resetting via SNMP
> RWCommunity extremelysecure
>
> 6.13.7 Managers
>
> This optional parameter specifies a list of SNMP managers that have
> access to SNMPAgent. The value is a list of host names or addresses,
> separated by white space or comma. You can have any number of Managers
> lines. Defaults to nothing with all hosts allowed.
>
> # allowed SNMP managers
> Managersfoo.bar.edu 192.168.1.11, noc.rz.uni-ulm.de
> Managersbaz.bar.com,10.1.1.254
>
> 
>
>
>
> TODO:
> Documentation should be rewritten by a native speaker :-(
>
>
> Have fun with it.
>
> Regards
> Charly Gaissmaier


===
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) Vendor specific attribute question.

2001-04-04 Thread Griff Hamlin

Hello all,

Can anyone tell me what the proper call is in a custom AuthBy module so
retrieve the 'Livingston' attribute from an Accounting Record? It is
VenderAttr 307 in my dictionary, but when I use $p->getAttrByNum(307), I
get an error message saying that Attirbute 307 is not found in my
dictionary. I can see it in my dictionary plain as day though. I guess
I'm not understanding something about the dictionary usage. Does anyone
know how this is supposed to work?

Griff Hamlin, III


===
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) SNMPAgent patch: access restrictions now available

2001-04-04 Thread Karl Gaissmaier

Hi all and Mike,

I wrote a patch to SNMPAgent to restrict the acces to the Radius
SNMP vars, especially to disallow unauthorized resets.

You can now spend two separate communities for read-only
and read-write and you can define a Managers list for allowed hosts.

I would appreciate if the community decides this stuff
useful. Please raise your hands if yes so Mike gets perhaps convinced
to add this to one of the next patches/releases.

I wrote this backward compatible to old config files with
Community defined. If you don't define a managers list all hosts
has access. The following parameters are new to the SNMPAgent clause:

-
6.13.3 Community
deprecated but allowed for backward compatibility

6.13.5 ROCommunity

SNMP V1 provides a weak method of authenticating SNMP requests, using
the "community name". This optional parameter allows you to specify
the SNMP V1 community name that will be honored by SNMPAgent for
read-only
access. Defaults to nothing, you have to define one by yourself.
We strongly recommend that you choose a community name and keep it
secret.

 
# Use a secret community.
ROCommunity mysnmprosecret

6.13.6 RWCommunity

This optional parameter allows you to specify the SNMP V1 community name
that will be honored by SNMPAgent for read-write access. Knowing this
secret you are able to reset Radiator via SNMP. Defaults to nothing.
If you don't need resetting via SNMP use only ROCommunity.

# only necessary for resetting via SNMP
RWCommunity extremelysecure

6.13.7 Managers

This optional parameter specifies a list of SNMP managers that have 
access to SNMPAgent. The value is a list of host names or addresses,
separated by white space or comma. You can have any number of Managers
lines. Defaults to nothing with all hosts allowed.

# allowed SNMP managers
Managersfoo.bar.edu 192.168.1.11, noc.rz.uni-ulm.de
Managersbaz.bar.com,10.1.1.254





TODO:
Documentation should be rewritten by a native speaker :-(


Have fun with it.

Regards
Charly Gaissmaier
 SNMPAgent.pm.gz


(RADIATOR) Little PasswordLogFileName problem

2001-04-04 Thread Robert von Bismarck

Hello,

I am using the PasswordLogFileName feature to provide our helpdesk people
with the missed logins.

This works fine, but I get a lot of fields that look like this :

Wed Apr 4 18:25:24 2001:986401524:username:UNKNOWN-CHAP:password:FAIL

How can I get rid of the UNKNOWN-CHAP field, because according to the docs
it is the password submitted by the user.

Here's the relevant handler in the config file :


ExcludeFromPasswordLog adminitrator root !root 
PasswordLogFileName %L/logs/password.log

Filename /etc/raddb/users



Thanks for any hints,

Robert von Bismarck
Head of UNIX Application Management

Cable & Wireless
Operations
25, Rue des Caroubiers
1227 Carouge
Tel : +41 (0)22 304 47 47
Fax : +41 (0)22 304 47 99
E-mail  : [EMAIL PROTECTED]
Web : http://www.cw.com/ch


===
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) Detecting login with prefixes

2001-04-04 Thread Elias
Title: Re: (RADIATOR) Detecting login with prefixes



Hi Hugh,
 
As you suggested, I tried using a handler to detect 
logins with specific prefixes, but it doesn't seem to work. My guess here 
is that there's probably something wrong with my regexp. I'm trying to detect 
logins such as IPASS/login@domain. Any 
ideas on what the corerct regexp should be? Man, I definately need to get myself 
a copy of the Camel book!
 
 
AuthBy 
iPassProxy
 
Regards,
Elias
 
 

  - Original Message - 
  From: 
  Hugh Irvine 

  To: Elias ; [EMAIL PROTECTED] 
  Sent: Saturday, March 31, 2001 4:11 
  PM
  Subject: Re: (RADIATOR) Detecting login 
  with prefixes
  
  
  Hello Elias -
  
  At 13:12 +0700 28/3/31, Elias wrote:
  Hi,
   
  Is there a way to 
detect login prefixes with radiator? I want to detect logins such 
as [EMAIL PROTECTED] 
[prefix/login@domain] and proxy the request 
to another radius server. Can this be done? Thanks.
   
   
  
  This is very easily done with Handlers and Perl regexp's:
  
  # configure AuthBy RADIUS clause for proxy
  
  
      Identifier 
  ProxyTo
      .
  
  
  # special Handler for prefix and proxy
  # where "prefix" is the string you want to match
  
  
      RewriteUsername 
  ..
      AuthBy 
  ProxyTo
  
  
  You will need to consult the Camel book (Perl reference) for the exact 
  syntax of the regexp for what you want to do.
  
  hth
  
  Hugh
  
  
      
  
  
  -- 
  
  NB: I am 
travelling this week, so there may be delays in our 
  correspondence.
  Radiator: 
the most portable, flexible and configurable RADIUS serveranywhere. 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.