Hi Hugh,

        The AuthByDynaddress is for a different realm, thats why it is
placed where it is. This RADIUS server is acting as a primary for our
service and as a "proxy" for a VISP scenario. We only want to allocate the
DYNADDRESS stuff to the VISP, not us, our NAS allocates our users the
right IP addresses. Does this clear up the *confusion*/ :)

        Thanks


On Tue, 20 Jun 2000, Hugh Irvine wrote:

> 
> Hello Dean -
> 
> On Mon, 19 Jun 2000, Dean Brandt wrote:
> > Hi Hugh,
> > 
> >     I am trying to Auth from a standard RADIUS users file and allocate
> > those users an IP address from a nominated pool.
> > 
> >     Here is the whole cfg file:
> > 
> > LogDir /var/log/radius
> > 
> > 
> > # Set this to the database directory. It should contain these files:
> > # users           The user database
> > # dictionary      The dictionary for your NAS
> > DbDir /etc/raddb/
> > 
> > # This clause defines a single client to listen to
> > <Client xxx.xxxx.xxx.xxx>
> >         Secret xxxxxxx
> >         NoDefault
> >         IgnoreAcctSignature
> > </Client>
> > 
> > # For testing: this allows us to honour requests from radpwtst 
> > # on the same host.
> > <Client localhost>
> >         Secret xxxxxxxxx
> >         DupInterval 0
> > </Client>
> > 
> > <AddressAllocator SQL>
> >          Identifier xxx
> > 
> >          DBSource        dbi:mysql:radius
> >          DBUsername      xxx
> >          DBAuth          xxxxxxx
> > 
> >          <AddressPool pool1>
> >                  Subnetmask      255.255.255.0
> >                  Range   203.44.90.130 203.44.90.134
> >          </AddressPool>
> >          </AddressAllocator>
> > 
> > <Log SYSLOG>
> >         Facility radius
> >         Trace 4 
> > </Log>
> > 
> > # This clause handles all users from all realms by looking them up
> > # in the users file at /usr/local/etc/raddb/users
> > <Realm DEFAULT>
> >         <AuthBy GROUP>
> >         AuthByPolicy ContinueWhileReject
> >         
> >         <AuthBy FILE>
> >                  #The filename defaults to %D/users     
> >                 </AuthBy>
> >         
> >                 <AuthBy UNIX>        
> >                 Filename /etc/shadow
> >                 FramedGroup 0
> >                 </AuthBy>
> >         </AuthBy>
> > </AuthBy>
> >         # Log accounting to the detail file in LogDir
> >         AcctLogFileName %L/detail
> > </Realm>
> > 
> > <Realm xxx.xxx.xxx>
> >         RewriteUsername s/^([^@]+).*/$1/
> >         <AuthBy RADIUS>
> >                 Host xxx.xxx.xxx.xxx 
> >                 Secret xxxxxxxx
> >         </AuthBy>
> >         AcctLogFileName %L/detail.xxx
> >         
> >          <AuthBy DYNADDRESS>
> >                  Allocator xxx
> >                  PoolHint %{Reply:PoolHint}
> >                 StripFromReply PoolHint                 
> >        </AuthBy>
> > 
> > </Realm>
> 
> As mentioned in my previous message, you appear to have your AuthBy FILE in one
> Realm, and your AuthBy DYNADDRESS in a different Realm. If you want to
> dynamically allocate addresses for the users in the users file, you would do
> something like this:
> 
> # This clause handles all users from all realms by looking them up
> # in the users file at /usr/local/etc/raddb/users
> <Realm DEFAULT>
> 
>       AuthByPolicy ContinueWhileAccept
> 
>       <AuthBy FILE>
>               #The filename defaults to %D/users     
>       </AuthBy>
> 
>       <AuthBy DYNADDRESS>
>               Allocator xxx
>               PoolHint %{Reply:PoolHint}
>               StripFromReply PoolHint                 
>       </AuthBy>
> 
>       # Log accounting to the detail file in LogDir
>       AcctLogFileName %L/detail
> 
> </Realm>
> 
> 
> The above configuration will check the user in the users file and if accepted
> will continue on to allocate an IP address.
> 
> hth
> 
> Hugh
> 
> 
> 

-- 

Dean Brandt

Technical Director
Cain Internet Services Pty Ltd
ACN 091949405
Ph 61-3-95231065
Satellite Access - $29.95 - no limits


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

Reply via email to