Cisco ASA Identity Firewall


When the CTO approached me asking how access to a subnet was restricted, I advised him that the people who needed access were given a DHCP reservation and an ACL on a Cisco ASA limited those IP addresses to certain destination hosts on certain ports. It wasn’t scalable and it wasn’t particularly secure. For example, if one of those users wanted to log on to a different machine, they would get a different IP address and access would break. If their computer NIC got sick and needed replacing, same thing. Worse still, anybody could log on to their machine and get access to the same resources or give themselves a static IP when the other user had their computer turned off and nobody would be the wiser.

I had been looking at a number of methods to address this, such as 802.1x authentication\application proxy and during our discussion, we both came to the conclusion that it would be pretty cool if we could restrict access via usernames, especially if this could remain transparent to those users. This would give us the flexibility and transparency we were looking for whilst maintaining the required level of security. Isn’t that the perfect balance that we strive for in IT security?


Enter the Identity Firewall feature on the Cisco ASA platform. This is a new feature available from software version 8.4(2). The Identity Firewall integrates with Active Directory using an external (to the ASA) agent. The website has a host of documentation on the feature which you should follow to get it up and running but below is a summary of how it works, some things to be aware of and my thoughts on the feature.

How it works

First of all, this feature has three main components. The ASA itself, Active Directory and an agent which sits on one of your domain machines and feeds information back to the ASA. There are a number of prerequisites you need to make sure are in place and rules you must follow before rolling this out e.g. AD must be installed on certain OS versions, same for the server the agent is on, you can have multiple agents for redundancy but only one installed on a domain controller, you must configure the correct level of domain wide security auditing, ensure host firewalls are opened accordingly. The configuration guide does a pretty good job of listing all of these and I would heartily recommend you check it out if deploying the feature.

There is also the relatively small matter of creating an account in AD that the ASA will use to communicate with AD. You also need to create some config on the ASA itself made up of a mix of AAA and specific ‘user-identity’ commands. The agent is configured via the command prompt (or Powershell prompt as I tend to always use since I fell in love with it deploying Exchange 2007). You set up which AD servers it should be monitoring (you want to point it to all DCs that will be logging account logon\logoff events) and then which clients (ASAs) the agents will be reporting to. You can also configure Syslog servers for better accounting.

In a nutshell, the agent is checking the security logs of the DCs to see who is logging on and with what IP address. It adds this information to a local cache and sends it to the configured ASA clients. This is done using Radius. The ASA also talks directly to AD using LDAP to get AD group membership. The final piece of the puzzle is enabling the Identity Firewall so that all of these components start talking. At this stage, there are various commands you can run via the agent or on the ASA to confirm the communication is working as expected.

It is then a matter of creating ACLs that utilise users and\or groups and giving them access to resources. You can also combine this with source IP which means you can say Fred can access Server X when he is in Subnet Y but if he moves, he loses access. If Janet logs on to Fred’s original machine, she could have the same IP but won’t be given the same access due to her username not being in the ACL.

I found setting it all up very easy. However, circumstance led to it being some time before all interested parties were happy with the outcome e.g. the firewall being used had recently been upgraded from 8.0 code to 8.4, and a load of migrated NAT rules started playing up, muddying the waters. The positive side to this was that the firewall config has been streamlined considerably. There was also the morning spent troubleshooting a single user’s issue that ended up being down to him not being in the correct AD group as assumed. That said, I think it’s a pretty robust feature for what is effectively a first iteration.


I’ve tried to break it a number of ways e.g. pull an authorised user’s network cable out of their machine, give myself their static IP, but without being logged on as them, my username\IP pairing doesn’t match what the firewall thinks. There are a number of timers involved with this feature that might trip you up if you don’t understand them e.g. the firewall can only check group membership every hour at best, meaning if you remove a user from a group, they could still retain access. Worse still, if you disable their account in AD but keep them in the group, they will still have access until their Kerberos ticket expires. You can manually update group membership on the ASA if this would be an issue for you. I would guess that if it is, the person has been marched out of the building at that point anyway.

VPN logon vs AD logon

