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: ٠xc٨b١٦e٩e
access-list FROM_INSIDE line ١ extended permit tcp object-group-user ADMIN any any eq telnet
(hitcnt=١) ٠x٨١ac٨٨٥d
access-list FROM_INSIDE line ٢ extended permit icmp object-group-user USER any any (hitcnt=٨٨)
٠x٥٧٧e٠٧٥f
access-list FROM_INSIDE line ٣ extended deny ip any any log informational interval ٣٠٠ (hitcnt=٢٢٣)
٠xbfc٤٣٠٣a
!

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:

!
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
!

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: ٠xc٨b١٦e٩e
access-list FROM_INSIDE line ١ extended permit tcp object-group-user ADMIN host ١٩٢٫١٦٨٫٣٢٫١٠ any
eq telnet (hitcnt=١) ٠xdf٢c٣٣٧c
access-list FROM_INSIDE line ٢ extended permit icmp object-group-user USER host ١٩٢٫١٦٨٫٣٢٫١١ any
(hitcnt=٤) ٠x٨aff٦ad٧
access-list FROM_INSIDE line ٣ extended deny ip any any log informational interval ٣٠٠ (hitcnt=٢٨)
٠xbfc٤٣٠٣a
!
******************************************************************
Scenario ٢ – 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: ١٩٢٫١٦٨٫٣٢٫١٠٠
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=١) ٠x٦٧٠٩١٥٨e

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.