Hello John -
You would not use the "users" file.
hth
Hugh
On Saturday 28 April 2001 14:11, John Coy wrote:
> Hugh,
>
> In your example below, I'm unclear how I involve my "users"
> file (which contains the DEFAULT entries I'd like to assign
> authenticated users) -- that's why I have <AuthBy FILE>
> and in that file, I have the Auth-Type pointing to the
> appropriate authentication process.
>
> John
>
> At 12:15 PM 4/28/01 +1000, Hugh Irvine wrote:
> >Hello John, Hello Dave -
> >
> >The problem you are seeing has to do with the the differences between
> >multiple DEFAULT handling in a user file and multiple AuthBy clauses under
> >the control of an AuthByPolicy.
> >
> >In the case of multiple DEFAULT entries, these are only consulted in the
> > case of a Reject (or multiple Rejects), except when Fall-Through is used,
> > in which case it will go on to the next in the case of an Accept. There
> > is no provision for Ignore as you have discovered.
> >
> >The way to deal with Ignore is by using multiple AuthBy clauses under the
> >control of an AuthByPolicy ContinueWhileIgnore. In your case, you could
> >replace your AuthBy FILE, with an AuthBy GROUP:
> >
> ><Realm DEFAULT>
> > RewriteUsername tr/A-Z/a-z/
> > AuthByPolicy ContinueWhileIgnore
> >
> > AuthBy AuthANCIUsers
> ></Realm>
> >
> ><AuthBy GROUP>
> > Identifier AuthANCIUsers
> > AuthByPolicy ContinueWhileIgnore
> > AuthBy AuthSQLPasswd
> > AuthBy UNIX
> ></AuthBy>
> >
> ><AuthBy SQL>
> > Identifier AuthSQLPasswd
> >
> > DBSource dbi:Oracle:starship
> > DBUsername uname
> > DBAuth password
> >
> > AuthSelect SELECT password, checkattr, replyattr \
> > FROM passwd \
> > WHERE username = LOWER('%n')
> >
> > AuthColumnDef 0, Encrypted-Password, check
> > AuthColumnDef 1, GENERIC, check
> > AuthColumnDef 2, GENERIC, reply
> >
> > AddToReplyIfNotExist Ascend-Maximum-Channels = 1
> >
> > AccountingTable
> ></AuthBy>
> >
> ><AuthBy UNIX>
> > Identifier UNIX
> > Filename /usr/local/etc/shadow
> > GroupFilename /usr/local/etc/group
> >
> > AddToReplyIfNotExist Ascend-Maximum-Channels = 1
> ></Authby>
> >
> >
> >hth
> >
> >Hugh
> >
> >On Saturday 28 April 2001 03:04, John Coy wrote:
> >> It's my understanding that Fall-Through = yes is the default
> >> setting. However, I did try it and it still did not work.
> >>
> >> Thank you for your reply, however. I'm certain that I'm
> >> doing something wrong, but I know eventually I'll figure
> >> it out or someone will nudge me in the right direction.
> >>
> >> John
> >>
> >> At 01:02 PM 4/27/01 -0400, you wrote:
> >> >I'm not a whiz at using DEFAULT, but you might benefit from:
> >> >
> >> >13.2.6 Fall-Through
> >> >This attribute is not actually returned to the NAS. Its presence causes
> >> >Radiator to continue looking for a match with the next DEFAULT user
> >> > name.
> >> >
> >> > Fall-Through = yes
> >> >
> >> >http://www.open.com.au/radiator/ref.html#pgfId=330995
> >> >
> >> >Dave
> >> >
> >> > > -----Original Message-----
> >> > > From: John Coy [mailto:[EMAIL PROTECTED]]
> >> > > Sent: Friday, April 27, 2001 11:31 AM
> >> > > To: [EMAIL PROTECTED]
> >> > > Subject: Re: (RADIATOR) best technique to fallback to flat file if
> >> > > DB server not available
> >> > >
> >> > >
> >> > > I know it's wierd to reply to my own message, but I found
> >> > > something in the RADIATOR archives:
> >> > >
> >> > > [ From Mike McCauley ]
> >> > > 2. Chain a second authentication method after SQL, so that if
> >> > > SQL fails (and
> >> > > says IGNORE), it will then auth from (say) a local flat file:
> >> > >
> >> > > <Realm whatever>
> >> > > AuthByPolicy ContinueWhileIgnore
> >> > > <AuthBy SQL>
> >> > > # whatever
> >> > > </AuthBy>
> >> > > # If SQL fails, auth from flat file:
> >> > > <AuthBy FILE>
> >> > > Filename whatever
> >> > > </AuthBy>
> >> > > </Realm>
> >> > >
> >> > > However, this technique doesn't work if you have an arrangement
> >> > > similar to this one -- here, my default realm is authenticated
> >> > > using <Authby FILE>. Inside that file, I make references to
> >> > > several authentication methods, including <AuthBy SQL> and
> >> > > <AuthBy UNIX>. However, since the <AuthBy SQL> fails, it
> >> > > never gets to move on to the second DEFAULT. Not sure if this
> >> > > is intended to be this way, or if my config is just so messed
> >> > > up... anyhow, if there's a way to get it to move on to the next
> >> > > DEFAULT entry that's what I'd like to do....
> >> > >
> >> > > My radiusd.cfg (excerpts):
> >> > >
> >> > > -- radiusd.cfg --
> >> > > <Realm DEFAULT>
> >> > > RewriteUsername tr/A-Z/a-z/
> >> > > AuthByPolicy ContinueWhileIgnore
> >> > >
> >> > > AuthBy AuthANCIUsers
> >> > > </Realm>
> >> > >
> >> > > <AuthBy FILE>
> >> > > Identifier AuthANCIUsers
> >> > > Filename %D/users
> >> > > </AuthBy>
> >> > >
> >> > > <AuthBy SQL>
> >> > > Identifier AuthSQLPasswd
> >> > >
> >> > > DBSource dbi:Oracle:starship
> >> > > DBUsername uname
> >> > > DBAuth password
> >> > >
> >> > > AuthSelect SELECT password, checkattr, replyattr \
> >> > > FROM passwd \
> >> > > WHERE username = LOWER('%n')
> >> > >
> >> > > AuthColumnDef 0, Encrypted-Password, check
> >> > > AuthColumnDef 1, GENERIC, check
> >> > > AuthColumnDef 2, GENERIC, reply
> >> > >
> >> > > AddToReplyIfNotExist Ascend-Maximum-Channels = 1
> >> > >
> >> > > AccountingTable
> >> > > </AuthBy>
> >> > >
> >> > > <AuthBy UNIX>
> >> > > Identifier UNIX
> >> > > Filename /usr/local/etc/shadow
> >> > > GroupFilename /usr/local/etc/group
> >> > >
> >> > > AddToReplyIfNotExist Ascend-Maximum-Channels = 1
> >> > > </Authby>
> >> > > -- end radiusd.cfg --
> >> > >
> >> > > Then, inside the "users" file, you have a DEFAULT entry:
> >> > >
> >> > > -- users --
> >> > > DEFAULT Auth-Type = AuthSQLPasswd
> >> > > Ascend-Idle-Limit = 1800,
> >> > > Ascend-Assign-IP-Pool = 0,
> >> > > User-Service = Framed-User,
> >> > > Framed-Protocol = PPP,
> >> > > Ascend-Maximum-Call-Duration = 480,
> >> > > Ascend-Client-Primary-DNS = 208.133.27.10,
> >> > > Ascend-Client-Secondary-DNS = 216.152.26.168,
> >> > > Ascend-Client-Assign-DNS = DNS-Assign-Yes,
> >> > > Ascend-Shared-Profile-Enable = 0,
> >> > > Ascend-Multicast-Client = 1,
> >> > > Ascend-Multicast-Rate-Limit = 5
> >> > >
> >> > > DEFAULT Auth-Type = UNIX
> >> > > Ascend-Idle-Limit = 1800,
> >> > > Ascend-Assign-IP-Pool = 0,
> >> > > User-Service = Framed-User,
> >> > > Framed-Protocol = PPP,
> >> > > Ascend-Maximum-Call-Duration = 480,
> >> > > Ascend-Client-Primary-DNS = 208.133.27.10,
> >> > > Ascend-Client-Secondary-DNS = 216.152.26.168,
> >> > > Ascend-Client-Assign-DNS = DNS-Assign-Yes,
> >> > > Ascend-Shared-Profile-Enable = 0,
> >> > > Ascend-Multicast-Client = 1,
> >> > > Ascend-Multicast-Rate-Limit = 5
> >> > > -- end users --
> >> > >
> >> > > At 09:02 PM 4/26/01 -0500, you wrote:
> >> > > >What's the best technique to have Radiator fall back to
> >> > >
> >> > > authentication
> >> > >
> >> > > >via flat file (UNIX-style auth for example) instead of SQL
> >> > >
> >> > > database if the
> >> > >
> >> > > >SQL database isn't available.
> >> > > >
> >> > > >I tried using two DEFAULT entries in my users file, one which did
> >> > > > SQL auth, the other which did UNIX auth but that didn't work.
> >> > >
> >> > > Instead, it
> >> > >
> >> > > >fails to connect to the DB server and won't move on to the flat
> >> > > > file.
> >> > > >
> >> > > >Hints, tips welcome.
> >> > > >
> >> > > >John
> >> > > >
> >> > > >
> >> > > >===
> >> > > >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.
> >> > >
> >> > > ===
> >> > > 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.
> >>
> >> ===
> >> 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.
> >
> >--
> >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.starport.net/~radiator/
> >Announcements on [EMAIL PROTECTED]
> >To unsubscribe, email '[EMAIL PROTECTED]' with
> >'unsubscribe radiator' in the body of the message.
>
> ===
> 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.
--
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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
