Re: (RADIATOR) Attribute to return DNS addresses

2001-04-04 Thread Hugh Irvine


Hello Brian -

Many vendors seem to support the Ascend attributes:

ATTRIBUTE   Ascend-Client-Primary-DNS   135 ipaddr
ATTRIBUTE   Ascend-Client-Secondary-DNS 136 ipaddr
ATTRIBUTE   Ascend-Client-Assign-DNS137 integer

But you will have to do some experiments and/or check a Livingston 
FAQ. There may also be something on the Radiator archive site:

http://starport.net/~radiator

I also found this on the LIvingston web site:

http://www.livingston.com/tech/archive/portmaster-radius/9711/0034.html


hth

Hugh


At 15:42 +1000 01/4/4, Brian Morris wrote:
Hugh,

I assumed that, but the livingston dictionary (PM3) does not have an entry
in there for a DNS setting.  Do you know of one?

Regards,  Brian Morris



- Original Message -
From: "Hugh Irvine" [EMAIL PROTECTED]
To: "Brian Morris" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, April 04, 2001 2:44 PM
Subject: Re: (RADIATOR) Attribute to return DNS addresses



  Hello Brian -

  I am afraid you are going to search in vain, as there is no standard
  attribute to do this. You will have to use whatever vendor-specific
  is supported by your NAS equipment.

  hth

  Hugh



  At 10:29 +1000 01/4/4, Brian Morris wrote:
  Hi Folks,
  
  I would like to assign a new name server/s to a dial-in account but I can
  not find the attribute I need to return to setup the client with the
primary
  and alternate DNS addresses.  I have looked in both the standard
dictionary
  and the livingston dictionary to no avail. (I am using a Portmaster 3)
  
  I am sure it is something simple but I just can't find it.
  
  Any help would be appreciated!
  
  Regards,  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.

  --

  NB: I am travelling this week, so there may be delays in our
correspondence.

  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.


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

-- 

NB: I am travelling this week, so there may be delays in our correspondence.

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) 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, butit 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!


Handler 
User-Name=/^\w+\/\w+\@.*$/AuthBy 
iPassProxy/Handler

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
  
  AuthBy RADIUS
   Identifier 
  ProxyTo
   .
  /AuthBy
  
  # special Handler for prefix and proxy
  # where "prefix" is the string you want to match
  
  Handler User-Name = /^prefix./
   RewriteUsername 
  ..
   AuthBy 
  ProxyTo
  /Handler
  
  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) 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 :

Handler NAS-IP-Address=some.ip.address.here
ExcludeFromPasswordLog adminitrator root !root 
PasswordLogFileName %L/logs/password.log
AuthBy DBFILE
Filename /etc/raddb/users
/AuthBy
/Handler

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.



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



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



(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:  186cN148204+132BmW167246SZ2169
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 =
"i4209F26200135144170154130F234198i28"
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:  186cN148204+132BmW167246SZ2169
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:  230207O14246224T19720721983089w
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:  230207O14246224T19720721983089w
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:  20718925015221219718b82431591905156212[
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) 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) 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 
**