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.
