AD Agent setup vs. using aaa ldap for remote access VPN

lcaruso · ‎08-06-2011

Hi,

I just started reading the documentation for the AD Agent.

I'm getting the impression there is overlap/duplication with setting up remote access VPN authentiction to Active Directory via aaa and ldap.

Can anyone who has already done this tell me if AD Agent and using aaa ldap to authenticate via AD will interoperate, interfere, or are the same thing?

I've never setup the former but have setup the latter serveral times. Thanks.

Tim Schneider · ‎08-08-2011

From my understanding the ASA is not "interoperating" the LDAP and RADIUS connections as the AD Agents purpose is to distribute the AD-IP mappings and the AD-LDAP connection is used to poll the Users/Groups.

I'm currently setting up a test scenario, as soon as it's working I will implement VPN auth via LDAP and tell you if problems are arising.

lcaruso · ‎08-08-2011

It was a vague question.

Here's an example that compares what I've done with AD ldap for remote access vpn authentication and what cisco has in their documentation as step one configuration, what they call

Configuring the Active Directory Domain.

From the documenation, it would appear you can either use port 389 or 636 if you SSL for AD Agent.

I was just trying to get a handle on how I'm going to do both AD Agent and Remote Access VPN authentication together. I'll probably open a TAC case when the time comes.

Configuring the Active Directory Domain

aaa-server adserver protocol ldap

aaa-server adserver (inside) host 172.168.224.6

ldap-base-dn DC=SAMPLE,DC=com

ldap-scope subtree

ldap-login-password obscurepassword

ldap-login-dn SAMPLE\user1

server-type microsoft

ldap-group-base-dn OU=Sample Groups,DC=SAMPLE,DC=com

ldap-over-ssl enable

server-port 636

group-search-timeout 300

Configuring Remote Access VPN to use AD via ldap

aaa-server ldap_ad protocol ldap

aaa-server ldap_ad (inside) host 192.168.15.21

server-port 389

ldap-base-dn DC=CLIENT,DC=LOCAL

ldap-scope subtree

ldap-naming-attribute sAMAccountName

ldap-login-password *****

ldap-login-dn CN=cisco-vpn,OU=Service Accounts,DC=CLIENT,DC=LOCAL

server-type microsoft

ldap-attribute-map ldap

ldap attribute-map ldap

map-name memberOf IETF-Radius-Class

map-value memberOf CN=VpnUsers,CN=Users,DC=CLIENT,DC=LOCAL

lcaruso · ‎08-11-2011

I asked TAC about this.

TAC cannot tell me if the aaa server that would be used for the Identity Firewall can co-exist with or be one in the same with the aaa server I use for remote access vpn AD authentication. I have no configuration examples that would show this either way.

TAC cannot tell me what the effects of not having/not having netbios probing and/or mac address checking capabilities would be. They are not required, but are affected by various site/configuration issues.

All TAC can offer is they are a "break and fix" organization, so I can call them if it doesn't work.

This is a new product in 8.4(2).

I say the documentation, being an early rev, is broken.

Maybe someone could fix the documentation

Maybe someone could fix the documentation so it has something more substantive. Instead of countless repetitive warnings about the Windows patches that are required, how about some examples in real world networks, where, for example, an existing configuration is being updated with Identity Firewall? Maybe even some examples that are not entirely boxed in, you know, like one normally sees in Cisco documetation. That way at least you can cut and paste all in one shot instead of having to navigate little cells for each individual command. How about a dicussion of the effects of having/not having netbios probing and/or mac address checking enabled/available?

Better yet, let's see one of the those Cisco Blog posts with detailed information regarding this subject.

So in the meantime, I can tell my client, "we don't know if Cisco's Identity Firewall will work for you, or if it does work, how it will integrate and perform with your existing requirements"

Super

lcaruso · ‎08-23-2011

You must mean something like this...

http://blog.pbmit.com/asa_identity_fw

http://blog.pbmit.com/asa_identity_fw2

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.

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.

lcaruso · ‎08-23-2011

YUP.

That's EXACTLY what I'm talking about.