FW: (RADIATOR) Three Authby Clauses and why they don't work

Hugh Irvine hugh at open.com.au
Tue Mar 26 00:54:15 CST 2002


Hello Leon -

Please disregard my previous mail.

The answer to your first question is yes, you will need the AuthBy DYNADDRESS 
in both the authentication and the accounting Handlers.

The easy way to do this is to define your AuthBy clauses separately with 
Identifiers, then use the Identifier to refer to the AuthBy clause.

# define AuthBy clauses

<AuthBy DYNADDRESS>
	Identifier AllocateIPAddress
	.....
</AuthBy>

<AuthBy SQL>
	Identifier SQLAccounting
	.....
</AuthBy>

<AuthBy SQL>
	Identifier SQLAuthentication
	.....
</AuthBy>

<Handler Request-Type = Accounting-Request, .....>
	AuthByPolicy ContinueAlways
	AuthBy SQLAccounting
	AuthBy AllocateIPAddress
	.....
</AuthBy>

<Handler .....>
	AuthByPolicy ContinueWhileAccept
	AuthBy SQLAuthentication
	AuthBy AllocateIPAddress
	.....
</AuthBy>


The answer to your second question is you will have to use a ReplyHook in the 
AuthBy RADIUS clause to check the reply attributes (and adjust if neccessary) 
and call the AuthBy DYNADDRESS clause if required.

There is an example of a hook that does this in the file "goodies/hooks.txt".

regards

Hugh