Another thing to be aware of is remote VPN access. When you remote VPN on, you get authenticated to the firewall. This could be via local ASA accounts, Radius, TACACS, ACS, LDAP etc. If you use AAA LDAP authentication (using Active Directory in this case), you are not logging on to the domain as you VPN in, you are simply saying ‘here are my AD credentials, please authenticate me on the firewall’. At that point, one of two things happens with the Identity Firewall. If you are using a domain computer to remote on, that machine will automatically try to make contact with a DC. When it finds one (over the VPN), it will log on to the domain, create a security log and the AD agent will let the ASA know. Any rules assigned to that user, that don’t filter on source IP, will now come in to effect. However, if the machine is not joined to the domain, there will be no logon event (the username\password given at connection was only for VPN authentication), and so any user-identity ACLs will not apply.

In the latter case, you may want to create a specific VPN connection profile with specific DHCP pool for example and go back to restricting by IP, only allowing users in a certain AD group for example to be able to connect to that profile. Not ideal, but it would work.


In summary, I really like this feature. It answers a number of questions specific to the environment I have implemented it in. Things I particularly like are its ease of setup including the troubleshooting commands to aid with this. Learning the syntax of the ACLs is a simple task, as they extend upon existing IP-based ACLs. I also like the fact that there are several ‘under the hood’ settings you can tweak to improve security further still e.g. remove users from the cache if their machine as been idle for a certain amount of time, force LDAP lookups over SSL.

Something that I wasn’t so keen on was the split communication i.e. the ASA getting group membership directly from AD, IP mapping from the agent. I would like to see the agent providing the group membership too. It should also not be too hard to tell the agent which groups to keep a closer eye on (the ones used in ACLs sounds like a good start). This would allow the ACL to be updated much quicker should a group be amended.

I would love to hear what others’ experience of this feature has been. Overall, I am very pleased with it and look forward to upcoming improvements.

Edit: additional points

A few other points I should highlight, if you move to a different subnet the new IP address will be picked up as long as your device authenticates with the domain. I tested this early on by disconnecting my laptop from the wired network with a persistent ping happening in the background. I then VPN’d back to the office via the WiFi network and within a couple of seconds of the connection be made, the ping reestablished.

The second point which will hopefully save somebody a head ache out there; a user testing this functionality was reporting it working as expected until they would open a spreadsheet that would make a data connection to a SQL database in a different subnet. The user had access to this SQL database as allowed by the Identity Firewall ACLs but as soon as the data was refreshed in the spreadsheet, he would get kicked. I could see it happening using the ASA and AD agent troubleshooting commands too. After a little bit of head scratching, we realised that the spreadsheet data connection was using a different set of domain credentials to connect to the database. This triggered a logon event for the user’s IP address but with the user account for the data connection. In turn, the AD Agent updated the cache with the new user and IP combination and denied the traffic based on the ACL. One answer to this would be to add the data connection account to the ACL but in the end, we just connected to the database in the spreadsheet using the user’s own credentials. This highlights the fact that, whilst a user can be affiliated with multiple IP addresses, only one user can be affiliated with any one IP address, which is the key to making this feature secure.

One last thing which is perhaps the most important, considering this is a discussion about a security feature. If your users connect via a shared IP address, you should be aware. For example, if your users log on to a Terminal Server, they will all be coming from the same IP address by default. That means that if a user with elevated permissions logs on to the TS, all other users will effectively gain the same access as permitted via the Identity Firewall. My advice would be to deny access via a shared IP address to any resources that need restricted access.

Till the next time.

