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.
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 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.
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.
Scenario 3: "Microsoft-style Windows Network - not 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, 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).
Scenario 4: "Unix or Netware Network"
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.
Note: 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.