Hello Charles -
Your understanding of "DefaultRealm" is incorrect. The "DefaultRealm" is only
added to usernames with _no_ realm present in the request, which of course
will never be the case with IPass (by definition IPass users all have realms,
otherwise the request would never get to you).
BTW - I would check with IPass to see why they are sending you requests for
"[EMAIL PROTECTED]", if you have only specified "[EMAIL PROTECTED]".
I would suggest you use a RewriteUsername in the Client clause to always
force the correct realm.
# define IPass client
<Client ....>
RewriteUsername s/^([^@]+).*/$[EMAIL PROTECTED]/
.....
</Client>
Have a look at section 6.5.2 in the Radiator reference manual.
regards
Hugh
On Friday 10 August 2001 08:00, Charles Sprickman wrote:
> Hi,
>
> We just got a big IPass bill for a user that's not 'enabled' for IPass.
>
> The way I'm forcing IPass users into a particular handler goes like so:
>
> # client for IPASS
> <Client 216.223.192.x>
> Secret
> DefaultRealm roam.inch.com
> </Client>
>
> I assume this means that any request coming from the IPass server is
> re-written to be "[EMAIL PROTECTED]", regardless of what the user has
> entered as a realm.
>
> A handler farther down for the realm:
>
> <Handler Realm=roam.inch.com>
> # you have to get rid of everything after the @
> RewriteUsername s/^([^@]+).*/$1/
>
> SessionDatabase SDB_mysql
> # set high as IPass seems to drop acct-stops
> MaxSessions 3
>
> AuthByPolicy ContinueWhileReject
>
> # stick the accounting records in their own table
> # for now, run scripts to look for big usage, mail
> # daily usage summary, etc.
> AuthBy SQL_acctonly_ipass
> AuthBy Ipass_User
>
> # call an external program to open up mail relaying for
> # this user
> PostAuthHook file:"%D/pop-auth.pm"
>
> </Handler>
>
> The AuthBy Ipass_User:
>
> # This defines which Unix groups are allowed to dial via IPass.
>
> <AuthBy FILE>
> Identifier Ipass_User
> Filename /usr/local/etc/radiator/users_ipass
> </AuthBy>
>
> My assumption here is that anything coming from the IPass client (which is
> just a box running their server that relays auth to them) will be tagged
> with the realm "roam.inch.com", but it's not. The user specified the
> realm "inch.com", which does exist, and passed right on to the handler for
> the "inch.com" realm and got in. There's no trace of them in our seperate
> accounting-only db that the "roam.inch.com" handler uses.
>
> I'll note that if the user does enter "roam.inch.com" as the realm,
> everything works as expected. If the user doesn't have an entry in the
> ipass users file, they are rejected. If they do, they are allowed in.
>
> Is the "DefaultRealm" Client clause broken? Or am I just going about this
> the completely wrong way?
>
> This is radiator 2.18.2.
>
> Thanks,
>
> Charles
>
> | Charles Sprickman | Internet Channel
> | INCH System Administration Team | (212)243-5200
> | [EMAIL PROTECTED] | [EMAIL PROTECTED]
>
> ===
> Archive at http://www.open.com.au/archives/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.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
