Chapter 7 - User Authentication Methods; Proxy Services And Authentication Methods; Which Method Should You Choose - Multitech RouteFinder RF850 User Manual

Chapter 7 – User Authentication
While you can restrict access of your internal clients to proxy services at the IP level by using packet filter rules,
you will run into problems when you use a dynamic IP configuration protocol like DHCP or BOOTP internally.
That's where Proxy User Authentication steps in. Here, clients must authenticate themselves to the proxy
service with a username and password, making it possible to limit access by-person instead of by-IP address. In
addition, it will also be possible to do "per-user" accounting, for example, in the HTTP proxy access logs.

Proxy Services and Authentication Methods

The RouteFinder currently includes two proxy applications: SOCKS5 and HTTP. Both of these proxies can be
configured to accept all clients (access control based on IP addresses) or only clients providing a valid
username and password (User Authentication). If you select to use User Authentication for either of these proxy
services, you must select a method for the RouteFinder to validate the supplied credentials. The RouteFinder
currently supports User Authentication against:
•
A RADIUS server configured in Administration > User Authentication > Radius & SAM
•
An NT SAM User Base configured in Administration > User Authentication > Radius & SAM
•
Users defined in Administration > User Authentication > Local
RADIUS User Authentication
With this method, ASL will forward User Information to a RADIUS server. RADIUS is a protocol typically
used to authenticate and account Dialup Users for Remote Access. However, the protocol is very flexible
and RADIUS servers are available for almost every operating system.
The RouteFinder's implementation of the RADIUS method allows you to configure access rights on both a
per-proxy and a per-user basis.
NT SAM (SMB) User Authentication
This method uses a Microsoft Windows NT/2000 domain controller to validate user accounts. Many
companies already run NT/2000 networks based on Microsoft NT or Windows 2000 Active Directory
Domain concepts. The advantage of this method is that it is very easy to set up if you already run a PDC
(Primary Domain Controller) on your network. The disadvantage is that only a "flat" authentication model
is supported, meaning that either ALL or NONE of the existing users in the NT Domain will be allowed to
use a proxy service (meaning that you cannot differentiate between User A and User B).
Local RouteFinder User Authentication
This method does not need an external server to validate user accounts. You can add users with the
RouteFinder's Web front end and specify the allowed proxy types on a "per-user" basis.

Which Method Should You Choose?

This section provides possible scenarios that can help you decide which method of user authentication is
the right one for your implementation of the RouteFinder.
Scenario 1: "Just a couple of Windows boxes"
You are running a small peer-to-peer network without a domain controller or other centralized
authentication. This will typically be a SOHO or "family home" network.
You should use "Local" ASL user authentication.
Scenario 2: "Microsoft-style Windows Network with all valid users able to use proxy services"
You are running a Windows Domain controller or a standalone server on your network, holding User
Accounts. Typically, this is also the case if you are running MS Exchange on your network and you want
every valid user to be able to use the proxy services.
You should use NT SAM (SMB) user authentication.
Multi-Tech Systems, Inc. RouteFinder RF850/860 User Guide (PN S000400E)
Methods
Chapter 7 – User Authentication Methods
139