Cisco ASA Identity Firewall (Part 2: Advance)

          We have seen, in my last article, the Cisco ASA identity firewall in action, and its fundamental capabilities. We were able to successfully deploy the AD agent, and have the ASA integrated with both Active Directory (for user group download), and AD agent (for user-to-IP mapping). At the end of the lab, I was still uncertain on how well it will perform in a production environment and whether there might  be more caveats in a deployment, at least in the current version of code 8.4(2). In an effort to answer these questions, I went back to the ASA configuration guide and came up with a few more lab scenarios.
          This article is a continuation of Cisco ASA Identify Firewall (Part 1: Introduction). We will be exploring some of the more advanced features, evaluating, and trying to identify any caveats during our labs. The lab setup is based on our previous lab with slight modifications (see lab diagram below). The following are lab scenarios.

          1. Combined user/user group and subnet in ACL
          2. Loss of connectivity to AD agent
          3. VPN user authentication

Prerequisites:
          - Please refer to Cisco ASA Identify Firewall (Part 1: Introduction)

Lab Diagram:



Lab Parameters:
          Domain: CISCOLAB.COM
          AD User1: user1 
          AD User2: neteng 
          AD User Group: Network Admin (member = neteng)
          Domain Test PC: TESTPC1 (Inside)
                                    TESTPC2 (Inside)
                                    TESTPC3 (Outside)

**************************************************************
Scenario 1 - Combined user and subnet in ACL
**************************************************************
           In this lab scenario, we will attempt to restrict network access using both user identity and location (ie. source IP).

Requirements:
          - User under Admin group can only telnet to  the DMZ host from TESTPC1 (192.168.32.10)
          - User1 can only ping the DMZ host from TESTPC2 (192.168.32.11)

ACL Configurations:

LAB-INET-FW# sh access-l FROM_INSIDE                  
access-list FROM_INSIDE; 3 elements; name hash: 0xc8b16e9e
access-list FROM_INSIDE line 1 extended permit tcp object-group-user ADMIN host 192.168.32.10 any eq telnet (hitcnt=1) 0xdf2c337c
access-list FROM_INSIDE line 2 extended permit icmp object-group-user USER host 192.168.32.11 any (hitcnt=4) 0x8aff6ad7
access-list FROM_INSIDE line 3 extended deny ip any any log informational interval 300 (hitcnt=28) 0xbfc4303a
!
******************************************************************
Scenario 2 – Loss of Connectivity to AD Agent
******************************************************************
           In this lab scenario, we will shutdown the AD agent service to emulate loss of connectivity and observe the change in ACL enforcement.

LAB-INET-FW# sh user-identity ad-ag
Primary AD Agent:
 Status                    down
 Mode:                     full-download
 IP address:               192.168.32.100
 Authentication port:      udp/1645
 Accounting port:          udp/1646
 ASA listening port:       udp/3799
 Interface:                INSIDE
 Up time:                  N/A
 Average RTT:              0 msec

Test Results:
           An active user with  command “user-identity action ad-agent-down disable-user-identity-rule” will bypass all of the identity ACL rules and evaluated against only the traditional ACL rules, which in this case is deny-all.
!
            1. neteng on TESTPC1 telnet to 192.168.30.4
                        Result = Failed

           An active user with command “no user-identity action ad-agent-down disable-user-identity-rule” will continued to be evaluated by the identity ACL rules.
!
            1. neteng on TESTPC1 telnet to 192.168.30.4
                        Result = Succeeded

           An inactive user, regardless of the command “user-identity action ad-agent-down disable-user-identity-rule” and the state of the AD agent, will only be evaluated by the traditional ACL rules.
!
            1. neteng on TESTPC1 telnet to 192.168.30.4
                        Result = Failed 
!
*********************************************
Scenario 3 - VPN User Authentication
*********************************************
           In this lab scenario, we will attempt to implement identity rule under group-profile tunnel ACL using SSL VPN.

Configurations (Partial):

! VPN user shows up as in LOCAL group
LAB-INET-FW# sh user-identity user all li
Total users: 6  Total IP addresses: 2
  <omitted>
  LOCAL\neteng: 0 active conns; idle 0 mins

LAB-INET-FW# sh user-identity ip-of-user LOCAL\neteng  
LOCAL\192.168.253.32 (Login)

LAB-INET-FW#sh access-l FROM_VPN_SSL                                       
access-list FROM_VPN_SSL; 1 elements; name hash: 0xac479031
access-list FROM_VPN_SSL line 1 extended permit tcp object-group-user ADMIN any any eq telnet (hitcnt=1) 0x6709158e

Observations and Caveats:  
            - Inactive and stale user IP mapping entries seem to remain on the ASA unless being cleared manually
            - Once a user becomes inactive (ie. idle timer expired), he will not be evaluated by any identity ACL rules, during which time he may be denied by subsequent ACL rules, until his next domain re-login, or a manual user-to-IP mapping table update is performed.
            - User-to-IP mapping table on the ASA is not automatically updated after the connection to  AD agent is recovered. The ASA is not informed of any user logging into the domain during the down time. Manual update by command “user-identity update active-user-database” is required.
            - VPN users will always appear as members of LOCAL group. There seems to be no way to make VPN users be members of different groups.

Conclusion:
             Based on our observations, deploying identity firewall requires careful design of ACL and extensive testing to make sure an AD agent outage will not neither cause user traffic to be blocked nor accidently allow an unauthorized access. Idle timer may also need to be adjusted to prevent deny-access due to users prematurely becoming inactive while they are still logged in to the domain. In addition, there is a chance that the ASA user-to-IP mapping table becomes out-of-sync from the AD agent. Although we can manually force update, this certainly is not practical.
This concludes my review on the ASA identity firewall. I hope both of my articles will help you decide whether deploying identity firewall is the right choice in your production environment.  

Additional Resources:
            Cisco ASA 5500 Series Configuration Guide using the CLI

Author: Metha Chiewanichakorn , CCIE#23585 (R&S/Security/Service Provider)