[RADIATOR] Radiator 4.10 make test errors
Hello, I am in the process of moving my Radius server to a cloud-based server on Rackspace.com. The cloud server is running Ubuntu Linux 12.04 LTS. I downloaded the latest Radiator version 4.10 from your site, and also downloaded the patches which I applied. When I run make test I get the following test failures: not ok 5a not ok 5d1 not ok 5d2 not ok 5f The remaining tests pass. I'm sure these errors are related to a Perl library or some other library not being installed on the server, but it's unclear from just the test numbers what they may be. Can you assist with this issue? ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: (RADIATOR) Email only access
I'm assuming that this is a problem for you because you share your UNIX password files between your RADIUS server and your e-mail server. That being the case, here's how I handled it before I switched to SQL authentication for RADIUS. I set usernames that are e-mail only to be in a different UNIX group. I then used the group as a RADIUS check item (which Radiator can do quite easily). Unfortunately I don't have a sample configuration since I no longer do this. It's pretty straight-forward, however. John Does anyone know how I can limit a dial-up account to email only access? I'm using USR HyperARC chassis if that helps... === 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.
[ off topic ] Re: (RADIATOR) Shells.
I took a relatively simplistic approach -- I simply created a table in my Oracle database which contained a field that corresponded to each field in a UNIX password file. I then wrote a script to split the password file on each colon character and inserted the data into the Oracle database. I did not modify the operating system to authenticate from the Oracle database, so on a regular basis I export the SQL-based password file out into a flat text file and re-construct the UNIX password file on the machines that need it. This allows me to make centralized changes to the SQL password database and have it flow through to all the other machines. (If someone knows how to get the operating system to authenticate directly from the Oracle database, let me know, it'll save me the step of exporting the SQL password data to a text file). I do all of this behind a firewall, of course, and you should too if you plan on it being secure. Hope that helps. John At 08:39 AM 10/5/01 +0800, you wrote: john, I also want to migrate my users in the /etc/passwd UNIX into ORACLE, but I got no idea how to do it. Hope you can share your experience. Thank you. Best Regards Jaafar Sarim SingNet === 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) Shells.
Back when I still used file-based authentication, I ran a script
on a regular basis that examined the password file and retrieved
the user shell. The script then assigned a user to a particular
UNIX-style group based on the value of the shell. Radiator has
a built-in ability to read from an arbitrary text file for UNIX
group data. You can then use that group file to create a check-item
in your authentication scheme.
Unfortunately, I don't have an example configuration since I've
migrated over to SQL-based authentication. I converted the UNIX-style
password file into an SQL database, and my authentication
query is built to consider the shell field during authentication.
Hope that helps.
John
Arkansas.Net
At 01:06 AM 10/5/01 +1000, you wrote:
Guys,
I noticed a couple of years back someone asked for the ability to check a
users shell for authentication.
I am migrating from Merit and as such I have used what shell the customer
had in the passwd file to lock them out if they had not payed.
I guess I can assume that this is not possible with Radiator as there is
nothing in the manual or many questions in the archive.
How can I make this work another way. I am using AuthBy UNIX and FILE aready.
Thanks
Rick
Foreground
LogStdout
LogDir /usr/local/radius/logs
DbDir /usr/local/radius/raddb
# User a lower trace level in production systems:
Trace 4
SnmpgetProg /usr/bin/snmpget
FingerProg /usr/bin/finger
AuthPort1645
AcctPort1646
# You will probably want to add other Clients to suit your site,
# one for each NAS you want to work with
Client monty.caboolture.net.au
Secret xxx
NasType Bay8000SNMP
DupInterval 0
IgnoreAcctSignature
/Client
Client monty1.caboolture.net.au
Secret xxx
NasType Bay
IgnoreAcctSignature
DupInterval 0
/Client
Client 127.0.0.1
Secret xxx
DupInterval 0
/Client
AuthBy UNIX
Identifier System
Filename /etc/shadow
/AuthBy
AuthBy FILE
Identifier CheckUsers
Filename %D/users
/AuthBy
AuthLog FILE
Identifier myauthlogger
Filename %L/authlog
LogSuccess 1
LogFailure 1
/AuthLog
Realm DEFAULT
AuthBy CheckUsers
AuthLog myauthlogger
# Log accounting to a detail file
AcctLogFileName %L/details
AcctLogFileFormat EXEC sp_ins_rad%{Acct-Status-Type} \
@login_time='%Y-%m-%d %H:%M:%S', \
@acct_session_id='%{Acct-Session-Id}', \
@acct_session_time=%{Acct-Session-Time}, \
@acct_input_packets=%{Acct-Input-Packets}, \
@acct_output_packets=%{Acct-Output-Packets}, \
@acct_input_octets=%{Acct-Input-Octets}, \
@acct_output_octets=%{Acct-Output-Octets}, \
@acct_terminate_cause='%{Acct-Terminate-Cause}', \
@user_name='%{User-Name}', \
@nas_ip_address='%{NAS-IP-Address}', \
@nas_port=%{NAS-Port}, \
@nas_port_type='%{NAS-Port-Type}', \
@service_type='%{Service-Type}', \
@framed_protocol='%{Framed-Protocol}', \
@acct_authentic='%{Acct-Authentic}', \
@acct_delay_time=%{Acct-Delay-Time}, \
@connect_info='%{Connect-Info}', \
@called_station_id='%{Called-Staton-Id}', \
@calling_station_id='%{Calling-Station-Id}', \
@annex_tx_speed='%{Annex-Transmit-Speed}', \
@annex_rx_speed='%{Annex-Received-Speed}', \
@framed_ip_address='%{Framed-IP-Address}'
/Realm
===
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) Feature Request - Shutdown hook
In any case, it is easy enough to add a ShutdownHook, so I will do that in a minute and I'll send you the patches (and I'll also send them to Mike so he can add the code to the distribution for the next release). This is *exactly* why you guys rule and why your software and support remains top knotch! Where else can you have a public forum with direct access to the developers who actually care enough to read and respond to EVERY SINGLE MESSAGE. It's unreal! Kudos to you guys -- keep up the excellent work. John === 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) Multiple Servers, centralised logging
Dave, The system you're describing does have a weakness in file-locking and a potential for data to be lost. If both Radius servers attempt to log at the same time, one set of data will be overwritten by the other. On a busy system, this could happen more often than you'd think. The most efficient way to use two servers and centralized logging is by setting up a database server to accept logging. There is good support for this in Radiator -- reference the manual for more information. An added advantage of setting up a Database server for logging is you could also set it up for authentication -- once you do that, you have a centralized place for updates as well. We use a single database server and export the authentication data to flat text files for backup in case the database server fails. Hope that helps. Hi All, We're currently using 2 RADIUS servers, basically a primary and a secondary in case the primary isn't available. Both servers share a mounted file system to write logfiles to, so that when I run radwho or radacct I get information from both servers at a glance. I'm concerned that sooner or later I'm going to come across a race condition and have problems. Is there a better way of doing this, or is this method totally safe? Thanks, Dave Walters Technical Manager Luna Internet Tel. 01782 544 099 Fax. 01782 535 184 Mob. 07968 729 489 [EMAIL PROTECTED] www.luna.co.uk === 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. === 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) CVX VSAs (again, sorry)
Hugh, I'm running the latest version 2.18.2 -- is there a newer version available? John At 06:23 PM 6/19/01 +1000, Hugh Irvine wrote: Hello John - The story is that the latest version of Radiator supports both types of CVX attributes (1 octet and 4 octet) and tries to do the right thing (although its a bit tough with no official attribute definitions). What version of Radaitor are you running? regards 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) CVX VSAs (again, sorry)
Hey guys, I never really got a good answer on the extended VSA support on the Nortel CVX chassis and Radiator. I noticed from the Aptis RADIUS dictionary (which uses some kind of macro language) that some of the VSAs are different than the others. There's a line that says: # # The CVX supports both regular and extended format VSAs # MACRO AptisVSA1(t,s) 26 [vid=2637 type1=%t% len1=+2 data=%s%] MACRO AptisVSA4(t,s) 26 [vid=2637 type4=%t% len1=+5 data=%s%] Everything is the same excep that type4 and type1 field, and the lenl field (+2 vs +5). I'm not exactly sure what those values mean, but I was hoping that Hugh or Mike might be able to explain it? In any case, one of the attributes I'm interested looks like this in the Aptis dictionary: # # VSA definitions with 4-octet sub-attribute types # ATTRIBUTE CVX-PPP-ConnectLimit AptisVSA4(0x85210066, integer) r Here's the same entry in my RADIUS dictionary (obtained from the distribution dictionary): VENDORATTR 2637 CVX-PPP-ConnectLimit0x85210066 integer The hex code and the vendor ID is the same, but I am a bit concerned about that 4-octet sub-attribute type issue. It seems that all of the attributes defined as 4-octet sub-attribute types in the Aptis dictionary do not work properly in the RADIATOR dictionary. However, I am receiving/sending the CVX VSAs with 1-octet sub-attribute types (for example, CVX-Identification, CVX-VPOP-ID, etc). If you guys could look at this I'd really appreciate it I think it's broken, but I don't know enough about it to be sure. If I can help in *any* way let me know. Here's a link to that Aptis RADIUS dictionary: http://zipdial.ziplink.net/docs/aptis-dict.html if you want to take a gander. John Coy Arkansas.Net === 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) Nortel CVX and VSAs
I'm wondering if anybody on the list has a Nortel CVX and is using Radiator for authentication? I cannot seem to get the vendor specific attributes to work properly (I'm using the CVX attributes from the dictionary that ships with the 2.18.2 Radiator). I even found that the CVX-Ascend-Maximum-Channels attribute will cause the CVX to dump core (at least it will make CVX OS v3.6p5 dump dore). Very ugly. I'm not exactly sure how to start troubleshooting -- I am curious if I post some radius logs from the CVX (it has a VERY handy radius debugging tool) as well as logs from Radiator if someone can take a look. I guess my overall question is: anybody out there have a CVX, using Radiator, and also using some VSAs? If so, any possibility of talking off-list? Hugh -- was also curious if you guys had a chance to test the CVX VSAs? It's my understanding that these are a relatively new feature (found in the 2.18 code?) Thanks in advance, John === 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) session database not logging variable %{Framed-IP-Address}
I just upgraded to Radiator 2.18.1 on a Sun Solaris box. After
my upgrade, my session database is no longer logging the
%{Framed-IP-Address} variable. It appears to be undefined. Included
below are my session database config and a debug output from
a Trace 4 on the insertion process.
The variable %{Framed-IP-Address} is being logged on my RADIUS
accounting packets, however.
I'm curious if this is a bug with the session database that someone
else has encountered? Advice appreciated.
PS - I saw today that 2.18.2 was released, but no mention of
a bug that affects the session database.
SessionDatabase SQL
DBSourcedbi:Oracle:XYZ
DBUsername ABC
DBAuth 123
AddQuery \
INSERT INTO radonline \
( username, \
server, \
port, \
session_id, \
login_time, \
framed_address ) \
VALUES \
( LOWER(SUBSTR('%{User-Name}', 0, 50)), \
'%{NAS-Identifier}', \
NVL((%{NAS-Port}-0), 0), \
'%{Acct-Session-Id}', \
NVL((%{Timestamp}-0), 0), \
'%{Framed-IP-Address}' )
DeleteQuery \
DELETE FROM radonline \
WHERE username = LOWER(SUBSTR('%{User-Name}', 0, 50)) \
AND port = NVL((%{NAS-Port}-0), 0) \
AND server = '%{NAS-Identifier}'
ClearNasQuery \
DELETE FROM radonline \
WHERE server = '%{NAS-Identifier}'
CountQuery \
SELECT server, port, session_id \
FROM radonline \
WHERE username = LOWER(SUBSTR('%{User-Name}', 0, 50))
/SessionDatabase
Fri Jun 8 01:23:51 2001: DEBUG: do query is: INSERT INTO radonline (
username,
server, port, session_id, login_time, framed_address ) VALUES (
LOWER(SUBSTR('ch
rist', 0, 50)), '216.152.9.3', NVL((20203-0), 0), '360159532',
NVL((991981431-0)
, 0), '' )
===
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) Radiator training courses- expressions of interest?
hehe, pick a cool place like Las Vegas and I'll get my company to pay my way =) At 08:49 PM 5/7/01 -0500, Mike McCauley wrote: Hi All, We are considering running some courses later in the year. The courses would be on Radius protocol and Radiator installation and configuration. They would run for about 3 days, with one in US, and one in Europe, open to all comers. If anyone is interested, please contact me directly. Cheers. === 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) best technique to fallback to flat file if DB serv er not available
Actually, I managed to get it working using your hints and a
user file. I just replaced the Auth-Type to point to the
identifier specified by the AuthBy GROUP:
In my users file:
DEFAULT Auth-Type = ANCI-SQLFallbackFILE
Ascend-Idle-Limit = 1800,
Ascend-Assign-IP-Pool = 0,
User-Service = Framed-User,
Framed-Protocol = PPP,
Ascend-Maximum-Call-Duration = 480,
Ascend-Client-Primary-DNS = 208.133.27.10,
Ascend-Client-Secondary-DNS = 216.152.26.168,
Ascend-Client-Assign-DNS = DNS-Assign-Yes,
Ascend-Shared-Profile-Enable = 0,
Ascend-Multicast-Client = 1,
Ascend-Multicast-Rate-Limit = 5
and in my radiusd.cfg:
AuthBy GROUP
Identifier ANCI-SQLFallbackFILE
AuthByPolicyContinueWhileIgnore
AuthBy ANCI-AuthSQLPasswd
AuthBy UNIX
/AuthBy
This way I could set default attributes and fall back to a flat
file if the SQL database failed. Worked like a champ.
Thanks a ton for your assistance!
At 12:01 PM 4/30/01 +1000, Hugh Irvine wrote:
Hello John -
You would not use the users file.
hth
Hugh
On Saturday 28 April 2001 14:11, John Coy wrote:
Hugh,
In your example below, I'm unclear how I involve my users
file (which contains the DEFAULT entries I'd like to assign
authenticated users) -- that's why I have AuthBy FILE
and in that file, I have the Auth-Type pointing to the
appropriate authentication process.
John
At 12:15 PM 4/28/01 +1000, Hugh Irvine wrote:
Hello John, Hello Dave -
The problem you are seeing has to do with the the differences between
multiple DEFAULT handling in a user file and multiple AuthBy clauses under
the control of an AuthByPolicy.
In the case of multiple DEFAULT entries, these are only consulted in the
case of a Reject (or multiple Rejects), except when Fall-Through is used,
in which case it will go on to the next in the case of an Accept. There
is no provision for Ignore as you have discovered.
The way to deal with Ignore is by using multiple AuthBy clauses under the
control of an AuthByPolicy ContinueWhileIgnore. In your case, you could
replace your AuthBy FILE, with an AuthBy GROUP:
Realm DEFAULT
RewriteUsername tr/A-Z/a-z/
AuthByPolicyContinueWhileIgnore
AuthBy AuthANCIUsers
/Realm
AuthBy GROUP
Identifier AuthANCIUsers
AuthByPolicy ContinueWhileIgnore
AuthBy AuthSQLPasswd
AuthBy UNIX
/AuthBy
AuthBy SQL
Identifier AuthSQLPasswd
DBSourcedbi:Oracle:starship
DBUsername uname
DBAuth password
AuthSelect SELECT password, checkattr, replyattr \
FROM passwd \
WHERE username = LOWER('%n')
AuthColumnDef 0, Encrypted-Password, check
AuthColumnDef 1, GENERIC, check
AuthColumnDef 2, GENERIC, reply
AddToReplyIfNotExistAscend-Maximum-Channels = 1
AccountingTable
/AuthBy
AuthBy UNIX
Identifier UNIX
Filename/usr/local/etc/shadow
GroupFilename /usr/local/etc/group
AddToReplyIfNotExistAscend-Maximum-Channels = 1
/Authby
hth
Hugh
On Saturday 28 April 2001 03:04, John Coy wrote:
It's my understanding that Fall-Through = yes is the default
setting. However, I did try it and it still did not work.
Thank you for your reply, however. I'm certain that I'm
doing something wrong, but I know eventually I'll figure
it out or someone will nudge me in the right direction.
John
At 01:02 PM 4/27/01 -0400, you wrote:
I'm not a whiz at using DEFAULT, but you might benefit from:
13.2.6 Fall-Through
This attribute is not actually returned to the NAS. Its presence causes
Radiator to continue looking for a match with the next DEFAULT user
name.
Fall-Through = yes
http://www.open.com.au/radiator/ref.html#pgfId=330995
Dave
-Original Message-
From: John Coy [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 11:31 AM
To: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) best technique to fallback to flat file if
DB server not available
I know it's wierd to reply to my own message, but I found
something in the RADIATOR archives:
[ From Mike McCauley ]
2. Chain a second authentication method after SQL, so that if
SQL fails (and
says IGNORE), it will then auth from (say) a local flat file:
Realm whatever
AuthByPolicy ContinueWhileIgnore
AuthBy SQL
# whatever
/AuthBy
# If SQL fails, auth from flat file:
AuthBy FILE
Filename whatever
/AuthBy
/Realm
Re: (RADIATOR) best technique to fallback to flat file if DB server not available
I know it's wierd to reply to my own message, but I found
something in the RADIATOR archives:
[ From Mike McCauley ]
2. Chain a second authentication method after SQL, so that if SQL fails (and
says IGNORE), it will then auth from (say) a local flat file:
Realm whatever
AuthByPolicy ContinueWhileIgnore
AuthBy SQL
# whatever
/AuthBy
# If SQL fails, auth from flat file:
AuthBy FILE
Filename whatever
/AuthBy
/Realm
However, this technique doesn't work if you have an arrangement
similar to this one -- here, my default realm is authenticated
using Authby FILE. Inside that file, I make references to
several authentication methods, including AuthBy SQL and
AuthBy UNIX. However, since the AuthBy SQL fails, it
never gets to move on to the second DEFAULT. Not sure if this
is intended to be this way, or if my config is just so messed
up... anyhow, if there's a way to get it to move on to the next
DEFAULT entry that's what I'd like to do
My radiusd.cfg (excerpts):
-- radiusd.cfg --
Realm DEFAULT
RewriteUsername tr/A-Z/a-z/
AuthByPolicyContinueWhileIgnore
AuthBy AuthANCIUsers
/Realm
AuthBy FILE
Identifier AuthANCIUsers
Filename%D/users
/AuthBy
AuthBy SQL
Identifier AuthSQLPasswd
DBSourcedbi:Oracle:starship
DBUsername uname
DBAuth password
AuthSelect SELECT password, checkattr, replyattr \
FROM passwd \
WHERE username = LOWER('%n')
AuthColumnDef 0, Encrypted-Password, check
AuthColumnDef 1, GENERIC, check
AuthColumnDef 2, GENERIC, reply
AddToReplyIfNotExistAscend-Maximum-Channels = 1
AccountingTable
/AuthBy
AuthBy UNIX
Identifier UNIX
Filename/usr/local/etc/shadow
GroupFilename /usr/local/etc/group
AddToReplyIfNotExistAscend-Maximum-Channels = 1
/Authby
-- end radiusd.cfg --
Then, inside the users file, you have a DEFAULT entry:
-- users --
DEFAULT Auth-Type = AuthSQLPasswd
Ascend-Idle-Limit = 1800,
Ascend-Assign-IP-Pool = 0,
User-Service = Framed-User,
Framed-Protocol = PPP,
Ascend-Maximum-Call-Duration = 480,
Ascend-Client-Primary-DNS = 208.133.27.10,
Ascend-Client-Secondary-DNS = 216.152.26.168,
Ascend-Client-Assign-DNS = DNS-Assign-Yes,
Ascend-Shared-Profile-Enable = 0,
Ascend-Multicast-Client = 1,
Ascend-Multicast-Rate-Limit = 5
DEFAULT Auth-Type = UNIX
Ascend-Idle-Limit = 1800,
Ascend-Assign-IP-Pool = 0,
User-Service = Framed-User,
Framed-Protocol = PPP,
Ascend-Maximum-Call-Duration = 480,
Ascend-Client-Primary-DNS = 208.133.27.10,
Ascend-Client-Secondary-DNS = 216.152.26.168,
Ascend-Client-Assign-DNS = DNS-Assign-Yes,
Ascend-Shared-Profile-Enable = 0,
Ascend-Multicast-Client = 1,
Ascend-Multicast-Rate-Limit = 5
-- end users --
At 09:02 PM 4/26/01 -0500, you wrote:
What's the best technique to have Radiator fall back to authentication
via flat file (UNIX-style auth for example) instead of SQL database if the
SQL database isn't available.
I tried using two DEFAULT entries in my users file, one which did SQL
auth, the other which did UNIX auth but that didn't work. Instead, it
fails to connect to the DB server and won't move on to the flat file.
Hints, tips welcome.
John
===
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.
RE: (RADIATOR) best technique to fallback to flat file if DB serv er not available
It's my understanding that Fall-Through = yes is the default
setting. However, I did try it and it still did not work.
Thank you for your reply, however. I'm certain that I'm
doing something wrong, but I know eventually I'll figure
it out or someone will nudge me in the right direction.
John
At 01:02 PM 4/27/01 -0400, you wrote:
I'm not a whiz at using DEFAULT, but you might benefit from:
13.2.6 Fall-Through
This attribute is not actually returned to the NAS. Its presence causes
Radiator to continue looking for a match with the next DEFAULT user name.
Fall-Through = yes
http://www.open.com.au/radiator/ref.html#pgfId=330995
Dave
-Original Message-
From: John Coy [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 11:31 AM
To: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) best technique to fallback to flat file if DB
server not available
I know it's wierd to reply to my own message, but I found
something in the RADIATOR archives:
[ From Mike McCauley ]
2. Chain a second authentication method after SQL, so that if
SQL fails (and
says IGNORE), it will then auth from (say) a local flat file:
Realm whatever
AuthByPolicy ContinueWhileIgnore
AuthBy SQL
# whatever
/AuthBy
# If SQL fails, auth from flat file:
AuthBy FILE
Filename whatever
/AuthBy
/Realm
However, this technique doesn't work if you have an arrangement
similar to this one -- here, my default realm is authenticated
using Authby FILE. Inside that file, I make references to
several authentication methods, including AuthBy SQL and
AuthBy UNIX. However, since the AuthBy SQL fails, it
never gets to move on to the second DEFAULT. Not sure if this
is intended to be this way, or if my config is just so messed
up... anyhow, if there's a way to get it to move on to the next
DEFAULT entry that's what I'd like to do
My radiusd.cfg (excerpts):
-- radiusd.cfg --
Realm DEFAULT
RewriteUsername tr/A-Z/a-z/
AuthByPolicyContinueWhileIgnore
AuthBy AuthANCIUsers
/Realm
AuthBy FILE
Identifier AuthANCIUsers
Filename%D/users
/AuthBy
AuthBy SQL
Identifier AuthSQLPasswd
DBSourcedbi:Oracle:starship
DBUsername uname
DBAuth password
AuthSelect SELECT password, checkattr, replyattr \
FROM passwd \
WHERE username = LOWER('%n')
AuthColumnDef 0, Encrypted-Password, check
AuthColumnDef 1, GENERIC, check
AuthColumnDef 2, GENERIC, reply
AddToReplyIfNotExistAscend-Maximum-Channels = 1
AccountingTable
/AuthBy
AuthBy UNIX
Identifier UNIX
Filename/usr/local/etc/shadow
GroupFilename /usr/local/etc/group
AddToReplyIfNotExistAscend-Maximum-Channels = 1
/Authby
-- end radiusd.cfg --
Then, inside the users file, you have a DEFAULT entry:
-- users --
DEFAULT Auth-Type = AuthSQLPasswd
Ascend-Idle-Limit = 1800,
Ascend-Assign-IP-Pool = 0,
User-Service = Framed-User,
Framed-Protocol = PPP,
Ascend-Maximum-Call-Duration = 480,
Ascend-Client-Primary-DNS = 208.133.27.10,
Ascend-Client-Secondary-DNS = 216.152.26.168,
Ascend-Client-Assign-DNS = DNS-Assign-Yes,
Ascend-Shared-Profile-Enable = 0,
Ascend-Multicast-Client = 1,
Ascend-Multicast-Rate-Limit = 5
DEFAULT Auth-Type = UNIX
Ascend-Idle-Limit = 1800,
Ascend-Assign-IP-Pool = 0,
User-Service = Framed-User,
Framed-Protocol = PPP,
Ascend-Maximum-Call-Duration = 480,
Ascend-Client-Primary-DNS = 208.133.27.10,
Ascend-Client-Secondary-DNS = 216.152.26.168,
Ascend-Client-Assign-DNS = DNS-Assign-Yes,
Ascend-Shared-Profile-Enable = 0,
Ascend-Multicast-Client = 1,
Ascend-Multicast-Rate-Limit = 5
-- end users --
At 09:02 PM 4/26/01 -0500, you wrote:
What's the best technique to have Radiator fall back to
authentication
via flat file (UNIX-style auth for example) instead of SQL
database if the
SQL database isn't available.
I tried using two DEFAULT entries in my users file, one which did SQL
auth, the other which did UNIX auth but that didn't work.
Instead, it
fails to connect to the DB server and won't move on to the flat file.
Hints, tips welcome.
John
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator
Re: (RADIATOR) best technique to fallback to flat file if DB serv er not available
Hugh,
In your example below, I'm unclear how I involve my users
file (which contains the DEFAULT entries I'd like to assign
authenticated users) -- that's why I have AuthBy FILE
and in that file, I have the Auth-Type pointing to the
appropriate authentication process.
John
At 12:15 PM 4/28/01 +1000, Hugh Irvine wrote:
Hello John, Hello Dave -
The problem you are seeing has to do with the the differences between
multiple DEFAULT handling in a user file and multiple AuthBy clauses under
the control of an AuthByPolicy.
In the case of multiple DEFAULT entries, these are only consulted in the case
of a Reject (or multiple Rejects), except when Fall-Through is used, in
which case it will go on to the next in the case of an Accept. There is no
provision for Ignore as you have discovered.
The way to deal with Ignore is by using multiple AuthBy clauses under the
control of an AuthByPolicy ContinueWhileIgnore. In your case, you could
replace your AuthBy FILE, with an AuthBy GROUP:
Realm DEFAULT
RewriteUsername tr/A-Z/a-z/
AuthByPolicyContinueWhileIgnore
AuthBy AuthANCIUsers
/Realm
AuthBy GROUP
Identifier AuthANCIUsers
AuthByPolicy ContinueWhileIgnore
AuthBy AuthSQLPasswd
AuthBy UNIX
/AuthBy
AuthBy SQL
Identifier AuthSQLPasswd
DBSourcedbi:Oracle:starship
DBUsername uname
DBAuth password
AuthSelect SELECT password, checkattr, replyattr \
FROM passwd \
WHERE username = LOWER('%n')
AuthColumnDef 0, Encrypted-Password, check
AuthColumnDef 1, GENERIC, check
AuthColumnDef 2, GENERIC, reply
AddToReplyIfNotExistAscend-Maximum-Channels = 1
AccountingTable
/AuthBy
AuthBy UNIX
Identifier UNIX
Filename/usr/local/etc/shadow
GroupFilename /usr/local/etc/group
AddToReplyIfNotExistAscend-Maximum-Channels = 1
/Authby
hth
Hugh
On Saturday 28 April 2001 03:04, John Coy wrote:
It's my understanding that Fall-Through = yes is the default
setting. However, I did try it and it still did not work.
Thank you for your reply, however. I'm certain that I'm
doing something wrong, but I know eventually I'll figure
it out or someone will nudge me in the right direction.
John
At 01:02 PM 4/27/01 -0400, you wrote:
I'm not a whiz at using DEFAULT, but you might benefit from:
13.2.6 Fall-Through
This attribute is not actually returned to the NAS. Its presence causes
Radiator to continue looking for a match with the next DEFAULT user name.
Fall-Through = yes
http://www.open.com.au/radiator/ref.html#pgfId=330995
Dave
-Original Message-
From: John Coy [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 11:31 AM
To: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) best technique to fallback to flat file if DB
server not available
I know it's wierd to reply to my own message, but I found
something in the RADIATOR archives:
[ From Mike McCauley ]
2. Chain a second authentication method after SQL, so that if
SQL fails (and
says IGNORE), it will then auth from (say) a local flat file:
Realm whatever
AuthByPolicy ContinueWhileIgnore
AuthBy SQL
# whatever
/AuthBy
# If SQL fails, auth from flat file:
AuthBy FILE
Filename whatever
/AuthBy
/Realm
However, this technique doesn't work if you have an arrangement
similar to this one -- here, my default realm is authenticated
using Authby FILE. Inside that file, I make references to
several authentication methods, including AuthBy SQL and
AuthBy UNIX. However, since the AuthBy SQL fails, it
never gets to move on to the second DEFAULT. Not sure if this
is intended to be this way, or if my config is just so messed
up... anyhow, if there's a way to get it to move on to the next
DEFAULT entry that's what I'd like to do
My radiusd.cfg (excerpts):
-- radiusd.cfg --
Realm DEFAULT
RewriteUsername tr/A-Z/a-z/
AuthByPolicyContinueWhileIgnore
AuthBy AuthANCIUsers
/Realm
AuthBy FILE
Identifier AuthANCIUsers
Filename%D/users
/AuthBy
AuthBy SQL
Identifier AuthSQLPasswd
DBSourcedbi:Oracle:starship
DBUsername uname
DBAuth password
AuthSelect SELECT password, checkattr, replyattr \
FROM passwd \
WHERE username = LOWER('%n')
AuthColumnDef 0, Encrypted
(RADIATOR) dictionary for CVX boxes? (dictionary.cvx)
Is there a separate data dictionary for the CVX boxes? I know that the CVX attributes appear in the standard large dictionary, but I want to build a custom dictionary which only contains dictionary.ascend, dictionary.redback and the CVX attributes. I noticed someone posted a CVX dictionary to the mailing list a bit ago, but it seemed to be in some kind of macro language and not a dictionary file per-se. If someone can tell me where to find a stand-alone CVX dictionary I'd be grateful. John === 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) best technique to fallback to flat file if DB server not available
What's the best technique to have Radiator fall back to authentication via flat file (UNIX-style auth for example) instead of SQL database if the SQL database isn't available. I tried using two DEFAULT entries in my users file, one which did SQL auth, the other which did UNIX auth but that didn't work. Instead, it fails to connect to the DB server and won't move on to the flat file. Hints, tips welcome. John === 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) dictionary for CVX boxes? (dictionary.cvx)
Hugh, Thanks for the feedback. I did upgrade to 2.18.1, appreciate the hint about the dictionary file. I did end up doing basically what you suggested -- started with the dictionary file and removed the VSA's I didn't need and added the redback ones. All in all I should be set. Thanks, John At 01:12 PM 4/27/01 +1000, Hugh Irvine wrote: Hello John - On Friday 27 April 2001 09:59, John Coy wrote: Is there a separate data dictionary for the CVX boxes? I know that the CVX attributes appear in the standard large dictionary, but I want to build a custom dictionary which only contains dictionary.ascend, dictionary.redback and the CVX attributes. I noticed someone posted a CVX dictionary to the mailing list a bit ago, but it seemed to be in some kind of macro language and not a dictionary file per-se. If someone can tell me where to find a stand-alone CVX dictionary I'd be grateful. You would be better off starting with the standard dictionary file, and removing the unwanted VSA's and adding the Redback VSA's from dictionary.redback to the result. Should take about 3 minutes with your favourite text editor. The reason you should start with the standard dictionary is because there are lots of things in it that Radiator uses. BTW - Radiator 2.18.1 was released yesterday with support for the extended CVX attributes. 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.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Ascend-Multicast-Client
Greetings all! It's been a long time since I've posted to this list -- probably a good sign because my RADIUS server has been authenticating nicely for several years now. I'm preparing to upgrade from 2.13 to 2.18 which is exciting, and a testimony to the rock-solid software these guys at Open System Consultants produce. In any case, I'm trying to figure out a few attributes that appear in the large dictionary file that ships with the 2.18 server. I'm particularly curious about the Ascend-Multicast-Client and the Ascend-Multicast-Rate-Limit attributes. In my *old* dictionary file (which seems to match the dictionary.ascend file which ships with 2.18) these attributes are defined as: ATTRIBUTE Ascend-Multicast-Client 155 integer VALUE Ascend-Multicast-Client Multicast-No0 VALUE Ascend-Multicast-Client Multicast-Yes 1 ATTRIBUTE Ascend-Multicast-Rate-Limit 152 integer However, in the new 2.18 dictionary file: VENDORATTR 2637 CVX-Ascend-Multicast-Client 155 integer VALUE CVX-Ascend-Multicast-Client No 0 VALUE CVX-Ascend-Multicast-Client Yes 1 VENDORATTR 2637 CVX-Ascend-Multicast-Rate-Limit 152 integer Now, the integer value of these attributes is the same (155 and 152) -- however, the VENDORATTR is definately different -- seems to reference the Nortel CVX's even though the Ascend-* attributes are Ascend non-standard attributes. In any case, I'm curious about this discrepancy and what steps I need to do to address it? I considered changing the reply attribute in my users file to CVX-Ascend-Multicast-Client, but was concerned that it wouldn't be recognized by my Ascend boxes due to the VENDORATTR tag... In any case, guidance would be greatly appreciated! John Coy Arkansas.Net === 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) AuthBY UNIX clause sample
The following statements are in my radiusd.cfg file: -- START radiusd.cfg -- # # This AuthBy statement is used to allow the user's file # to refer to a UNIX-style password file when authenticating # users from the 'users' file. --jcoy # AuthBy UNIX Identifier UNIX Filename/usr/local/etc/shadow GroupFilename /usr/local/etc/group /Authby # # This AuthBy statement defines the location of the 'users' # file on the ANCI dial-up system. --jcoy # AuthBy FILE Identifier AuthANCIUsers Filename%D/users /AuthBy # # This realm handles every other user on the ANCI network. --jcoy # Realm DEFAULT RewriteUsername tr/A-Z/a-z/ AuthByPolicyContinueAlways AuthBy AuthANCIUsers /Realm -- STOP radiusd.cfg -- Then in my user's file I have: -- START users -- # # Default clause for handling everyone not handled explicitly above # DEFAULT Auth-Type = UNIX Ascend-Idle-Limit = 900, Ascend-Assign-IP-Pool = 0, User-Service = Framed-User, Framed-Protocol = PPP, Ascend-Maximum-Channels = 1, Ascend-Maximum-Call-Duration = 480, Ascend-Client-Primary-DNS = 10.10.10.1, Ascend-Client-Secondary-DNS = 10.10.10.2, Ascend-Client-Assign-DNS = DNS-Assign-Yes, Ascend-Shared-Profile-Enable = 0 -- STOP users -- At 11:14 AM 8/14/00 +0530, Administrator wrote: Using Radiator RADIUS ver. 2.13 - Authtentication is through /etc/passwd file of UNIX - I would also like to validate the 'group' check item. Can anyone show me a sample implementation of the above using the AuthBY UNIX clause - I did give it a try, BUT could NOT succeed - Would appreciate any help from anyone using the above authtentication format. Vidur === 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.
(RADIATOR) more simple way to reject a certain group of users
In my operation, we sell e-mail only accounts which get written to /etc/password/shadow. However, we also use /etc/password/shadow to authenticate using Radius. When an e-mail only user is created, his shell is set to /usr/bin/mailshell, and I have a script that extracts those usernames and places them in a "group" file. Radiator uses that group file to reject users: in my users file: DEFAULT Auth-Type = UNIX, Group = mail, Auth-Type = "Reject: Dial-up access not authorized for this account" in my radiusd.cfg file: AuthBy UNIX Identifier UNIX Filename/usr/local/etc/shadow GroupFilename /usr/local/etc/group /Authby The dilemma I'm having is that the "group" file is a single large comma-delimited string, and it's 'ugly'. Is there a better way to reject a group of users based on the value of their shell variable, or is there a way I can write a different type of file (or even an SQL query) with a list of usernames to reject. Help is greatly appreciated. John === 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) upgrading from 1.13.1 to 1.15
If I were to upgrade from version 1.13.1 to 1.15, are there any configuration changes I need to make to my radiusd.cfg file or are the config files backwards compatible? John === 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) How to split between normal users and ISDN users
There is also a port type attribute you can check. Modem users are Async and ISDN users are sync. That could probably be a better check instead of connect rate, since you can actually connect at 56k with ISDN if you set it to do robbed bit signaling instead of clear channel. John At 05:32 PM 2/19/00 +1100, Hugh Irvine wrote: Hello Sony - On Sat, 19 Feb 2000, Sony Sunjaya wrote: Hi, I'm using Ascend Max6000 for ISDN users and for analog 56K dial up users. I want Radiator to reject normal users who connect with ISDN modem. But those normal users should be able to connect with analog modem (56Kbps or below). The ISDN users should be able to connect with both analog or ISDN modem. Can I do that with Radiator ? How ? Yes this is very easy to do with the Connect-Rate check attribute. You would add a check item like this to your users file for those limited users: user1 Connect-Rate = 56000, Password etc This will allow these users to connect at speeds up to 56Kbps, but no higher. If your configuration is more complex you might consider sending me your configuration file (no secrets) and I'll suggest a better way. 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. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) OFF TOPIC: authentication for large-scale internet mail applications
Oh, I want to clarify that we're *not* on NT -- I'm using Sun Solaris boxes (2.5.1 and 2.6) for RADIUS, sendmail, and POP3 services. At 08:17 AM 2/9/00 +0100, [EMAIL PROTECTED] wrote: On Tue, Feb 08, 2000 at 06:53:30PM -0600, John Coy wrote: use Radiator for dial-up authentication. I was wondering if there are solutions out there which integrate Radius (or LDAP, or whatever is the appropriate piece) along with Sendmail and POP3 services. What I'm looking for is a way to distribute e-mail systems across multiple servers with a common authentication (and user directory) scheme. we're using Radiator with mysql and qmail with a virtual domain addon (www.inter7.com/vpopmail) that uses the same mysql database to store users for receiving mail and authorizing pop. it shouldnt be a problem to use vpopmail on more servers... if you want to stick to NT... if i'm not mistaken, exchange supports LDAP and so does radiator... Ricardo. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) OFF TOPIC: authentication for large-scale internet mail applications
I know this is off topic, but it has to do with authentication and I do use RADIUS. I was hoping someone could help get me pointed in the right direction: I run a moderate sized ISP (20,000+ customers). We currently use Radiator for dial-up authentication. I was wondering if there are solutions out there which integrate Radius (or LDAP, or whatever is the appropriate piece) along with Sendmail and POP3 services. What I'm looking for is a way to distribute e-mail systems across multiple servers with a common authentication (and user directory) scheme. I'm just starting to read and understand about LDAP, but I'm being told it's an important part of trying to implement. I am sure other people have run into this, and I'm curious how they've attacked the problem. I apologize for the off-topic post. Reply off-list (or, if possible, provide me with a mailing list that discusses these issues). Thanks in advance, John Coy ANCI/Arkansas.Net === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Warning message
What version of TAOS are you running on your MAX boxes? I have 50 or so MAX boxes running on my network and don't see these errors. I'm running 7.0.22 on my MAX40XX boxes, and 7.2.3 on my MAX60XX boxes. At 11:22 AM 12/28/99 -0500, Mike McCauley wrote: Hi Erik, Thiose messages indicate that you have a Max that has non RFC compliant signature in accounting requests. You should probbaly enable IgnoreAcctSignature in teh Client clause for those Max's. Although your users are authenticating, you are probably losing some accounting data. You should fix it soon. Cheers. On Dec 27, 10:43am, Erik Meitner wrote: Subject: (RADIATOR) Warning message What exactly do these mean? Sat Dec 18 04:06:16 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.50) Sat Dec 18 04:06:42 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.56) Sat Dec 18 04:06:48 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.6) Sat Dec 18 04:06:55 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.5) Sat Dec 18 04:07:01 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.7) Sat Dec 18 04:07:09 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.17.2) Sat Dec 18 04:07:10 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.57) Sat Dec 18 04:07:30 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.47.18) Sat Dec 18 04:07:33 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.51) Sat Dec 18 04:07:33 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.13) Sat Dec 18 04:07:35 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.47.147) Sat Dec 18 04:07:42 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.56) Sat Dec 18 04:07:45 1999: WARNING: Bad authenticator in request from 206.242.16.2 (4.17.200.2) Sat Dec 18 04:08:34 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.13) Sat Dec 18 04:08:39 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.2) Sat Dec 18 04:09:02 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.16.7) Sat Dec 18 04:09:09 1999: WARNING: Bad authenticator in request from 206.242.16.2 (206.242.17.2) 206.24.16.2 is one of our Ascend MAX's. The IP's in the parentheses are our other MAX's. All of these MAX's have Client entries: #ascend Client 206.242.16.2 #ascend2 IdenticalClients 206.242.16.6 #ascend3 IdenticalClients 206.242.16.7 #ascend4 IdenticalClients 206.242.16.5 #ascend5 IdenticalClients 206.242.16.11 #ascend6 IdenticalClients 206.242.16.13 #ascend7 IdenticalClients 206.242.16.50 #ascend8 IdenticalClients 206.242.16.51 #ascend9 IdenticalClients 206.242.16.56 #ascend10 IdenticalClients 206.242.16.57 #ascend11 IdenticalClients 206.242.16.58 #ascend12 IdenticalClients 206.242.16.10 #ascend13 IdenticalClients 4.17.220.2 #ascend14 IdenticalClients 4.17.220.3 #ascend15 IdenticalClients 206.242.47.18 #ascend16 IdenticalClients 206.242.47.147 #ascend17 IdenticalClients 4.17.200.2 #ascend18 IdenticalClients 206.242.17.2 Secret thesecret NasType Ascend /Client Everything works fine, I don't think users are being rejected. Thanks Erik Meitner - Network Technician Valley Business Equipment and Internet http://www.vbe.com 3200 North Main Street Oshkosh, Wisconsin 54901 Phone: 920.236.6500 x125 Fax: 920.236.6501 mailto:[EMAIL PROTECTED] http://erik.vbe.com Please visit http://www.thehungersite.com/ === 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 Erik Meitner -- 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. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Quick easy question....
update table_name set username = lower(username) SVRMGR create table test ( username varchar2(16) ); Statement processed. SVRMGR insert into test values ( 'JOHN' ); 1 row processed. SVRMGR update test set username = lower(username); 1 row processed. SVRMGR select * from test; USERNAME john 1 row selected. At 03:12 PM 11/11/99 -0500, Kelly Hamlin wrote: We imported our database of users and info from a VFP database into platypus and all is great except for the fact all usersnames and passwords are listed UPPERCASe and i need a simple SQL query where i can change username and password to all lower case, then i will have everything running smoothly :) thanks in advance Kelly Hamlin [EMAIL PROTECTED] Network Administrator (941) 332.4900 http://www.neosmart.com === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Different logfiles for different groups?
You could merge your /etc/passwd and /etc/shadow files and place it in a secure location for your radius server to achive the functionality you're looking for. There's no need for a separate /etc/passwd and /etc/shadow file. At 12:03 PM 10/30/99 -0700, you wrote: The prob is w/ linux the users primary group is only listed in /etc/passwd, not shadow.. On Sat, 30 Oct 1999, John Coy wrote: Date: Sat, 30 Oct 1999 13:37:31 -0500 From: John Coy [EMAIL PROTECTED] To: Jason Godsey [EMAIL PROTECTED] Subject: Re: (RADIATOR) Different logfiles for different groups? I synchronize flat UNIX-style shadow, and group files without any problem. I use an Identifier statement to point to the UNIX password and group files. These are my entries in my radiusd.cfg file: # # This AuthBy statement is used to allow the user's file # to refer to a UNIX-style password file when authenticating # users. --jcoy # AuthBy UNIX Identifier UNIX Filename/usr/local/etc/shadow GroupFilename /usr/local/etc/group /Authby # # This AuthBy statement defines the location of the user's # file on the ANCI dial-up system. --jcoy # AuthBy FILE Identifier AuthANCIUsers Filename%D/users /AuthBy # # This realm handles every other user on the ANCI network. --jcoy # Realm DEFAULT RewriteUsername tr/A-Z/a-z/ AuthByPolicyContinueAlways AuthBy AuthANCIUsers /Realm Then, in my 'users' file, I have: # # Default clause for handling everyone not handled explicitly above # DEFAULT Auth-Type = UNIX Ascend-Idle-Limit = 900, Ascend-Assign-IP-Pool = 0, User-Service = Framed-User, Framed-Protocol = PPP, Ascend-Maximum-Channels = 1, Ascend-Maximum-Call-Duration = 480, Ascend-Client-Primary-DNS = 208.133.27.10, Ascend-Client-Secondary-DNS = 208.145.38.10, Ascend-Client-Assign-DNS = DNS-Assign-Yes, Ascend-Shared-Profile-Enable = 0 Hope that helps. John At 08:35 AM 10/30/99 -0700, you wrote: I will give it a try, however I'm fairly sure we have tried. In my case there is a bit of a problem, I am generating/maintaining the password files on our mail server. There are 2 seperate radius servers who I rsync the files over ssh to every change. The radius server also act as backup MX servers for us so I didn't want any local accounts on the machines. In my case I'm actually pointing to /usr/local/etc/shadow,passwd,group. Will auth by system work in this way? This is why I said I just whiped up a little perl program to make the user:pass:uid:gid file in the mix. On the mail server I use PAM which matches primary and secondary just fine. Jason On Sat, 30 Oct 1999, Hugh Irvine wrote: Date: Sat, 30 Oct 1999 10:00:35 +1000 From: Hugh Irvine [EMAIL PROTECTED] To: Jason Godsey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: (RADIATOR) Different logfiles for different groups? Hello Jason - On Sat, 30 Oct 1999, Jason Godsey wrote: I'm having a problem getting the users primary group, I'm running radiator on linux and have the passwordfile pointed to /etc/shadow, it is able to check the crypted password just fine, however linux's shadow file does not contain the users primary group (however the freebsd box's master.passwd does). Is there an easier fix that my current solution? Perhaps try AuthBy SYSTEM rather than AuthBy UNIX. Please let me know how it works. cheers 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. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) (Radiator) Client
Scott certainly makes some valuable points. As with anything in the networking world, there are several ways to "skin the cat". I think when you're managing a network of hundreds of NASs, having a different secret for each, and a different Client clause makes things just a bit unmanagable. It's an issue of scalability,convenience, etc. Scott's points are certainly valid and I would agree that a little access list functionality would be nice to complement the convenience of the default client clause. Mike? Whatcha think of that for a feature request? John At 10:24 PM 10/30/99 -0400, you wrote: John Coy writes: I use Tom's approach -- set all the secrets the same on all my NAS' and then use a default client statement. It will protect you any which way. Personally, I think this can pose a security risk. Using the same secrets on all the NAS's isn't so bad, though, not quite secure, but the DEFAULT client is something that bothers me. What prevents somebody from the net from hitting your Radius server and trying to authenticate? I would either define a seperate CLIENT section for each NAS, or define a single CLIENT section and use IdenticalClients to indicate all the other NAS's that can also use that section. I would suggest a couple new features that would allow the above suggestion from John work, similar to how Apache does it: LIMIT Order Deny,Allow AllowFrom IP_PATTERN IP_PATTERN ... DenyFrom IP_PATTERN IP_PATTER ... /LIMIT In any the case, keep security in mind when configuring your radius server, even if you are sitting behind a firewall or router using filters. As for DNS, you should have a primary and a secondary and the chance of both failing should be slim. You can always set several DNS entries on your UNIX host's /etc/resolv.conf which point to off-site DNS servers such as your upstream ISPs DNS servers. At 12:42 AM 10/31/99 +1000, you wrote: On Sat, Oct 30, 1999 at 07:00:07AM -0600, Chris M wrote: Is it a better practice to use IP addresses instead of names for Client? What about using both (if DNS fails for some reason it can check the IP)? Back to the original question, I think I would prefer to use IP addresses over DNS names. We don't use DNS names anywhere in our router card configs, radius configs, etc. If all the DNS's go (for instance, part of the network goes out), at least they can still connect, authenticate and use the net by way of IP addresses (though, not optimal). However, it is only an opinion and does not mean to say that DNS addresses are bad. Just my 2 pence worth. Scott -- +-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineermailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-+ CNS, HDL Center, Suite 301, Ohio University, Athens, OH 45701-2979 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Hugh...
Hugh, You answer questions too fast :) I never get a chance to look smart and answer other user's questions. Do you ever sleep? :) (just joking of course, I think *everyone* appreciates your help). === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Multiple instances
Absolutely -- set up two configuration files and run radiator by specifying which configuration file to use (ie the -config_file paramater). Then, in the config file: BindAddress 123.123.123.1 That will force radiator to bind to a specific IP address. Hope that helps. John At 05:54 PM 10/25/99 -0500, you wrote: Hello, Can anyone tell me if it's possible to have multiple instances of Radiator running but listening on different IP addresses?? Thank you in advance for any light you may be able to shed on this. Robert === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Radiator Stopped Working
I think that Paul's problems here show a fundamental weakness in the design of Radiator -- the fact that if the *accounting* SQL server goes down, all your functionality for *authentication* is lost as well. I've personally worked around this by running two separate daemons. One for authentication and the other for accounting. This limits my exposure to a total network outage due to a glitch with my Oracle database (which is rare, but did happen once and that was enough for me). I love the Radiator product, but something should be done to separate the code from its heavy reliance on the remote database server. There should be a way to ignore errors. Instead of dumping core when accounting packets don't get written to the database, the system should generate an SNMP trap, write to the logs or something less dramatic than shutting down. Just my 2 cents worth. If anyone is interested in how I separated my authentication from my accounting, let me know. John At 09:23 AM 10/17/99 +1000, you wrote: I seem to have sorted the problem out now. There is a handy mysql program called isamchk which allowed me to check each of the tables, sure enough a couple of them had corrupted pointers. Used the repair option and now Radiator seems to be working ok again. Regards. Paul Hugh Irvine wrote: Hello Paul - On Fri, 15 Oct 1999, Paul Black wrote: I've found out where the problem is with my Radiator. When I commented out the Session Database section of my radius.cfg file, Radiator started to work again. I've noticed that a couple of my mysql processes are using up 99% of the cpu time. I'm fairly sure the problem lies in the Session Database. Could anyone tell me which table(s) to deleted and how to recreate it again? Have a look in the Radiator goodies directory - there is a mysqlCreate.sql script that does both, although it does all the other tables as well!! *** You will have to extract just the bit that drops and recreates the table called RADONLINE. Don't just run the script as it is, as it will destroy and recreate all your other tables as well*** You might also check in the RAdmin directory to verify the format that was created by the schema.pl module. I just had a look here and the RADONLINE tables in both places look identical, but you should check yourself. If you have any questions please don't hesitate to contact me. 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. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Radiator in accounting only mode?
I sent the message below last night -- I think that my main goal is to get Radiator to only bind one socket when intitializing... is there a way to do this? The reason I ask is that I want to run two instances of Radiator -- one on port 1812 for auth, and one on port 1813 for accounting. If I try to specify only one port in the radiusd.cfg file, it will default to the 1645 or 1646 ports automatically for either auth or acct (depending on which one I omit in the config file) -- Is there a way to put the Radiator daemon in accounting-only mode? (ie: not respond to auth requests or bind an auth port?) John === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Radiator in accounting only mode?
Is there a way to put the Radiator daemon in accounting-only mode? (ie: not respond to auth requests or bind an auth port?) John === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Blocking calls with no CLI
I believe that you can use PERL regexps in the check items. In that case, you can have in your users file: # # DEFAULT user to reject blank CLI # DEFAULT Calling-Station-ID=/^$/, Auth-Type="Reject" I'm not sure if that'll work, but give it a try. John At 05:11 PM 9/16/99 +1000, you wrote: Hello, Just wondering if anyone knows how to block a call when there is no caller ID. I can use a check item such as: test Password="testpass", Calling-Station-Id=/249/ but Just wondering how to only accept when there is CLI Thanks Matt --- Matthew Nichols - CCNA Network / Systems Engineer HunterLink Pty Ltd Newcastle NSW Australia Phone: +61 2 4969 0122 Fax: +61 2 4969 0133 Reply To: [EMAIL PROTECTED] PGP Public Key: http://moonah.hunterlink.net.au/~matt/pgp/pgpkey.html HunterLink Web Site: http://www.hunterlink.net.au === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radpwtst
I've found that you have to specify the name/IP address of the RADIUS server, as well as the shared secret. Also, make sure your radius server is configured to allow authentication requests from the machine you're using to run radpwtst. I use the following command line: ./radpwtst -s radius.server.com -secret SECRET \ -noacct -dictionary /your/dictionary/file/here \ -auth_port 1812 At 01:45 PM 9/10/99 -0400, you wrote: I am trying to get radpwtst to work to test password via a command line ... I try using radpwtst -noacct -user username -password and I get sending Access-Request... No reply any ideas how to get this working ??? Jamie Orzechowski RipNET Internet Services System Administrator Tel.: 800-267-4434 ext 293 Tel.: 613-342-3946 ext 293 Fax.: 613-342-8672 Web.: http://www.ripnet.com Web.: http://www.moonchilli.com EMail.: [EMAIL PROTECTED] === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Identifier statement inside a REALM clause
In the RADIATOR documentation section 6.13.5, there is an example usage of the "Identifier" statement. It shows: Realm DEFAULT AuthBy FILE /AuthBy /Realm Realm dummyrealmforholdingauthbyunix AuthBy UNIX Identifier System /AuthBy /Realm It then goes on to show a typical usage example in the "users" file: DEFAULT Auth-Type = System I was wondering if it is truly required to place the AuthBy statement inside Realm dummyrealm to be used this way? I guess I'm asking, could you have in your radiusd.cfg: AuthBy UNIX Identifier System /AuthBy And then still use "DEFAULT Auth-Type = System"? I hope my question makes sense. Thanks in advance for the answer :) John === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging everything with sql into database
Radiator already provides funtionality to log everything to an SQL database. There's no hacking required. Look at the AuthBy SQL and the Log SQL directives. The docs are at http://www.open.com.au/radiator/ref.html I've even posted an example implementation to log accounting packets into an SQL database while retaining authentication using another method. Search the mailing list archives. At 02:29 PM 9/2/99 +0300, Ragnar Kurm wrote: i'm trying to make radiator to log everything into my database. my database table would contain following fields: id, key, value. one log event would be grouped by id. how can this be achieved? nearest solution i can think of is following: * hack radiator to provide a perl code to access all event attributes * encode them into a long string * call database procedure and pass the string * the procedure would decode the string and insert key-value pairs with shared id into table is there more elegant way to do this? especially should i hack radiator or does it provide facilities to satisfy my needs without hacking one? ragnar === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) L/C Login Ids
This is handled by the RewriteUsername directive. You can have a global one or one applied to a specific client or realm. To make usernames all lower case: RewriteUsername tr/A-Z/a-z/ See the radiator docs section 6.3.19 RewriteUsername for a start (that's the section for the 2.13 docs). At 09:02 PM 8/31/99 +, Paul Black wrote: My most frequent cause of support calls comes from people who are logging in with their caps lock key on. How can I use Radiator to translate all usernames and passwords to lowercase, or better yet, to be case insensitive? Regards. Paul === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Session database
Look at section 6.5 of the RADIATOR manual under the SessionDatabase SQL section. There is an option called AddQuery and one called DeleteQuery to handle what you're asking. At 10:42 PM 8/28/99 +0530, you wrote: Hi all i am using sql for maintaining session logs. How can I change the query that is executed for insert delete so that I can vary the parameters that can be inserted into the table Rajesh Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com. Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) feature request: allow include directive anywhere
I'm looking at the docs for 2.13 and 2.14.1 side by side and they don't look different -- 2.13 implies you can use the "include" directive anywhere, but you cannot use it inside of an AuthBy clause (I get an error -- keyword "include" not recognized or something like that). Has this behavior changed in 2.14.1 or am I doing something wrong in my config file? Sorry to ask all these goofy questions, but I just swung Radiator over as my primary RADIUS daemon (replacing Ascend's stock daemon) and all these things suddenly came up even though we tested this thing for about 3-4 months. John At 02:48 PM 8/27/99 +1000, you wrote: Hi John - On Fri, 27 Aug 1999, John Coy wrote: I'm currently using 2.13 and one feature I'd love to have is the use of the "include" directive anywhere within the configuration file (including inside an AuthBy clause). Have a look at Section 6.1 in the Radiator 2.14.1 reference manual: Each line in the configuration file can be one of: Comment line with a `# ' as the first character. Anything including and after the `# ' is ignored. Blank lines are also ignored. Example: # This is a comment An include directive. The word include followed by a filename. The named file will be opened and read to the end as a configuration file before processing of the current file continues. Special filename characters are permitted (see Section 6.2 ). Files can be recursively included to any depth. Example: include %D/clients.cfg Is this a feature in 2.14.1 (I looked at the docs but they look the same as the 2.13 docs with respect to this directive). Anyhow, just some food for thought. Is there an "official" place to post feature requests? The mailing list is the best place - we very often implement what people request - although we reserve the right to discussion. :-) And Mike always makes the final decision! 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) way to stop accounting packets from being proxied
I am using RADIATOR as a proxy radius server for my network. I've configured it to log all accounting packets to my SQL database. However, it is also forwarding the accounting packets on to the radius server for which it serves as a proxy. Is there a way to only log the accounting packets in SQL and then *not* proxy the accounting packets? Thank you in advance. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) messages in my logfile
I keep seeing this message repeatedly in my logfile: Thu Aug 26 20:47:33 1999: ERR: Attribute number 33 (vendor ) is not defined in y our dictionary What can I do to fix this problem? === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) feature request: allow include directive anywhere
I'm currently using 2.13 and one feature I'd love to have is the use of the "include" directive anywhere within the configuration file (including inside an AuthBy clause). This would allow me to maintain commonly used code in my config file and insert it anywhere. I have a particularly complex AuthBy SQL statement that's used in most of my realm definitions. It would be really nice to be able to do a "include %D/authbysql.cfg" inside my Realm definition (it would clean up the config significantly)! Is this a feature in 2.14.1 (I looked at the docs but they look the same as the 2.13 docs with respect to this directive). Anyhow, just some food for thought. Is there an "official" place to post feature requests? John === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radiator dumps core when using dbi:Oracle:remote_database
Port 1645
AcctPort 1646
/AuthBy
/Realm
-- end --
I thought it would also be helpful to include the test program
I wrote to test remote database connectivity:
#! /usr/bin/perl
#
use DBD::Oracle;
$ORACLE_DSN = "dbi:Oracle:";
$ORACLE_UNAME = "XXX";
$ORACLE_PWORD = "YYY";
$ORACLE_DB = "reliant_tcp_WG73";
$ORACLE_MAX_RETRIES = 10;
{
$dbh = DbLogin();
$query = qq{
SELECT * FROM radius WHERE username = 'jcoy'
ORDER BY login_time
};
$sth = $dbh-prepare($query);
$sth-execute;
while (@data = $sth-fetchrow_array) {
print join(" -- ", @data), "\n";
}
}
sub DbLogin {
my($dbname, $uname, $pword) = @_;
my($retries);
if ($dbname) {
$dbname = $ORACLE_DSN . $dbname;
}
else {
$dbname = $ORACLE_DSN . $ORACLE_DB;
}
$uname = $ORACLE_UNAME if (! $uname);
$pword = $ORACLE_PWORD if (! $pword);
while ((! $dbh) ($retries $ORACLE_MAX_RETRIES)) {
$dbh = DBI-connect($dbname, $uname, $pword, {PrintError=0} );
$retries++;
}
if (! $dbh) {
die($DBI::errstr);
}
else {
warn("Retries: $dbname $retries\n");
return $dbh;
}
}
-- original post and reply for reference --
Re: (RADIATOR) radiator dumps core when using dbi:Oracle:remote_database
Cheers.
On Jul 18, 11:30pm, John Coy wrote:
Subject: (RADIATOR) radiator dumps core when using dbi:Oracle:remote_datab
I'm running Radiator version 2.13.1 on a Sun Sparc Solaris
2.5.1 machine. I have an exact copy of Radiator running
on two machines, one of which has a local copy of Oracle running,
the other accesses the database server remotely using SQL*Net v2
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) WARNING: Bad authenticator errors
I'm receiving a steady stream of bad authenticator errors in my log file (at trace level 3). Mon Jul 19 12:42:40 1999: WARNING: Bad authenticator received in reply to ID 77 They're coming once a second or so. What does that error message mean? === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Tracking SPAMMERS
Radiator is nicely designed to accept RADIUS accounting packets and store them in an SQL database. The config is a little tricky, but generally speaking: -- skeleton config -- AuthByPolicy ContinueAlways AuthBy SQL # Disable authentication via SQL AuthSelect # [ follow instructions for AuthBy SQL for accounting ] /AuthBy AuthBy YOUR_PREFERRED_AUTHBY_METHOD # [ whatever you normally put here ] /AuthBy -- The trick is to use the AuthByPolicy ContinueAlways to let it cascade from the AuthBy SQL on to your preferred AuthBy method. I posted my configuration for Oracle accounting not too long ago. You can use it for hints. I think the best hint is in the online documentation at http://www.open.com.au/radiator/ref.html At 08:40 AM 7/19/99 -0400, Jamie Orzechowski wrote: I am having a problem with spammers and need a way to track them down. what I need is a config that will send the: date start time stop time username ip address callerID and store this into an SQL database (MS SQL 6.5) ... I will then be able to make querys and pull up the info I need ... any ideas how I create the database table and the config to send to info into the database ?? === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) radiator dumps core when using dbi:Oracle:remote_database
I'm running Radiator version 2.13.1 on a Sun Sparc Solaris 2.5.1 machine. I have an exact copy of Radiator running on two machines, one of which has a local copy of Oracle running, the other accesses the database server remotely using SQL*Net v2 On the radius server with the local database, everything works fine. I am able to log accounting packets without any problems. However, on the radius server with the remote database, it dumps core every time an accounting packet arrives. I can see it authenticate (when using Trace level 4) and then dumps core when the accounting packet arrives. I tested Perl's ability to connect to my remote database without any problem using a test perl program. It was able to reliably connect, login, and retrieve data. Is anyone else experiencing this (or a similar) problem? I know there is a lot more information required to help me troubleshoot the problem. I just wanted to get a feel for anyone else trying something similar. If this is a bug with the program, what is the procedure to get it resolved? === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Run perl code to generate more accounting fields
I typoed in this paragraph, it should have read: "I thought I read in the docs you can add arbitrary authentication replies to an auth record, but nothing that I read talked about the accounting record." ^^ Is there an easy way to have Radiator calculate the LOGIN_TIME field prior to insertion into the Radius database? If there was a way to add a fake accounting field by running arbitrary perl code, that would be helpful. I thought I read in the docs you can add arbitrary authentication replies to an auth record, but nothing that I read talked about the authentication record. Ideas would be appreciated. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Accounting to SQL w/out authenticating via SQL
Is there a way to configure Radiator to log accounting records to SQL without requiring authentication to occur via SQL? I have radiator configured for Proxy for several realms, but I'd like to capture the accounting records for those realms into an SQL (Oracle) database. The manual for AuthBy SQL is unclear if you can just use that for accounting. Thanks in advance. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Wierdness when setting up Radiator to Authenticate off Platypus Database
The errors aren't that strange -- you're inserting
rows with duplicate primary keys (or other constraints
which you've defined as unique). The constraint
is pk_Calls (primary key calls I'm guessing).
You should redefine your table's fields to not use
a primary key, select a different primary key that
is guaranteed to be unique, or use multiple
fields in your uniqueness constraint (ie: username,
framed address, timestamp).
At 02:02 PM 11/4/99 -0500, you wrote:
Im using the default emerald.cfg file and i changed the odbc connection to
point to the right thing.
when i run perl radpwtst -user scttest -password scttest i get rejected and
then ok and ok
That username and password is correct.. and in the radiusd window open i get
all kinds of strange odbc connection errors im guessing at leat thats what
they are!
CLIP---
(UserName, CallDate, AcctStatusType, AcctDelayTime,
AcctInputOct
ets, AcctOutputOctets, AcctSessionId, AcctSessionTime, NASIdentifier,
NASPort)
values
('SCTTEST', 'Nov 4, 1999 13:40', 2, 0, 2, 3,
'1234',
1000, '203.63.154.1', 1234)': [Microsoft][ODBC SQL Server Driver][SQL
Server]Vi
olation of PRIMARY KEY constraint 'pk_Calls'. Cannot insert duplicate key in
obj
ect 'Calls'. (SQL-23000)
[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been
terminated
. (SQL-01000)(DBD: st_execute/SQLExecute err=-1)
DBD::ODBC::db do failed: [Microsoft][ODBC SQL Server Driver][SQL
Server]Violatio
n of PRIMARY KEY constraint 'pk_Calls'. Cannot insert duplicate key in
object 'C
alls'. (SQL-23000)
[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been
terminated
. (SQL-01000)(DBD: st_execute/SQLExecute err=-1) at Radius/SqlDb.pm line
228.
Thu Nov 4 13:40:35 1999: ERR: do failed for 'insert into Calls
(UserName, CallDate, AcctStatusType, AcctDelayTime,
AcctInputOct
ets, AcctOutputOctets, AcctSessionId, AcctSessionTime, NASIdentifier,
NASPort)
values
('SCTTEST', 'Nov 4, 1999 13:40', 2, 0, 2, 3,
'1234',
1000, '203.63.154.1', 1234)': [Microsoft][ODBC SQL Server Driver][SQL
Server]Vi
olation of PRIMARY KEY constraint 'pk_Calls'. Cannot insert duplicate key in
obj
ect 'Calls'. (SQL-23000)
[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been
terminated
. (SQL-01000)(DBD: st_execute/SQLExecute err=-1)
-CLIP--
Kelly Hamlin
[EMAIL PROTECTED]
Network Administrator
(941) 332.4900
http://www.neosmart.com
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
