Enforce Security Policies using ClearPass
By configuring the security policies, you can control access to the internet for users based on their username and group name.
Understanding Enforcement of ClearPass User and Group Authentication
This topic describes how the SRX Series Firewall or NFX Series device enforces user and group authentication when a user attempts to access a resource. It also explains how the device handles information in the ClearPass authentication table user entries when a security policy that references a group in a user entry is removed. Understanding that process will help you troubleshoot issues related to group identity and give you insight into changes in the ClearPass authentication table user entries.
- Understanding How the Device Manages the ClearPass Authentication Table
- User Authentication Entries in the ClearPass Authentication Table
- Communication Between ClearPass and the SRX Series Firewall or NFX Series Device
- Understanding Domains and Interested Groups
- When a User Has Already Been Authenticated By Another Source
Understanding How the Device Manages the ClearPass Authentication Table
The integrated ClearPass authentication and enforcement feature enables the SRX Series or NFX Series device and the Aruba ClearPass Policy Manager (CPPM) to collaborate in protecting your company’s resources. It enables the device to apply firewall security policies to user traffic and to control user access to protected resources based on user or group identity. To ensure the identity of the user, the device relies on authenticated user information that it receives from the CPPM.
It is useful to understand how the device gets authenticated user identity information from the CPPM, generates entries in its ClearPass authentication table, and manages those entries in relation to security policies and user events. Understanding these processes will help you to quickly identify and resolve related problems.
This topic focuses on:
How the device obtains user identity information from the CPPM and manages it, and how you can use this information in security policies.
How security policies that reference a group as the source (source-identity) have bearing on the groups listed in user entries in the ClearPass authentication table. Groups that are referenced by security policies are referred to as interested groups.
User Authentication Entries in the ClearPass Authentication Table
In their collaboration, ClearPass acts as the authentication source for the SRX Series or NFX Series device. The CPPM sends to the device identity information about users that it has authenticated. The UserID daemon process in the device receives this information, processes it, and synchronizes it to the Packet Forwarding Engine side in the independent ClearPass authentication table that is generated for this purpose.
As administrator of the device, you can use the authenticated user identity information in security policies to control access to your protected resources and the Internet.
The collection of user identity information that the device obtains from the CPPM and uses to create entries in its global Routing Engine authentication table that is synchronized to its individual ClearPass authentication table is referred to as a mapping, or, more commonly, an IP-user mapping because the username and the related group list are mapped to the IP address of the user’s device.
For each user authentication entry in the ClearPass authentication table, a group list identifies the groups that a user belongs to in addition to other information such as the posture token, which indicates state of the device, such as whether it is healthy.
The integrated user firewall feature for both ClearPass and active directory authentication will manage up to 2048 sessions for each user for whom there is a user identity and authentication entry in the authentication table. There might be additional sessions associated with a user beyond the 2048 supported sessions, but they are not managed by integrated user firewall. When an authentication entry in an authentication table is deleted, integrated user firewall only closes sessions that are associated with that entry. It will not close sessions that it does not manage. That is, sessions that are not associated with the authentication entry are not closed.
You can use a username or a group name in security policies to identity a user and not rely directly on the IP address of the device used, because the IP address of the device is tied to the username and its groups in the ClearPass authentication table entry.
For each user entry, the number of groups, or roles, in the entry cannot exceed 200. After the capacity is reached, additional roles are discarded and the following syslog message is sent:
userid_get_and_check_adauth_num: src_ip ip-address user domain:user dropped.record numrecord-number has arrived max num of db
In Junos OS Releases 18.4R3, 19.4R2, 19.1R3, 19.2R2, 19.3R3, for SRX300 devices with eUSB (SRX300, SRX320, SRX340, and SRX345), the SRX Series user firewall (UserFW) module tries to synchronize user entries from the domain controller or Juniper Identity Management Service (JIMS) after booting up. If the historical login events expired on the domain controller, then the SRX Series UserFW module is unable to retrieve those user entries after the UserFW module boots up.
The CPPM posts user information to the device in the following format. The device does not use all of this information.
<userfw-entries>
<userfw-entry>
<source>Aruba ClearPass</source>
<timestamp>2016-01-29T0310Z</timestamp>
<operation>logon</operation>
<IP>192.0.2.123</IP>
<domain>my-company-domain</domain>
<user>user1</user>
<role-list>
<role>human-resources-grp</role>
<role>[User Authenticated],/role>
</role-list>
<posture>HEALTHY</posture>
<device_category>Computer</device_category>
</userfw-entry>
</userfw-entries>
Here is the format for a ClearPass authentication table entry for a user, followed by an example entry and a description of its components.
IP-address, domain, user, user-group-list
In the following example, the user belongs to two groups, the human-resources-grp group and the posture-healthy group. The SRX Series Firewall converts the posture information from the CPPM to a group name. You might configure a security policy that allows all users access to the marketing server if their devices belong to the posture-healthy group (role).
192.0.2.11 , my-company-domain, lin, human-resources-grp, posture-healthy
IP address
This is the IP address of the device used.
The name of the domain that the user belongs to.
In this example, the domain name is “my-company-domain.” The default domain name GLOBAL is used if a domain name is not provided.
The username
The username is the user’s login name used to connect to the network, which, in this example, is lin.
This name is constant regardless of the device used.
When you configure a security policy whose source-identity tuple identifies the source of the traffic by username or group name, not by the IP address of the device used, it is as if the security policy were device independent; it applies to the user’s activity regardless of the device used.
One or more groups that a user belongs to
It is here where the concept of interested groups and their relationship to security policies comes into play. An interested group is a group that is referenced in a security policy. The concept of interested groups is covered later in this topic.
Note that if a user is connected to the network using multiple devices, there might be more than one IP-user mapping for that user. Each mapping would have its own set of values—that is, domain name and group-list—in conjunction with the username and IP address.
For example, the following three IP address-to-username mappings might exist for the user abe who is connected to the network using three separate devices:
203.0.113.5 abe, marketing-grp, posture-healthy 192.0.2.34 abe, marketing-grp, posture-transition 203.0.133.19 abe, marketing-grp, posture-unknown
Assume that the SRX Series Firewall receives a logout message for 110.208.132.23, abe. The following partial user authentication entry shows that the user abe is now logged in to the network using only two devices:
192.0.2.34 abe, marketing-grp, posture-transition 203.0.133.19 abe, marketing-grp, posture-unknown
If more than 2048 sessions are associated with a single authentication entry in the ClearPass authentication table, the integrated user firewall for ClearPass will not manage the sessions that caused the overflow. Consequently, there will be no user identification information for those sessions reported in the session close log for those sessions.
Communication Between ClearPass and the SRX Series Firewall or NFX Series Device
Here is a summary of how the SRX Series Firewall or NFX Series device and ClearPass communicate:
A user joins the company network via a wired or wireless LAN.
The CPPM authenticates the user.
The CPPM initiates a secure connection with the device using the integrated Web API.
The UserID daemon gets the full IP-user mapping from the CPPM. For each authenticated user, the UserID daemon generates an entry in the Routing Engine authentication table.
The Routing Engine authentication table is common in that it holds authentication entries based on information from other authentication sources in addition to ClearPass. For example, it might also hold entries for users authenticated by Microsoft Active Directory.
The UserID daemon synchronizes the user authentication information from the Routing Engine authentication table to the ClearPass authentication table on the Packet Forwarding Engine. The ClearPass authentication table is dedicated to holding only ClearPass authentication information. See Figure 1.
Figure 1: User Information from the CPPM to the SRX Series Firewall Routing Engine Synchronized to the ClearPass Authentication Table
The device uses the authenticated user identity information in the following process. When a user attempts to access an internal, protected resource or the Internet, the device:
Checks the traffic generated by the user for a matching security policy. The source traffic must match all of the tuples specified in the security policy. The match includes the source-identity field, which specifies a username or a group name.
To identify a match, the device compares the username or the group name with the source-identity specification that is configured in a security policy, along with all other security policy values.
Checks the ClearPass authentication table for an authentication entry for the user, if a security policy match was found.
If it does not find an entry in the ClearPass authentication table, the device checks other local authentication tables, in the order that you specified, until a match is found. However, it does not check other local authentication tables if the user query function is configured. See Understanding the Integrated ClearPass Authentication and Enforcement User Query Function.
The device can query the CPPM for individual user information, under certain circumstances, when it has not already received that information from the CPPM. This feature is referred to as user query.
Figure 2 illustrates the connection and communication between the device and the CPPM. It also shows the paths entailed in authenticating users and allowing them access to the Internet and internal, protected resources.
As Figure 2 depicts, the following activity takes place:
-
The CPPM initiates a secure connection with the SRX Series Firewall using the Web API.
Three users join the network and are authenticated by the CPPM.
A tablet user joins the network across the corporate WAN.
A smartphone user joins the network across the corporate WAN.
A wireless laptop user joins the network from a wired laptop connected to a Layer 2 switch that is connected to the corporate LAN.
The CPPM sends the user authentication and identity information for the users who are logged in to the network to the device in POST request messages using the Web API.
When traffic from a user arrives at the device, the device:
Identifies a security policy that the traffic matches.
Locates an authentication entry for the user in the ClearPass authentication table.
Applies the security policy to the traffic after authenticating the user.
Traffic from the smartphone user who is requesting access to an internal, protected resource arrives at the device. Because all of the conditions identified in Step 3 are met and the security policy permits it, the device allows the user connection to the protected resource.
Traffic from the wired laptop user who is requesting access to a protected resource arrives at the device. Because all of the conditions identified in Step 3 are met and the security policy permits it, the device allows the user connection to the resource.
Traffic from the tablet user who is requesting access to the Internet arrives at the device. Because all of the conditions identified in Step 3 are met and the security policy permits it, the device allows the user connection to the Internet.
Understanding Domains and Interested Groups
How the user identity group information is managed on the device is dominated by two concepts:
Domain group
The device follows the usual course in regard to how it handles usernames in domain namespaces. It makes use of the namespace to distinguish names that are the same–such as
admin—but that are from different sources and are in different domains. Because they belong to different domains, the names are not in conflict.Any group that is part of an IP-user mapping will always belong to a domain, whether that domain is a specific domain or the GLOBAL domain. If a domain name is not specified in the IP-user mapping, then the GLOBAL domain is assumed.
Table 1 illustrates how the domain for a group is determined, based on the IP-user mapping information obtained from the CPPM.
Table 1: Assigning a Domain to a Group Does the IP-User Mapping Contain a Domain Name?
What Domain Is Applied to the Group?
No
For example:
IP, , user1, group-list
The second comma serves as a placeholder for the domain name and the GLOBAL domain is applied.
Groups included in group-list belong to the GLOBAL domain.
Yes
For example:
IP, domain1, user1, group-list
Note:In this example, the IP-user mapping specifies the domain name as domain1.
The domain name, domain1, is included in the IP-user mapping from the CPPM, and it is used. It is retained in the entry for the authenticated user in the ClearPass authentication table on the Packet Forwarding Engine.
Interested group
A group qualifies as an interested group if it is referenced by a security policy–that is, if it is specified in a policy’s source-identity field. On the Routing Engine authentication table, each user entry contains a group referenced by a policy list that identifies the names of the groups for which a security policy exists. If a group included in a user entry is not currently used in a security policy, it is not included in this list. A group can move in and out of the groups referenced by a policy list.
Interested group lists
An interested group list, or a list of groups referenced by policies, is a subset of overall groups. It is the intersection of the group list in a user authentication entry and the source-identity list for security policies. That is, any group included in a ClearPass authentication table user entry qualifies as an interested group. The Routing Engine synchronizes to the user entry in the ClearPass authentication table on the Packet Forwarding Engine only those groups that are referenced by security policies.
Here is how it works:
The UserID daemon gets the full IP-user role (group) mapping from the CPPM.
For each group, the UserID daemon identifies whether it is an interested group by determining if there is a security policy that references it. Any qualifying groups are included in the groups referenced by a policy list on the Routing Engine. The UserID daemon synchronizes to the user entry in the ClearPass authentication table on the Packet Forwarding Engine interested groups along with the rest of the user authentication and identity information.
The interested groups list for a user entry on the Routing Engine can change, based on the following events:
A new security policy is configured that references a group included in the user entry on the Routing Engine but that is not already in the entry’s referenced groups list.
A currently configured security policy that references a group in its source-identity is deleted.
Consider the following example:
Assume that the CPPM posted the following information for two users to the SRX Series Firewall:
192.51.100.1, abe, group1, group2, group3, group4, healthy 192.0.2.21, john, group1, group5, healthy
After the device maps the posture, defining it as a group, the two user entries in the device Routing Engine authentication table appear as follows:
192.51.100.1, abe, group1, group2, group3, group4, posture-healthy 192.0.2.21, john, group1, group5, posture-healthy
Assume that several security policies include source-identity fields that reference one of the following: group1, group3, posture-healthy.
The intersection of the preceding sets—the original group list and the list of security policies that refer to the groups—results in the following interested groups list:
For the user john, the groups referenced by policy list includes group1 and posture-healthy.
For the user abe, the groups referenced by policy list includes group1, group3, and posture-healthy.
Now suppose that the security policy whose source-identity field specified group1 was deleted. The groups referenced by policy lists for the user authentication entries for the two users—john and abe—would be changed, producing the following results:
For the user john, the list would include only posture-healthy.
For the user abe, the list would include group3 and posture-healthy.
Table 2 shows how a security policy that references a group affects the ClearPass authentication table. It also shows the effect on the ClearPass authentication table when a group is not referenced by a security policy, and therefore is not an interested group.
Table 2: Interested Groups: Effect on the ClearPass Authentication Table Security Policies Configuration and Modification
Resulting Effect on ClearPass Authentication Table Packet Forwarding Engine Entries
Case 1:
The SRX Series Firewall gets the IP-user mapping for a user from the CPPM.
None of the groups in the user mapping are referenced by security policies.
IP-user mapping from the CPPM:
203.0.113.9, ,user1, g1, g2, g3, g4
The user authentication entry written to the ClearPass authentication table in the Packet Forwarding Engine for this user does not contain any groups.
203.0.113.9 , ,user1
Case 2:
The SRX Series Firewall gets the IP-user mapping for a user from the CPPM. It checks the groups list against the security policies list and finds that two of the groups are referenced by security policies.
IP-user mapping on the Routing Engine:
192.0.2.1, domain1, user2, g1, g2, g3, g4
The user authentication entry written to the ClearPass authentication table on the Packet Forwarding Engine for this user includes the following groups that are included in the groups referenced by the policy list on the Routing Engine:
192.0.2.1, domain1, user2, g2, g4
When a User Has Already Been Authenticated By Another Source
It can happen that the device Routing Engine authentication table and the individual Microsoft Active Directory authentication table on the Packet Forwarding Engine, for example, contain an entry for a user who was authenticated by Active Directory. As usual, the CPPM sends the IP-user mapping for the user to the device. The device must resolve the problem because its Routing Engine authentication table is common to both Active Directory and ClearPass.
Here is how the device handles the situation:
On the Routing Engine authentication table:
The device overwrites the Active Directory authentication entry for the user in its common Routing Engine authentication table with the newly generated one from the IP-user mapping for the user from the CPPM.
There is now no IP address or username conflict.
On the Packet Forwarding Engine:
The device deletes the existing Active Directory authentication entry for the user from the Active Directory authentication table.
This will delete active sessions associated with the IP address.
The device generates a new entry for the CPPM-authenticated user in the Packet Forwarding Engine ClearPass authentication table.
Traffic associated with the IP-user mapping entry will initiate new sessions based on user authentication in the ClearPass authentication table.
Example: Enforcing SRX Series Security Policies Using Aruba ClearPass as the Authentication Source
This example covers how to configure security to protect your resources and control access to the internet using the SRX Series Firewall integrated ClearPass authentication and enforcement feature, which relies on the Aruba ClearPass Policy Manager as its authentication source. The SRX Series integrated ClearPass feature allows you to configure security policies that control access to company resources and the Internet by identifying users by username, group name, or the name of a role that ties together a group of users and a device type.
Today’s network environments are more open to attacks of various kinds because they support anywhere, anytime, any device access, to a greater or lesser degree, and they allow a user to use multiple concurrently network-connected devices. Because it allows you identify the user by username, the integrated ClearPass authentication and enforcement feature narrows the security gap that these capabilities introduce.
For details on how user authentication and identity information is conveyed from the CPPM to the SRX Series Firewall, see the following topics:
Configure Integrated ClearPass Authentication and Enforcement
Understanding the Integrated ClearPass Authentication and Enforcement User Query Function
The example covers the following processes:
How to control access at the user level based on username or group name, not device IP address.
You can use the source-identity parameter in a security policy to specify the name of a user or the name of a group of users whose authentication is provided by the CPPM. The policy is applied to traffic generated by the users when they attempt to access a protected resource or the Internet regardless of the device used. The access control is tied to the user’s name, and not directly to the IP address of the user’s device.
You can configure different security policies for a single user that specify different actions, differentiated by the zones and the destination addresses specified or a group that the user belongs to.
How to display and interpret the contents of the ClearPass authentication table.
The SRX Series Firewall creates the ClearPass authentication table to contain user authentication and identity information that it receives from the CPPM. The device refers to the table to authenticate a user who requests access to a resource.
The ClearPass authentication table contents are dynamic. They are modified to reflect user activity in response to various events and also in regard to security policies that reference groups.
For example, when a user logs out of the network or in to the network, the ClearPass authentication table is modified, as is the case when a user is removed from a group or a referenced security policy that specifies a group that the user belongs to is deleted. In the latter case, the user entry no longer shows the user as belonging to that group.
In this example, the ClearPass authentication table contents are displayed to depict changes made because of two events. The content for the users is displayed:
Before and after a specific user logs out of the network
Before and after a referenced security policy is deleted
The entry for the user who belonged to the group referenced by the security policy is displayed before and after the policy is deleted.
Requirements
This section defines the software and hardware requirements for the topology for this example. See Figure 3 for the topology design.
The hardware and software components are:
Aruba ClearPass. The ClearPass Policy Manager (CPPM) is configured to use its local authentication source to authenticate users.
It is assumed that the CPPM is configured to provide the SRX Series Firewall with user authentication and identity information, including the username, a list of the names of any groups that the user belongs to, the IP addresses of the devices used, and the device posture token.
SRX Series Firewall running Junos OS that includes the integrated ClearPass feature.
A server farm composed of six servers, all in the servers-zone:
marketing-server-protected (203.0.113.23 )
human-resources-server (203.0.113.25 )
accounting-server (203.0.113.72)
public-server (203.0.113.62)
corporate-server (203.0.113.71)
sales-server (203.0.113.81)
AC 7010 Aruba Cloud Services Controller running ArubaOS.
Aruba AP wireless access controller running ArubaOS.
The Aruba AP is connected to the AC7010.
Wireless users connect to the CPPM through the Aruba AP.
Juniper Networks EX4300 switch used as the wired 802.1 access device.
Wired users connect to the CPPM using the EX4300 switch.
Six end-user systems:
Three wired network-connected PCs running Microsoft OS
Two BYOD devices that access the network through the Aruba AP access device
One wireless laptop running Microsoft OS
Overview
In its capacity as the authentication source for the integrated ClearPass feature, the CPPM posts to the SRX Series Firewall user authentication and identity information. When it receives this information, the SRX Series UserID daemon processes it and generates entries for the authenticated users in the Routing Engine authentication table and then synchronizes that information to the ClearPass authentication table on the Packet Forwarding Engine side.
The SRX Series Firewall requires the user authentication and identity information to verify that a user is authenticated when the user makes an access request and the traffic generated from the user’s device arrives at the SRX Series Firewall. If a security policy exists that specifies in the source-identity parameter the username or the name of a group that the user belongs to, the SRX Series Firewall searches the contents of its ClearPass authentication table for an entry for that user.
If it does not find an entry for the user in its ClearPass authentication table, the SRX Series Firewall can search its other authentication tables, if you have configured a search order that includes them. See Configure Integrated ClearPass Authentication and Enforcement for information about the authentication table search order.
The integrated ClearPass feature allows you to create identity-aware security policies configured to match traffic issued by users based on their username or the name of a group that they belong to.
You configure role mappings on the CPPM, not on the SRX Series Firewall.
For example, a device type role mapping might tie user identities to company-owned computers. You could specify this role as a group in a security policy configured to apply to all users who are mapped to the rule. In this case, the conditions set by CPPM for the rule—use of company-owned computer—would apply to all users mapped to the rule. The SRX Series Firewall does not consider the conditions, but rather accepts the rule from the CPPM.
The following configurations included in this example cover security policies that are applicable based on the type of device used as defined by the CPPM through rule mappings. It is assumed that the CPPM posted to the SRX Series Firewall the following mapped rules that are used as groups in security policies:
marketing-access-for-pcs-limited-group
Maps jxchan to the device type PC.
The policy that specifies marketing-access-for-pcs-limited-group in its source-identity field allows jxchan, and other users who are mapped to it, access to the marketing-server-protected server using their PC, whether it is company owned or not.
accounting-grp-and-company-device
Maps users who belong to accounting groups using company devices. The CPPM sends the role accounting-grp-and-company-device to the SRX Series Firewall. The mapping is done on the CPPM by role mapping rules.
The policy that specifies accounting-grp-and-company-device in its source identity field allows users who are mapped to the rule to access protected resources on the accounting-server. The group accounting-grp is mapped to the rule. Therefore the mapped rule applies to the members of accounting-grp.
The user viki2 belongs to accounting-grp. If all conditions apply—that is, if viki2 is using a company-owned device and the policy permits access—she is allowed access to the resources on accounting-server. But, recall that the SRX Series Firewall does not analyze the rule. Rather it applies it to all users who are mapped to it by the CPPM.
guest-device-byod
Maps the guest group to the device type byod—that is, any user-owned device brought to the network.
The policy that specifies guest-device-byod in its source identity field denies users who are mapped to the rule access to all servers in the server zone if they are using smartphones or other user-owned devices. The username guest2 is mapped to this rule by the CPPM.
For all cases, if the users are allowed or denied access according to the security policy conditions, you can assume that the following conditions exist:
The CPPM posted the correct authentication information for the users and groups to the SRX Series Firewall.
The SRX Series Firewall processed the authenticated user information correctly and generated entries for the users and groups in its ClearPass authentication table.
Starting with Junos OS Release 15.1X49-D130, the SRX Series Firewall supports the use of IPv6 addresses associated with source identities in security policies. If IPv4 or IPv6 entry exists, policies matching that entry are applied to the traffic and access is allowed or denied.
Table 3 summarizes the users, their groups, and the zones to which they belong. All users belong to the default GLOBAL domain.
User |
Group |
Zone |
|---|---|---|
Abe (abew1) |
|
marketing-zone |
John (jxchan) |
|
marketing-zone |
Lin (lchen1) |
|
human-resources-zone |
Viki (viki2) |
|
accounting-zone |
guest1 |
|
public-zone |
guest2 |
|
public-zone |
Topology
Figure 3 shows the topology for this example.
Configuration
This section covers how to configure the SRX Series Firewall to include security policies that match traffic issued by users authenticated by the CPPM.
- CLI Quick Configuration
- Configuring Interfaces, Zones, and an Address Book
- Configuring Identity-Aware Security Policies to Control User Access to Company Resources
- Results
CLI Quick Configuration
To quickly configure this example, copy the following statements, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the statements into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
set interfaces ge-0/0/3 vlan-tagging set interfaces ge-0/0/3.0 vlan-id 300 family inet address 203.0.113.45/24 set interfaces ge-0/0/3.1 vlan-id 310 family inet address 192.0.2.18/24 set interfaces ge-0/0/3.2 vlan-id 320 family inet address 192.0.2.14/24 set interfaces ge-0/0/4 vlan-tagging set interfaces ge-0/0/4.0 vlan-id 400 family inet address 192.0.2.16/24 set interfaces ge-0/0/4.1 vlan-id 410 family inet address 192.0.2.19/24 set security zones security-zone marketing-zone interfaces ge-0/0/3.0 host-inbound-traffic system-services all set security zones security-zone marketing-zone interfaces ge-0/0/3.0 host-inbound-traffic protocols all set security zones security-zone accounting-zone interfaces ge-0/0/3.1 host-inbound-traffic system-services all set security zones security-zone accounting-zone interfaces ge-0/0/3.1 host-inbound-traffic protocols all set security zones security-zone human-resources-zone interfaces ge-0/0/3.2 host-inbound-traffic system-services all set security zones security-zone human-resources-zone interfaces ge-0/0/3.2 host-inbound-traffic protocols all set security zones security-zone public-zone interfaces ge-0/0/4.0 host-inbound-traffic system-services all set security zones security-zone public-zone interfaces ge-0/0/4.0 host-inbound-traffic protocols all set security zones security-zone servers-zone interfaces ge-0/0/4.1 host-inbound-traffic system-services all set security zones security-zone servers-zone interfaces ge-0/0/4.1 host-inbound-traffic protocols all set security address-book servers-zone-addresses address marketing-server-protected 203.0.113.23 set security address-book servers-zone-addresses address human-resources-server 203.0.113.25 set security address-book servers-zone-addresses address accounting-server 203.0.113.72 set security address-book servers-zone-addresses address corporate-server 203.0.113.71 set security address-book servers-zone-addresses address public-server 203.0.113.91 set security address-book servers-zone-addresses attach zone servers-zone set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p1 match source-address any destination address any set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p1 match application any set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p1 match source-identity “global\marketing-access-for-pcs-limited-group” set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p1 then permit set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p2 match source-address any destination address marketing-zone-protected set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p2 match application any set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p2 match source-identity “global\abew1” set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p2 then permit set security policies from-zone accounting-zone to-zone servers-zone policy acct-cp-device match source-address any destination-address accounting-server set security policies from-zone accounting-zone to-zone servers-zone policy acct-cp-device match application any set security policies from-zone accounting-zone to-zone servers-zone policy acct-cp-device match source-identity “global\accounting-grp-and-company-device” set security policies from-zone accounting-zone to-zone servers-zone policy acct-cp-device then permit set security policies from-zone human-resources-zone to-zone servers-zone policy human-resources-p1 match source-address any destination-address corporate-server set security policies from-zone human-resources-zone to-zone servers-zone policy human-resources-p1 match application any set security policies from-zone human-resources-zone to-zone servers-zone policy human-resources-p1 match source-identity “global\corporate-limited” set security policies from-zone human-resources-zone to servers-zone policy human-resources-p1 then permit set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p0 match source-address any destination-address corporate-server set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p0 match application any set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p0 match source-identity “global\marketing-access-limited-grp” set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p0 then permit set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p3 match source-address any destination-address human-resources-server set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p3 match application any set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p3 match source-identity “global\sales-limited-group” set security policies from-zone marketing-zone to-zone servers-zone policy marketing-p3 then permit set security policies from-zone public-zone to-zone servers-zone policy guest-allow-access match source-address any destination address public-server set security policies from-zone public-zone to-zone servers-zone policy guest-allow-access match application any set security policies from-zone public-zone to-zone servers-zone policy guest-allow-access match source-identity “global\guest” set security policies from-zone public-zone to-zone servers-zone policy guest-allow-access then permit set security policies from-zone public-zone to-zone servers-zone policy guest-deny-access match source-address any destination-address any set security policies from-zone public-zone to-zone servers-zone policy guest-deny-access match application any set security policies from-zone public-zone to-zone servers-zone policy guest-deny-access match source-identity “global\guest-device-byod” set security policies from-zone public-zone to-zone servers-zone policy guest-deny-access then deny
Configuring Interfaces, Zones, and an Address Book
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.
Configure the following interfaces and assign them to zones:
ge-0/0/3.0 > marketing-zone
ge-0/0/3.1 > human-resources-zone
ge-0/0/3.2> accounting-zone
ge-0/0/4.0 > public-zone
ge-0/0/4.1 > servers-zone
Because this example uses logical interfaces, you must configure VLAN tagging.
-
Configure interfaces for the SRX Series Firewall:
[edit interfaces] set ge-0/0/3 vlan-tagging set ge-0/0/3.0 vlan-id 300 family inet address 203.0.113.45/24 set ge-0/0/3.1 vlan-id 310 family inet address 192.0.2.18/24 set ge-0/0/3.2 vlan-id 320 family inet address 192.0.2.14/24 set ge-0/0/4 vlan-tagging set ge-0/0/4.0 vlan-id 400 family inet address 192.0.2.16/24 set ge-0/0/4.1 vlan-id 410 family inet address 192.0.2.19/24
Configure zones.
[edit security zones] user@host#set security-zone marketing-zone interfaces ge-0/0/3.0 host-inbound-traffic system-services all user@host#set security-zone marketing-zone interfaces ge-0/0/3.0 host-inbound-traffic protocols all user@host#set security-zone accounting-zone interfaces ge-0/0/3.1 host-inbound-traffic system-services all user@host#set security-zone accounting-zone interfaces ge-0/0/3.1 host-inbound-traffic protocols all user@host#set security-zone human-resources-zone interfaces ge-0/0/3.2 host-inbound-traffic system-services all user@host#set security-zone human-resources-zone interfaces ge-0/0/3.2 host-inbound-traffic protocols all user@host#set security-zone public-zone interfaces ge-0/0/4.0 host-inbound-traffic system-services all user@host#set security-zone public-zone interfaces ge-0/0/4.0 host-inbound-traffic protocols all user@host#set security-zone servers-zone interfaces ge-0/0/4.1 host-inbound-traffic system-services all user@host#set security-zone servers-zone interfaces ge-0/0/4.1 host-inbound-traffic protocols all
Configure an address book containing the IP addresses of the servers to use as destination addresses in security policies.
[edit security address-book servers-zone-addresses] user@host# set address marketing-server-protected 203.0.113.23 user@host# set address human-resources-server 203.0.113.25 user@host# set address accounting-server 203.0.113.72 user@host# set address corporate-server 203.0.113.71 user@host# set address public-server 203.0.113.91
Attach the servers-zone-addresses address book to servers-zone.
[edit security address-book] user@host# set servers-zone-addresses attach zone servers-zone
Results
From configuration mode, confirm your configuration for interfaces by entering the show interfaces command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
ge-0/0/3 {
unit 0 {
vlan-id 300;
family inet {
address 203.0.113.45/24;
}
}
unit 1 {
vlan-id 310;
family inet {
address 192.0.2.18/24;
}
}
unit 2 {
vlan-id 320;
family inet {
address 192.0.2.14/24;
}
}
}
ge-0/0/4 {
vlan-tagging;
unit 0 {
vlan-id 400;
family inet {
address 192.0.2.16/24;
}
}
unit 1 {
vlan-id 410;
family inet {
address 192.0.2.19/24;
}
}
}
From configuration mode, confirm your configuration for zones by entering the show security zones command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
security-zone human-resources-zone {
interfaces {
ge-0/0/3.2 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
security-zone accounting-zone {
interfaces {
ge-0/0/3.1 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
security-zone marketing-zone {
interfaces {
ge-0/0/3.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
security-zone servers-zone {
interfaces {
ge-0/0/4.1 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
security-zone public-zone {
interfaces {
ge-0/0/4.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
From configuration mode, confirm your configuration for the address book by entering the show security address-book command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
servers-zone-addresses {
address marketing-zone-protected 203.0.113.23 /32;
address human-resources-server 203.0.113.25 /32;
address accounting-server 203.0.113.72/32;
address corporate-server 203.0.113.71/32;
address public-server 203.0.113.91/32;
attach {
zone servers-zone;
}
}
Configuring Identity-Aware Security Policies to Control User Access to Company Resources
Step-by-Step Procedure
This task entails configuring security policies that apply to a user’s access to resources based on username or group name, and not the IP address of the device used.
Note that all users belong to the default GLOBAL domain.
Configure a security policy that specifies marketing-access-for-pcs-limited-group as the source-identity. It allows the user jxchan, who belongs to this group, access to any of the servers in the servers-zones when he is using a PC, whether it is a personal device or a company-owned device. The username jxchan is mapped by the CPPM to the rule marketing-access-for-pcs-limited-group.
[edit security policies] user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p1 match source-address any destination address any user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p1 match application any user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p1 match source-identity “global\marketing-access-for-pcs-limited-group” user@hoset from-zone marketing-zone to-zone servers-zone policy marketing-p1 then permit
Configure a security policy that allows the user abew1 access to the marketing-zone-protected server (IP address 203.0.113.23 ) in the servers-zone regardless of the device that he uses.
[edit security policies] user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p2 match source-address any destination address marketing-zone-protected user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p2 match application any user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p2 match source-identity “global\abew1” user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p2 then permit
Configure a security policy that allows the user viki2 access to the accounting-server (IP address 203.0.113.72) in the servers-zone when she is using a company-owned device. The user viki2 belongs to accounting-grp which is mapped to the company-owned-device rule (accounting-grp-and-company-device) by the CPPM.
[edit security policies] user@host# set from-zone accounting-zone to-zone servers-zone policy acct-cp-device match source-address any destination-address accounting-server user@host# set from-zone accounting-zone to-zone servers-zone policy acct-cp-device match application any user@host# set from-zone accounting-zone to-zone servers-zone policy acct-cp-device match source-identity “global\accounting-grp-and-company-device” user@host# set from-zone accounting-zone to-zone servers-zone policy acct-cp-device then permit
Configure a security policy that allows users who belong to the corporate-limited group limited access to the corporate-server server (IP address 203.0.113.71) in the servers-zone when they are initiating a request from the human-resources zone.
If the source-address were specified as “any”, the policy would apply to other users who also belong to the corporate-limited group.
[edit security policies] user@host# set from-zone human-resources-zone to-zone servers-zone policy human-resources-p1 match source-address any destination-address corporate-server user@host# set from-zone human-resources-zone to-zone servers-zone policy human-resources-p1 match application any user@host# set from-zone human-resources-zone to-zone servers-zone policy human-resources-p1 match source-identity “global\corporate-limited” user@host# set from-zone human-resources-zone to servers-zone policy human-resources-p1 then permit
Configure a security policy that allows the user abew1 access to the corporate-server (IP address 203.0.113.71) server in the servers-zone. The user abew1 belongs to marketing-access-limited-grp to which the security policy applies.
[edit security policies] user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p0 match source-address any destination-address corporate-server user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p0 match application any user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p0 match source-identity “global\marketing-access-limited-grp” user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p0 then permit
Configure a security policy that allows users who belong to the sales-limited-group access to the human-resources-server (IP address 203.0.113.81) server when they initiate a request from the marketing-zone. The user jxchan belongs to sales-limited-group.
[edit security policies] user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p3 match source-address any destination-address human-resources-server user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p3 match application any user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p3 match source-identity “global\sales-limited-group” user@host# set from-zone marketing-zone to-zone servers-zone policy marketing-p3 then permit
Configure a security policy that allows users who belong to the guest group access to the public-server (IP address 203.0.113.91) in the servers-zone.
[edit security policies] user@host# set from-zone public-zone to-zone servers-zone policy guest-allow-access match source-address any destination address public-server user@host# set from-zone public-zone to-zone servers-zone policy guest-allow-access match application any user@host# set from-zone public-zone to-zone servers-zone policy guest-allow-access match source-identity “global\guest” user@host# set from-zone public-zone to-zone servers-zone policy guest-allow-access then permit
Configure a security policy that denies users who belong to the guest-device-byod group access to any servers in the servers-zone when they use their own devices.
[edit security policies] user@host# set from-zone public-zone to-zone servers-zone policy guest-deny-access match source-address any destination-address any user@host# set from-zone public-zone to-zone servers-zone policy guest-deny-access match application any user@host# user@host# set from-zone public-zone to-zone servers-zone policy guest-deny-access match source-identity “global\guest-device-byod” user@host# set from-zone public-zone to-zone servers-zone policy guest-deny-access then deny
Results
From configuration mode, confirm your security policies configuration for integrated ClearPass by entering the show security policies command.
If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
from-zone marketing-zone to-zone servers-zone {
policy marketing-p1 {
match {
source-address any;
destination-address any;
application any;
source-identity "global\marketing-access-for-pcs-limited-group";
}
then {
permit;
}
}
policy marketing-p2 {
match {
source-address any;
destination-address marketing-zone-protected;
application any;
source-identity "global\abew1";
}
then {
permit;
}
}
policy marketing-p0 {
match {
source-address any;
destination-address corporate-server;
application any;
source-identity "global\marketing-access-limited-grp";
}
then {
permit;
}
}
policy marketing-p3 {
match {
source-address any;
destination-address human-resources-server;
application any;
source-identity "global\sales-limited-group";
}
then {
permit;
}
}
}
from-zone accounting-zone to-zone servers-zone {
policy acct-cp-device {
match {
source-address any;
destination-address accounting-server;
application any;
source-identity "global\accounting-grp-and-company-device";
}
then {
permit;
}
}
}
from-zone human-resources-zone to-zone servers-zone {
policy human-resources-p1 {
match {
source-address any;
destination-address corporate-server;
application any;
source-identity "global\corporate-limited";
}
then {
permit;
}
}
}
from-zone public-zone to-zone servers-zone {
policy guest-allow-access {
match {
source-address any;
destination-address public-server;
application any;
source-identity “global\guest”;
}
then {
permit;
}
}
policy guest-deny-access {
match {
source-address any;
destination-address any;
application any;
source-identity “global\guest-device-byod”;
}
then {
deny;
}
}
}
Verification
This section verifies the ClearPass authentication table contents after certain events occur that cause some of its user authentication entries to be modified. It also shows how to ensure that the ClearPass authentication table has been deleted successfully after you issue the delete command. It includes the following parts:
- Displaying the ClearPass Authentication Table Contents Before and After an Authenticated User Logs Out of the Network
- Displaying the Authentication Table Contents Before and After a Referenced Security Policy Is Deleted
Displaying the ClearPass Authentication Table Contents Before and After an Authenticated User Logs Out of the Network
Purpose
Display the ClearPass authentication table contents when a specific, authenticated user is logged in to the network and after the user logs out.
Action
Enter the show services user-identification authentication-table authentication-source authentication-source command for the ClearPass authentication table, which is referred to as aruba-clearpass. Notice that the ClearPass authentication table includes an entry for the user viki2.
show services user-identification authentication-table authentication-source aruba-clearpass Domain: GLOBAL Total entries: 6 Source IP Username groups(Ref by policy) state 203.0.113.21 viki2 accounting-grp-and-company-dev Valid 203.0.113.89 abew1 marketing-access-limited-grp Valid 203.0.113.52 jxchan marketing-access-for-pcs-limit Valid 203.0.113.53 lchen1 corporate-limited Valid 203.0.113.54 guest1 Valid 203.0.113.55 guest2 Valid
Enter the same command again after viki2 logs out of the network. Notice that the ClearPass authentication table no longer contains an entry for viki2.
Domain: GLOBAL Total entries: 6 Source IP Username groups(Ref by policy) state 203.0.113.89 abew1 marketing-access-limited-grp Valid 203.0.113.52 jxchan marketing-access-for-pcs-limit Valid 203.0.113.53 lchen1 corporate-limited Valid 203.0.113.54 guest1 Valid 203.0.113.55 guest2 Valid
Displaying the Authentication Table Contents Before and After a Referenced Security Policy Is Deleted
Purpose
Display the ClearPass authentication table contents for a specific user—lchen1—who belongs to a group that is referenced by a security policy. Delete that security policy, then display the entry for that user again.
Action
Enter the show service user-identification authentication-table authentication-source user user-name command to display the ClearPass authentication table entry for a specific user, lchen1. Notice that it includes the group corporate-limited.
show service user-identification authentication-table authentication-source user lchen1 Domain: GLOBAL Source IP Username groups(Ref by policy) state 203.0.113.53 lchen1 corporate-limited Valid
The human-resources-p1 security policy source-identity field refers to the group corporate-limited. As shown above in the ClearPassauthentication entry for him, the user lchen1 belongs to that group. Here is the configuration for the human-resources-p1 referenced security policy:
from-zone human-resources-zone to-zone servers-zone {
policy human-resources-p1 {
match {
source-address any;
destination-address corporate-server;
application any;
source-identity "global\corporate-limited";
}
then {
permit;
}
}
}After you delete the human-resources-p1 security policy, whose source-identity parameter refers to the group called corporate-limited, enter the same command again. Notice that the authentication entry for lchen1 does not contain the corporate-limited group.
show service user-identification authentication-table authentication-source aruba-clearpass user lchen1 Domain: GLOBAL Source IP Username groups(Ref by policy) state 203.0.113.53 lchen1 Valid
Take a different approach in verifying the ClearPass authentication table state after the modification. Display the entire table to verify that the group—corporate-limited—is not included in any of the user entries. Note that if more than one user belonged to the corporate-limited group, authentication entries for all of the affected users would not show that group name.
From operational mode, enter the show services user-identification authentication-table authentication-source aruba-clearpass command.
show services user-identification authentication-table authentication-source aruba-clearpass Domain: GLOBAL Total entries: 6 Source IP Username groups(Ref by policy) state 203.0.113.21 viki2 accounting-grp-and-company-dev Valid 203.0.113.89 abew1 marketing-access-limited-grp Valid 203.0.113.52 jxchan marketing-access-for-pcs-limit Valid 203.0.113.53 lchen1 Valid 203.0.113.54 guest1 Valid 203.0.113.55 guest2 Valid
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.