On Tue, 26 Mar 2002 13:25, Hugh Irvine wrote:
> Hello Leon -
>
> In your case I would add an additional Handler that looks for the
> Framed-IP-Address and then add a StripFromRequest to the Handler.
>
> regards
>
> Hugh
>
> On Tue, 26 Mar 2002 07:42, Leon Oosterwijk wrote:
> > Hugh,
> >
> >
> > Will using the separate handlers for Accounting and authentication still
> > clear the state on addresses in the RADPOOL table? Or would I need to put
> > my authBy DYNADDRESS In both the accounting and authentication handler?
> >
> > I was able to implement the solution below by using AuthByGroup. The only
> > problem I ran into with the AuthBy DYNADDRESS is that this AuthBy Handler
> > returns ACCEPT if it detects that the request packet already has a
> > Framed-IP-Address set. This behaviour that not what I wanted because I
> > wanted my downstream Radius servers to not have to change anything in
> > their setup. They were passing Framed-IP-Address=255.255.255.254 for
> > dynamically assigned addresses and Framed-IP-Address=10.10.10.10 for
> > static customers. I did not want to lose this functionality to I made a
> > modification to the AuthDYNADDRESS.pm Perm Module.
> >
> > Here's the Diff:
> >
> > 187,188c187,191
> > <       return ($main::ACCEPT) # Do nothing
> > <           if $rp->get_attr($self->{MapAttribute}{yiaddr});
> > ---
> >
> > >        return ($main::ACCEPT) # Do nothing
> > >         # ALTER: BY LEON Oosterwijk March 2002 to only ACCEPT if ip
> > > Addres
> >
> > attribute is there and is not dynamic
> >
> > >             if $rp->get_attr($self->{MapAttribute}{yiaddr}) ne
> >
> > "255.255.255.254" &&
> >
> > >               $rp->get_attr($self->{MapAttribute}{yiaddr}) ne "";
> >
> > As you can see the routine now only returns ACCEPT if the yiaddr
> > attribute is not only there, but is set to an address other than
> > 255.255.255.254.
> >
> > This seems to work quite nicely. The only potential problem is that reply
> > packets could have Framed-IP-Address set twice. Our Ascend MAX TNT units
> > only listen to the last occurance of an attribute to this works nicely.
> >
> >
> > <Handler Realm=ippool.isdn.net>
> >         RewriteUsername      s/^([^@]+).*/$1/
> >         RewriteUsername   tr/A-Z/a-z/
> >         AuthByPolicy ContinueWhileAccept
> >                 <AuthBy SQL>
> >                    . . . #authentication
> >                 </AuthBy>
> >         <AuthBy GROUP>
> >                 AuthByPolicy ContinueAlways
> >                 # this always returns reject
> >                 <AuthBy SQL>
> > 			 . . . # Accounting
> >                 </AuthBy>
> > 		   # this always returns accept (unless no more addresses in
> > pool)
> >                 <AuthBy DYNADDRESS>
> > 			 . . .
> >                 </AuthBy>
> >         </AuthBy>
> > </Handler>
> >
> >
> >
> > Sincerely,
> >
> > Leon Oosterwijk
> > ISDN-NET Inc.
> > www.isdn.net
> > +1 615-221-4200
> >
> > > -----Original Message-----
> > > From: Hugh Irvine [mailto:hugh at open.com.au]
> > > Sent: Monday, March 25, 2002 2:01 PM
> > > To: Leon Oosterwijk; 'radiator at open.com.au'
> > > Subject: Re: (RADIATOR) Three Authby Clauses and why they don't work
> > >
> > >
> > >
> > > Hello Leon -
> > >
> > > It is *much* easier to do this sort of thing with separate
> > > Handlers for
> > > authentication and accounting.
> > >
> > >
> > > <Handler Request-Type = Accounting, Realm=ippool.isdn.net>
> > > 	# do accounting
> > > 	.....
> > > </Handler>
> > >
> > > <Handler Realm=ippool.isdn.net>
> > > 	# do authentication
> > > 	.....
> > > </Handler>
> > >
> > > ......
> > >
> > > regards
> > >
> > > Hugh
> > >
> > > On Tue, 26 Mar 2002 02:24, Leon Oosterwijk wrote:
> > > > Hugh,
> > > >
> > > > I'm trying to set up the address allocation by using Radiator. I'm
> > > > running into the following problem. The goodies directory indicates
> > > > that the authby DYNADDRESS needs to be the last authby handler in a
> > > > realm. This however causes problems for me.
> > > >
> > > > In the setup showed below the accounting needs to go to one
> > >
> > > database,
> > >
> > > > while the auth happens in a different database. This means that the
> > > > original setup whas AuthByPolicy ContinueAlways. This will
> > >
> > > not work if
> > >
> > > > the DynAddress is the last auth by clause because the result would
> > > > always be an accept. However if it say continueWhileAccept
> > >
> > > the first
> > >
> > > > AuthBySQL, the one that just does accounting will return access
> > > > denied, and that is the end of the processing. What can be
> > >
> > > done to fix
> > >
> > > > this problem?
> > > >
> > > > Concider the following AuthBy clause
> > > >
> > > > #*******************************************************************
> > > > # TEST - leon's ip pool test ippool.isdn.net
> > > > #*******************************************************************
> > > > <Handler Realm=ippool.isdn.net>
> > > >         RewriteUsername   s/^([^@]+).*/$1/
> > > >         RewriteUsername   tr/A-Z/a-z/
> > > > #       AuthByPolicy ContinueAlways
> > > >         AuthByPolicy ContinueWhileAccept
> > > >
> > > >
> > > >                 <AuthBy SQL>
> > > >                         # Adjust DBSource, DBUsername,
> > >
> > > DBAuth to suit
> > >
> > > > your DB
> > > >                         DBSource
> > >
> > > dbi:dbtype:dbname:host=10.10.10.10
> > >
> > > >                         DBUsername      user
> > > >                         DBAuth          pass
> > > >                         FailureBackoffTime  60
> > > >                         # Empty Auth Select because this AuthBy is
> > > > only for Accounting
> > > >                         AuthSelect
> > > >                         #We only want stop records
> > > >                         AccountingStopsOnly
> > > >                         # You may want to tailor these for your
> > > > ACCOUNTING table
> > > >                         AccountingTable ACCOUNTING
> > > >                         AcctColumnDef   USERNAME,User-Name
> > > >                         AcctColumnDef   TIME_STAMP,Timestamp,integer
> > > >                         AcctColumnDef
> > > > ACCT_DATE,Timestamp,formatted-date,'%Y-%m-%d'
> > > >                         AcctColumnDef
> > > > ACCT_TIME,Timestamp,formatted-date,'%H:%M:%S'
> > > >                         AcctColumnDef
> > >
> > > ACCTSTATUSTYPE,Acct-Status-Type
> > >
> > > >                         AcctColumnDef
> > > > ACCTDELAYTIME,Acct-Delay-Time,integer
> > > >                         AcctColumnDef
> > > > ACCTINPUTOCTETS,Acct-Input-Octets,integer
> > > >                         AcctColumnDef
> > > > ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
> > > >                         AcctColumnDef
> > >
> > > ACCTSESSIONID,Acct-Session-Id
> > >
> > > >                         AcctColumnDef
> > > > ACCTSESSIONTIME,Acct-Session-Time,integer
> > > >                         AcctColumnDef
> > > > ACCTTERMINATECAUSE,Acct-Terminate-Cause
> > > >                         AcctColumnDef   NASIDENTIFIER,NAS-IP-Address
> > > >                         AcctColumnDef   NASPORT,NAS-Port,integer
> > > >                         AcctColumnDef
> > >
> > > FRAMEDIPADDRESS,Framed-IP-Address
> > >
> > > >                         AcctColumnDef
> > > > DisconnectCause,Ascend-Disconnect-Cause,integer
> > > >                         AcctColumnDef
> > > > ConnectProgress,Ascend-Connect-Progress,string
> > > >                         AcctColumnDef
> > >
> > > CallingStationId,Calling-Station-Id
> > >
> > > >                         AcctColumnDef
> > >
> > > CalledStationId,Called-Station-Id
> > >
> > > >         </AuthBy>
> > > >
> > > >                 <AuthBy SQL>
> > > >                         # Adjust DBSource, DBUsername,
> > >
> > > DBAuth to suit
> > >
> > > > your DB
> > > >                         DBSource        dbi:dbtype:dbname
> > > >                         DBUsername      user
> > > >                         DBAuth          pass
> > > >                         # The SQL SELECT statement to fetch
> > >
> > > the right
> > >
> > > > data from the Mysql DB
> > > >                         AuthSelect select PASSWORD, CHECKATTR,
> > > > REPLYATTR from SUBSCRIBERS where USERNAME='%n'
> > > >                         AuthColumnDef 0, User-Password, check
> > > >                         AuthColumnDef 1, GENERIC, check
> > > >                         AuthColumnDef 2, GENERIC, reply
> > > >                         AddToReply
> > >
> > > Ascend-Shared-Profile-Enable =
> > >
> > > > Shared-Profile-Yes
> > > >                 </AuthBy>
> > > >
> > > >         # AuthBy DYNADDRESS needs to be the last AuthBy. If
> > > >         # all the previous ones have succeeded, then an address
> > > >         # is allocated
> > > >         <AuthBy DYNADDRESS>
> > > >                 # This refers to the AddressAllocator
> > > >                 # defined below. IT says tyo us that allocator
> > > >                 # to get an address. Insterad ofg this, you can
> > > >                 # put the <AddressAllocator xxx> clause directly
> > > >                 # in here
> > > >                 Allocator PoolAllocator
> > > >
> > > >                 # This specifies how to form the pool hint, that
> > > >                 # the allocator uses to specifiy which pool
> > > >                 # to allocate an address from. The default
> > > >                 # is %{Reply:PoolHint}, ie a pseudo
> > > >                 # attribute in teh current reply,
> > > >                 # presumably set by an earlier
> > > >                 # AuthBy, but it could be for example
> > > >                 # the NAS IP address or similar, or a hardwired
> > > >                 # string.
> > > >                 #PoolHint %{Reply:PoolHint}
> > > >                 # hard code the pool hint.
> > > >                 PoolHint 1
> > > >
> > > >                 # These parameters tell us how to set reply
> > > >                 # attribtues from the result of the allocation.
> > > >                 # The left hand side of each pair is
> > > >                 # the "name" of the data item. The right hand
> > > >                 # side is the Radius attribute name to use
> > > >                 # in the reply. The valid data item names are:
> > > >                 # yiaddr - The allocated address
> > > >                 # subnetmask - The subnet mask to use
> > > >                 # dnsserver - the IP address of the DNS server
> > > >                 # The defualt mappings are:
> > > >                 #MapAttribute   yiaddr, Framed-IP-Address
> > > >                 #MapAttribute   subnetmask, Framed-IP-Netmask
> > > >
> > > >                 # The AuthBy FILE above sets the pseudo
> > >
> > > reply attribute
> > >
> > > >                 # PoolHint as the clue to the address allocator
> > > >                 # need to strip it out at the end of processing
> > > >
> > > >                 #StripFromReply PoolHint
> > > >                 # do not need to strip. we never added the poolhint
> > > >
> > > >         </AuthBy>
> > > > </Handler>
> > > >
> > > >
> > > > Sincerely,
> > > >
> > > > Leon Oosterwijk
> > > > ===
> > > > 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.
> > >
> > > --
> > > 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 radiator-announce at open.com.au
> > To unsubscribe, email 'majordomo at open.com.au' with
> > 'unsubscribe radiator' in the body of the message.

-- 
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 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