(RADIATOR) Orinoco wireless Access Points

[Bon sy]

Hi Mike, Hugh, and others,

	I have three questions. Please forgive me if some may look too
obvious since I am new to RADIUS:

1. In your test for the Orinoco product(s), did you test for AP-500 and
AP-1000? For the Orinoco APs, can you post the attributes to be passed to
RADIUS for authentication and the reply message (attributes)? In
particular, the test on 802.1X --- I am still not clear about the
"EAP_Message" and "Message_Authenticator". In any event, I wonder whether 
level 4/5 trace log output example will suffice to answer this question.

2. I wonder you or anyone in the list can help and/or comment the best way
to do the following:

	<NAS ADR_1>
	<NAS ADR_2>
	...
	<NAS ADR_k>

	<AuthBy Opt_1>
	<AuthBy Opt_2>
	...
	<AuthBy Opt_w>

	I would like NAS in ADR_1 to be authenticated through 
	<AuthBy Opt1>, and if it does not succeed, try <AuthBy Opt2>.
	For ADR_2, have it authenticated through <AuthBy Opt_w>, and if not
	successful, try <AuthBy Opt_1>, and if still not successful, then 
	<AuthBy Opt_2>.
	This situation will araise when RADIUS is running properly, but  
	the DB in one AuthBY fails, then we want RADIUS to use the DB in 
	an alternative site, thus switching to another AuthBy.

	My question is: What is the best way to set up the conf file for
			this situation?



3. When AuthBY SQL, is there a way not to expose the DB access
information? I am particularly concern the need of storing DB acccess
information in the conf file (and the Unix environment variable
such as ORACLE_USERID in the initialization file for Perl DBI). Since the
DB access will require more than just DML query, but also transaction
involving insert, update and delete, if RADIUS or conf file got
compromised, one will have all the information needed to do
damage on the DB side. 

	Thanks in advance!

Bon





On Sat, 21 Sep 2002, Mike McCauley wrote:

> Hello All,
> 
> We have just finished local testing of Radiator 3.1.1 with Orinoco AP-2000 
> Access Points. We tested successfully witha range of authentication methods, 
> wireless clients and platforms.
> 
> One important point to note is that successful interoperation with the Odyssey 
> TTLS client requires that the access point have the latest firware  
> v2.0.0(266).
> 
> Feedback to me.
> Cheers.
> 
> 
> -- 
> Mike McCauley                               mikem at open.com.au
> Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
> 24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
> Phone +61 3 9598-0985                       Fax   +61 3 9598-0955
> 
> Radiator: the most portable, flexible and configurable RADIUS server 
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
> TTLS etc on Unix, Windows, MacOS etc.
> 
> ===
> 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.
> 

===
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.