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

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.

The key benefits of the Identity Firewall include:

  • Decoupling network topology from security policies
  • Simplifying the creation of security policies
  • Providing the ability to easily identify user activities on network resources
  • Simplify user activity monitoring

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:

  • ASA
  • Microsoft Active Directory

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.

  • Active Directory (AD) Agent

The AD Agent runs on a Windows server. Supported Windows servers include Windows 2003, Windows 2008, and Windows 2008 R2.

note.gif

Noteblank.gif Windows 2003 R2 is not supported for the AD Agent server.


Figure 36-1 Identity Firewall Components

access_idfw-4.jpg

 

1

On the ASA : Configure local user groups and Identity Firewall policies.

4

Client <-> ASA : The client logs onto the network through Microsoft Active Directory. The AD Server authenticates users and generates user logon security logs.

Alternatively, the client can log onto the network through a cut-through proxy or by using VPN.

2

ASA <-> AD Server : The ASA sends an LDAP query for the Active Directory groups configured on the AD Server.

The ASA consolidates local and Active Directory groups and applies access rules and MPF security policies based on user identity.

5

ASA <-> Client : Based on the policies configured on the ASA, it grants or denies access to the client.

If configured, the ASA probes the NetBIOS of the client to pass inactive and no-response users.

3

ASA <-> AD Agent : Depending on the Identity Firewall configuration, the ASA downloads the IP-user database or sends a RADIUS request to the AD Agent querying the user’s IP address.

The ASA forwards the new mappings learned from web authentication and VPN sessions to the AD Agent.

6

AD Agent <-> AD Server : Periodically or on-demand, the AD Agent monitors the AD Server security event log file via WMI for client login and logoff events.

The AD Agent maintains a cache of user ID and IP address mappings. and notifies the ASA of changes.

The AD Agent sends logs to a syslog server.

Features of the Identity Firewall

The Identity Firewall has the following key features.

Flexibility

  • 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.

Scalability

  • 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.

Availability

  • 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

access_idfw-5.jpg

 

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

access_idfw-6.jpg

 

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

access_idfw-7.jpg

 

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

access_idfw-8.jpg

 

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

access_idfw-9.jpg

 

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

access_idfw-10.jpg

 

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

access_idfw-11.jpg

 

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.

See Configuring Cut-through Proxy Authentication.

Licensing for the Identity Firewall

The following table shows the licensing requirements for this feature:

 

Model
License Requirement

All models

Base License.

Guidelines and Limitations

This section includes the guidelines and limitations for this feature.

Context Mode Guidelines

Supported in single and multiple context mode.

Firewall Mode Guidelines

Supported in routed and transparent firewall modes.

Failover Guidelines

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.

IPv6 Guidelines

  • Supports IPv6.

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.

  • NetBIOS over IPv6 is not supported
  • Cut through proxy over IPv6 is not supported.

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:

blank.gif route-map

blank.gif Crypto map

blank.gif WCCP

blank.gif NAT

blank.gif group-policy (except VPN filter)

blank.gif DAP

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:

blank.gif Authentication port for UDP—1645

blank.gif Accounting port for UDP—1646

blank.gif Listening port for UDP—3799

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.

AD Agent

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.gif

Noteblank.gif 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

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.gif

Noteblank.gif 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

This section contains the following topics:

Task Flow for Configuring the Identity Firewall

Prerequisite

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.

Task Flow in the ASA

To configure the Identity Firewall, perform the following tasks:


Step 1blank.gif 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 2blank.gif 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 3blank.gif Configure Identity Options.

See Configuring Identity Options.

Step 4blank.gif 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 5blank.gif Configure the cut-through proxy.

See Configuring Cut-through Proxy Authentication.

Step 6blank.gif 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:

 

Command
Purpose

Step 1

hostname(config)# aaa-server server-tag protocol ldap
Example:
hostname(config)# aaa-server adserver protocol ldap

Creates the AAA server group and configures AAA server parameters for the Active Directory server.

Step 2

hostname(config-aaa-server-group)# aaa-server server-tag [( interface-name)] host { server-ip | name } [ key ] [ timeout seconds ]
Example:

hostname(config-aaa-server-group)# aaa-server adserver (mgmt) host 172.168.224.6

For the Active Directory server, configures the AAA server as part of a AAA server group and the AAA server parameters that are host-specific.

Step 3

hostname( config-aaa-server-host)# ldap-base-dn string
Example:
hostname(config-aaa-server-host)# ldap-base-dn DC=SAMPLE,DC=com

