Hello Mike -
What are you doing currently with the DefaultRealm?
There are a number of ways to approach this problem, however I need a bit
more information about what else you are doing to know which way to go.
cheers
Hugh
On Thursday 01 March 2001 11:50, Mike Bacher wrote:
> We have a situation where we are outsourcing some ports to a third party
> provider. We have run in to an issue that I'm hoping someone might have
> some insight in to. We are using Radiator 2.16.3 with Oracle 8 as the
> backend. We pull the ClientList from SQL as well as use AuthSQL for
> authentication (with a slightly modified AuthEMERALD). We set a
> DefaultRealm per Client device, which works quite well with our current NAS
> devices. However, this same method will not work with our new third party
> provider because all requests come from their proxy RADIUS server. We are
> outsourcing ports in 3 locations with them, and since they send all
> requests (irregardless of location) from this same proxy RADIUS server, we
> can no longer, based on IP address of the Client, determine what
> DefaultRealm should be used (they are different for each location). In the
> Authenticion Request, they _do_ pass the NAS-IP-Address attribute for their
> NAS, which _is_ unique per location, but I don't see a way, in my current
> config, of using that attribute to base the DefaultRealm on. I thought
> about using a Handler, but I've read that you cannot use a Handler when you
> have a <Realm DEFAULT> statement.
>
> Below is our config file:
>
> Foreground
> LogStdout
> LogDir .
> DbDir .
> SnmpgetProg /usr/local/bin/snmpget
> # Disable logging to log file completely
> LogFile
>
> # Translate all uppercase to lowercase
> RewriteUsername tr/A-Z/a-z/
> # Strip leading spaces
> RewriteUsername s/^\s+//
> # Strip trailing spaces
> RewriteUsername s/\s+$//
>
> <ClientListSQL>
> DBSource dbi:Oracle:XXXX
> DBUsername XXXX
> DBAuth XXXX
> </ClientListSQL>
>
> <Realm DEFAULT>
> <AuthBy EMERALD>
> DBSource dbi:Oracle:XXXX
> DBUsername XXXX
> DBAuth XXXX
>
> AccountingTable RadUsage
> AcctColumnDef User_Name,User-Name
> AcctColumnDef Time,Timestamp,formatted-date,to_date('%D
> %T', 'MM/DD/YY HH24:MI:SS')
> AcctColumnDef NAS_IP_Address,NAS-IP-Address
> AcctColumnDef NAS_Port,NAS-Port,integer
> AcctColumnDef NAS_Port_Type,NAS-Port-Type
> AcctColumnDef Called_Station_ID,Called-Station-Id
> AcctColumnDef User_Caller_ID,Calling-Station-Id
> AcctColumnDef Acct_Status_Type,Acct-Status-Type
> AcctColumnDef Acct_Session_Id,Acct-Session-Id
> AcctColumnDef Framed_Address,Framed-IP-Address
> AcctColumnDef Acct_Terminate_Cause,Acct-Terminate-Cause
> AcctColumnDef Terminate_Detail,LE-Terminate-Detail
> AcctColumnDef Terminate_Detail,Ascend-Disconnect-Cause
> AcctColumnDef
> Acct_Input_Octets,Acct-Input-Octets,integer AcctColumnDef
> Acct_Output_Octets,Acct-Output-Octets,integer AcctColumnDef
> Acct_Session_Time,Acct-Session-Time,integer AcctColumnDef
> Connect_Speed,Connect-Info
> AcctColumnDef Connect_Speed,Ascend-Xmit-Rate
> AcctColumnDef Connect_Speed,USR-Connect-Speed
>
> # Permit case insensitive password checks
> CaseInsensitivePasswords
> NoDefault
> </AuthBy>
> </Realm>
>
> Without totally redoing the way we handle Realms, is there some way to
> accomodate this?
>
> --Mike
>
>
> ===
> 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.
