(RADIATOR) DSL Auth setup

Hugh Irvine hugh at open.com.au
Tue Aug 14 20:39:55 CDT 2007


Hello Adam -

We have many customers who use MySQL very successfully, and all of  
our SQL examples in the Radiator distrubution also use MySQL.

There is script to set up the example MySQL schema in "goodies/ 
mysqlCreate.sql".

In my consulting practice I generally tend to organise things around  
functional groups based on Client clause(s) with Identifier(s).

Something like this:

......

# define Client clauses with Identifiers

<Client 1.1.1.1>
	Identifier SomethingMeaningful
	.....
</Client>

<Client 2.2.2.2>
	Identifier SomethingMeaningful
	.....
</Client>

<Client 3.3.3.3>
	Identifier AnotherUsefulTag
	.....
</Client>

<Client 4.4.4.4>
	Identifier AnotherUsefulTag
	.....
</Client>

......

# define AuthBy clause(s) with Identfier(s)

<AuthBy SQL>
	Identifier CheckDatabase
	......
	AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \
		from SUBSCRIBERS \
		where USERNAME = %0
	AuthColumnDef 0, Password, check
	AuthColumnDef 1, GENERIC, check
	AuthColumnDef 2, GENERIC, reply
	......
	# add common reply attributes
	AddToReply ......
	......
</AuthBy>

......

# define Handlers

<Handler Client-Identifier = SomethingMeaningful>

	<AuthBy GROUP>
		
		AuthBy CheckDatabase

		AddToReply ......

	</AuthBy>

</Handler>

<Handler Client-Identifier = AnotherUsefulTag>

	<AuthBy GROUP>
		
		AuthBy CheckDatabase

		AddToReply ......

	</AuthBy>

</Handler>

.......
	
	
Groups of reply attributes for a single user can all be specified in  
the field called "REPLYATTR" in the database.

All of the common reply attributes can be specified in the AddToReply  
in the AuthBy SQL clause, and reply attributes that depend on each  
Handler can be specified in the AddToReply in the AuthBy GROUP.

See section 5.29 in the Radiator 3.17.1 reference manual ("doc/ 
ref.html").

BTW - we are available on a contract basis for design, implementation  
and training as required.

regards

Hugh



On 14 Aug 2007, at 21:00, Adam Armstrong wrote:

> Hugh Irvine wrote:
>>
>> Hello Adam -
>>
>> Can you give us a bit more detail on your requirements?
>>
>> You mention a "flat file mess" - do you need to use flat files or  
>> would you prefer to use SQL or LDAP or something else?
>>
>> There are many example configuration files in the "goodies"  
>> directory of the Radiator 3.17.1 distribution.
>>
> I'd prefer to use MySQL, but it seemed like a nightmare with  
> FreeRadius. A previous employer of mine used Radiator, so i thought  
> it might be worth looking to see if Radiator could do what we want  
> somewhat more sanely.
>
> I initially have 2 basic type of account, a standard internet  
> account and an account which gives access to a VRF.
>
> First, the internet service has two types, static and dynamic, i'm  
> sure this is nothing special :)
>
> Dynamic like :
>
> test at vostron.net     User-Password == "testing"
>        Tunnel-Type = L2TP,
>        Tunnel-Medium-Type = IP,
>        Tunnel-Password = BLAH,
>        Tunnel-Server-Endpoint = x.x.x.x,
>        Tunnel-Client-Auth-ID = BLAH,
>        Service-Type = Framed-User,
>        Framed-Protocol = PPP
>
> and static the same with the addition of IP details
>
>        Framed-IP-Address = 89.21.240.0,
>        Framed-IP-Netmask = 255.255.255.255,
>
> Is there a way radiator could generate these additions of a  
> particular field in the database has a CIDR block in it or something?
>
> It's also possible that static customers could have one or more  
> additional subnets routed to them, which would require cisco  
> avpairs. Are there any best practices on handling that?
>
> VRF access accounts are a bit more complicated, and need two extra  
> cisco-avpairs to put them in the right vrf and give them the  
> correct ip unnumbered interface like this :
>
> blah at mpls.vostron.net  User-Password == "blah"
>        Tunnel-Type = L2TP,
>        Tunnel-Medium-Type = IP,
>        Tunnel-Password = blah,
>        Tunnel-Server-Endpoint = x.x.x.x,
>        Tunnel-Client-Auth-ID = BLAH,
>        Service-Type = Framed-User,
>        Framed-Protocol = PPP,
>        Framed-IP-Address = 10.255.254.1,
>        Framed-IP-Netmask = 255.255.255.255,
>        Cisco-AVPair = "ip:dns-servers=10.10.0.1",
>        Cisco-AVPair += "ip:route=10.255.254.1 255.255.255.255",
>        Cisco-AVPair += "ip:route#1=10.1.0.0 255.255.0.0",
>        Cisco-AVPair += "ip:route#2=10.0.0.0 255.0.0.0",
>        Cisco-AVPair += "lcp:interface-config=ip vrf forwarding  
> XXXXXXXX",
>        Cisco-AVPair += "lcp:interface-config=ip unnumbered loopback  
> 60001"
>
> These accounts can also have a bunch of extra routes, as they're  
> often used to provide backup to a private leased line.
>
> The final thing i want to be able to do (that i can remember!) is  
> to pool our LNSes. For example, static and dynamic customers could  
> get assigned lns 1.1.1.1 1.1.1.2 or 1.1.1.3 in a round-robin  
> fashion, but i need to be able to lock vrf accounts to one or maybe  
> two LNSes (otherwise every VRF has to be present on every LNS,  
> which is a pain!)
>
> I'm basically just looking for a sane database schema and radiator  
> config setup to handle this. An existing management interface would  
> be ace, but I doubt any exist, and i'll probably end up writing one  
> anyways!
>
> Kind Regards,
> Adam Armstrong
> Vostron Limited
>
>> On 14 Aug 2007, at 10:05, Adam Armstrong wrote:
>>
>>> Hi,
>>>
>>> I'm trying to sort out an authentication for our L2TP ADSL  
>>> delivery to replace the current FreeRadius + Flat Files mess.
>>>
>>> Are there any front-ends out there which handle this stuff  
>>> nicely? I also need to pass the occasional extra Cisco-AVPair  
>>> (for clients in other VRFs).
>>>
>>> Any example Radiator configs or pointers to some decent  
>>> documentation would be great!
>>>
>>> Thanks,
>>> adam.
>>>
>>> -- 
>>> 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.
>>
>>
>>
>> NB:
>>
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (www.open.com.au/ 
>> archives/radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>> Have you checked the RadiusExpert wiki:
>> http://www.open.com.au/wiki/index.php/Main_Page
>>
>
> --
> 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.



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
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