Specifies the location in the LDAP hierarchy where the server should begin searching when it receives an authorization request.

Specifying the ldap-base-dn command is optional. If you do not specify this command, the ASA retrieves the defaultNamingContext from Active Directory and uses it as the base DN.

Step 4

hostname(config-aaa-server-host)# ldap-scope subtree

Specifies the extent of the search in the LDAP hierarchy that the server should make when it receives an authorization request.

Step 5

hostname(config-aaa-server-host)# ldap-login-password string
Example:
hostname(config-aaa-server-host)# ldap-login-password obscurepassword

Specifies the login password for the LDAP server.

Step 6

hostname(config-aaa-server-host)# ldap-login-dn string
Example:
hostname(config-aaa-server-host)#ldap-login-dn SAMPLE\user1

Specifies the name of the directory object that the system should bind this as. The ASA identifies itself for authenticated binding by attaching a Login DN field to the user authentication request. The Login DN field describes the authentication characteristics of the ASA.

Where string is a case-sensitive string of up to 128 characters that specifies the name of the directory object in the LDAP hierarchy. Spaces are not permitted in the string, but other special characters are allowed.

You can specify the traditional or simplified format.

The traditional ldap-login-dn in format includes: CN=username,OU=Employees,OU=Sample Users,DC=sample,DC=com is accepted also.

Step 7

hostname(config-aaa-server-host)# server-type microsoft

Configures the LDAP server model for the Microsoft Active Directory server.

Step 8

hostname(config-aaa-server-host)# ldap-group-base-dn string
Example:
hostname(config-aaa-server-host)# ldap-group-base-dn OU=Sample Groups,DC=SAMPLE,DC=com

Specifies location of the Active Directory groups configuration in the Active Directory domain controller. If not specified, the value in ldap-base-dn is used.

Specifying the ldap-group-base-dn command is optional.

Step 9

hostname(config-aaa-server-host)# ldap-over-ssl enable

Allows the ASA to access the Active Directory domain controller over SSL. To support LDAP over SSL, Active Directory server needs to be configured to have this support.

By default, Active Directory does not have SSL configured. If SSL is not configured on on Active Directory, you do not need to configure it on the ASA for the Identity Firewall.

Step 10

hostname(config-aaa-server-host)# server-port port-number
Examples:
hostname(config-aaa-server-host)# server-port 389
hostname(config-aaa-server-host)# server-port 636

By default, if ldap-over-ssl is not enabled, the default server-port is 389; if ldap-over-ssl is enabled, the default server-port is 636.

Step 11

hostname(config-aaa-server-host)# group-search-timeout seconds
Examples:
hostname(config-aaa-server-host)# group-search-timeout 300

Sets the amount of time before LDAP queries time out.

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.

Requirement

  • AD agent IP address
  • Shared secret between ASA and AD agent

To configure the AD Agents, perform the following steps:

 

Command
Purpose

Step 1

hostname(config)# aaa-server server-tag protocol radius
Example:
hostname(config)# aaa-server adagent protocol radius

Creates the AAA server group and configures AAA server parameters for the AD Agent.

Step 1

hostname(config)# ad-agent-mode

Enables the AD Agent mode.

Step 2

hostname(config-aaa-server-group)# aaa-server server-tag [( interface-name)] host { server-ip | name } [ key ] [ timeout seconds ]
Example:
hostname(config-aaa-server-group)# aaa-server adagent (inside) host 192.168.1.101

For the AD Agent, configures the AAA server as part of a AAA server group and the AAA server parameters that are host-specific.

Step 3

hostname(config-aaa-server-host)# key key
Example:
hostname(config-aaa-server-host)# key mysecret

Specifies the server secret value used to authenticate the ASA to the AD Agent server.

Step 4

hostname(config-aaa-server-host)# user-identity ad-agent aaa-server aaa_server_group_tag
Examples:
hostname(config-aaa-server-hostkey)# user-identity ad-agent aaa-server adagent

Defines the server group of the AD Agent.

The first server defined in aaa_server_group_tag variable is the primary AD Agent and the second server defined is the secondary AD Agent.

The Identity Firewall supports defining only two AD-Agent hosts.

When ASA detects the primary AD Agent is down and a secondary agent is specified, it switches to secondary AD Agent. The aaa-server for the AD agent uses RADIUS as the communication protocol, and should specify key attribute for the shared secret between ASA and AD Agent.

Step 5

hostname(config-aaa-server-host)# test aaa-server ad-agent

