Multi-Tech Systems RF600 ユーザーズマニュアル

Chapter 7 – User Authentication Methods 

Multi-Tech Systems, Inc. RouteFinderVPN RF760/660/600VPN User Guide (PN S000323D) 

130 

 

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. 

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 

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 including Microsoft Windows NT and 2000. 
The RouteFinder's implementation of the RADIUS method allows you to configure access rights on both a per-
proxy and a per-user basis. 

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

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. 

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. 

 

 

 

 

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. 

 

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.  

 

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, but not all of your users should be able to use 
proxy services. 

• 

You should use RADIUS user authentication with Microsoft's IAS (Internet Authentication Server).

You are running any other type of Network with a centralized user base.  

• 

In this case, you can use RADIUS user authentication; however, it is up to you to find a suitable RADIUS 
server for your network type. 

• 

You can also use the "Local" user authentication, but you must re-define all your users in the RouteFinder Web 
Front end. 

  Many mixed scenarios are also possible. For example, you could have some local users being able to use 

the SOCKS service, plus a RADIUS server authenticating users for the HTTP proxy service.