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]

Users, endpoints, and roles
With network plumbing in place, it was time to configure our target policies. UAC maps every device that tries to access the network into one or more roles, based on user identity and endpoint security. Recall that our users fell into three distinct communities: staff, guests, and customers. We implemented this by configuring three user realms, each with its own authentication server, rules, and database.

We started by defining a local Authentication Server and user list (below). This is fine for testing and small networks, but most IC installations will consult an external server, as we did for our Active Directory. Finally, we configured an Anonymous Server for unauthenticated access through the IC's portal. To differentiate between guests and customers, we had to ask users to choose a realm on the main portal landing page.

Next, we defined endpoint security policies to be evaluated or enforced. As shown below, these policies must be created in several incremental steps.

• At the top layer, Host Checker policies to be verified by the IC can be combined with third-party policies to be verified by external IMVs.
• Each Host Checker policy contains three separate rule sets: one for Windows, one for Mac, one for Linux.
• Each OS rule set consists of zero or more predefined or custom rules, combined into a logical statement.
• Each rule set specifies an action (e.g., kill process) to be invoked or remediation instructions displayed whenever the policy evaluates to false.

These endpoint security policies can grow complicated fast. For example, the above policies only check for AV presence—more rules (checked against a Juniper database) would be needed to verify recent AV signatures. Actively scanning for viruses would involve consulting a third-party IMC/IMV. And, although UAC offers dozens of predefined Windows checks, we quickly learned to be selective, because every rule adds to login delay. The bottom line: start with simple checks, but plan to spend ongoing time to refining endpoint security rules to get the most out of UAC.

Next, we used our endpoint and authentication building blocks to map users onto roles. At connect time and periodically thereafter, the IC evaluates conditions to determine eligible roles for each user realm (see below). It then eliminates invalid roles for that endpoint, based on restrictions for the realm and role. If a given endpoint maps to multiple roles, those roles can either be merged or a single role can be used to determine resource access.

In the above example, only endpoints that pass our pre-authentication SupportedOS restriction (a Host Checker policy) are candidates for the Domain Users realm. Authenticated users who are found to be members of the "CS/Domain Users" group become eligible for CompliantPC and RemediationRole. When post-authentication restrictions are enforced, endpoints running our required AV and Firewall programs are mapped to the CompliantPCRole, while the rest end up in the RemediationRole.

User Realm and Role mapping can be complex, but it is critical to get this part of your policy right. In addition to Host Checker policies, possible realm or role restrictions include source IP, browser type, certificate, session limits, and requirements for agentless and/or UAC Agent access. Our initial policies were completed in two hours, but we had to experiment for a few more days to get them working as we really intended, especially for cross-platform restrictions. A searchable user access log and a detailed user trace diagnostic feature (below) proved very helpful in understanding how roles were actually determined.

 

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