Tests the communication between the ASA and the AD Agent server.

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:

 

Command
Purpose

Step 1

hostname(config)# user-identity enable

Enables the Identity Firewall feature.

Step 2

hostname(config)# user-identity default-domain domain_NetBIOS_name
Example:
hostname(config)# user-identity default-domain SAMPLE

Specifies the default domain for the Identity Firewall.

For domain_NetBIOS_name, enter a name up to 32 characters consisting of [a-z], [A-Z], [0-9], [!@#$%^&()-_=+[]{};,. ] except '.' and ' ' at the first character. If the domain name contains a space, enclose the entire name in quotation marks. The domain name is not case sensitive.

The default domain is used for all users and user groups when a domain has not been explicitly configured for those users or groups. When a default domain is not specified, the default domain for users and groups is LOCAL. For multiple context modes, you can set a default domain name for each context, as well as within the system execution space.

Note The default domain name you specify must match the NetBIOS domain name configured on the Active Directory domain controller. If the domain name does not match, the AD Agent will incorrectly associate the user identity-IP address mappings with the domain name you enter when configuring the ASA. To view the NetBIOS domain name, open the Active Directory user event security log in any text editor.

The Identity Firewall uses the LOCAL domain for all locally defined user groups or locally defined users. Users logging in through a web portal (cut-through proxy) are designated as belonging to the Active Directory domain with which they authenticated. Users logging in through a VPN are designated 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.

Step 3

hostname(config)# user-identity domain domain_nickname aaa-server aaa_server_group_tag
Example:
hostname(config)# user-identity domain SAMPLE aaa-server ds

Associates the LDAP parameters defined for the AAA server for importing user group queries with the domain name.

For domain_nickname, enter a name up to 32 characters consisting of [a-z], [A-Z], [0-9], [!@#$%^&()-_=+[]{};,. ] except '.' and ' ' at the first character. If the domain name contains a space, you must enclose that space character in quotation marks. The domain name is not case sensitive.

Step 4

hostname(config)# user-identity logout-probe netbios local-system probe-time minutes minutes retry-interval seconds seconds retry-count times [ user-not-needed | match-any | exact-match ]
Example:
hostname(config)# user-identity logout-probe netbios local-system probe-time minutes 10 retry-interval seconds 10 retry-count 2 user-not-needed

Enables NetBIOS probing. Enabling this option configures how often the ASA probes the user client IP address to determine whether the client is still active. By default, NetBIOS probing is disabled.

To minimize the NetBIOS packets, the ASA only sends a NetBIOS probe to a client when the user has been idle for more than the specified number of minutes.

Set the NetBIOS probe timer from1 to 65535 minutes and the retry interval from 1 to 256 retries. Specify the number of times to retry the probe:

  • match - any —As long as the NetBIOS response from the client contains the user name of the user assigned to the IP address, the user identity is be considered valid. Specifying this option requires that the client enabled the Messenger service and configured a WINS server.
  • exact - match —The user name of the user assigned to the IP address must be the only one in the NetBIOS response. Otherwise, the user identity of that IP address is considered invalid. Specifying this option requires that the client enabled the Messenger service and configured a WINS server.
  • user - not - needed —As long as the ASA received a NetBIOS response from the client the user identity is considered valid.

The Identity Firewall only performs NetBIOS probing for those users identities that are in the active state and exist in at least one security policy. The ASA does not perform NetBIOS probing for clients where the users logged in through cut-through proxy or by using VPN.

Step 5

hostname(config)# user-identity inactive-user-timer minutes minutes
Example:
hostname(config)# user-identity inactive-user-timer minutes 120

Specifies the amount of time before a user is considered idle, meaning the ASA has not received traffic from the user's IP address for specified amount of time.

When the timer expires, the user's IP address is marked as inactive and removed from the local cached user identity-IP address mappings database and the ASA no longer notifies the AD Agent about that IP address removal. Existing traffic is still allowed to pass. When this command is specified, the ASA runs an inactive timer even when the NetBIOS Logout Probe is configured.

By default, the idle timeout is set to 60 minutes.

Note The Idle Timeout option does not apply to VPN or cut through proxy users.

Step 6

hostname(config)# user-identity poll-import-user-group-timer hours hours
Example:
hostname(config)# user-identity poll-import-user-group-timer hours 1

Specifies the amount of time before the ASA queries the Active Directory server for user group information.

If a user is added to or deleted from to an Active Directory group, the ASA received the updated user group after import group timer runs.

By default, the poll - import - user - group - timer is 8 hours.

To immediately update user group information, enter the following command:

user-identity update import-user

See the CLI configuration guide

Step 7

hostname(config)# user-identity action netbios-response-fail remove-user-ip

Specifies the action when a client does not respond to a NetBIOS probe. For example, the network connection might be blocked to that client or the client is not active.

When the user - identity action remove - user - ip is configured, the ASA removed the user identity-IP address mapping for that client.

By default, this command is disabled.

Step 8

hostname(config)# user-identity action domain-controller-down domain_nickname disable-user-identity-rule
Example:
hostname(config)# user-identity action domain-controller-down SAMPLE disable-user-identity-rule

Specifies the action when the domain is down because Active Directory domain controller is not responding.

When the domain is down and the disable - user - identity - rule keyword is configured, the ASA disables the user identity-IP address mappings for that domain. Additionally, the status of all user IP addresses in that domain are marked as disabled in the output displayed by the show user - identity user command.

By default, this command is disabled.

Step 9

hostname(config)# user-identity user-not-found enable

Enables user-not-found tracking. Only the last 1024 IP addresses tracked.

By default, this command is disabled.

Step 10

hostname(config)# user-identity action ad-agent-down disable-user-identity-rule

Specifies the action when the AD Agent is not responding.

When the AD Agent is down and the user - identity action ad-agent-down is configured, the ASA disables the user identity rules associated with the users in that domain. Additionally, the status of all user IP addresses in that domain are marked as disabled in the output displayed by the show user - identity user command.

By default, this command is disabled.

Step 11

hostname(config)# user-identity action mac-address-mismatch remove-user-ip

Specifies the action when a user's MAC address is found to be inconsistent with the ASA device IP address currently mapped to that MAC address.

When the user - identity action mac-address-mismatch command is configured, the ASA removes the user identity-IP address mapping for that client.

By default, the ASA uses the remove - user - ip keyword when this command is specified.

Step 12

hostname(config)# user-identity ad-agent active-user-database { on-demand | full-download }
Example:
hostname(config)# user-identity ad-agent active-user-database full-download

Defines how the ASA retrieves the user identity-IP address mapping information from the AD Agent:

  • full-download —Specifies that the ASA send a request to the AD Agent to download the entire IP-user mapping table when the ASA starts and then to receive incremental IP-user mapping when users log in and log out.
  • on-demand —Specifies that the ASA retrieve the user mapping information of an IP address from the AD Agent when the ASA receives a packet that requires a new connection and the user of its source IP address is not in the user-identity database.

By default, the ASA 5505, uses the on-demand option. The other ASA platforms use the full-download option.

Full downloads are event driven, meaning that subsequent requests to download the database, send just the updates to the user identity-IP address mapping database.

When the ASA registers a change request with the AD Agent, the AD Agent sends a new event to the ASA.

Step 13

hostname(config)# user-identity ad-agent hello-timer seconds seconds retry-times number
Example:
hostname(config)# user-identity ad-agent hello-timer seconds 20 retry-times 3

Defines the hello timer between the ASA and the AD Agent.

The hello timer between the ASA and the AD Agent defines how frequently the ASA exchanges hello packets. The ASA uses the hello packet to obtain ASA replication status (in-sync or out-of-sync) and domain status (up or down). If the ASA does not receive a response from the AD Agent, it resends a hello packet after the specified interval.

By default, the hello timer is set to 30 seconds and 5 retries.

Step 14

hostname(config)# user-identity ad-agent aaa-server aaa_server_group_tag
Example:
hostname(config)# user-identity ad-agent aaa-server adagent

Defines the server group of the AD Agent.

For aaa_server_group_tag, enter the value defined by the aaa-server command.

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:

hostname (config)# object network src
fqdn www.cisco.com
 
hostname (config)# object network dst
fqdn google.com
 
hostname (config)# access-list abc extended permit ip object src any
hostname (config)# access-list abc extended permit ip any object dst
hostname (config)# access-list abc extended permit ip object src object dst
 

You also need to configure the DNS server group on the ASA so that it can perform a DNS lookup for the FQDN.

For example:

hostname (config)# dns domain-lookup cisco
DNS server-group DefaultDNS
expire-entry-timer minutes 120
poll-timer minutes 120
name-server 171.70.168.183
 

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.

  • Supports up to 1024 user identity-IP address mappings in active ASA policies for the ASA 5505.

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 256 user groups in active ASA security policies.
  • A single rule can contain one or more user groups or users.

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:

 

Command
Purpose

Step 1

hostname(config)# object-group user user _ group _name
Examples:
hostname(config)# object-group user users1

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.

Step 2

hostname(config-user-object-group)# user domain_NetBIOS_name \ user_name
Examples:
hostname(config-user-object-group)# user SAMPLE\users1

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.

Step 3

hostname(config-user-object-group)# user - group domain _ _NetBIOS_name \\ user _ group_name
Examples:
hostname(config-user-object-group)# user-group SAMPLE\\group.marketing

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.

Step 4

hostname(config-user-object-group)# exit

Exit from the configure user object group mode to the global configuration mode.

Step 5

hostname(config)# access-list access _ list _ name { deny | permit } protocol [{ user-group [ domain_name \\ ] user_group_name | user {[ domain_name \\ ] user_name | any | none } | object-group-user object_group_user_name }] { any | host sip | sip smask | interface name | object src_object_name | object-group network_object_group_name > [ eq port | …] { object-group-user dst_object_group_name | object dst_object_name host dst_host_name | ip_address } [ object-group service_object_name | eq port | …]
 
Examples:
hostname(config)# access-list identity-list1 permit ip user SAMPLE\user1 any any
hostname(config)# access-list aclname extended permit ip user-group SAMPLE\\group.marketing any any
hostname(config)# access-list aclname extended permit ip object-group-user asausers any any
 

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.

Step 6

hostname(config)# access-group access-list global
Examples:
hostname(config)# access-group aclname global

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:

 

Command
Purpose

Step 1

hostname(config)# access - list access _ list _ name extended permit tcp any user_ip_address 255.255.255.255 eq http
hostname(config)# access - list access _ list _ name extended permit tcp any user_ip_address 255.255.255.255 eq https
Examples:
hostname(config)# access-list listenerAuth extended permit tcp any any
 

Creates an access list that permits traffic from the users client that uses the HTTP or HTTPS protocol.

Step 2

hostname(config)# aaa authentication listener http inside port port
Examples:
hostname(config)# aaa authentication listener http inside port 8888

Enables HTTP(S) listening ports to authenticate the user.

Step 3

hostname(config)# access-list access _ list _ name { deny | permit } protocol [{ user-group [ domain_name \\ ] user_group_name | user {[ domain_name \\ ] user_name | any | none } | object-group-user object_group_user_name }] { any | host sip | sip smask | interface name | object src_object_name | object-group network_object_group_name > [ eq port | …] { object-group-user dst_object_group_name | object dst_object_name host dst_host_name | ip_address } [ object-group service_object_name | eq port | …]
Examples:
hostname(config)# access-list 100 ex deny ip user CISCO\abc any any
hostname(config)# access-list 100 ex permit ip user NONE any any

Creates an access control entry that controls access using user identity or group identity.

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.

  • any —The access list matches any IP addresses that has already been associated with any users.
  • none —The access list matches any IP addresses that has not been associated with any IP address.

Step 4

hostname(config)# aaa authenticate match access _ list _ name inside user-identity
Examples:
aaa authenticate match listenerAuth inside user-identity

Enables authentication for connections through the ASA and matches it to the Identity Firewall feature.

Examples

Example 1

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.
hostname(config)# access-list AUTH extended permit tcp any 172.1.1.118 255.255.255.255 eq http
hostname(config)# access-list AUTH extended permit tcp any 172.1.1.118 255.255.255.255 eq https
hostname(config)# aaa-server LDAP protocol ldap
hostname(config-aaa-server-group)# aaa-server LDAP (inside) host 171.1.2.93
hostname(config-aaa-server-host)# ldap-base-dn DC=cisco,DC=com
hostname(config-aaa-server-host)# ldap-group-base-dn DC=cisco,DC=com
hostname(config-aaa-server-host)# ldap-scope subtree
hostname(config-aaa-server-host)# ldap-login-dn cn=kao,OU=Employees,OU=Cisco Users,DC=cisco,DC=com
hostname(config-aaa-server-host)# ldap-login-password *****
hostname(config-aaa-server-host)# ldap-over-ssl enable
hostname(config-aaa-server-host)# server-type microsoft
hostname(config-aaa-server-host)# aaa authentication match AUTH inside LDAP
hostname(config)#
hostname(config)# http server enable
hostname(config)# http 0.0.0.0 0.0.0.0 inside
hostname(config)#
hostname(config)# auth-prompt prompt Enter Your Authentication
hostname(config)# auth-prompt accept You are Good
hostname(config)# auth-prompt reject Goodbye

Example 2

hostname(config)# access-list listenerAuth extended permit tcp any any
hostname(config)# aaa authentication match listenerAuth inside ldap
hostname(config)# aaa authentication listener http inside port 8888
hostname(config)# access-list 100 ex permit ip user SAMPLE\user1 any any
hostname(config)# access-list 100 ex deny ip user SAMPLE\user2 any any
hostname(config)# access-list 100 ex permit ip user NONE any any
hostname(config)# access-list 100 ex deny any any
hostname(config)# access-group 100 in interface inside
hostname(config)# aaa authenticate match 200 inside user-identity
 

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.

! Apply VPN-Filter with bypassing access-list check disabled
no sysopt connection permit-vpn
access-list v1 extended deny ip user LOCAL\idfw any 10.0.0.0 255.255.255.0
access-list v1 extended permit ip user LOCAL\idfw any 20.0.0.0 255.255.255.0
access-group v1 in interface outside >> Control VPN user based on regular IDFW ACLs
 

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.

! Apply VPN-Filter with bypassing access-list check enabled
sysopt connection permit-vpn
access-list v1 extended permit ip user LOCAL\idfw any 10.0.0.0 255.255.255.0
access-list v2 extended deny ip user LOCAL\user1 any 10.0.0.0 255.255.255.0
username user1 password QkBIIYVi6IFLEsYv encrypted privilege 0 username user1 attributes
vpn-group-policy group1 vpn-filter value v2 >> Per user VPN-filter control
username idfw password eEm2dmjMaopcGozT encrypted
username idfw attributes
vpn-group-policy testgroup vpn-filter value v1
 
sysopt connection permit-vpn
access-list v1 extended permit ip user LOCAL\idfw any 10.0.0.0 255.255.255.0 access-list v1 extended deny ip user LOCAL\user1 any 10.0.0.0 255.255.255.0 group-policy group1 internal
group-policy group1 attributes >> Per group VPN-filter control
 
vpn-filter value v1
vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless
 

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:

 

Command
Purpose
user-statistics [ accounting | scanning ]
 
hostname(config)# class-map c-identity-example-1
hostname(config-cmap)# match access-list identity-example-1
hostname(config-cmap)# exit
hostname(config)# policy-map p-identity-example-1
hostname(config-pmap)# class c-identity-example-1
hostname(config-pmap)# user-statistics accounting
hostname(config-pmap)# exit
hostname(config)# service-policy p-identity-example-1 interface outside

Activates the collection of user statistics by the Modular Policy Framework and matches lookup actions for the Identify Firewall.

The accounting keyword specifies that the ASA collect the sent packet count, sent drop count, and received packet count. The scanning keyword specifies that the ASA collect only the sent drop count.

When you configure a policy map to collect user statistics, the ASA collects detailed statistics for selected users. When you specify the user-statistics command without the accounting or scanning keywords, the ASA collects both accounting and scanning statistics.

Monitoring the Identity Firewall

This section contains the following topics:

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:

  • show user-identity ad-agent
  • show user-identity ad-agent statistics

These commands display the following information about the primary and secondary AD Agents:

  • Status of the AD Agents
  • Status of the domains
  • Statistics for the 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:

displays the list of user groups in the following format:

domain \ group_name

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:

  • Users
  • Groups
  • User Stats
  • LDAP

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.

  • AD Agent
  • Miscellaneous
  • Total Memory Usage
note.gif

Noteblank.gif 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:

  • show user-identity user all list
  • show user-identity user active user domain \ user-name list detail

These commands display the following information for users:

 

domain \ user_name

Active Connections

Minutes Idle

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.gif

Noteblank.gif 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.

\

Table 36-1 Feature History for the Identity Firewall

Feature Name
Releases
Feature Information

Identity Firewall

8.4(2)

The Identity Firewall feature was introduced.

We introduced or modified the following commands: user-identity enable, user-identity default-domain, user-identity domain, user-identity logout-probe, user-identity inactive-user-timer, user-identity poll-import-user-group-timer, user-identity action netbios-response-fail, user-identity user-not-found, user-identity action ad-agent-down, user-identity action mac-address-mismatch, user-identity action domain-controller-down, user-identity ad-agent active-user-database, user-identity ad-agent hello-timer, user-identity ad-agent aaa-server, user-identity update import-user, user-identity static user, dns domain-lookup, dns poll-timer, dns expire-entry-timer, object-group user, show user-identity, show dns, clear configure user-identity, clear dns, debug user-identity.