(RADIATOR) Orinoco wireless Access Points

[Hugh Irvine]

Hello Bon -

On Sunday, September 22, 2002, at 10:02 AM, Mike McCauley wrote:

> Hello Bon,
>
> On Sat, 21 Sep 2002 23:10, Bon sy wrote:
>> 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.
>
> We tested here with AP-2000. We have added some information to the 
> Radiator
> FAQ about how to set up the client, AP-2000 and Radiator to work with 
> Dynamic
> WEP.
>
> EAP-Message contains encoded EAP data that is exchanged between the 
> client and
> Radiator during authenticaiotn. Message_Authenticator is an 
> authenticator
> that proves that EAP-Message has not been tampered with.
>
>
>>
>> 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?
>
> Ill leave this one for Hugh.
>

There are several questions here.

For the first one, you can use Identifiers in your Client clauses and 
set up Handers to look at them.

Ie.

# define Client clauses with Identifiers

<Client ....>
	Identifier SomeThing
	....
</Client>

<Client ....>
	Identifier SomeThing
	....
</Client>

<Client ....>
	Identifier OrOther
	....
</Client>

.....

The same Identifier can be used in more than one Client clause to form 
groups as required.

Then you can use Handlers:

# define Handlers

<Handler Client-Identifier = SomeThing>
	.....
</Handler>

<Handler Client-Identifier = OrOther>
	.....
</Handler>

  .......


For multiple databases, you simply need to define them in the AuthBy 
SQL clause like this:

# define AuthBy SQL

<AuthBy SQL>
	Identifier CheckSQL

	# first database
	DBSource ....
	DBUsername .....
	DBAuth .....

	# second database
	DBSource ....
	DBUsername .....
	DBAuth .....

	.....
</AuthBy>

Note that all of these topics are covered in the Radiator 3.3.1 
reference manual ("doc/ref.html"), and almost all questions have been 
dealt with at least once on the mailing list already, and you should 
check the archive site and do a search.

	http://www.open.com.au/archives/radiator

Also note that we are available on a contract basis for custom 
installations, configuration and training.


>
>>
>>
>>
>> 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.
>
> Hmmm, some types of DBD interface support environment variables to 
> determine
> that database to use (Im thinking of Oracle). But in the final 
> analysis, the
> data is in a file somewhere. If you are concerned about that 
> informaiton, I
> think you should set up your file permissions to suit.
>

In general, your database and administrative equipment should be behind 
a firewall, and rather than running SQL accross the firewall with DB 
information outside, it is usually preferable to proxy the radius 
requests across the firewall to an instance of Radiator running inside.

regards

Hugh


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