Last week, I had an opportunity to sit in a Security presentation given by Cisco at PBM.

There was a
mention on the recent release of () code, and one of the features that caught my attention was
Identity Firewall. This is something that other firewall vendors like Palo Alto has already been doing so I
was curious to see how it works on the Cisco ASA.
This article demonstrates, through a lab setup, the basic concept of identity-based Access Control
List (ACL) introduced in Cisco ASA (). In addition to the traditional method of using source IP
address to restrict network access, identity-based ACL allows the flexibility of enforcing security policy
based on Active Directory domain username and user group. The new type of object-group (object-group
user) is also introduced as part of this feature.
Prerequisites:
- ASA ()
- Active Directory on Windows (non-R), , and R server
- AD agent installed on Windows (non-R), , and R server
Lab Diagram:



Lab Parameters:
Domain: CISCOLAB.COM
AD User: user (allowed ping only)
AD User: neteng (allowed telnet only)
AD User Group: Network Admin (member = neteng)
Domain Test PC: TESTPC
Configuration Steps:
. Create AD user for ASA and AD Agent
. Create desired AD User/Group
. Install/Configure AD Agent
. Configure AD Domain on ASA
. Configure AD Agent on ASA
. Configure Identity Options
. Configure Identity-Based ACL

ACL Configurations:
!
object-group user USER
user CISCOLAB\user
object-group user ADMIN
user-group "CISCOLAB\\Network Admin"
!
access-list FROM_INSIDE permit tcp object-group-user ADMIN any any eq
access-list FROM_INSIDE permit icmp object-group-user USER any any
access-list FROM_INSIDE deny ip any any log
!
access-group FROM_INSIDE in inter INSIDE
!
Test Results:

Test# - user ping
Result = Succeeded
Test# - user telnet to
Result = Failed
Test# - neteng ping .
Result = Failed
Test# - neteng telnet
Result = Succeeded
LAB-INET-FW# sh access-l FROM_INSIDE
access-list FROM_INSIDE; elements; name hash: xcbee
access-list FROM_INSIDE line extended permit tcp object-group-user ADMIN any any eq telnet
(hitcnt=) xacd
access-list FROM_INSIDE line extended permit icmp object-group-user USER any any (hitcnt=)
xef
access-list FROM_INSIDE line extended deny ip any any log informational interval (hitcnt=)
xbfca
!
Show Command Outputs:

! List of AD users
LAB-INET-FW# sh user-identity ad-users CISCOLAB
Domain:CISCOLAB AAA Server Group: AD_PRIMARY
User list retrieved successfully
Number of Active Directory Users:
dn: CN=Administrator,CN=Users,DC=CISCOLAB,DC=COM
sAMAccountName: Administrator
dn: CN=Guest,CN=Users,DC=CISCOLAB,DC=COM
sAMAccountName: Guest
dn: CN=krbtgt,CN=Users,DC=CISCOLAB,DC=COM
sAMAccountName: krbtgt
dn: CN=ASALDAP,OU=CISCOLAB,DC=CISCOLAB,DC=COM
sAMAccountName: ASALDAP
dn: CN=neteng,OU=CISCOLAB,DC=CISCOLAB,DC=COM
sAMAccountName: neteng
dn: CN=IBF_SERVICE_USER,CN=Users,DC=CISCOLAB,DC=COM
sAMAccountName: IBF_SERVICE_USER
dn: CN=ADAGENT,OU=CISCOLAB,DC=CISCOLAB,DC=COM
sAMAccountName: ADAGENT
dn: CN=user,OU=CISCOLAB,DC=CISCOLAB,DC=COM
sAMAccountName: user
! Status of AD Agent
LAB-INET-FW# sh user-identity ad-agent
Primary AD Agent:
Status up (registered)
Mode: full-download
IP address:
Authentication port: udp/
Accounting port: udp/
ASA listening port: udp/
Interface: INSIDE
Up time: mins secs
Average RTT: msec
AD Domain Status:
Domain CISCOLAB: up
! List of member users of an AD group
LAB-INET-FW# sh user-identity ad-group-members "CISCOLAB\\Network Admin"
Domain:CISCOLAB AAA Server Group: AD_PRIMARY
Group Member List Retrieved Successfully
Number of Members in AD Group Network Admin
dn: CN=neteng,OU=CISCOLAB,DC=CISCOLAB,DC=COM
! AD Username-to-IP mapping
LAB-INET-FW# sh user-identity ip-of-user CISCOLAB\neteng
CISCOLAB\ (Login)
LAB-INET-FW# sh user-identity ip-of-user CISCOLAB\user
CISCOLAB\ (Login)
! Status cache AD users
LAB-INET-FW# sh user-identity user all list
Total users: Total IP addresses:
CISCOLAB\Administrator: active conns
CISCOLAB\ADAGENT: active conns; idle mins
CISCOLAB\user: active conns
CISCOLAB\neteng: active conns; idle mins
!
Conclusion:
We were able to restrict user access to the lab telnet server based on both the AD username and
user group. The ASA was able to correctly obtain the username-to-IP mapping information from the AD
agent, and utilize them in the ACL.

