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]

Resource access and policy enforcement
Mapping users onto role(s) is just a means to an end. Ultimately, our objective was to map those Roles onto Resource Access Policies that L2/L3 PEPs could enforce.

L2 (802.1X) enforcement was added in UAC 2.0 and is easy to configure. During initial IC set-up, our switches and APs were added as RADIUS clients. Now, during policy configuration, we configured the RADIUS attributes returned for each role (below).

We stumbled here by sending VLAN tags to older/low-end PEPs that ignored them. The IC didn't notice our mistake—after all, enforcement is up to the PEP. The bottom line: choose L2 PEPs that support not only 802.1X and 802.1Q, but also RFC 3580 guidelines for mapping RADIUS attributes to 802.1X protocol fields. Non-3580 L2 PEPs can only enforce go/no-go policies. Also, to connect both agentless and managed endpoints, use an AP that supports multiple SSIDs with different security policies, or a switch that lets 802.1X-controlled ports time out and fall back to a non-802.1X "guest access" VLAN.

L3 (firewall) enforcement is UAC's biggest value-add over vanilla TNC. But it is also harder to wrap your head around, and requires a Juniper Infranet Enforcer: our SSG5, or any other Juniper VPN, firewall, or IDP product that supports UAC.

Our L3 Resource Access Policies were not terribly intricate (below). But it still took us a few tries, and a conversation with tech support, before we really understood how to use them. On the surface, it is easy to grasp how these policies associate TCP/IP allow/deny filters with roles. This is an ordered list; the first action that fits is applied. For example, we gave CustXRole access to their 2.1.1.0/24 subnet, then denied everyone else. This syntax is familiar, though Juniper never could tell us how to permit ESP.

The tricky part was learning how firewall policy administration gets split between the IC and connected Intranet Enforcer(s). First, we had to configure "framework" policies on the SSG—for example, giving UAC control over all traffic from any trusted source to any untrusted destination (denoted by tiny red shields below).

Doing so gives the IC the opportunity to further refine SSG policies, based on Roles and Resource Access Policies. For example, users mapped to the GuestPDARole can only send web traffic because the IC adds that granular policy to the SSG every time someone gets admitted in that role.

Manually-configured SSG policies can let other traffic bypass the IC—for example, letting everyone resolve URLs through an external DNS and redirecting unauthenticated web traffic to the IC's captive portal. Early on, we got ourselves into trouble by creating SSG policies that conflicted with IC-mapped policies. As we debugged our IC policies, we used SSG deny-all policies to log/stop anything that accidentally slipped through.

UAC's automated approach can save the firewall administrator a lot of detailed policy set-up. For example, we used a one-line IPsec Resource Access policy on the IC to secure NetAdminRole traffic; the IC then configured detailed policies on both the SSG and UAC Agent whenever that role was applied. However, delegating firewall policy control to the IC in this fashion requires trust and can impact related IT practices.

 

Page one: Assembling the pieces

Page two: Charting a course

Page three: Building a foundation

Page four: Users, endpoints, and roles

Page five: Resource access and policy enforcement

>Page six: Conclusion