Novell BorderManager Proxy
Session Failover with BorderManager 3.8.4
How Session Failover Works
Load-Balancing the BorderManager Proxy
Network Diagram Information
Configuring the HTTP Service on the BorderManager Proxy
Configuring Auth Agent
Starting Auth Agent
Configuring the Proxy for Session Failover
Starting Proxy Agent
Configuring the L4 Switch
Verifying the Setup
When a large number of authenticated users access the BorderManager Proxy service on multiple proxy servers, it becomes important to optimize the usage of the proxy servers. Traditionally, each BorderManager proxy kept record of authenticated users and did not share the information with other proxies. With the introduction of session failover feature on BorderManager 3.8.4, it is now possible for the proxy to share the authenticated user information with other BorderManager proxies configured in the system.
This Appnote uses this concept and provides the guidelines for deploying Novell BorderManager Proxy with load balancing capabilities to service a number of users. This solution relies on using a multiple BorderManager 3.8.4 server farm connected through a Layer-4 switch. It also uses the session failover feature of Novell BorderManager 3.8.4.
This AppNote is intended for those who want the following:
There are three main applications of the Novell BorderManager proxy: Forward, Reverse and Transparent. Novell BorderManager’s HTTP forward proxy is used by most organizations for providing Internet access to their employees. Forward proxy is one of the widely used features, because of its caching, authentication, and single-sign-on capabilities.
The Novell BorderManager proxy does not have built-in load balancing capabilities, except when deployed as a cluster. However, load balancing in a cluster scenario still requires users to re-authenticate when they switch proxies. Still, Novell BorderManager provides an advantage in the Cluster environment – the cached information will be available with the other nodes of the cluster. Once the re-authentication is complete, the new proxy node can service the web requests from the cache. Even though the caching information is shared with all the nodes in the cluster, the authentication information is not shared. Now with the release of BoderManager 3.8.4, the proxy can share the authentication information, using the session failover feature.
In the 3.8.4 version of Novell BorderManager a new feature has been added that provides the session failover capability. This feature allows multiple proxies to share the user’s authentication information. Whenever a user does login, logout or timeout from a proxy , that information is shared to other pre-configured proxies through an agent. This arrangement enables a user to switch to another proxy during the Internet Access session.
This solution has two components: Auth Agent and Proxy Agent. There is generally one Auth Agent configured in the system and a Proxy Agent configured at each BorderManager proxy. All the entities share a similar configuration file that defines the Auth Agent and all proxy agents in the system.
Auth Agent is a central entity that collects information from multiple proxy agents and distributes the same to all other proxy agents. This ensures sharing of authentication information among all proxies that are configured to use the Auth Agent. Even if the user has authenticated to only one proxy, that information would be shared with all other configured proxies. Auth Agent is a java application that can be deployed either on NetWare or Linux server.
Proxy Agent is the new authchk.nlm, running in each of the proxy servers configured for Session failover. Proxy Agents run on each BorderManager proxy server and have the responsibility to inform Auth Agent about every user login, logout, or timeout. Whenever a similar event happens at any other proxy, the auth agent forwards the information to each proxy where a Proxy Agent is configured. The Proxy Agent updates the local authenticated user’s table on receiving the information from the Auth Agent.
Prior to Novell BorderManager 3.8.4 (i.e., the session failover feature), it was not possible to provide transparent load balancing for proxy servers. As mentioned earlier, a proxy deployed on clusters could provide failover, but it is not transparent and the user must re-authenticate to the newly switched proxy. With the introduction of the session failover feature, now all the proxies in the deployed network can be configured to share authentication information. This has made it possible to use load balancing for BorderManager proxy servers.
To provide load balancing capabilities, an L4 switch is configured to distribute the load among different proxies. Novell Border Manager proxies are configured behind the L4 switch. The proxy server is configured with the session failover feature for sharing authentication information.
Figure 1 shows the sample setup used for the purpose of this AppNote. Details on the setup are described in Section 5.2. In the proposed load balancing solution, a typical sequence of interaction between users, L4 switch, Novell BorderManager Proxy (Proxy Agent) and Auth Agent is described below.
Here’s the process:
1. The User authenticates via the L4 switch to any of the proxies (as selected by the L4 switch).
2. Once the authentication is successful, the proxy sends the authentication information to the Auth Agent, which in turn distributes it to other proxies in the setup.
3. After successful authentication, even if the L4 switch sends the subsequent HTTP request to other proxies, that proxy would be able to service the request without asking user to re-authenticate.
4. If for some reason the connectivity to any of the proxy is down, the L4 switch will forward the client requests to another proxy in the setup so the request can be serviced.
5. In the event of user logout or user authentication timeout the information is propagated to all the proxies through the Auth Agent (as in Step 2).
Figure 1 – Network Diagram for Load Balancing Setup
Below are the details of the network setup as shown in Figure 1.
Proxy (BorderManager Server)
All NBM servers are configured with forward HTTP proxy and authentication enabled. These servers have the private interface in the 10.x.x.x network and public interface in the 192.168.10.x network.
Brand: Dell Power Edge 2650 series
Processor: Intel xeon 1.8 Ghz
RAM: 2 GB
The L4 switch is configured for load balancing among three proxy servers. It is in the same network as clients and the private interface of BorderManager servers. For this setup, it also provides connectivity between the proxy and the Auth Agent.
Brand: Alteon 184 series
OS Version: 10.0.32.1
Processor: Intel Pentium 4
RAM: 1 GB
To configure the Border Manager server for Forward Proxy, use the following link, which provides detailed information:
For configuring Authentication for Forward Proxy use the following link:
Note: Configure the same Idle Timeout value on all proxies that are doing load balancing.
Auth Agent can be configured on Netware or Linux servers; this AppNote deals with Linux. To configure the Auth Agent,
1. Create auth.cfg in /etc/proxy directory (SYS:/ETC/PROXY/ for NetWare).
2. Copy bmauth.jar to the system where the Auth Agent is being configured.
3. Create auth.cfg in /etc/proxy directory (SYS:/ETC/PROXY/ for NetWare). You can copy a sample auth.cfg file to the /etc/proxy folder from the SYS:/ETC folder of the BorderManager Server.
4. Modify the file as per your setup.
Auth Agent and Proxy Agent should be able to contact each other. Choose the proxy interface in the same network as the Auth Agent.
For example, the auth.cfg file for the setup in Figure 1 would look like this:
Figure 2 – auth.cfg file for Auth Agent
In the above sample configuration 1, 2 and 3 are unique proxy IDs for Proxy Agent-1(10.10.1.1), Proxy Agent-2(10.10.1.2) and Proxy Agent-3 (10.10.1.3). 10.10.1.5 is the IP address of the server where Auth Agent is running.
Java must be installed on your server where Auth Agent is configured. Use the following command to start Auth Agent:
java -classpath <full_path_of_bmauth.jar> com.novell.bordermanager.proxy.auth.AuthDB
The trust between Proxy Agent and Auth Agent is established by the configuration file. Proxy Agent also has a configuration file similar to the one configured for Auth Agent.
1. Before starting Proxy Agent, make sure that Auth Agent is configured and running.
2. Copy a sample auth.cfg file to SYS:/etc/proxy folder from SYS:/ETC folder of BorderManager Server. For example, the auth.cfg file for the first proxy server in the setup would look like this:
Figure 3 – auth.cfg file for proxy server
Again, in the above file note that 1, 2 and 3 are unique proxy IDs for Proxy Agent-1 (10.10.1.1), Proxy Agent-2 (10.10.1.2) and Proxy Agent 3(10.10.1.3). 10.10.1.5 is the IP address of the server where Auth Agent is configured.
Note: In both the auth.cfg files, each individual proxy agent for the local agent needs to add the value “localhost”.
On the Netware console of your BorderManager Proxy server, run stopbrd and startbrd after configuring the auth.cfg file. On restarting the BorderManager services, the proxy service starts with the Proxy Agent. The logger screen indicates that session failover is enabled.
Different L4 switches may be deployed in different implementations. In this section we discuss L4 configuration at a higher level. Users/administrators should configure the L4 switch deployed in their network as described below. Following are the steps for setup in this document (relating to Figure 1):
1. Add all the BorderManager proxy servers as “real servers” (proxies).
2. Configure the IP address and add a port for the service provided by each server. For this deployment, the ports are 8080 and 443.
3. Configure a group with three real servers configured in the above step. This group acts as a pool for load balancing.
4. Configure a Virtual Server with services provided for port 8080 and 443.
5. Attach the group created in step 3 to this virtual service, which enables the L4 switch to do load balancing among real servers.
6. Configure the load balancing algorithm to be used for distributing the load among all the proxies. For the purpose of this AppNote, the load balancing algorithm used was HASH (which binds clients to a specific server based on client’s IP).
Important: Note that the L4 switch provides various algorithms for load balancing. It includes load-based, round-robin, hash, and many more. When the L4 switch is configured with a round-robin or load-based algorithm the authentication requests themselves are distributed across multiple proxies. This may result in many security warning messages at the browser. The best choice of algorithm in this scenario could be “hash,” where each client is tied to only one server based on the client’s address.
1. Configure proxy setting for the browser at the client, using the L4 switch IP as as proxy address and the port configured as 8080.
2. Start an HTTP session from a client.
3. Observe through which proxy the user login occurs. Once you determine that, bring down that proxy server and initiate further HTTP requests. For new HTTP requests, the proxy should not ask for re-authentication.
Using these two capabilities – the L4 switch and BorderManager 3.8.4 session failover – you can add load balancing capabilities to BorderManager proxy to provide high availability.
Online Documentation for BorderManager Session Failover:
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.