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
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.
Authentication Setup
Choose one of the following setup methods.
Setting Up RADIUS Authentication
To set up RADIUS Authentication, first you need a RADIUS server on your network. The server can be anywhere on the Internet, but keep in mind that passwords are transferred in clear text. Therefore, we strongly recommend putting the RADIUS server somewhere near your RouteFinder and to use a switched Network hub to connect them.
Choosing the RADIUS server is up to you. Below is some generic setup information. The RouteFinder will send a RADIUS authentication packet with three fields:
1. Username
2. Password in plain text (PAP)
3. The proxy type ("http" or "socks") in the NAS-Identifier field based on these values, your RADIUS server should just decide to grant or deny access.
Setting Up a Microsoft IAS RADIUS Server
This section explains how to set up a Microsoft IAS (Internet Authentication Server). IAS is delivered with all Windows 2000 Server versions. However, it is often not installed by default.
1. Check if the IAS service is installed. If not, follow the rest of these steps.
2. Using 2000 User Manager, edit User Profiles of those users who have rights to proxy services. Set the "Dial-In Permission" flag. This is necessary since IAS uses the "master flag" to respond to requests positively.
3. Create a new user group for each proxy service you wish to provide to your users. For clarity, give the groups descriptive names (for example, call the group "multitech _http_users").
4. Put the users in the newly created groups for using the respective proxy services.
5. Enter the IAS administration interface at Start > Programs > Administrative Tools > Internet
Authentication Service and add a new client using these settings:
Friendly Name: routefinder Protocol: RADIUS
Client Address: Use the address of the RouteFinder's interface pointing "towards" the RADIUS server (this will be the "internal" interface for most people). Client Vendor: RADIUS Standard. Uncheck the Client must always send signature
attribute box.
Select a shared secret. This is needed for the RouteFinder configuration. 6. Go to the policy list. There is one pre-defined entry. Delete it. Add a new Policy for each proxy
service you wish to provide to your users. Choose a "Friendly Name" (i.e.; "SOCKS access"). 7. On the next screen, add two conditions:
• NAS-Identifier matches <string> (where <string> is the proxy identifier ("socks" or "http"). • Windows-Groups matches <yourgroup> (where <yourgroup> is one of the newly created
user groups).
Note: You can add groups from the local machine or from Domains in which the RADIUS server is a member. Specify the user name as <DOMAIN>\<USER> for authentication to succeed, if required.
8. Choose Grant Remote Access Permission in the next screen.
9. Edit the profile on the next screen. Select the Authentication Tab. Check Unencrypted Authentication (PAP).
10. Click OK and Finish. Remember you need one policy for each proxy service.
11. Configure the RADIUS authentication method on the RouteFinder (use the IP of the IAS server and the shared secret). Use the RADIUS authentication method settings in User Authentication > RADIUS & SAM.
12. Check the System Log in the NT/2000 Event Viewer; that's where NT/2000 puts information about RADIUS authentication requests.
Setting Up NT/2000 SAM (SMB) Authentication
To setup Windows NT/2000 SAM Authentication, you will need an NT/2000 machine on your network that holds the user accounts. This can be a domain controller (PDC) or a simple standalone server. The server has a NETBIOS name (the NT/2000 server name) and an IP address.
Put these values in the configuration of the NT SAM method in User Authentication > RADIUS & SAM as PDC Name and PDC address. If you have a Backup domain controller, also enter its corresponding values in User Authentication > RADIUS & SAM.
Finally, you need the default domain to authenticate against. This will be overridden if users specify their user name as <DOMAIN>\<USERNAME>. Otherwise, it will be filled in as the <DOMAIN> part.
Caution: Disable the Guest account of your NT domain, since this one will allow Any username/password combination to pass!