General

Bolting the Back Door with NAC
Part 4: Deploying the Juniper Networks UAC 2.0
— continued

by Lisa Phifer VP Core Competence, Inc. [June 25, 2007]

Getting online
After the IC was deployed, it was time to admit users. We started with anonymous guest access. This is supposed to be quick and easy, and it was. Guests plugged into guest VLAN switch ports or associated to our open "GuestNet" SSID were automatically redirected to a custom IC portal page (below).

Clicking "Guest" redirects the user to the default sign-in page which tries to launch Host Checker using ActiveX or Java. Guests that pass all restrictions will be mapped to our GuestPCRole; the rest (including those that cannot run Host Checker) will be mapped to our GuestPDARole. Our visitors with Windows XP sailed through using IE or Firefox, distracted only by self-signed certificate warnings. A Linux laptop had to install the JRE plug-in before it could run Host Checker—that meant starting in GuestPDARole, downloading JRE, closing the browser, and then starting over again. Visitors using Mac (Safari) and Vista (beta) laptops complained about the lack of a progress indication while waiting for Host Checker to run or time out. However, all guests did manage to get online, and most breezed through later connect requests.

Note that closing the portal page terminates an authenticated session.

The "Customer" and "Employee" buttons on our custom portal page lead users down two different paths. Customers are prompted for login/password, found on a local user list. Authenticated users are then sent to a customer-specific success page (below left) or a rule-specific failure page (below right). Note that we could have evaluated common Host Checker rules for the entire realm, while enforcing customer-specific Host Checker rules for each mapped role.

Using the UAC Agent
Our staff was required to use the Windows UAC Agent (below), so why did we include an "Employees" button on the portal page? That button leads to a custom sign-in page that automatically installs the UAC Agent with "CompanyNet" settings. This only works for Windows users that allow ActiveX and have administrative privileges.

According to Juniper, most enterprises install the UAC Agent out-of-band instead, using desktop management tools. But to facilitate auto-installation during our test, Juniper gave us a sample "choice" sign-in template from which we created our unified landing page.

The UAC Agent (above) is an extension of the Odyssey Access Client that Juniper acquired with Funk Software. The agent can control access at L2 (using the 802.1X Supplicant) or at L3 (by connecting to a routable upstream IC). The above figures illustrate what our staff sees when successfully authenticated (above, left) or when post-authentication Host Checker restrictions fail (above, bottom). Note that the IP subnet differs—compliant staff stay on the 10.0.2.x subnet (VID #2), while non-compliant endpoints are moved to the 10.0.4.x subnet (VID #4). The "How do I resolve this problem" URL leads to rule-specific instructions as shown here. In real life, that URL could guide the user to a remediation server to download required software or patches.

Our UAC Agent experiences were largely positive. One host with an old Odyssey Access Client was forced to uninstall that software first. Another host running an overly-paranoid IDS just refused to let us install the UAC Agent. Once installed, the agent played nicely with other endpoint programs—for example, stopping the XP WZC service when managing Wi-Fi adapters. Every once in awhile, the agent reported that our computer was compliant when the IC had determined otherwise, taking a minute or so to catch up as the endpoint moved from one VLAN to another.

We didn't mind installing the UAC Agent on a handful of Windows laptops, but some companies prefer not to install any new client software. This is why we had wanted to connect staff laptops to UAC using third-party TNC Clients. On Linux, using an open source TNC Client would have been great. On Windows Vista, using the native Microsoft 802.1X Supplicant would have been nice. But neither could be attempted with the UAC version we tested; Juniper says that both are in the works. Specifically, these combinations were demonstrated at Interop, where Juniper pledged that UAC will work with the native Vista client by 1H08.

Conclusion
In this review, our goal was to illustrate the potential benefits of network access control, affected systems, and related deployment considerations. We chose Juniper's UAC 2.0 for this test drive because it claimed to use TNC standards to interoperate in a diverse multi-vendor environment. By the end, we were pleased to have implemented nearly all of our planned policies, using most of the switches and APs that we happened to try.

To be sure, we had to make some adjustments—upgrading firmware here, deprecating an old AP there, revising our non-compliant guest access policy. But we fully expected this test drive would be a learning process—and so should you. The best way to get a handle on NAC is to try it. Identify a business problem that NAC could help you solve (parts 1 and 2), choose a platform that will fit into your own network/system environment (part 3), and use it to launch a trial (as we did here in part 4). The more you learn, the better prepared you will be to tighten network access control and stop those compromised endpoints from harming your company LAN.

—End