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.
