[RADIATOR] Fallback Function ?

2011-02-03 Thread Patrik Forsberg
Hi, Me again ;P Another question now.. tried to browse through the archives but there are simply to many threads without a search function it becomes a hassle ;) Anyways.. I'm trying to figureout how to activate a "fall back" function. The scenary is like this I have two ldap servers that are

Re: [RADIATOR] Fallback Function ?

2011-02-03 Thread Patrik Forsberg
Nvm, I figured it out :) Regards, Patrik Forsberg > -Original Message- > From: radiator-boun...@open.com.au [mailto:radiator- > boun...@open.com.au] On Behalf Of Patrik Forsberg > Sent: Thursday, February 03, 2011 10:48 AM > To: radiator@open.com.au > Subject: [RADIATOR] Fallback Functio

Re: [RADIATOR] Assigning IP's directly from the Radius server

2011-02-03 Thread Gerard Alcorlo Bofill
Hello, thanks Michael for your good explanation. I checked your configuration with mine and it was similar. Well, I only have one Radius so I don't use two AddressAllocators like you. Heikki, thank you too. Now I understand a little more the difference between the two different AddressAllocators.

Re: [RADIATOR] Assigning IP's directly from the Radius server

2011-02-03 Thread Michael
I think the AddressPool only populates the sql table with the available ips in that pool. I guess you're missing a FindQuery definition of an sql query that returns an available ip from the sql db. my example had this: # sql select statement seems to need the ip address in the 2nd re

Re: [RADIATOR] Assigning IP's directly from the Radius server

2011-02-03 Thread Michael
oh and keep in mind, when you restart radiator, or even maybe reload radiator, the AddressPool may re-mark all ips as available, therefore it may hand out an IP that is already in use. Maybe someone else can confirm that is correct? On 11-02-03 11:53 AM, Michael wrote: > I think the AddressPoo

[RADIATOR] check-items in chained authby queries

2011-02-03 Thread Linuxchuck
Hello again, I am attempting to validate both the username and appropriate group membership via MySQL on an incoming access-request before bothering to process the HOTP password provided. If the username doesn't exist, or the user is not a member of the group in the list provided, send a rejec

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Michael
your "AuthBy GROUP AuthSQL" will not flow down into the "AuthBy GROUP AuthHOTP". I don't think the AuthHOTP will be used at all in this config. Look like you need an "AuthBy AuthHOTP" in the AuthSQL config, like this: > > Identifier AuthSQL > AuthByPolicyContinueWhi

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Michael
Actually, probably nicer to understand, and easier to look at if you clean it up like this: # configure AuthSQL Identifier AuthSQL GroupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=%0 AND groupname=%1

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Linuxchuck
Hi Michael, Thanks for the response. Actually, it does hit the AuthHOTP section. I should have put a little more emphasis on the fact that there is an "AuthType=AuthHOTP" for the user when it is looked up in the database. I did mention that, but it was kind of jammed into the beginning, and w

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Linuxchuck
Michael, Unfortunately, I need it to be a bit more dynamic. I have both HOTP and DIGIPASS tokens in use, and the type of token authentication to use is selected by providing an authtype identifier in the username database. Instead of forcing the server to try both HOTP and DIGIPASS, I can save

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Michael
ah ok, i see. the AuthSQL specifies "Auth-Type=AuthHOTP". Never done this type of setup before, but maybe the 'Auth-Type=AuthHOTP' in the sql query should be after the 'GroupList="Group1 Group2 Group3"?? Again, not sure, but I would think the 'check' is done in order. it sounds like you want

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Linuxchuck
Michael, Ok, I gave it a shot, and got some completely different results. Thanks for the suggestion. The order of check items is certainly taken into account, which I should have thought of. However, the error I am receiving is a little strange. All I have done is changed the order of the t

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Linuxchuck
With the "called with 2 bind variables when 0 are needed" errors showing, I believe the initial problem I was experiencing has been solved, and a new, unrelated one has cropped up in it's place. Let me provide a full unabridged version of my config file to avoid further confusion. I am using g

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Michael
instead of: roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=%0 AND groupname=%1 try: roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=? AND groupname=? On Thu, 3 Feb 2011, Linuxchuck wrote: > Michael, > > Ok, I gave it a shot, and got some com

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Michael
the version, 4.7, that i have, it looks like the GroupMembershipQuery should honor %0 and %1 and replace them with the 'sql quoted user name' and 'sql quoted group name' as per the manual as well. But, as per your debug, it looks like it's using 'bind variables', so i think sql would replace

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Linuxchuck
Michael, I have version 4.7 based on the log output during startup. Your solution works! I really appreciate your assistance on all this. Now to finish working out a way to add the proper reply type based on group membership, and I can call my eval "done", and push the move to production. I

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Michael
Perfect. But it looks like you're just using a default setup. there are other things that should be considered. very fine details, like one i run into is the nas wait times, and failover when problems arise. failing over to multiple sql servers for authentication is great. with accounting, if

Re: [RADIATOR] check-items in chained authby queries

2011-02-03 Thread Michael
oh, and, you may not want to stop there. you may want to find out why %0 and %1 don't work. I think it should as per source code and manual. Since you are using the 2 '?' the order is very important. You can't change the order of: WHERE username=? AND groupname=? to this: WHERE groupname=

Re: [RADIATOR] Assigning IP's directly from the Radius server

2011-02-03 Thread Gerard Alcorlo Bofill
Hi Michael, I don't think it's necessary to specify the FindQuery, AllocateQuery and DeallocateQuery. There is a default query for each one. I can see how my radius is sending correctly the information stored on my sqlserver and how the IP addresses are also marked as assigned. I've deleted all t