(RADIATOR) Help With Configuration

Hugh Irvine hugh at open.com.au
Tue Jun 21 14:41:56 CDT 2005


Hello Sergio -

Could you please tell me the name of the registered company that has  
purchased this copy of Radiator?

Please reply to me directly.

To be  able to help with your problem we will need to see a trace 4  
debug with a LogMicroseconds logger so we can see how long each  
processing step is taking. I suspect your database is probably the  
main cause of performance problems.

regards

Hugh


On 22 Jun 2005, at 04:56, Sergio Pantoja H. wrote:

> Hello,
>
> I having perfomance issues with radiator, this radius it's receive  
> request from 2 redbacks,
> this is a legacy implementation so i don't know the deep details  
> about it.
>
> Regullary the radius receive excesive petitions from the redbacks  
> causing a huge number
> of time outs.
>
> Here is my actual config, if anyone can see something duplicate,  
> strange or misconf.
>
> Regards
> --
> Sergio Pantoja H.
> sergio at pantoja.cl
>
> ----- Original Message ----- From: "Bosse Klykken" <bosse at linpro.no>
> To: <radiator at open.com.au>
> Sent: Tuesday, June 21, 2005 8:54 AM
> Subject: (RADIATOR) Digipass+password checking
>
>
>
>> In the implementation process I'm currently in, I've discovered  
>> that there
>> are several routers and other equipment that needs to authenticate  
>> to RADIUS
>> through static passwords. As the Digipass module rejects requests  
>> where it
>> can't find the username in the RADDIGIPASS database, I've looked  
>> at using
>> Handlers to check the password field so that the request can be  
>> handled by
>> the correct chain. Unfortunately, as the passwords are MD5, I believe
>> that this might be somewhat problematic.
>>
>> But as AuthBy EXTERNAL allows me to decrypt the password before  
>> sending it
>> to an external program, I thought I might try that as a  
>> workaround. The
>> script looks like this:
>>
>> ---8<--- radchkpwd.sh
>> #!/bin/sh
>>
>> if echo $1 | grep -q ^[0-9][0-9][0-9][0-9][0-9][0-9]$
>> then
>>    echo "REJECT"
>>    exit 1 # This is probably a digipass token
>> else
>>    echo "ACCEPT"
>>    exit 0 # This is something else
>> fi
>> ---8<---
>>
>> When I call this script from the commandline with some test  
>> parameter,
>> the output looks okay, and if it contains six digits, it responds  
>> with
>> "REJECT", as it (probably) should. I also verified through the log  
>> that
>> the $1 parameter is correct.
>>
>> Here's the relevant parts of radius.cfg that calls the script:
>>
>> ---8<--- radius.cfg
>> <Realm DEFAULT>
>> <AuthBy GROUP>
>> AuthByPolicy ContiniueWhileAccept
>>        <AuthBy EXTERNAL>
>>        # If exit 0 then password is NOT Digipass, and the chain  
>> should continiue
>>        # If exit 1 then password is Digipass, and the chain should  
>> be broken
>> # and hopefully pass on to the next AuthBy GROUP.
>>        DecryptPassword
>>        Command /usr/bin/radchkpwd.sh %P
>>        # ResultInOutput
>> </AuthBy>
>>
>> <AuthBy RADMIN>
>> # Standard AuthBy RADMIN information here, but removed  
>> NoCheckPassword
>> </AuthBy>
>> </AuthBy>
>> <AuthBy GROUP>
>> AuthByPolicy ContiniueWhileAccept
>> <AuthBy DIGIPASS>
>> # Standard DIGIPASS stuff here
>> </AuthBy>
>> <AuthBy RADMIN>
>> # Standard RADMIN stuff here
>> </AuthBy>
>> </AuthBy>
>> # Some AuthLog stuff here
>> </Realm>
>> ---8<---
>>
>> The following log snippet is from an attempt logging on with  
>> digipass. It
>> runs the radchkpwd.sh script with a correct six-digit parameter,  
>> and should
>> give a REJECT so that the AuthBy should stop traversing downwards,  
>> according
>> to the AuthByPolicy ContiniueWhileAccept - but as you see from the  
>> log, it
>> gets handled by Radius::AuthRADMIN.
>>
>> ---8<--- logfile
>> Tue Jun 21 14:19:23 2005: DEBUG: Handling request with Handler  
>> 'Realm=DEFAULT'
>> Tue Jun 21 14:19:23 2005: DEBUG:  Deleting session for sttest,  
>> 127.0.0.1,
>> Tue Jun 21 14:19:23 2005: DEBUG: do query is: 'delete from  
>> RADONLINE where NASIDENTIFIER='127.0.0.1' and NASPORT=0':
>> Tue Jun 21 14:19:23 2005: DEBUG: Handling with Radius::AuthGROUP
>> Tue Jun 21 14:19:23 2005: DEBUG: Running command: /usr/bin/ 
>> radchkpwd.sh 444872
>> Tue Jun 21 14:19:23 2005: DEBUG: Handling with Radius::AuthRADMIN
>> Tue Jun 21 14:19:23 2005: DEBUG: Handling with Radius::AuthRADMIN:
>> ---8<---
>>
>> Now, as this is now, it works with password auth, but not  
>> digipass. I guess
>> that it would work with digipass again if I reordered the  
>> radmin.cfg a bit,
>> so from what I can tell, I might have misunderstood the concept of  
>> AuthBy
>> GROUP and AuthByPolicy.
>>
>> Could anyone here help me by pointing me in the right direction,  
>> considering
>> my objective of having both digipass and password authentication?  
>> I believe
>> I could use Handlers with triggers on NAS-identifiers in order to  
>> set up
>> static password handling in radmin.cfg for requests from certain  
>> NASes or
>> User-IDs, but this really isn't what I had in mind.
>>
>> .../Bosse
>> -- 
>> Bosse Klykken, operations consultant
>> Linpro AS - http://www.linpro.no
>>
>> --
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
>>
>> <radius.cfg>
>


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

-- 
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.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list