(RADIATOR) Ascend Session-Timeout includes PreSession time?
Hello, We have Ascend RASes and I was wondering if anyone with these devices can clarify something for me. If I send a Session-Timeout value in my access accept, does this value include the time it takes for the modem to train and the user to authenticate, or is the timer started after authentication is successful? Related to this, does the Acct-Session-Time in accounting include that pre-authentication time as well? Thanks, Viraj. === 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) Timestamp attribute
Hello,
>From what I can understand, the timestamp used in AuthSQL for accounting is
the Timestamp attribute that is created in the request packet by the current
time minus Acct-Delay-Time.
However, when I have one Radiator proxying to another, the 2nd Radiator ends
up with 2 Timestamp different attributes. It isn't clear to me which one will
be used by the 2nd Radiator. I see get_attr in the code being called for this
value but wouldn't this just return the first (incorrect) Timestamp value?
Would it be better for me to depend on a database function for the timestamp?
For example, with an insert statement similar to:
..., now() - 0%{Acct-Delay-Time}, ...
Viraj.
===
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) multiple DEFAULT behavior
Hello, If I have something like the following in a AuthBy FILE: DEFAULT Calling-Station-Id = 111, Auth-Type = A DEFAULT Calling-Station-Id = 111, Auth-Type = B This seems to do the same behavior as if A and B were in an AuthBy GROUP with a policy of ContinueUntilAccept. Is it safe to assume this? i.e. will Radiator continue processing these DEFAULT entries if a request came in with Calling-Station-Id = 111 but failed Auth-Type A? Viraj. === 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) passing information between Radiators and authby question
On Tue, Jun 04, 2002 at 06:47:25AM +1000, Hugh Irvine wrote:
>
> Hello Viraj -
>
> I think I would write a PreClientHook that would figure out what VISP a
> request was for and add a pseudo-attribute to the request indicating which
> one. Something like VISP-Identifier = x would do nicely. Then you can
> simply have one Handler for each VISP:
>
> # define Handlers
>
>
> .
>
>
>
> .
>
>
> .
>
> There are some example hooks in the file "goodies/hooks.txt".
Hm, yes this seems like a much better idea, thanks.
One question, if my PreClientHook can also figure out what AuthBy should be
used, is there a way I could pass this parameter to the Handlers?
For example, if I analyze a packet in PreClientHook and determine it should be
authenticated with the AuthBy XXX, if I were to place this information in the
packet, could I do something like the following:
AuthBy %{AuthBy-String}
i.e., get the AuthBy name from the packet?
Viraj.
> On Mon, 3 Jun 2002 23:08, Viraj Alankar wrote:
> > On Mon, Jun 03, 2002 at 05:32:20PM +1000, Hugh Irvine wrote:
> > > Hello Viraj -
> > >
> > > Could you please give me a bit more detail on your requirements?
> > >
> > > I am sure we can come up with a better solution than modifying code.
> >
> > Hugh,
> >
> > Basically what we are trying to do is handle many different VISPs. Using
> > the standard flat Handler configuration would require up to thousands of
> > Handlers for every possible authentication combination in our situation
> > (NAS IP, NAS IP+DNIS, regex NAS IP, realm, etc...). So the first thing I am
> > trying to do is move towards the below type of configuration so that the
> > number of handlers can be reduced. I want to first check for NAS IP, then
> > branch further down from there. I believe this will reduce processing quite
> > a bit.
> >
> > So normally we would have:
> >
> >
> > AuthBy Some_SQL
> > if Auth, Append a Class to tag this as a certain VISP for
> > accounting
> >
> > Where the above AuthBy gets accounting and auth. That is, our VISPs are
> > defined as some combination of NAS IP, DNIS, Realm, username prefix, or
> > some regex involving these.
> >
> > We make this instead:
> >
> >
> >
> > Filename nas-1.2.3.4
> >
> >
> >
> > And in nas-1.2.3.4 we would have:
> >
> > DEFAULT Calling-Station-Id = 111, Auth-Type = Some_SQL
> > Class = "visp_info"
> >
> > This config would seem to work for authentication, but for accounting I am
> > unsure. I think I just need to add 'AuthenticateAccounting' to the AuthBy
> > FILE.
> >
> > Viraj.
> >
> > > On Sun, 2 Jun 2002 10:31, Viraj Alankar wrote:
> > > > > > Another question I have is using Auth-By in a users file. For
> > > > > > example:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Filename nas-1.2.3.4
> > > > > > > > > > >
> > > > > >
> > > > > > nas-1.2.3.4:
> > > > > >
> > > > > > DEFAULT Calling-Station-Id = 111, Auth-Type = DoA
> > > > > >
> > > > > > DEFAULT Calling-Station-Id = 222, Auth-Type = DoB
> > > >
> > > > Hello Hugh,
> > > >
> > > > I just realized something about my proposed config above, in that DoA
> > > > and DoB will not get accounting. Basically 'DoA' and 'DoB' correspond
> > > > to 2 different virtual ISPs and I need the accounting handled for each
> > > > one differently, but in other words they need to GET the accounting.
> > > >
> > > > My guess is I need to write a new auth module that inherits AuthFILE.
> > > > Looking at this I think I just need to add some code to call
> > > > AuthGeneric::checkAttributes on an accounting request instead of just
> > > > accepting it. Do you think that modification will work ok?
> > > >
> > > > Just FYI, the reason I am looking at the above type of configuration is
> > > > I would like to reduce the number of handlers. We simply would have too
> > > > many if we did this with all Handlers. The goal with the above config
> > > > is to emulate a 'sub-handler' or cascading setup, where first the NAS
> > > > IP is matc
(RADIATOR) AcctColumnDef for MySQL datetime type
Hello, What would be the proper way to insert the Timestamp from accounting into a MySQL datetime field? Basically it requires format of '-00-00 00:00:00' but I cannot seem to figure out how to do this with the date formatting. There is no format specifier for month with preceeding 0. Viraj. === 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) passing information between Radiators and authby question
On Mon, Jun 03, 2002 at 05:32:20PM +1000, Hugh Irvine wrote: > > Hello Viraj - > > Could you please give me a bit more detail on your requirements? > > I am sure we can come up with a better solution than modifying code. > Hugh, Basically what we are trying to do is handle many different VISPs. Using the standard flat Handler configuration would require up to thousands of Handlers for every possible authentication combination in our situation (NAS IP, NAS IP+DNIS, regex NAS IP, realm, etc...). So the first thing I am trying to do is move towards the below type of configuration so that the number of handlers can be reduced. I want to first check for NAS IP, then branch further down from there. I believe this will reduce processing quite a bit. So normally we would have: AuthBy Some_SQL if Auth, Append a Class to tag this as a certain VISP for accounting Where the above AuthBy gets accounting and auth. That is, our VISPs are defined as some combination of NAS IP, DNIS, Realm, username prefix, or some regex involving these. We make this instead: Filename nas-1.2.3.4 And in nas-1.2.3.4 we would have: DEFAULT Calling-Station-Id = 111, Auth-Type = Some_SQL Class = "visp_info" This config would seem to work for authentication, but for accounting I am unsure. I think I just need to add 'AuthenticateAccounting' to the AuthBy FILE. Viraj. > On Sun, 2 Jun 2002 10:31, Viraj Alankar wrote: > > > > Another question I have is using Auth-By in a users file. For example: > > > > > > > > > > > > > > > > Filename nas-1.2.3.4 > > > > > > > > > > > > > > > nas-1.2.3.4: > > > > > > > > DEFAULT Calling-Station-Id = 111, Auth-Type = DoA > > > > > > > > DEFAULT Calling-Station-Id = 222, Auth-Type = DoB > > > > Hello Hugh, > > > > I just realized something about my proposed config above, in that DoA and > > DoB will not get accounting. Basically 'DoA' and 'DoB' correspond to 2 > > different virtual ISPs and I need the accounting handled for each one > > differently, but in other words they need to GET the accounting. > > > > My guess is I need to write a new auth module that inherits AuthFILE. > > Looking at this I think I just need to add some code to call > > AuthGeneric::checkAttributes on an accounting request instead of just > > accepting it. Do you think that modification will work ok? > > > > Just FYI, the reason I am looking at the above type of configuration is I > > would like to reduce the number of handlers. We simply would have too many > > if we did this with all Handlers. The goal with the above config is to > > emulate a 'sub-handler' or cascading setup, where first the NAS IP is > > matched, then Calling-Station-Id only if NAS IP had matched. This will > > reduce the amount of processing for each packet. If you think there is some > > better way please let me know. > > > > Thanks, > > > > Viraj. > > -- > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. > - > Nets: internetwork inventory and management - graphical, extensible, > flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) passing information between Radiators and authby question
On Sat, Jun 01, 2002 at 08:31:07PM -0400, Viraj Alankar wrote: > I just realized something about my proposed config above, in that DoA and DoB > will not get accounting. Basically 'DoA' and 'DoB' correspond to 2 different > virtual ISPs and I need the accounting handled for each one differently, but > in other words they need to GET the accounting. > > My guess is I need to write a new auth module that inherits AuthFILE. Looking > at this I think I just need to add some code to call > AuthGeneric::checkAttributes on an accounting request instead of just > accepting it. Do you think that modification will work ok? I think I just answered my own question. I just saw the AuthenticateAccounting setting. It seems I just need to set this. and I should be ok right? Viraj. === 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) passing information between Radiators and authby question
> > Another question I have is using Auth-By in a users file. For example: > > > > > > > > Filename nas-1.2.3.4 > > > > > > > nas-1.2.3.4: > > > > DEFAULT Calling-Station-Id = 111, Auth-Type = DoA > > > > DEFAULT Calling-Station-Id = 222, Auth-Type = DoB Hello Hugh, I just realized something about my proposed config above, in that DoA and DoB will not get accounting. Basically 'DoA' and 'DoB' correspond to 2 different virtual ISPs and I need the accounting handled for each one differently, but in other words they need to GET the accounting. My guess is I need to write a new auth module that inherits AuthFILE. Looking at this I think I just need to add some code to call AuthGeneric::checkAttributes on an accounting request instead of just accepting it. Do you think that modification will work ok? Just FYI, the reason I am looking at the above type of configuration is I would like to reduce the number of handlers. We simply would have too many if we did this with all Handlers. The goal with the above config is to emulate a 'sub-handler' or cascading setup, where first the NAS IP is matched, then Calling-Station-Id only if NAS IP had matched. This will reduce the amount of processing for each packet. If you think there is some better way please let me know. Thanks, Viraj. === 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) passing information between Radiators and authby question
Hello, I am trying to determine what's the best way to pass information between 2 Radiator's, one proxying requests to the other. For example, say I have Radiator A proxying requests to Radiator B. I would like to pass some request specific information from A to B, such as a VISP ID. I thought of using Class, but there could be requests coming to A that are already using Class, so there may be some conflict. So I'm wondering what's the best way to deal with this. Create a new attribute in each dictionary and use that? If so, how can I use something that I'm sure will not conflict with other vendors? Also, I need the attribute to come in accounting packets as well. I only know of Class that is honored by RASes as being returned in accounting. Another question I have is using Auth-By in a users file. For example: Filename nas-1.2.3.4 nas-1.2.3.4: DEFAULT Calling-Station-Id = 111, Auth-Type = DoA DEFAULT Calling-Station-Id = 222, Auth-Type = DoB First, is this method efficient if we have up to 500 RASes? Suppose I want to do a RewriteUsername to ALL the authbys (DoA and DoB), is there a way I can do something like: DEFAULT Auth-Type = DoRewrites DEFAULT Calling-Station-Id = 111, Auth-Type = DoA DEFAULT Calling-Station-Id = 222, Auth-Type = DoB where it will fall through after the first one? I was thinking of making an AuthBy DoRewrites that returns IGNORE. In that case it should fall through correct? Basically I would like to do the rewrites in the users file level and not in the Handler level. Thanks, Viraj. === 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) Suggestions for high volume system
Hello, I am wondering what's the best design for a high volume radius system. We are looking at on the order of 100-150 requests/second (auth+acct) on average. Does anyone here have a load balancing system setup? If so, I'd appreciate any tips on how you set this up. After using Radiator for quite awhile, I've found that the main things that cause slowdowns is database queries or network outages. I've noticed during network outages, some RASes (we have mostly Ascend) and proxy servers start flooding the server once the connectivity comes back. These appear to be queued requests (mostly accounting) on the systems. In this situation it pretty much kills our radius server (CPU -> 99%) and many times we have to run Radiator in a very basic configuration (no database, no authentication) for some time to cool things down. Many times I've even had to go to our firewall and block some RAS traffic. So I am just looking for some tips on how to setup a scalable system. We have a test system setup with a Foundry switch load balancing to 2 Radiator servers via roundrobin. However, in our tests we are noticing that the load balancing is not even when the source UDP port stays constant, which is for example when another Radiator is forwarding requests to it. It only seems to load balance properly when the source ports change. Anyone have any ideas what could be wrong here? What I was thinking was to instead setup one Radiator system that uses the AuthBy loadbalance clause instead of the Foundry switch. Any thoughts on this instead of hardware load balancing? The next issue is database slowdowns. I am thinking that the best setup would be for the RASes to go directly to Radiators that do not have any sort of DB dependency, and instead they proxy to respective servers that do have DB dependencies. For example: A / \ / \ B C / \ / \ D E F G A = Radiator doing AuthBy loadbalance to B and C (or hardware switch) B/C = Radiator with only AuthBy RADIUS clauses D/E/F/G = Radiator with DB access The B and C trees would be identical. Does this sound like a proper setup? As far as the type of database access, we've mostly seen that accounting is what causes problems. I believe this is due to our table designs. For example, we have unique indexes to drop duplicate accounting, indexed on many fields. At some point when there is alot of data inserts become slow. I was thinking that Radiator's access to the DB should be made as fast as possible, and that Radiator should instead use the DB as sort of a log table for accounting (with no indexes at all), similar to writing to raw files. Then, periodically, an external process would process this data and move to the real accounting tables (with indexes, etc). This way, DB query time is kept to a minimal for accounting. Another problem we have is the number of Handlers. We handle requests depending on the following: RAS IP RAS IP+DNIS RAS IP+DNIS+Realm With all of our devices, the number of handlers is getting quite large. I'm wondering what would be an upper bound on this and if there is a better way to handle this. We have almost 500 handlers at this point. Anyhow, I'd appreciate any info or tips anyone has on a large setup like this. Thanks, Viraj. === 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) unix, LDAP, and Active Directory
Hello, I'm sort of confused whether this is possible or not: Can I authenticate from a Linux Radiator to a Windows 2000 Active Directory server? I'm wondering if anyone has this working on unix and could give me an example. Or do I need to run Radiator on a Windows 2000 and use the ADSI module? Viraj. === 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) Rejecting Caller-ID from SQL without auth from SQL
On Fri, Feb 15, 2002 at 09:38:37AM -0500, Viraj Alankar wrote:
> Now I was able to get it working with the following config. However, it
> appears the select query is still called twice when the callerid doesn't exist
> in the table. Basically in this config I took out the options in
> VE_Check_CallerID.
Just wanted to let you know I was able to get it working without any problems
now. Adding the 'NoDefault' to the SQL authby stopped it from executing the
query twice. Here is what I did:
Identifier VE_CallerID
...
AuthSelect select "Reject" from ve where callerid = '%{Calling-Station-Id}'
AuthColumnDef 0, Auth-Type, check
AccountingTable
NoDefault
Identifier VE_Check_CallerID
Filename%D/VE_Check_CallerID.users
Identifier My_Users_File
Filename...
AuthBy VE_Check_CallerID
And VE_Check_CallerID.users has:
DEFAULT Auth-Type = VE_CallerID
DEFAULT Auth-Type = My_Users_File
Thanks for the help.
Viraj.
===
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) Rejecting Caller-ID from SQL without auth from SQL
Radius::AuthFILE: VE_Check_CallerID
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthFILE looks for match with [EMAIL PROTECTED]
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthFILE looks for match with DEFAULT
Fri Feb 15 09:33:47 2002: ERR: Attribute number 79 is not defined in your dictionary
Fri Feb 15 09:33:47 2002: DEBUG: Handling with Radius::AuthSQL
Fri Feb 15 09:33:47 2002: DEBUG: Handling with Radius::AuthSQL: VE_CallerID
Fri Feb 15 09:33:47 2002: DEBUG: Query is: select "Reject" from ve where callerid =
'0212212232'
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthSQL looks for match with [EMAIL PROTECTED]
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthSQL REJECT_IMMEDIATE: Rejected explicitly
by Auth-Type=Reject
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthFILE REJECT_IMMEDIATE: Rejected
explicitly by Auth-Type=Reject
Fri Feb 15 09:33:47 2002: INFO: Access rejected for [EMAIL PROTECTED]: Rejected explicitly
by Auth-Type=Reject
Fri Feb 15 09:33:47 2002: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 32782
Code: Access-Reject
Identifier: 17
Authentic: 1234567890123456
Attributes:
Reply-Message = "Request Denied"
But in a test where the callerid does NOT exist in the table, it still works
properly but the query appears to be executed twice:
Fri Feb 15 09:36:48 2002: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 32782
Code: Access-Request
Identifier: 198
Authentic: 1234567890123456
Attributes:
User-Name = "[EMAIL PROTECTED]"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = "123456789"
Calling-Station-Id = "987654321"
NAS-Port-Type = Async
User-Password = "<215>f<171><11><174><150><128>>x<243>f<245>>I$<157>"
Fri Feb 15 09:36:48 2002: DEBUG: Check if Handler should be used to handle this
request
Fri Feb 15 09:36:48 2002: DEBUG: Handling request with Handler ''
Fri Feb 15 09:36:48 2002: DEBUG: Deleting session for [EMAIL PROTECTED], 203.63.154.1,
1234
Fri Feb 15 09:36:48 2002: DEBUG: Handling with Radius::AuthFILE: VE_Check_CallerID
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE looks for match with [EMAIL PROTECTED]
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE looks for match with DEFAULT
Fri Feb 15 09:36:48 2002: ERR: Attribute number 79 is not defined in your dictionary
Fri Feb 15 09:36:48 2002: DEBUG: Handling with Radius::AuthSQL
Fri Feb 15 09:36:48 2002: DEBUG: Handling with Radius::AuthSQL: VE_CallerID
Fri Feb 15 09:36:48 2002: DEBUG: Query is: select "Reject" from ve where callerid =
'987654321'
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthSQL looks for match with [EMAIL PROTECTED]
Fri Feb 15 09:36:48 2002: DEBUG: Query is: select "Reject" from ve where callerid =
'987654321'
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE REJECT: No such user
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE looks for match with DEFAULT1
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE ACCEPT: Accept explicitly by
Auth-Type=Accept
Fri Feb 15 09:36:48 2002: DEBUG: Handling with Radius::AuthFILE: Users_File
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE looks for match with [EMAIL PROTECTED]
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE ACCEPT:
Fri Feb 15 09:36:48 2002: DEBUG: Access accepted for [EMAIL PROTECTED]
Fri Feb 15 09:36:48 2002: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 32782
Code: Access-Accept
Identifier: 198
Authentic: 1234567890123456
Attributes:
Any ideas?
Viraj.
> On Fri, 15 Feb 2002 02:52, Viraj Alankar wrote:
> > On Thu, Feb 14, 2002 at 11:01:08AM +1100, Hugh Irvine wrote:
> > > Hello Viraj -
> > >
> > > You have to do this with different AuthBy clauses, something like this:
> > >
> > > # define AuthBy clauses
> > >
> > >
> > > Identifier CheckNumber
> > > .
> > > AuthSelect select ACTION from BLACKLIST \
> > > where NUMBER = %{Calling-Station-Id}
> > > AccountingTable
> > >
> > >
> > >
> > > Identifier CheckBlacklist
> > > Filename %D/blacklist
> > > NoDefaultIfFound
> > >
> > >
> > >
> > > Identifier YourNormalAuthBy
> > > Filename %D/users
> > > .
> > >
> > >
> > > # define Realms or Handlers
> > >
> > >
> > > AuthByPolicy ContinueWhileAccept
> > > AuthBy CheckBlacklist
> > > AuthBy YourNormalAuthBy
> > > .
> > >
> > >
> > >
> > > The BLACKLIST table in the database would have the list of numbers in the
> > > NUM
Re: (RADIATOR) Rejecting Caller-ID from SQL without auth from SQL
On Thu, Feb 14, 2002 at 11:01:08AM +1100, Hugh Irvine wrote:
>
> Hello Viraj -
>
> You have to do this with different AuthBy clauses, something like this:
>
> # define AuthBy clauses
>
>
> Identifier CheckNumber
> .
> AuthSelect select ACTION from BLACKLIST \
> where NUMBER = %{Calling-Station-Id}
> AccountingTable
>
>
>
> Identifier CheckBlacklist
> Filename %D/blacklist
> NoDefaultIfFound
>
>
>
> Identifier YourNormalAuthBy
> Filename %D/users
> .
>
>
> # define Realms or Handlers
>
>
> AuthByPolicy ContinueWhileAccept
> AuthBy CheckBlacklist
> AuthBy YourNormalAuthBy
> .
>
>
>
> The BLACKLIST table in the database would have the list of numbers in the
> NUMBER column and "Auth-Type = Reject" in the ACTION column.
>
>
> The file %D/blacklist would contain this:
>
> # DEFAULT entries to check blacklist
>
> DEFAULT Auth-Type = CheckNumber
>
> DEFAULT Auth-Type = Accept
>
>
Hello Hugh,
This makes sense, however I seem to have some trouble setting this up. First
of all I cannot change the blacklist table in my case, but I think it can be
worked around. Here is what I have:
In MySQL, we have a table 've' that looks like this:
mysql> desc ve;
+---+---+--+-+-+---+
| Field | Type | Null | Key | Default | Extra |
+---+---+--+-+-+---+
| callerid | varchar(80) | | PRI | | |
| comment | varchar(80) | YES | | NULL| |
| timestamp | timestamp(14) | YES | | NULL| |
+---+---+--+-+-+---+
Which is basically the blacklist table. For radiator I did:
Identifier VE_CallerID
DBSource ...
AuthSelect select "Reject" from ve where callerid = %{Calling-Station-Id}
AuthColumnDef 0, Auth-Type, check
AccountingTable
Identifier VE_Check_CallerID
Filename%D/VE_Check_CallerID.users
NoDefaultIfFound
Identifier Users_File
Filename%D/users
AuthByPolicy ContinueWhileAccept
AuthBy VE_Check_CallerID
AuthBy Users_File
VE_Check_CallerID.users file looks like:
# DEFAULT entries to check blacklist
DEFAULT Auth-Type = VE_CallerID
DEFAULT Auth-Type = Accept
users file looks like:
[EMAIL PROTECTED]
Now I did a radpwtst with a calling-station-id that did not exist in the table:
radpwtst ... -noacct -user [EMAIL PROTECTED] -password test
But it is rejected for some reason. The logfile looks like this:
Thu Feb 14 10:46:27 2002: INFO: Server started: Radiator 2.19 on tutraddev.ifxcorp.com
Thu Feb 14 10:46:40 2002: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 32782
Code: Access-Request
Identifier: 100
Authentic: 1234567890123456
Attributes:
User-Name = "[EMAIL PROTECTED]"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = "123456789"
Calling-Station-Id = "987654321"
NAS-Port-Type = Async
User-Password = "<215>f<171><11><174><150><128>>x<243>f<245>>I$<157>"
Thu Feb 14 10:46:40 2002: DEBUG: Check if Handler should be used to handle this
request
Thu Feb 14 10:46:40 2002: DEBUG: Handling request with Handler ''
Thu Feb 14 10:46:40 2002: DEBUG: Deleting session for [EMAIL PROTECTED], 203.63.154.1,
1234
Thu Feb 14 10:46:40 2002: DEBUG: Handling with Radius::AuthFILE: VE_Check_CallerID
Thu Feb 14 10:46:40 2002: DEBUG: Radius::AuthFILE looks for match with [EMAIL PROTECTED]
Thu Feb 14 10:46:40 2002: DEBUG: Radius::AuthFILE looks for match with DEFAULT
Thu Feb 14 10:46:40 2002: ERR: Attribute number 79 is not defined in your dictionary
Thu Feb 14 10:46:40 2002: DEBUG: Handling with Radius::AuthSQL
Thu Feb 14 10:46:40 2002: DEBUG: Handling with Radius::AuthSQL: VE_CallerID
Thu Feb 14 10:46:40 2002: DEBUG: Query is: select "Reject" from ve where callerid =
987654321
Thu Feb 14 10:46:40 2002: DEBUG: Radius::AuthSQL looks for match with [EMAIL PROTECTED]
Thu Feb 14 10:46:40 2002: DEBUG: Query is: select "Reject" from ve where callerid =
987654321
Thu Feb 14 10:46:40 2002: DEBUG: Radius::AuthFILE REJECT: No such user
Thu Feb 14 10:46:40 2002: INFO: Access rejected for [EMAIL PROTECTED]: No such user
Thu Feb 14 10:46:40 2002: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 32782
Code: Access-Reject
Identifier: 100
Authentic: 1234567890123456
Attributes:
Reply-Message = "Request Denied"
I'm not sure what I'm doing wrong here. First it appears the select query is
called twice. Also the 'users' file is never checked. Any ideas?
Thanks,
Viraj.
===
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) Rejecting Caller-ID from SQL without auth from SQL
Hello, I'm trying to setup Radiator to do the following: if access request's Calling-Station-Id exists in a callerid SQL table reject the request else authenticate with a FILE What would be the simplest way to do this? Note I am not authenticating via SQL, but only checking a callerid table for existence of a number. Thanks, Viraj. === 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) Question on Encrypted-Password/User-Password
Hello,
Is there a functional difference between the following:
...
AuthSelect select PASSWORD from SUBSCRIBERS where USERNAME='%n'
AuthColumnDef 0, User-Password, check
and this:
...
AuthSelect select PASSWORD from SUBSCRIBERS where USERNAME='%n'
AuthColumnDef 0, Encrypted-Password, check
when the result of the select returns '{crypt}crypted_password' ? In other
workds, I can use either AuthBy and it should work right?
Thanks,
Viraj.
PGP signature
Re: (RADIATOR) Forced URL
- Forwarded message from Viraj Alankar <[EMAIL PROTECTED]> -
Date: Thu, 6 Sep 2001 12:36:55 -0400
From: Viraj Alankar <[EMAIL PROTECTED]>
To: Amit Anand <[EMAIL PROTECTED]>
Subject: Re: (RADIATOR) Forced URL
On Thu, Sep 06, 2001 at 11:15:08AM -0400, Amit Anand wrote:
> Hello all:
>
> I was wondering if there is a way within Radius to make users goto a
> particular URL after they have been authenticated. Sort of like a filter
> designed to make people visit a certain website first, and then after they
> can go out into the world. I would really appreciate any input any of you
> all could give me if you have done this or know how to do it. Thanks alot!!
Hello Amit,
Depending on your RAS, you may be able to redirect users ALWAYS to a web page,
but as far as just doing that initially, and then letting them browse
elsewhere, I don't think it's possible.
We have implemented simple redirects for Ascend/Lucent devices. Our solution
involves sending DNS attributes in the radius response, and running a bogus
DNS server that always returns one IP.
For example, say I have a bogus DNS setup as 1.2.3.4, that always returns the
IP 5.6.7.8. This means any user using this DNS will get redirected to 5.6.7.8
no matter where they browse.
I send back in the radius reply the following to enforce this DNS restriction
as well as IP filters to block them from using another DNS or going to other
hosts:
Ascend-Client-Primary-DNS = 1.2.3.4,
Ascend-Client-Secondary-DNS = 1.2.3.4,
Ascend-Client-Assign-DNS = DNS-Assign-Yes,
Ascend-Data-Filter = "ip in forward dstip 1.2.3.4/32 udp dstport = 53",
Ascend-Data-Filter = "ip in forward dstip 5.6.7.8/32 tcp dstport = 80",
Ascend-Data-Filter = "ip in drop",
Ascend-Data-Filter = "ip out forward"
We then use BIND 8 and a config similar to:
zone "." {
type master;
file "named.redirect.hosts";
};
and named.redirect.hosts containing something like:
$TTL 1D
@ IN SOA . hostmaster.mydomain.com. (
5
8H
2H
1W
1D )
IN NS 1.2.3.4
*. IN A 5.6.7.8
4.3.2.1.in-addr.arpa. IN PTR mydns.mydomain.com.
Hope that helps.
Viraj.
- End forwarded message -
PGP signature
Re: (RADIATOR) Forced URL
On Thu, Sep 06, 2001 at 11:15:08AM -0400, Amit Anand wrote:
> Hello all:
>
> I was wondering if there is a way within Radius to make users goto a
> particular URL after they have been authenticated. Sort of like a filter
> designed to make people visit a certain website first, and then after they
> can go out into the world. I would really appreciate any input any of you
> all could give me if you have done this or know how to do it. Thanks alot!!
Hello Amit,
Depending on your RAS, you may be able to redirect users ALWAYS to a web page,
but as far as just doing that initially, and then letting them browse
elsewhere, I don't think it's possible.
We have implemented simple redirects for Ascend/Lucent devices. Our solution
involves sending DNS attributes in the radius response, and running a bogus
DNS server that always returns one IP.
For example, say I have a bogus DNS setup as 1.2.3.4, that always returns the
IP 5.6.7.8. This means any user using this DNS will get redirected to 5.6.7.8
no matter where they browse.
I send back in the radius reply the following to enforce this DNS restriction
as well as IP filters to block them from using another DNS or going to other
hosts:
Ascend-Client-Primary-DNS = 1.2.3.4,
Ascend-Client-Secondary-DNS = 1.2.3.4,
Ascend-Client-Assign-DNS = DNS-Assign-Yes,
Ascend-Data-Filter = "ip in forward dstip 1.2.3.4/32 udp dstport = 53",
Ascend-Data-Filter = "ip in forward dstip 5.6.7.8/32 tcp dstport = 80",
Ascend-Data-Filter = "ip in drop",
Ascend-Data-Filter = "ip out forward"
We then use BIND 8 and a config similar to:
zone "." {
type master;
file "named.redirect.hosts";
};
and named.redirect.hosts containing something like:
$TTL 1D
@ IN SOA . hostmaster.mydomain.com. (
5
8H
2H
1W
1D )
IN NS 1.2.3.4
*. IN A 5.6.7.8
4.3.2.1.in-addr.arpa. IN PTR mydns.mydomain.com.
Hope that helps.
Viraj.
PGP signature
(RADIATOR) Lucent APX and auth-config requests
Hello, I recently lost some sleep over a problem with a Ascend/Lucent APX. Maybe someone else here can advise (or take heed). One night the APX suddenly started sending authentication requests for frdlink-*, ipxroute-*, appleroute, and other nonsense. Well in our case authentication for this RAS just happened to be promiscuous (that is, free authentication). This seemed to cause some sort of problem for the RAS, because it kept sending these requests over and over at about 40 auth packets/second with these bogus requests. Now I assumed that the following setting would fix this: http://www.open.com.au/radiator/faq.html#71 But it didn't. The requests kept coming even after a RAS reboot. What I then did was deny these bogus requests: which stopped them altogether. Then everything was back to normal. Just wondering if anyone else has come across this problem of the RAS ignoring the auth-config setting. We are running TAOS 9.0.1 on the RAS. Thanks, Viraj. PGP signature
Re: (RADIATOR) Oracle SQL timeout causing crash
Hello, Awhile ago I posted the message below regarding Radiator dying on a SQL timeout. I received some suggestions to update the DBI/DBD modules, which I did and am also running v2.18.2 of Radiator. I see the same thing in the log, and restart_wrapper reports: Your program /usr/bin/radiusd -config /disk/store0/radius/raddb/radiusd.cfg exited unexpectedly with exit status 0, signal number 0 and dump indication 0. The STDERR output was . The program will be restarted again by /disk/store0/radius/bin/restartWrapper in 10 seconds. My current versions: DBI v1.19 DBD::Oracle v1.08 Oracle v8.0.5 x86 client libraries The Oracle server being queried is v8.1.7 on Sun PERL v5.005_03 (came with Redhat 6.2) It is strange because sometimes, Radiator processes the error normally and backs off from querying the database. However at other times it just dies as above. I'm using 'Timeout 10' for these SQL AuthBy's. The reason for the SQL timeout is that the database is overloaded during these times. Any help appreciated. Viraj. On Thu, Jun 28, 2001 at 09:46:53AM -0400, Viraj Alankar wrote: > > Hello, > > We are using v2.18.1 on Linux x86. Whenever there is a SQL > timeout, the Radiator process just exits. > > Thu Jun 28 08:57:40 2001: ERR: Execute failed for 'select ...': SQL Timeout > > It then exits with error code 0. We have the restart_wrapper in place > which restarts it, but is there a reason why it would die? I have not > placed it in a higher trace level yet because it is in production, getting > a large # of requests (about 20-40/sec), and this happens rarely. Though > if needed I can do this. Thanks for any help. > > Viraj. === 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) Duplicate users in users file
Hello, I'm trying to setup different replies based on different check items in a users file: joe Password = "test", Client-Identifier = "ROUTER1" Service-Type = "Administrative-User", joe Password = "test", Client-Identifier = "ROUTER2" Service-Type = "Login-User" In my client clauses I am setting Identifiers accordingly. Now when joe logs into ROUTER1, he gets rejected: Tue Aug 21 17:06:44 2001: DEBUG: Radius::AuthFILE REJECT: Client-Identifier does not match So it appears it is just falling through to the last entry in the users file. Is there any way to stop this or do the equivalent of what I am trying to do? Thanks, Viraj. === 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) AcctLogFilename in AuthBy's
Hello, We are implementing many AuthBy's in Handlers. Currently, I believe AcctLogFilename can only be specified at the Handler level. However, what we are trying to do is have different AuthBy's have different AcctLogFilename's. Is this possible? It seems so when using SQL accounting, since the accounting is part of the AuthBy, but not when doing raw file accounting. Thanks for any help. Viraj. === 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) Designing for security
On Sun, Jul 08, 2001 at 02:31:15AM +0800, Miguel A.L. Paraz wrote: > On Sun, Jul 08, 2001 at 03:17:38AM +1000, Hugh Irvine wrote: > > You should always have your main Radiator hosts behind a firewall of > > some sort, and you should also use packet filters to limit which > > hosts and/or NAS's are allowed to contact these internal hosts. > > does anyone have experience with Radiator or other RADIUS daemons > being hit by DoS attacks? Even if you filter out your Radiator host, > someone can spoof requests pretending to be from your NAS's. We had something very similar happen to us. We are still looking into the problem but basically it appears to be a misconfigured proxy radius server sending us a ridiculous amount of access and accounting requests. On average we see about 10 requests (account + auth) from this proxy server. At various times during the day, we would see spurts of up to 170 requests per second, all pretty much duplicates. During these times it would kill our server and we started timing out to any requests, effectively causing a DoS. When we removed IP from our clients file our server load would still be quite high and create very large logs of 'unknown client' requests, but it was not really DoS'ed. We ended up blocking the IP at the firewall. Unfortunately this is actually a client of ours sending the requests, who has no idea why their server would flood requests to us. We are still trying to analyze the problem. So it was not malicious, or at least we don't think so :). I would think that if there was a distributed DoS, you could probably kill any radius server, be it Radiator or not. I don't think it's practical to block these on the network level because like you said UDP packets can be spoofed. Viraj. === 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) Oracle SQL timeout causing crash
Hello Hugh, On Fri, 29 Jun 2001, Hugh Irvine wrote: > > Hello Viraj - > > What database and what versions of DBI/DBD are you using? We are using DBI 1.15, and DBD::Oracle 1.06 built with Oracle 8.0.5 libraries. > Can you also send me a copy of the Perl output that is captured by > restartWrapper? I do not have a copy at hand, but basically there was no output and it was and error return code of 0. I will send an exact copy once it happens again. Thanks, Viraj. > At 9:46 AM -0400 6/28/01, Viraj Alankar wrote: > >Hello, > > > > We are using v2.18.1 on Linux x86. Whenever there is a SQL > >timeout, the Radiator process just exits. > > > >Thu Jun 28 08:57:40 2001: ERR: Execute failed for 'select ...': SQL Timeout > > > >It then exits with error code 0. We have the restart_wrapper in place > >which restarts it, but is there a reason why it would die? I have not > >placed it in a higher trace level yet because it is in production, getting > >a large # of requests (about 20-40/sec), and this happens rarely. Though > >if needed I can do this. Thanks for any help. > > > >Viraj. > > > > > >=== > >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.
(RADIATOR) Oracle SQL timeout causing crash
Hello, We are using v2.18.1 on Linux x86. Whenever there is a SQL timeout, the Radiator process just exits. Thu Jun 28 08:57:40 2001: ERR: Execute failed for 'select ...': SQL Timeout It then exits with error code 0. We have the restart_wrapper in place which restarts it, but is there a reason why it would die? I have not placed it in a higher trace level yet because it is in production, getting a large # of requests (about 20-40/sec), and this happens rarely. Though if needed I can do this. Thanks for any help. Viraj. === 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) question on Auth-Requests
Hello, Watching authentication requests from our Ascend RASes show that the Acct-Session-Id is in the auth request packet, as well as the accounting start and stop. I noticed that radpwtst does not send Acct-Session-Id in the auth request. I would like if all RASes send the Acct-Session-Id in the auth request packet, or is this an Ascend specific thing? We are making use of this attribute in an AuthLog, but now I'm wondering if it's correct to do make the assumption it will always be there. Thanks for any help. Viraj. === 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) Debugging with Identifiers feature request
Hello, I don't think this is currently available in Radiator, but it would be very useful to have a Trace 4 show Identifier strings in the logfile when entering different AuthBy's. Sometimes it is hard to tell which AuthBy is being executed when there are many of them being done in a sequence. If there is some way to do this currently, please let me know. Thanks, Viraj. === 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) Oracle stored procedures
Hello,
We were having some difficulty using Oracle stored procedures with
Radiator (and DBI in general). Maybe some of this is helpful to others,
but we found that we couldn't use 'exec' in the DBI query. It seems 'exec'
may be something specific to Sqlplus, but I'm not sure. Anyhow, we wanted
our AddQuery for SessionDatabase SQL to call a stored procedure. The only
thing that worked was similar to the following:
AddQuery BEGIN my_procedure('%n', ...); END;
We had also used a stored procedure in an AuthBy SQL that took the
username as argument and returned the password:
AuthSelect select validate_password(%0) from dual
AuthColumnDef 0, User-Password, check
dual is an Oracle builtin junk table that always returns the row you
selected for.
Hope this helps, and if anyone has some other suggestions I'd be
interested.
Viraj.
===
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) AuthLog SQL and v2.18.1
Hello, We are using v2.18.1 on Linux. We have some problems using %u/%n in the AuthLog SQL statements, where if '@' exists in the username the query is blank. I noticed some discussion about this problem in v2.17.1, as well as a patch for it, but is it fixed in 2.18.1? Also, is there a %0 from AuthBy SQL context equivalant in AuthLog SQL? %0 takes on different meaning in AuthLog, and we are doing inserts based on username which we want to make sure have all of the bad characters escaped. Thanks for any help, Viraj. === 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) radstock password patch
Hello, I've written a patch for radstock (the very useful radius packet analyzer) to show user's passwords (Attribute #2) and/or filter based on this. It is available here in case anyone is interested: http://www.bigfoot.com/~valankar/ Viraj. === 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) subhandlers?
Hello, I was wondering if it is possible to do something like the following in any way: ... ... That is, to provide a drill-down like configuration. Thanks, Viraj. === 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.
No Subject
Hello, I have a quick question on the regular expression parsing in radiator. Say I have something like this: Is it correct that the . needs to be escaped (\.) to correctly match the IP? Viraj. === 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) 99% CPU usage on Linux
Hello, We recently switched from Solaris to Linux running Radiator. At some point, the radiusd process on the Linux box goes to 99% CPU usage and becomes sluggish when responding to auth/acct. It does respond, but definitely alot slower than it should. 'top' shows me: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 1832 admin 20 0 16052 15M 1228 R 0 98.6 3.1 405:23 radiusd load avg is always 1 understandably: 1:45pm up 1 day, 4:17, 1 user, load average: 1.00, 1.00, 1.00 I'm wondering what's going on here. Radiator runs fine for awhile, hovering around 30-40% CPU usage, but then at some point it goes to 99%. On our Solaris machine, it was always 40-60% from a 'top'. We are using v2.17.1. The Linux machine is a P3-800 512M RAM, and the Solaris machine was an E250 450mhz (single) CPU 1G RAM. Any help appreciated. Viraj. === 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) Bad authenticator
Hugh, Actually this client is in our clients file with the correct secret, and we indeed get proper accounting and authentication from it. However, I am also seeing those entries in the log so I'm wondering what it means. Thanks, Viraj. On Wed, 29 Nov 2000, Hugh Irvine wrote: > > Hello Viraj - > > On Wed, 29 Nov 2000, Viraj Alankar wrote: > > Hello, > > > > I am noticing in my logs warnings similar to: > > > > WARNING: Bad authenticator in request from 1.2.3.4 > > > > The manual suggests that if I am gettings these, my accounting > > requests are not being store, and authentications are OK, to try > > IgnoreAcctSignature. However, I am getting accounting and authentications > > just fine, and have verified the secrets are correct. > > > > These messages usually occur because the host 1.2.3.4 is not listed in the > Clients definitions in Radiator. It is usually some radius device that is > firing radius packets indiscriminately. > > 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. > === 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) Bad authenticator
Hello, I am noticing in my logs warnings similar to: WARNING: Bad authenticator in request from 1.2.3.4 The manual suggests that if I am gettings these, my accounting requests are not being store, and authentications are OK, to try IgnoreAcctSignature. However, I am getting accounting and authentications just fine, and have verified the secrets are correct. Should I just ignore these messages? What exactly could they mean? Thanks, Viraj. === 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) Fallback to flatfiles if mysqldb is down
Hugh Irvine wrote: > > Hello Matthias - > > On Tue, 10 Oct 2000, Matthias Fechner (Temp) wrote: > > Hi, > > > > i want to integrate a complete fallback, if the database isn't working like > > client-auth, user-auth or accounting radiator should be use flatfiles. If > > accounting cannot be write to mysqldb it is written to a > > flatfile(AcctLogFileName ). > > > > I think for the user I only write > > > > > > DBSourcedbi:mysql:cndps > > DBUsername radiator > > DBAuth * > > AuthSelect SELECT password,NULL,replyattr FROM snapshot > > WHERE \ > > loginname='%U' AND realmname='%R' > > > > NoDefault > > # You may want to tailor these for your ACCOUNTING table > > # You can add your own columns to store whatever you like > > AccountingStopsOnly > > AccountingTable accounting > > AcctColumnDef username,User-Name > > > > AcctColumnDef disconnect_cause,Ascend-Disconnect-Cause > > > > > > # use this for fallback > > > > Filename users > > > > > > AcctLogFileName accounting.log > > PasswordLogFileName password.log > > > > > > You will need to add an AuthByPolicy to the above: > > > AuthByPolicy ContinueUntilAccept > . Sorry to reply to such an old message, but shouldn't the AuthByPolicy here be ContinueWhileIgnore? Otherwise it seems all failed authentications will unnecessarily go through the flatfile as well. Viraj. === 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) Questions on creating AuthBy's
Hello,
I am inheriting AuthFILE to create a modified version. I have the
following at the top of my .pm file:
package Radius::AuthFILE_AND_LOG;
use Radius::AuthFILE;
use strict;
use vars qw($VERSION @ISA);
BEGIN
{
@ISA = qw(Radius::AuthFILE);
}
My question is do I have to implement new() if it will just be
calling $self->SUPER::new() ? i.e. I don't need to change anything in the
new() method. I have left it out of my file and everything seems to work
ok, however is it correct to do this?
Another question is do my new handlers need to be copied to the
Perl site lib directory under Radius or is there another location that I
can place my additions? I would like to separate my additions from the
main code if possible.
Thanks for any help.
Viraj.
===
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) PasswordLogFilename and non-existant users
Hello, We have a situation where we would like to attempt authentication via SQL and if that fails, to log the attempt, and send an access accept anyhow. Basically it will be free authentication, but I'd like to know what requests would have failed. What I have currently in my config is similar to this: ... PasswordLogFileName %D/blah.com.passwd.log AuthByPolicy ContinueUntilAccept AuthBy Local_Mysql_DB Filename %D/blah.com.defaults And within blah.com.defaults I have: DEFAULT Realm = "blah.com" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, Session-Timeout = 82800, Idle-Timeout = 900, Framed-MTU = 1500 This works just fine for users that exist in the database. However the password log doesn't contain the non-existant users. I found an old message on this topic in the archives stating there are plans to add this capability. Have there been any changes to add this capability? I understand it can be done with a hook, but I'm not too sure how to do this. The above Realm will be under heavy load, averaging about 20 requests/sec. Passwdlogfilename suffices for existing users. If I were to add a hook, how could I set it up such that it is only executed if the user does not exist? I'm a little confused on how to do that, or if there are alternatives. Thanks for any help. BTW, I just want to say that Radiator probably has the best support I've ever seen. Hugh when do you sleep? :) Viraj. === 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) Problem with Client-Identifier in Handler clause
Hello, We're using 2.16.1 on Solaris and I'm noticing a strange problem with Client-Identifier in a Handler clause. In my clients list I have something similar to: Identifier BO_LAPAZ_RAS1 Secret blah And my Handler: ... However, watching a trace 4 shows that it passing over this Handler to the next one when I'm trying an authentication from 1.2.3.4. When I change this to: ... Everything works fine. Is there something incorrect I'm doing with the identifier? Thanks. Viraj. === 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) applying patches
Hello, This may be a silly question, but what is the correct procedure for applying patches? If I'm installing from scratch do I just copy the .pm files to the 'Radius' directory from the source archive? If Radiator is already installed, do I just copy over the .pm files in the Perl library locations? Thanks. Viraj. === 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) Allocating RASes to specific realms
Hello, We have about 200 RASes in our clients file. I would like to restrict certain realms to a group of RASes only. One solution I see is to use NAS-Address-Port-List in each of my handlers. This would be fine, but I'd have to duplicate the RASes in the clients list in the portlist file. I'd like to avoid that if possible. However the only way I can see is to have identifiers for the clients: Identifier realm1.com Identifier realm1.com And adding this check item. However, what if I need 5.6.7.8 to authenticate both realm1.com and realm2.com? Can a client have 2 identifiers? Maybe I'm just approaching this the wrong way. Regarding the portlist file format, is there a way to specify 'all ports'. Can I just leave the port range blank? One last thing, I noticed a few spelling errors in the Radiator docs under section 13.1.16, the words 'paramter' and 'IdentificalClients'. Not a big deal to me but thought I would let you guys know. Thanks for any help, Viraj === 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) Restricting proxy to certain realms
Hello, We are running Radiator and there is another radius server proxying us auth/accounting for certain realms. I would like Radiator to only accept auth/accounting from this server for specified realms, and ignore everything else. I'm trying to find the best way to put this in our config file. We currently have a few sections and sections at the bottom of our config, ie: ... ... ... Now say I want to accept ONLY realms c and d from the radius server 1.2.3.4. What I was thinking is I would first have to change all Realm clauses to Handler's and add something like this before all of the Handlers: authenticate... ignore or reject somehow ... rest of my Handlers I'm wondering if anyone has a better solution. Can anything be done in the definition (say rewrite unknown realms to bogus realm which will fail authentication)? Any help appreciated. Thanks, Viraj. === 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) record not deleted from RADONLINE
Hugh Irvine wrote: > > Hello Mark - > > On Sat, 28 Oct 2000, Mark Brettin wrote: > > I'm having a problem with records being 'stuck' in the RADONLINE > > table when user's disconnect. Then when they try to reconnect > > they get rejected because it appears they are still online. > > Has anyone ever encountered this problem before? Anyone > > know what the problem is? It doesn't happen all the time > > and I can't seem to isolate what the cause may be. > > > > The reason this happens is because of lost radius accounting stop packets, > either because of link congestion or other packet loss, or because of NAS bugs. > > The best way to discover what is happening is to look at a trace 4 debug from > Radiator to verify the packets being received and sent by Radiator. > > This topic has been discussed on the list many times, so have a look at the > archive site here: > > http://www.starport.net/~radiator > Just a quick question on this. Isn't it actually the accounting response acknowledgement packet sent back from the radius server that is lost in these scenarios? That is, the RAS should keep retrying to send the accounting packet until the acknowledgement packet is received. Is this correct? Thanks. Viraj. === 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) HUP signal behavior
Hello,
Recently, I tried increasing my Trace level from 2 to 4 in my config
file and then sent a HUP to radiator. It died with the following error.
We are using v2.16.1 on Sparc Solaris 2.7. Let me know if I can provide
more information. It is difficult to duplicate, however it happens to us
occasionally.
Viraj.
Original Message
Subject: Your program exited
Date: Tue, 24 Oct 2000 11:00:16 -0400 (EDT)
Your program
/usr/local/bin/radiusd -config /usr/local/radiator/raddb/radiusd.cfg
-foreground
exited unexpectedly with exit status 255,
signal number 0 and dump indication 0.
The STDERR output was Can't use string ("") as a subroutine ref while
"strict refs" in use at
/usr/local/lib/perl5/site_perl/5.005/Radius/Util.pm line 285,
chunk 22906.
===
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) StripFromReply not working for certain items
Hello, We are using Radiator 2.16.1 on Solaris SPARC. For some reason I cannot get StripFromReply to remove a certain reply item: Ascend-Assign-IP-Pool All of my other reply item stripping works fine. Is there some reason it would not work for this attribute? Also, is there a way to remove ALL reply items (i.e. StripFromReply *)? Thanks for any help. Viraj. === 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) Attribute number 67 (vendor 529) definitions
Hello, We are receiving alot of these in our logs: Thu Sep 14 15:17:46 2000: ERR: Attribute number 66 (vendor 529) is not defined in your dictionary Thu Sep 14 15:17:46 2000: ERR: Attribute number 67 (vendor 529) is not defined in your dictionary I wasn't able to find these in any of the dictionaries. Does anyone know what they are and what needs to be added to the dictionary? Thanks for any help. Viraj. === 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) Strange SIGHUP handling
Hugh, Here is an example, my current config, with IPs changed: LogDir /usr/local/radiator/raddb DbDir /usr/local/radiator/raddb Trace 4 AuthPort 1645 AcctPort 1646 Secret hello # DEFAULT handler # Strip out junk from username RewriteUsername s/[^A-Za-z0-9\-\.\@_\/]//g; AcctLogFileName /radius/radiator/roaming/%R/%m-%d-%Y/%c Host 1.2.3.4 Secret blah RetryTimeout 30 I sent a radius test to hit the AuthBy TEST. Then I edited the config, and commented out the last 4 lines. I then sent a SIGHUP, and tried the same radius test. It again hit the AuthBy TEST clause even though it wasn't there. Below are logs. Hope this helps. Viraj. Thu Sep 7 23:28:39 2000: DEBUG: AuthTEST loaded Thu Sep 7 23:28:39 2000: DEBUG: New Radius::AuthTEST constructed Thu Sep 7 23:28:39 2000: DEBUG: AuthTEST DESTROY ed Thu Sep 7 23:28:39 2000: INFO: Server started: Radiator 2.16.3 on my.host.com Thu Sep 7 23:29:04 2000: DEBUG: Packet dump: *** Received from 5.6.7.8 port 1026 Code: Access-Request Identifier: 102 Authentic: <0><0>-<213><0><0>Bl<0><0>C<169><0><0>O<198> Attributes: User-Name = "blah@blah" User-Password = "C<159>!<172><251><7><180><187><189><250>.<234><129>R/y" NAS-Port = 21 Livingston = "test" USR-Blah-Index = 1952805748 NAS-IP-Address = 5.6.7.8 Thu Sep 7 23:29:04 2000: DEBUG: Handling request with Handler 'Realm=DEFAULT' Thu Sep 7 23:29:04 2000: DEBUG: Deleting session for blah@blah, 5.6.7.8, 21 Thu Sep 7 23:29:04 2000: INFO: AuthTEST handle_request: Received from 5.6.7.8 port 1026 Thu Sep 7 23:29:04 2000: DEBUG: Access accepted for blah@blah Thu Sep 7 23:29:04 2000: DEBUG: Packet dump: *** Sending to 5.6.7.8 port 1026 Code: Access-Accept Identifier: 102 Authentic: <0><0>-<213><0><0>Bl<0><0>C<169><0><0>O<198> Attributes: Thu Sep 7 23:29:36 2000: NOTICE: SIGHUP received: restarting Thu Sep 7 23:29:36 2000: INFO: Server started: Radiator 2.16.3 on my.host.com Thu Sep 7 23:29:45 2000: DEBUG: Packet dump: *** Received from 5.6.7.8 port 1026 Code: Access-Request Identifier: 107 Authentic: <0><0>6<152><0><0>nv<0><0>W<205><0><0>n<208> Attributes: User-Name = "blah@blah" User-Password = "<30><196>2evyjm<176><215>1qn<216>&<2>" NAS-Port = 21 Livingston = "test" USR-Blah-Index = 1952805748 NAS-IP-Address = 5.6.7.8 Thu Sep 7 23:29:45 2000: DEBUG: Handling request with Handler 'Realm=DEFAULT' Thu Sep 7 23:29:45 2000: DEBUG: Deleting session for blah@blah, 5.6.7.8, 21 Thu Sep 7 23:29:45 2000: INFO: AuthTEST handle_request: Received from 5.6.7.8 port 1026 Thu Sep 7 23:29:45 2000: DEBUG: Access accepted for blah@blah Thu Sep 7 23:29:45 2000: DEBUG: Packet dump: *** Sending to 5.6.7.8 port 1026 Code: Access-Accept Identifier: 107 Authentic: <0><0>6<152><0><0>nv<0><0>W<205><0><0>n<208> Attributes: Thu Sep 7 23:29:57 2000: NOTICE: SIGTERM received: stopping Thu Sep 7 23:29:57 2000: DEBUG: AuthTEST DESTROY ed On Thu, 7 Sep 2000, Hugh Irvine wrote: > > Hello Viraj - > > On Thu, 07 Sep 2000, Viraj Alankar wrote: > > On v2.16.3, I just noticed that if I have a: > > > > > > > > in the configuration file, startup Radiator, then remove the > DEFAULT> clause and send a SIGHUP, it appears to still be in the > > configuration. > > > > I'm not sure if it is a bug or not, but I was thinking HUP would first > > remove the current config and reload from the file, so this section would > > be gone from the running config. > > > > This is what should happen. If you are seeing odd behaviour, it would be very > helpful if you could send us the relevant configuration files and debug output > so we can try to reproduce the problem. > > many thanks > > Hugh > > -- > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. > Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. > > > > === > Archive at http://www.starport.net/~radiator/ > Announcements on [EMAIL PROTECTED] > To unsubscribe, email '[EMAIL PROTECTED]' with > 'unsubscribe radiator' in the body of the message. > === 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) Proxy Accounting Problem
Hugh, Thanks for the help. One question, see below: On Wed, 6 Sep 2000, Hugh Irvine wrote: > > City B with IP 1.2.3.4 running v2.16.1: > > . > > > Secret somesecret > . > > > . > > > Identifier Forward_All_Requests_To_City_A > Host 5.6.7.8 > Secret blah > > > > RewriteUsername tr/A-Z/a-z/; > AcctLogFileName /radius_logs/%R/%m-%d-%Y/%c > > > > > > RewriteUsername tr/A-Z/a-z/; > AcctLogFileName /radius_logs/%R/%m-%d-%Y/%c > AuthBy Forward_All_Requests_To_City_A > Won't this result in duplicate accounting in City B when a user logs in City B with a realm from City A? That is, a user logs in with [EMAIL PROTECTED] in City B. Accounting packet is sent to radius server in City B, which logs locally, then forwards to City A. City A then logs the accounting locally and forwards it back to City B, which from the: And then depend on the proxied back accounting for local storage? Thanks. Viraj. > > > Hopefully you get the idea. If you have problems, please feel free to ask any > questions. > > regards > > Hugh > > > On Wed, 06 Sep 2000, Viraj Alankar wrote: > > Hello, > > > > We have a situation in which we have 2 Radiator servers setup, one > > in city A and one in city B. Our goal is the following: > > > > Users authenticating in city A authenticate and store accounting locally, > > but also forward accounting to city B. > > > > Users with realms from city A can login to city B. Basically city B > > forwards authentication & accounting for those realms to the radius server > > running in city A. However, accounting must be also be stored locally in > > city B. > > > > The idea is that both city A and city B need the get the accounting > > associated with realms from city A. > > > > I've done what I believe is the proper configuration, but it seems like > > what is happening is the accounting packets are ping-ponging back and > > forth between the radius servers when a user logs into city A. The > > accounting logs in city A show the following: > > > > Tue Sep 5 10:30:25 2000 > > Acct-Status-Type = Start > > Acct-Session-Id = "a10a6962" > > Acct-Delay-Time = 15 > > NAS-Port = 39 > > NAS-Port-Type = Async > > User-Name = "[EMAIL PROTECTED]" > > Service-Type = Framed-User > > Framed-Protocol = PPP > > Called-Station-Id = "8400" > > Idle-Timeout = 900 > > Connect-Info = "26400 19200 V.34" > > Acct-Authentic = RADIUS > > NAS-IP-Address = 199.199.199.199 > > Timestamp = 968160482 > > Timestamp = 968160619 > > Timestamp = 968160483 > > Timestamp = 968160620 > > Timestamp = 968160484 > > Timestamp = 968160620 > > Timestamp = 968160485 > > Timestamp = 968160622 > > Timestamp = 968160486 > > Timestamp = 968160623 > > ... > > > > and so on. It appears a duplicate accounting packets are dumped, each one > > with one more Timestamp field. This is what tells me that accounting must > > be being bounced back and forth. > > > > Here is the relevant configuration we have in city A with radius server IP > > 5.6.7.8 running v2.16.3: > > > > > >AuthByPolicy DoAll > > > ># Lower case everything > >RewriteUsername tr/A-Z/a-z/; > > > >AcctLogFileName /radius/radiator/%c/detail > > > ># Forward accounting to City B > > > > Host 1.2.3.4 > > Secret blah > > RetryTimeout 30 > > NoForwardAuthentication > > > > > ># Authentication, also some work with Accounting > > > > > > > > > > > > And in City B with IP 1.2.3.4 running v2.16.1: > > > > > >RewriteUsername tr/A-Z/a-z/; > >AcctLogFileName /radius_logs/%R/%m-%d-%Y/%c > > > > Host 5.6.7.8 > > Secret blah > > > > > > > > Now what I believe must be happening is a user logs in at city A. An > > accounting packet is generated from the RAS and sent to the radius server > > in city A. This server stores it locally, then forwards the accounting to > > city B. Now city B gets the accounting and sees that it is the > > e-net.com.br realm, and th
(RADIATOR) Strange SIGHUP handling
On v2.16.3, I just noticed that if I have a: in the configuration file, startup Radiator, then remove the clause and send a SIGHUP, it appears to still be in the configuration. I'm not sure if it is a bug or not, but I was thinking HUP would first remove the current config and reload from the file, so this section would be gone from the running config. Viraj. === 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) Proxy Accounting Problem
Hello, We have a situation in which we have 2 Radiator servers setup, one in city A and one in city B. Our goal is the following: Users authenticating in city A authenticate and store accounting locally, but also forward accounting to city B. Users with realms from city A can login to city B. Basically city B forwards authentication & accounting for those realms to the radius server running in city A. However, accounting must be also be stored locally in city B. The idea is that both city A and city B need the get the accounting associated with realms from city A. I've done what I believe is the proper configuration, but it seems like what is happening is the accounting packets are ping-ponging back and forth between the radius servers when a user logs into city A. The accounting logs in city A show the following: Tue Sep 5 10:30:25 2000 Acct-Status-Type = Start Acct-Session-Id = "a10a6962" Acct-Delay-Time = 15 NAS-Port = 39 NAS-Port-Type = Async User-Name = "[EMAIL PROTECTED]" Service-Type = Framed-User Framed-Protocol = PPP Called-Station-Id = "8400" Idle-Timeout = 900 Connect-Info = "26400 19200 V.34" Acct-Authentic = RADIUS NAS-IP-Address = 199.199.199.199 Timestamp = 968160482 Timestamp = 968160619 Timestamp = 968160483 Timestamp = 968160620 Timestamp = 968160484 Timestamp = 968160620 Timestamp = 968160485 Timestamp = 968160622 Timestamp = 968160486 Timestamp = 968160623 ... and so on. It appears a duplicate accounting packets are dumped, each one with one more Timestamp field. This is what tells me that accounting must be being bounced back and forth. Here is the relevant configuration we have in city A with radius server IP 5.6.7.8 running v2.16.3: AuthByPolicy DoAll # Lower case everything RewriteUsername tr/A-Z/a-z/; AcctLogFileName /radius/radiator/%c/detail # Forward accounting to City B Host 1.2.3.4 Secret blah RetryTimeout 30 NoForwardAuthentication # Authentication, also some work with Accounting And in City B with IP 1.2.3.4 running v2.16.1: RewriteUsername tr/A-Z/a-z/; AcctLogFileName /radius_logs/%R/%m-%d-%Y/%c Host 5.6.7.8 Secret blah Now what I believe must be happening is a user logs in at city A. An accounting packet is generated from the RAS and sent to the radius server in city A. This server stores it locally, then forwards the accounting to city B. Now city B gets the accounting and sees that it is the e-net.com.br realm, and then forwards it back to city A, and then back and forth. I am not sure if this is happening though, because I thought the Proxy state flag would be set and no more forwarding would take place. If it will help that I get some debug information, please let me know. I was thinking someone could point out an error in my configuration or if I'm doing something else wrong. Thanks for any help. Viraj. === 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.
