- About This Guide
- Index
- Glossary
-
- Configuring IPSec and ISAKMP
- Configuring L2TP over IPSec
- Setting General VPN Parameters
- Configuring Tunnel Groups, Group Policies, and Users
- Configuring IP Addresses for VPN
- Configuring Remote Access VPNs
- Configuring Network Admission Control
- Configuring Easy VPN on the ASA 5505
- Configuring the PPPoE Client
- Configuring LAN-to-LAN VPNs
- Configuring Clientless SSL VPN
- Configuring AnyConnect VPN Client Connections
- Configuring AnyConnect Host Scan
Configuring the Identity Firewall
This chapter describes how to configure the ASA for the Identity Firewall. The chapter includes the following sections:
Information About the Identity Firewall
This section includes the following topics:
- Overview of the Identity Firewall
- Architecture for Identity Firewall Deployments
- Features of the Identity Firewall
- Deployment Scenarios
- Cut-through Proxy and VPN Authentication
- Collecting User Statistics
Overview of the Identity Firewall
In an enterprise, users often need access to one or more server resources. Typically, a firewall is not aware of the users’ identities and, therefore, cannot apply security policies based on identity. To configure per-user access policies, you must configure a user authentication proxy, which requires user interaction (a user name/password query).
The Identity Firewall in the ASA provides more granular access control based on users’ identities. You can configure access rules and security policies based on user names and user groups name rather than through source IP addresses. The ASA applies the security policies based on an association of IP addresses to Windows Active Directory login information and reports events based on the mapped user names instead of network IP addresses.
The Identity Firewall integrates with Microsoft Active Directory in conjunction with an external Active Directory (AD) Agent that provides the actual identity mapping. The ASA uses Windows Active Directory as the source to retrieve the current user identity information for specific IP addresses and allows transparent authentication for Active Directory users.
Identity-based firewall services enhance the existing access control and security policy mechanisms by allowing users or groups to be specified in place of source IP addresses. Identity-based security policies can be interleaved without restriction between traditional IP address based rules.
Architecture for Identity Firewall Deployments
The Identity Firewall integrates with Window Active Directory in conjunction with an external Active Directory (AD) Agent that provides the actual identity mapping.
The identity firewall consists of three components:
Though Active Directory is part of the Identity Firewall on the ASA, they are managed by Active Directory administrators. The reliability and accuracy of the data depends on data in Active Directory.
Supported versions include Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 servers.
The AD Agent runs on a Windows server. Supported Windows servers include Windows 2003, Windows 2008, and Windows 2008 R2.
Note Windows 2003 R2 is not supported for the AD Agent server.
Figure 36-1 Identity Firewall Components
Features of the Identity Firewall
The Identity Firewall has the following key features.
- The ASA can retrieve user identity and IP address mappings from the AD Agent by querying the AD Agent for each new IP address or by maintaining a local copy of the entire user identity and IP address database.
- Supports host group, subnet, or IP address for the destination of a user identity policy.
- Supports a fully qualified domain name (FQDN) for the source and destination of a user identity policy.
- Supports the combination of 5-tuple policies with ID-based policies. The identity-based feature works in tandem with existing 5-tuple solution.
- Supports usage with IPS and Application Inspection policies.
- Retrieves user identity information from remote access VPN, AnyConnect VPN, L2TP VPN and cut-through proxy. All retrieved users are populated to all ASA devices connected to the AD Agent.
- Each AD Agent supports 100 ASA devices. Multiple ASA devices are able to communicate with a single AD Agent to provide scalability in larger network deployments.
- Supports 30 Active Directory servers provided the IP address is unique among all domains.
- Each user identity in a domain can have up to 8 IP addresses.
- Supports up to 64,000 user identity-IP address mappings in active ASA policies for ASA 5500 Series models. This limit controls the maximum users who have policies applied. The total users are the aggregated users configured on all different contexts.
- Supports up to 1024 user identity-IP address mappings in active ASA policies for the ASA 5505.
- Supports up to 256 user groups in active ASA policies.
- A single rule can contain one or more user groups or users.
- Supports multiple domains.
- The ASA retrieves group information from Active Directory and falls back to web authentication for IP addresses that the AD Agent cannot map a source IP address to a user identity.
- The AD Agent continues to function when any of the Active Directory servers or the ASA are not responding.
- Supports configuring a primary AD Agent and a secondary AD Agent on the ASA. If the primary AD Agent stops responding, the ASA can switch to the secondary AD Agent.
- If the AD Agent is unavailable, the ASA can fall back to existing identity sources such as cut through proxy and VPN authentication.
- The AD Agent runs a watchdog process that automatically restarts its services when they are down.
- Allows a distributed IP address/user mapping database among ASA devices.
Deployment Scenarios
You can deploy the components of the Identity Firewall in the following ways depending on your environmental requirement.
As shown in Figure 36-2, you can deploy the components of the Identity Firewall to allow for redundancy. Scenario 1 shows a simple installation without component redundancy.
Scenario 2 also shows a simple installation without redundancy. However, in that deployment scenario, the Active Directory server and AD Agent are co-located on one Windows server.
Figure 36-2 Deployment Scenario without Redundancy
As shown in Figure 36-3, you can deploy the Identity Firewall components to support redundancy. Scenario 1 shows a deployment with multiple Active Directory servers and a single AD Agent installed on a separate Windows server. Scenario 2 shows a deployment with multiple Active Directory servers and multiple AD Agents installed on separate Windows servers.
Figure 36-3 Deployment Scenario with Redundant Components
As shown in Figure 36-4, all Identity Firewall components—Active Directory server, the AD Agent, and the clients—are installed and communicate on the LAN.
Figure 36-4 LAN -based Deployment
Figure 36-5 shows a WAN-based deployment to support a remote site. The Active Directory server and the AD Agent are installed on the main site LAN. The clients are located at a remote site and connect to the Identity Firewall components over a WAN.
Figure 36-5 WAN-based Deployment
Figure 36-6 also shows a WAN-based deployment to support a remote site. The Active Directory server is installed on the main site LAN. However, the AD Agent is installed and access by the clients at the remote site. The remote clients connect to the Active Directory servers at the main site over a WAN.
Figure 36-6 WAN-based Deployment with Remote AD Agent
Figure 36-7 shows an expanded remote site installation. An AD Agent and Active Directory servers are installed at the remote site. The clients access these components locally when logging into network resources located at the main site. The remote Active Directory server must synchronize its data with the central Active Directory servers located at the main site.
Figure 36-7 WAN-based Deployment with Remote AD Agent and AD Servers
Cut-through Proxy and VPN Authentication
In an enterprise, some users log onto the network by using other authentication mechanisms, such as authenticating with a web portal (cut-through proxy) or by using a VPN. For example, users with a Machintosh and Linux client might log in a web portal (cut-through proxy) or by using a VPN. Therefore, you must configure the Identity Firewall to allow these types of authentication in connection with identity-based access policies.
Figure 36-8 shows a deployment to support a cut-through proxy authentication captive portal. Active Directory servers and the AD Agent are installed on the main site LAN. However, the Identity Firewall is configured to support authentication of clients that are not part of the Active Directory domain.
Figure 36-8 Deployment Supporting Cut-through Proxy Authentication
The ASA designates users logging in through a web portal (cut-through proxy) as belonging to the Active Directory domain with which they authenticated.
The ASA designates users logging in through a VPN as belonging to the LOCAL domain unless the VPN is authenticated by LDAP with Active Directory, then the Identity Firewall can associate the users with their Active Directory domain.
The ASA reports users logging in through VPN authentication or a web portal (cut-through proxy) to the AD Agent, which distributes the user information to all registered ASA devices. Specifically, the user identity-IP address mappings of authenticated users are forwarded to all ASA contexts that contain the input interface where packets are received and authenticated.
Licensing for the Identity Firewall
The following table shows the licensing requirements for this feature:
|
|
---|---|
Guidelines and Limitations
This section includes the guidelines and limitations for this feature.
Supported in single and multiple context mode.
Supported in routed and transparent firewall modes.
The Identity Firewall supports user identity-IP address mappings and AD Agent status replication from active to standby when stateful failover is enabled. However, only user identity-IP address mappings, AD Agent status, and domain status are replicated. User and user group records are not replicated to the standby ASA.
When failover is configured, the standby ASA must also be configured to connect to the AD Agent directly to retrieve user groups. The standby ASA does not send NetBIOS packets to clients even when the NetBIOS probing options are configured for the Identity Firewall.
When a client is determined as inactive by the active ASA, the information is propagated to the standby ASA. User statistics are not propagated to the standby ASA.
When you have failover configured, you must configure the AD Agent to communicate with both the active and standby ASA devices. See the Installation and Setup Guide for the Active Directory Agent for the steps to configure the ASA on the AD Agent server.
The AD Agent supports endpoints with IPv6 addresses. It can receive IPv6 addresses in log events, maintain them in its cache, and send them through RADIUS messages.
Additional Guidelines and Limitations
- A full URL as a destination address is not supported.
- For NetBIOS probing to function, the network between the ASA, AD Agent, and clients must support UDP-encapsulated NetBIOS traffic.
- MAC address checking by the Identity Firewall does not work when intervening routers are present. Users logged onto clients that are behind the same router have the same MAC addresses. With this implementation, all the packets from the same router are able to pass the check, because the ASA is unable to ascertain to the actual MAC addresses behind the router.
- The following ASA features do not support using the identity-based object and FQDN:
– group-policy (except VPN filter)
See Configuring Identity-based Access Rules.
- When you use the Cisco Context Directory Agent (CDA) in conjunction with the ASA or Cisco Ironport Web Security Appliance (WSA), make sure that you open the following ports:
– Authentication port for UDP—1645
– Accounting port for UDP—1646
The listening port is used to send change of authentication requests from the CDA to the ASA or to the WSA.
- For domain names, the following characters are not valid: \/:*?"<>|. For naming conventions, see http://support.microsoft.com/kb/909264.
- For usernames, the following characters are not valid: \/[]:;=,+*?"<>|@.
- For user groups, the following characters are not valid: \/[]:;=,+*?"<>|.
Prerequisites
Before configuring the Identity Firewall in the ASA, you must meet the prerequisites for the AD Agent and Microsoft Active Directory.
The AD Agent must be installed on a Windows server that is accessible to the ASA. Additionally, you must configure the AD Agent to obtain information from the Active Directory servers. Configure the AD Agent to communicate with the ASA.
Supported Windows servers include Windows 2003, Windows 2008, and Windows 2008 R2.
Note Windows 2003 R2 is not supported for the AD Agent server.
For the steps to install and configure the AD Agent, see the Installation and Setup Guide for the Active Directory Agent.
Before configuring the AD Agent in the ASA, obtain the secret key value that the AD Agent and the ASA use to communicate. This value must match on both the AD Agent and the ASA.
Microsoft Active Directory must be installed on a Windows server and accessible by the ASA. Supported versions include Windows 2003, 2008, and 2008 R2 servers.
Before configuring the Active Directory server on the ASA, create a user account in Active Directory for the ASA.
Additionally, the ASA sends encrypted log in information to the Active Directory server by using SSL enabled over LDAP. SSL must be enabled on the Active Directory server. See the documentation for Microsft Active Diretory for the steps to enable SSL for Active Directory.
Note Before running the AD Agent Installer, you must install the following patches on every Microsoft Active Directory server that the AD Agent monitors. These patches are required even when the AD Agent is installed directly on the domain controller server. See the README First for the Cisco Active Directory Agent.
Configuring the Identity Firewall
Task Flow for Configuring the Identity Firewall
Before configuring the Identity Firewall in the ASA, you must meet the prerequisites for the AD Agent and Microsoft Active Directory. See Prerequisites for information.
To configure the Identity Firewall, perform the following tasks:
Step 1 Configure the Active Directory domain in the ASA.
See Configuring the Active Directory Domain.
See also Deployment Scenarios for the ways in which you can deploy the Active Directory servers to meet your environment requirements.
Step 2 Configure the AD Agent in ASA.
See Configuring Active Directory Agents.
See also Deployment Scenarios for the ways in which you can deploy the AD Agents to meet your environment requirements.
Step 3 Configure Identity Options.
See Configuring Identity Options.
Step 4 Configure Identity-based Access Rules in the ASA.
After AD domain and AD-Agent are configured, identity-based rules can be specified to enforce identity-based rules. See Configuring Identity-based Access Rules.
Step 5 Configure the cut-through proxy.
See Configuring Cut-through Proxy Authentication.
Step 6 Configure VPN authentication.
See Configuring VPN Authentication.
Configuring the Active Directory Domain
Active Directory domain configuration on the ASA is required for the ASA to download Active Directory groups and accept user identities from specific domains when receiving IP-user mapping from the AD Agent.
Prerequisites
- Active Directory server IP address
- Distinguished Name for LDAP base dn
- Distinguished Name and password for the Active Directory user that the Identity Firewall uses to connect to the Active Directory domain controller
To configure the Active Directory domain, perform the following steps:
What to Do Next
Configure AD Agents. See Configuring Active Directory Agents.
Configuring Active Directory Agents
Periodically or on-demand, the AD Agent monitors the Active Directory server security event log file via WMI for user login and logoff events. The AD Agent maintains a cache of user ID and IP address mappings. and notifies the ASA of changes.
Configure the primary and secondary AD Agents for the AD Agent Server Group. When the ASA detects that the primary AD Agent is not responding and a secondary agent is specified, the ASA switches to secondary AD Agent. The Active Directory server for the AD agent uses RADIUS as the communication protocol; therefore, you should specify a key attribute for the shared secret between ASA and AD Agent.
To configure the AD Agents, perform the following steps:
What to Do Next
Configure access rules for the Identity Firewall. See Configuring Identity-based Access Rules.
Configuring Identity Options
Perform this procedure to add or edit the Identity Firewall feature; select the Enable check box to enable the feature. By default, the Identity Firewall feature is disabled.
Prerequisites
Before configuring the identify options for the Identity Firewall, you must you must meet the prerequisites for the AD Agent and Microsoft Active Directory. See Prerequisites the requirements for the AD Agent and Microsoft Active Directory installation.
To configure the Identity Options for the Identity Firewall, perform the following steps:
What to Do Next
Configure the Active Directory domain and server groups. See Configuring the Active Directory Domain.
Configure AD Agents. See Configuring Active Directory Agents.
Configuring Identity-based Access Rules
An access rule permits or denies traffic based on the protocol, a source and destination IP address or network, and the source and destination ports. For information about access rules, see in Chapter32, “Configuring Access Rules”
The Identity Firewall feature adds the ability to permit or deny traffic based on a users’ identities or based on a user group. You configure access rules and security policies based on user names and user groups name in addition to source IP addresses. The ASA applies the security policies based on an association of IP addresses to Windows Active Directory login information and reports events based on the mapped user names instead of network IP addresses.
Users can be local, remote (via VPN), wired or wireless. Server resources can include server IP address, server DNS name, or domain.
Identity-based access rules follow the same general format that standard IP-address-based rules follow: action, protocol, source, destination, and optional source service when the protocol for the rule is TCP or UDP. In addition, they include specifying user and user group objects before traditional IP-address-based objects—any, network object/network group, interface, host, IP address, and network mask.
You can create access rules that solely contain identity-based objects (users and user groups) or combine identity-based objects with traditional IP-address-based objects. You can create an access rule that includes a source user or source user group from a qualifying IP-address-based source. For example, you could create and access rule for sample_user1 11.0.0.0 255.0.0.0, meaning the user could have any IP address on subnet 11.0.0.0/8.
You can create an access rule with the fully-qualified domain name (FQDN) in the source and the destination. For example:
You also need to configure the DNS server group on the ASA so that it can perform a DNS lookup for the FQDN.
The destination portion of an identity-based access rule follows the same format and guidelines as traditional IP-address-based access rules.
Guidelines and Limitations
- Supports up to 64,000 user identity-IP address mappings in active ASA policies for ASA 5500 Series models.
This limit controls the maximum users who have policies applied. The total users are the aggregated users configured on all different contexts.
This limit controls the maximum users who have policies applied. The total users are the aggregated users configured on all different contexts.
Prerequisites
After AD domain and AD-Agent are configured, Identity-based rules can be specified to enforce identity-based rules.
To configure identity-based access rules, perform the following steps:
|
|
|
---|---|---|
|
Defines object groups that you can use to control access with the Identity Firewall. You can use the object group as part of an access group or service policy. |
|
|
Specifies the user to add to the access rule. The user_name can contain any character including [a-z], [A-Z], [0-9], [!@#$%^&()-_{}. ]. If domain_NetBIOS_name \ user _ name contains a space, you must enclose the domain name and user name in quotation marks. The user _ name can be part of the LOCAL domain or a user imported by the ASA from Active Directory domain. If the domain_NetBIOS_name is associated with a AAA server, the user _ name must be the Active Directory sAMAccountName, which is unique, instead of the common name (cn), which might not be unique. The domain_NetBIOS_name can be LOCAL or the actual domain name as specified in user - identity domain domain_NetBIOS_name aaa - server aaa _ serve r_ group _ tag command. |
|
|
Specifies a user group to add to the access rule. The group_name can contain any character including [a-z], [A-Z], [0-9], [!@#$%^&()-_{}. ]. If domain _ NetBIOS_name \ group _ name contains a space, you must enclose the domain name and user name in quotation marks. Specifying the domain_NetBIOS_name for user - group has the same requirements as specifying it for user. The ASA imports the nested user groups from in Active Directory when the access rule is used in an access group or service policy. |
|
|
Exit from the configure user object group mode to the global configuration mode. |
|
|
Creates an access control entry that controls access using user identity or group identity. You can specify [ domain _ nickname >\] user _ name and [ domain _ nickname >\] user _ group _ name directly without specifying them in an object-group first. See the access - list extended command in the Cisco ASA 5500 Series Command Reference for a complete description of the command syntax. The keywords user - group any and user - group none can be specified to support cut-through proxy authentication. See Configuring Cut-through Proxy Authentication. |
|
|
Applies a single set of global rules to all interfaces with the single command. |
Configuring Cut-through Proxy Authentication
In an enterprise, some users log onto the network by using other authentication mechanisms, such as authenticating with a web portal (cut-through proxy) or by using a VPN. For example, users with a Machintosh and Linux client might log in a web portal (cut-through proxy) or by using a VPN. Therefore, you must configure the Identity Firewall to allow these types of authentication in connection with identity-based access policies.
The ASA designates users logging in through a web portal (cut-through proxy) as belonging to the Active Directory domain with which they authenticated. The ASA designates users logging in through a VPN as belonging to the LOCAL domain unless the VPN is authenticated by LDAP with Active Directory, then the Identity Firewall can associate the users with their Active Directory domain. The ASA reports users logging in through VPN authentication or a web portal (cut-through proxy) to the AD Agent, which distributes the user information to all registered ASA devices.
Users can log in by using HTTP/HTTPS, FTP, Telnet, or SSH. When users log in with these authentication methods, the following guidelines apply:
- For HTTP/HTTPS traffic, an authentication window appears for unauthenticated users.
- For Telnet and FTP traffic, users must log in through the cut-through proxy and again to Telnet and FTP server.
- A user can specify an Active Directory domain while providing login credentials (in the format domain \ username). The ASA automatically selects the associated AAA server group for the specified domain.
- If a user specifies an Active Directory domain while providing login credentials (in the format domain \ username), the ASA parses the domain and uses it to select an authentication server from the AAA servers configured for the Identity Firewall. Only the username is passed to the AAA server.
- If the backslash (\) delimiter is not found in the log in credentials, the ASA does not parse a domain and authentication is conducted with the AAA server that corresponds to default domain configured for the Identity Firewall.
- If a default domain or a server group is not configured for that default domain, the ASA rejects the authentication.
- If the domain is not specified, the ASA selects the AAA server group for the default domain that is configured for the Identity Firewall.
Detailed Steps
To configure the cut-through proxy for the Identity Firewall, perform the following steps:
Examples
This example shows a typical cut-through proxy configuration to allow a user to log in through the ASA. In this example, the following conditions apply:
- The ASA IP address is 172.1.1.118.
- The Active Directory domain controller has the IP address 71.1.2.93.
- The end user client has the IP address 172.1.1.118 and uses HTTPS to log in through a web portal.
- The user is authenticated by the Active Directory domain controller via LDAP.
- The ASA uses the inside interface to connect to the Active Directory domain controller on the corporate network.
In this example, the following guidelines apply:
- In access - list commands, “permit user NONE” rules should be written before the “access-list 100 ex deny any any” to allow unauthenticated incoming users trigger AAA Cut-Through Proxy.
- In auth access-list command, “permit user NONE” rules guarantee only unauthenticated trigger Cut-Through Proxy. Ideally they should be the last lines.
Configuring VPN Authentication
In an enterprise, some traffic might need to bypass the Identity Firewall.
The ASA reports users logging in through VPN authentication or a web portal (cut-through proxy) to the AD Agent, which distributes the user information to all registered ASA devices. Specifically, the IP-user mapping of authenticated users is forwarded to all ASA contexts that contain the input interface where HTTP/HTTPS packets are received and authenticated. The ASA designates users logging in through a VPN as belonging the LOCAL domain.
There are two different ways to apply IDFW rules on VPN users.
- Apply VPN-Filter with bypassing access-list check disabled
- Apply VPN-Filter with bypassing access-list check enabled
Configuration Example -- VPN with IDFW Rule -1
By default, “sysopt connection permit-vpn" is enabled and VPN traffic is exempted from access-list check. In order to apply regular interface based ACL rules for VPN traffic, VPN traffic access-list bypassing needs to be disabled.
In the this example, if the user logs in from outside interface, the IDFW rules will control what network resource he can access. All VPN users are be stored under domain LOCAL. Therefore, it is only meaningful to apply the rules over LOCAL users or object-group containing LOCAL users.
Configuration ExampleVPN with IDFW Rule -2
By default, "sysopt connection permit-vpn" is enabled, with VPN traffic access bypassing enabled. VPN-filter can be used to apply the IDFW rules on the VPN traffic. VPN-filter with IDFW rules can be defined in CLI username and group-policy.
In the example, when user idfw logs in, he is able to access to network resources in 10.0.00/24 subnet. However, when user user1 loggs in, his access to network resources in 10.0.00/24 subnet will be denied. Note that all VPN users will be stored under domain LOCAL. Therefore, it is only meaningful to apply the rules over LOCAL users or object-group containing LOCAL users.
Note: IDFW rules can only be aplpied to vpn-filter under group-policy and are not available in all the other group-policy features.
Collecting User Statistics
To activate the collection of user statistics by the Modular Policy Framework and match lookup actions for the Identify Firewall, enter the following command:
Monitoring the Identity Firewall
This section contains the following topics:
- Monitoring AD Agents
- Monitoring Groups
- Monitoring Memory Usage for the Identity Firewall
- Monitoring Users for the Identity Firewall
Monitoring AD Agents
You can monitor the AD Agent component of the Identity Firewall.
Use the following options of the show user-identity command to obtain troubleshooting information for the AD Agent:
These commands display the following information about the primary and secondary AD Agents:
Monitoring Groups
You can monitor the user groups configured for the Identity Firewall.
Use the show user-identity group command to obtain troubleshooting information for the user groups configured for the Identity Firewall:
Monitoring Memory Usage for the Identity Firewall
You can monitor the memory usage that the Identity Firewall consumes on the ASA.
Use the show user-identity memory command to obtain troubleshooting information for the Identity Firewall:
The command displays the memory usage in bytes of various modules in the Identity Firewall:
The ASA sends an LDAP query for the Active Directory groups configured on the Active Directory server. The Active Directory server authenticates users and generates user logon security logs.
Note How you configure the Identity Firewall to retrieve user information from the AD Agent impacts the amount of memory used by the feature. You specify whether the ASA uses on demand retrieval or full download retrieval. Selecting On Demand has the benefit of using less memory as only users of received packets are queried and stored. See Configuring Identity Options for a description of these options.
Monitoring Users for the Identity Firewall
You can display information about all users contained in the IP-user mapping database used by the Identity Firewall.
Use the following options of the show user-identity command to obtain troubleshooting information for the AD Agent:
These commands display the following information for users:
The default domain name can be the real domain name, a special reserved word, or LOCAL. The Identity Firewall uses the LOCAL domain name for all locally defined user groups or locally defined users (users who log in and authenticate by using a VPN or web portal). When default domain is not specified, the default domain is LOCAL.
The idle time is stored on a per user basis instead of per the IP address of a user.
Note The first three tabs in the
If the commands user - identity action domain - controller - down domain _ name disable - user - identity - rule is configured and the specified domain is down, or if user - identity action ad - agent - down disable - user - identity - rule is configured and AD Agent is down, all the logged on users have the status disabled.
Feature History for the Identity Firewall
Table 36-1 lists the release history for this feature.