Using Active Directory authentication on your KEMP load balancer

Most IT pros use Active Directory and its seamless authentication process on their workstations and servers, as well as for general Microsoft applications (Exchange, Skype for Business, SharePoint, File Server, and so forth). In most of these scenarios, the user authenticates just once on the device, and then it is good to go on all other applications running on that session.

However, the vast majority of the IT environments are not made up of just Microsoft applications. We may end up with several components to manage, such as load balancers, switches, firewalls, anti-spam software, and appliances in general. In most of the cases, I noticed that the administrators keep local authentication on this type of device, which makes it more secure (sort of), but creates a pain to manage for several reasons:

• Hard to manage when you have several devices and they use different passwords.
• Using the same password or a similar password for all devices is not a security best practice.
• If the administrator leaves the company, then it is a manual process and it requires the knowledge of the current password. If the administrator was the only one who knew the password, and if he or she left on not so good terms, the new administrator may have a big problem.
• If you disable an account on Active Directory, the user still has access to some components of your infrastructure.

In this article, we are going over the process to configure a KEMP load balancer to rely on Active Directory in the authentication and authorization process. A KEMP load balancer is a device able to balance traffic among several applications. It can do a lot more, but for the purpose of this article we are going to use a simple environment as depicted in the image below.

By default, any KEMP will use the username bal and the initial password is 1fourall. A few things must be configured on the load balancer before we start configuring the Active Directory integration:

• Create an Active Directory group where the members of such group will be able to access the KEMP devices. For this tutorial we are going to use Network-CA-SWAdmins.
• Enable Session Management on the KEMP device: Click on Certificates & Security, Admin WUI Access and enable the checkbox Enable Session Management.
• The bal administrator and its password will never go away — they are local administrator of the KEMP. Make sure to define a strong password and save in an envelope in case you need it in the future, but do not share that password.

Step 1: Configuring RADIUS client

In this step we will configure the communication between KEMP and the NPS server.

The first step is to retrieve the IP that is going to be used by the KEMP to connect to the NPS server. In the diagram, we can see that is going to be 10.130.210.11; if you are not sure what the IP is, on the KEMP management console, expand System Configuration, Network Setup and click on the interfaces available eth0, eth1, and so forth.

The second step is to create a client in the NPS server. While logged on the Network Policy Server console, expand RADIUS Clients and Servers, right-click on RADIUS Clients and then click New. In the new window, assign the IP retrieved from the previous step and generate a Shared Secret and copy that information.

Time to go back to the KEMP console. Expand Certificates & Security, and click on Remote Access, then click on WUI Authorization Options.

In the new page, define the IP of the RADIUS server and save the Shared Secret that was copied from the previous step. (Make sure to click on Set Secret to save the information.) Last but not least, make sure that Authentication and Authorization checkboxes are selected on the RADIUS line.

Step 2: Configuring authorization

In this step we will configure network policies that will allow the Active Directory group that we already defined to log on the KEMP device. The process is easy but requires attention. Here are the steps you must follow:

1. Log on the Network Policy Server.

2. Expand Policies, right-click on Network Policies, and click New.

3. In the Specify Network Policy Name and Connection Type page, assign a name for the policy and click Next.

4. In the Specify Conditions page, click on Add, select Windows Groups, click on Add Groups, and type in the group name and click OK twice. We should be back on the main page of the wizard. Click Next.

5. In the Specify Access Permissions page, click Next.

6. In the Configure Authentication Methods page, leave selected only this options: Microsoft Encrypted Authentication (MS-CHAP), User can change password after it has expired and Unencrypted authentication (PAP, SPAP). Click Next.

7. In the Configure Constraints page, just click Next.

8. In the Configure Settings page… be forwarmed, this one is a pain. The best thing is to remove all entries listed on the Standard item, and then add them exactly in the order listed on the image below and with the proper values. After that, just click Next.

9. In the Completing New Network Policy page, click on Finish.

Step3: Final adjustments and testing

Before starting the testing phase, we must make sure that the new Network Policy that we have created in the previous step is not listed after the default network policies: Connections to Microsoft Routing and Remove Access Server and Connections to other access servers, because those policies deny access. After all, we want our policy to be processed before being denied by the default policies.

Another cool feature that I like to use for my clients is to disable the Basic Authentication and define a text to be displayed before the authentication. We can find both options on the Admin WUI Access item located underneath Certificates & Security.

After that is just a simple test: Go to the KEMP web console and enter your username and password from your Active Directory, and voilà!

Another benefit is that when any new administrator requires access to the system from now on, it is just a matter of adding him or her to the group. Yes, it’s that simple!

Photo credit: Wikimedia