12 Replies to “Cisco ASA Identity Firewall”

  1. Hi Vegaskid, First of all, excellent blog. It’s very helpful so Thank you.

    Regarding your comment

    “When I VPN on, I get authenticated via LDAP, but to get from the firewall to anywhere else, I need to authenticate against a domain controller (through the already authenticated VPN) which will log my VPN IP address in the security log and update the AD agent accordingly”

    May I ask how did you enforce “second” authentication to domain controller ? We have an ASA which is only used for Identity firewall policy (CDA is installed on DC) on a specific branch office.

    VPN users are coming via some other firewall/VPN gateway (which is using LDAP for authentication). So, when this VPN users try to access the branch office behind ASA, identity policy are not enforced (they can’t access). This is due to the fact that ASA as well as CDA can not get User/IP mapping for these VPN users and hence identity based policy fail.

    So, I would also like to enforce “second” authentication for these VPN users so DC can log the security event against these VPN users.

    Would greatly appreciate your feedback.

    1. Hi Sam, I turned off notifications many moons ago to stop me getting spammed about my comment spam so missed your question! Regarding the 2nd authentication, this should happen naturally via the Windows client i.e. when you log on to your computer at home, without a VPN back to the office, it uses cached credentials, but if you sniff your home network, you will see your work computer trying to find a domain controller occasionally.

      Once you connect via VPN, it can then contact the domain controller to get a kerberos ticket, which generates the security log (logon success event) that the ASA Identity agent is looking for, which maps that user to their VPN IP address.

      It uses DNS, so you should ensure the VPN settings on the firewall are using your AD DNS servers. Something on the lines of (on an ASA):

      group-policy YOUR_GROUP_POLICY
      dns-server value
      default-domain value yourdomain.local

      Hope that makes sense and is of use, apologies again for the late response. Let me know how you get/got on.

  2. Looking at implementing IDFW by vpn authentication, :

    “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.”

    So you sure I can’t create user identity policy thanks to ldap vpn auhtentication even though I have no logon events on Domain Controller ? The asa where vpn is terminated should inform AD agent about authenticated user and then distribute this info to all the other ASAs.

    1. Hi Jay and thanks for reading. I have the identity firewall feature setup on certain interface ACLs and VPN authentication is done via LDAP policies i.e. two separate mechanisms.

      When I VPN on, I get authenticated via LDAP, but to get from the firewall to anywhere else, I need to authenticate against a domain controller (through the already authenticated VPN) which will log my VPN IP address in the security log and update the AD agent accordingly.

      I’ve not used this feature to authenticate the VPN connection itself as I have a number of dynamic policies in place that does that already.

      Hope that answers your question.

  3. Thanks for responding,

    Not sure if I have the correct email or not. I emailed it to the one you left on my blog. “…” I just received an undelivered message. Which is pretty obviously not real.

    No firewall on the Active Directory Server. Communication between the ASA and the Active Directory Server is fine. I believe it has something to do with the “DN” and my user account/password. Like I said I’m not so well versed in MS, so it’s something with the “DN” or query that I’m not getting/understanding. It’s not a networking problem (per say).

    Do you have any set up guides or anything? Unless you want to send me your email. I have all relevant stuff ready for you.

    Thanks again matt, in the mean time I can try without anything in between the server and the ASA.

    1. Hi Joey, I used this guide to help me along for the feature outlined in this post:

      You should check the logs on the AD server after trying to authenticate to see what errors are thrown up. It does sound like either an incorrect DN format or wrong username\password. You need to make sure the base DN for searching and authentication is set correctly according to your domain configuration. Email address is in the footer.

  4. Hi Matt,

    I see you have done a successful AAA LDAP setup? I’m trying to get this going in my lab, and to be honest, I’m having troubles. btw RADIUS & Kerberos no problem…

    Following along with this

    moved on to this:

    …and tons of MS Docs.

    The following pretty much outlines my problem

    I’m not as well versed in the world of MS. If you have any thing that could enlighten me I would appreciate it.


    1. Email me with your setup if you like. Is the ASA on the same subnet as your AD server? If not, can it route to it? Is there anything that could filter between the ASA and AD? Are your credentials correct e.g. correct password\privileges? What about the firewall on the server itself; is it blocking the communication?

  5. I’m really enjoying the design and layout of your blog. It’s a very easy on the eyes which makes it much more pleasant for me to come here and visit more often. Did you hire out a developer to create your theme? Great work!|

  6. enjoying the blog and I’m looking forward to some of the stuff I know you’ll be working on over the coming few months 🙂

  7. @Roland assuming the user or computer authenticates against a domain controller the additional IP will be added to the cache and kept until a log off even it detected. Multiple IP’s can be associated with a user.

    @Matt nice post, covers off the salient points pretty well, I have to say it’s a really cool feature I was surprised it took Cisco this long to bring this feature to fruition.

  8. Have you tested what happens if a pc after authenticating moves to another subnet or from wired to wireless interface?

Please let me know your thoughts!

This site uses Akismet to reduce spam. Learn how your comment data is processed.