Caveat: Username-to-IP mapping does not get updated when the IP on a user computer is changed
while the user is logged in to the domain. This causes the user IP information on the ASA to become
inaccurate, and potentially results in an incorrect ACL being applied to user traffic. This is due to the fact
that the AD agent creates the username-to-IP mapping table by monitoring user logon/logoff activities,
hence uninformed of the IP change after the user has already logged in.

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 (). 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 : 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.
. Combined user/user group and subnet in ACL
. Loss of connectivity to AD agent
. VPN user authentication
Prerequisites:
- Please refer to Cisco ASA Identify Firewall (Part : Introduction)
Lab Diagram:



Lab Parameters:
Domain: CISCOLAB.COM
AD User: user
AD User: neteng
AD User Group: Network Admin (member = neteng)
Domain Test PC: TESTPC (Inside)
TESTPC (Inside)
TESTPC (Outside)
**************************************************************
Scenario - 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 TESTPC ()
- User can only ping the DMZ host from TESTPC ()

ACL Configurations:
!
















Test Results:
. neteng on TESTPC ping to
Result = Failed
. neteng on TESTPC telnet to
Result = Succeeded
. neteng on TESTPC telnet to
Result = Failed
. user on TESTPC ping to
Result = Succeeded
. user on TESTPC ping to
Result = Failed
LAB-INET-FW# sh access-l FROM_INSIDE
access-list FROM_INSIDE; elements; name hash: xcbee
access-list FROM_INSIDE line extended permit tcp object-group-user ADMIN host any
eq telnet (hitcnt=) xdfcc
access-list FROM_INSIDE line extended permit icmp object-group-user USER host any
(hitcnt=) xaffad
access-list FROM_INSIDE line extended deny ip any any log informational interval (hitcnt=)
xbfca
!
******************************************************************
Scenario Loss of Connectivity to AD Agent
******************************************************************
In this lab scenario, we will shutdown the AD agent service to emulate loss of connectivity and
object-group user USER
user CISCOLAB\user
object-group user ADMIN
user-group "CISCOLAB\\Network Admin"
!
name TESTPC
name TESTPC
!
access-list FROM_INSIDE permit tcp object-group-user ADMIN host any eq
access-list FROM_INSIDE permit icmp object-group-user USER host any
access-list FROM_INSIDE deny ip any any log
!
access-group FROM_INSIDE in inter INSIDE
!
observe the change in ACL enforcement.

LAB-INET-FW# sh user-identity ad-ag
Primary AD Agent:
Status down
Mode: full-download
IP address:
Authentication port: udp/
Accounting port: udp/
ASA listening port: udp/
Interface: INSIDE
Up time: N/A
Average RTT: 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.
!
. neteng on TESTPC telnet to
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.
!
. neteng on TESTPC telnet to
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.
!
. neteng on TESTPC telnet to
Result = Failed
!
*********************************************
Scenario - VPN User Authentication
*********************************************
In this lab scenario, we will attempt to implement identity rule under group-profile tunnel ACL using
SSL VPN.
Configurations (Partial):
!
object-group network VPN_NET
network-object
!
ip local pool VPN_POOL - mask
!
object-group user ADMIN
user LOCAL\neteng
!
access-list FROM_VPN_SSL permit tcp object-group-user ADMIN any any eq
access-list FROM_VPN_SSL deny ip any any
!
access-list ADMIN_ST stand permit
!
tunnel-group ADMIN type remote-access
tunnel-group ADMIN general-attributes
address-pool VPN_POOL
authentication-server-group RADIUS
default-group-policy ADMIN
!
group-policy ADMIN internal
group-policy ADMIN attributes
dns-server value
vpn-filter value FROM_VPN_SSL
vpn-tunnel-protocol ssl-client ssl-clientless
split-tunnel-policy tunnelspecified
split-tunnel-network-list value ADMIN_ST
default-domain value CISCOLAB.COM
!

Test Results:
After connecting to SSL VPN from TESTPC

. neteng on TESTPC ping to
Result = Failed
. neteng on TESTPC telnet to
Result = Succeeded
! VPN user shows up as in LOCAL group
LAB-INET-FW# sh user-identity user all li
Total users: Total IP addresses:
<omitted>
LOCAL\neteng: active conns; idle mins
LAB-INET-FW# sh user-identity ip-of-user LOCAL\neteng
LOCAL\ (Login)
LAB-INET-FW#sh access-l FROM_VPN_SSL
access-list FROM_VPN_SSL; elements; name hash: xac
access-list FROM_VPN_SSL line extended permit tcp object-group-user ADMIN any any eq telnet
(hitcnt=) xe

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.