(RADIATOR) Client and DefaultRealm

[Hugh Irvine]

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 
"user at inch.com", if you have only specified "user at roam.inch.com".

I would suggest you use a RewriteUsername in the Client clause to always 
force the correct realm.

# define IPass client

<Client ....>
	RewriteUsername  s/^([^@]+).*/$1 at roam.inch.com/
	.....
</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 "user at roam.inch.com", 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
> | spork at inch.com                     | access at inch.com
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' 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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.