With Herbert Baerten
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn about the use of AAA (Authentication, Authorization, Accounting) for Remote Access VPN on the Cisco Adaptive Security Appliance (ASA) with Cisco expert Herbert Baerten who will answer questions on this topic. He can also answer questions on the use of various AAA protocols such as TACACS, RADIUS, LDAP and PKI (certificates), as well as the usage of the local AAA database, including Dynamic Access Policies (DAP.) Herbert Baerten is a customer support engineer at the Cisco Technical Assistance Center in Brussels, Belgium, where he has been part of the Security team since joining Cisco six years ago. His area of expertise is in security, including VPN, IPSec VPN, and SSL VPN on the Cisco IOS and Cisco ASA platforms.
Remember to use the rating system to let Herbert know if you have received an adequate response.
Herbert might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Security sub-community Other Security Subjects discussion forum shortly after the event. This event lasts through December 22nd, 2011. Visit this forum often to view responses to your questions and the questions of other community members.
We would like to use LDAP to authenticate VPN users against our Active Directory. How can I configure this in such a way that only users that are member of a certain group can connect?
thank you for your question. When the ASA performs an LDAP authentication request, the AD server will (if the authentication is successful) send back a number of attributes, one of which is the "memberOf" attribute which tells the ASA what AD group(s) the user is in.
This attribute can be used in 2 ways, similar to what is described in an excellent document my colleague Nicolas Fournier wrote:
In this document, the access is granted/rejected based on the "Remote Access Permission" attribute that the user has in AD (and which is also passed to the ASA in the LDAP response).
The way to grant or deny access based on the memberOf attribute is very similar.
Method 1: using DAP (Dynamic Access Policies)
Using ASDM, create a DAP rule that matches on AAA attribute "ldap.memberOf" and the action set to "continue".
Then in the default rule, set the action to "terminate".
This way only users that are part of the group matched in the first rule will be granted access, all others will be denied.
Method 2: using an LDAP attribute map
Start by creating 2 group-policies, as described in the document:
group-policy AllowVPN internal
group-policy AllowVPN attributes
group-policy NoVPN internal
group-policy NoVPN attributes
Then set the NoVPN policy as the default one in your tunnel-group:
tunnel-group myTG type remote-access
tunnel-group myTG general-attributes
So by default, all users connecting to this tunnel-group will be denied access (because group-policy NoVPN is applied which allows 0 simultaneous connections).
Next, create an LDAP attribute map that maps the desired group to the AllowVPN policy:
ldap attribute-map VPN-LDAP-MAP
map-name memberOf IETF-Radius-Class
map-value memberOf "CN=VPNUSERS,OU=Users,DC=CISCOTEST,DC=COM" AllowVPN
What this does is create a mapping between the LDAP "memberOf" attribute and the ASA "IETF-Radius-Class" attribute (which indicates the group-policy to use). In the most recent ASA software versions, "IETF-Radius-Class" has been replaced with "Group-policy".
It also defines that the LDAP group "CN=VPNUSERS,OU=Users,DC=CISCOTEST,DC=COM" should be mapped to the group-policy "AllowVPN"
Finally, apply the attribute map to the the LDAP server(s):
aaa-server myLDAP protocol ldap
aaa-server myLDAP (inside) host 10.0.0.1
I hope this helps, if you have any follow-up questions just let me know.
My customer uses a clientless WebVPN profile where his users are redirected directly to their Outlook Web Access (OWA) webinterface using SSO. This has worked well until he changed to Exchange 2010 just a few days ago. I have to assume that Microsoft has changed some parameters on their OWA webpage, so SSO needs to be reconfigured in order to get it working again.
I've browsed through the config guides and communities on Cisco.com and I've also analyzed the POST content of the webpage - still, no success so far. As the ASA release notes state that with 8.4(2), Exchange 2010 is explicitly supported, I'd like know if you can tell me the proper bookmark and SSO parameters that solve the problem. Or is there any other possible problem source?
for Exchange 2010, I believe this should work with something like:
depending on whether your OWA server is reachable through HTTP or HTTPS.
Obviously you may want to modify the SSO variables if you use double authentication or an internal password.
If this does not work I would suggest getting captures of the traffic in the SSL tunnel (e.g. using HTTPwatch or Charles or similar tool) and to open a TAC case to analyze those captures if it's not obvious what's going wrong.
I hope this helps
Is it possible to authenticate with AAA server using SSL VPN? We have ASA 5510.
yes you can use Tacacs, Radius, LDAP, SDI, Kerberos etc. to authenticate both clientless SSLVPN (aka WebVPN) and Anyconnect (aka SSL client) users.
A very common approach is to use Radius towards a Cisco ACS server or to use LDAP towards a Microsoft Active Directory (AD) server.
These are the 2 relevant sections of the ASA 8.4 configuration guide:
Configuring AAA Servers and the Local Database
Configuring Remote-Access Connection Profiles
Furthermore you can use AAA not only to authenticate users but also to assign IP addresses, restrict access on a per-user or per-group basis, etc.
It's a very broad subject and the possibilities are endless so I hope this more or less answers your intitial question, if you have any follow up questions please don't hesitate to ask.
Thank you for your hints, yet after trying probably about thirty variants of POST plug-in and normal HTTP with POST parameter syntaxes, I have to give up. Maybe there's something different with the German Exchange OWA page (well, this one is definitely: 'submit=Anmelden'), yet I've analyzed the page with three different HTTP sniffers and belive there's nothing else left to analyze. I think the only way to solve this is going via TAC
One last question: Would you recommend to use the POST plug-in URL or the HTTP URL with advanced POST values? None of both worked for me...
1) What do you recommend on levels of authentication ? What I meant is how many forms of authentication is recommended?
If I am using LDAP with AD username and password is that good enough or do you recommend using second form of authentication. I am pretty sure that it would depend on an organizations security policy but would like to know if there are any baseline recommendations.
2) Are there any best practices you would suggest for implementing anyconnect & clientless VPN ?
This is a really tough one . As you say this is primarily a question of the organizations security policy. As often in security, there is a trade-off between security, user (in)convenience, and cost.
LDAP with AD is of course cost-effective if you already have AD and very user-friendly in the sense that the users can log in to the VPN using the same credentials as they use to log in to his workstation or laptop.
Possibly even more user-friendly is the use of a client certificate which can be used to log in without the user having to type anything but setting up and maintaining a PKI infrastructure is of course a whole other ballpark.
On the other end of the spectrum you can have a client certificate on a smartcard (or hardware token) protected by a PIN as first level, username & password (using Radius or LDAP) as second level, and a one-time-password (OTP) (using something like an RSA token or a system that sends a OTP to the user by text message to his cell phone) as third level.
So sorry for not giving you a very explicit answer but obviously the recommendations will be different for a non-profit or a small company compared to a financial, military or healthcare organization.
One basic "rule of thumb" though is that you strongly increase security if authenticating requires something that you have (like the smartcard, the RSA token or the cellphone in the example above) as well as something you know (a password).
For your second question, that's again very broad and depends on a lot of factors (how many users, where will they connect from (company or public computers), which applications, expected uptime etc etc). Just a few tips though: for Anyconnect I would recommend using the latest client version available, for clientless the most recent ASA 8.2 or 8.4 version, and be aware of memory and licensing requirements.
Consider using CSD if you want additional options to tighten security (e.g. restrict access to clients with recent Anti-Virus software installed).
Specifically for LDAP with AD, check the first question and answer in this thread on how to use DAP or an LDAP attribute map.
I hope this still helps, if you have any more specific questions I'll be glad to discuss them.
we are using Cisco ASA 8.2.3 as RAS solution for our customers. Different kind of authentication mechanisms are already deployed yet.
Now we want to use two factor authentication, where first, user needs to be verified by AD (by secure LDAP) and secondly, user needs to be verified by SMS passcode to SMS text messaging server.
We already created a separate DAP, separate Anyconnect Connection profile, separate Group Policy and separate customization page for this.
I know ASA supports this functionality but when configuring authentication server group and secondary authentication server group together you will have to fill in credentials for both on the Logon page. This is not what we want. We want users to fill in credentials for AD on Logon screen and after this user should receive SMS text message and get (pop-up) second login screen where he can enter the SMS passcode. Then logon process is completed and he should get RAS portal page.
When we test using only primary authentication AD by secure LDAP connection functions. When enabling secondary authentication you have to fill in credentials also on first logon page (instead of second logon page we would like to have). Also then, customer does not see any requests coming in on SMS text message server.
How do we need to configure the RAS environment so that it functions the way we want to?
The way (most of) these SMS systems work, is that you configure the ASA to do single authentication using Radius, where the SMS server acts as Radius server. On the SMS server you then configure the LDAP server as a back-end.
What will happen then is this:
On the login page the user enters his AD username and password.
The ASA sends this to the SMS server (using Radius).
The SMS server uses (for example) LDAP to AD to verify the credentials.
If ok, the SMS server then sends an SMS to the user's phone, and it sends back a Radius "challenge" message to the ASA, requesting an additional password.
This triggers the ASA to display a second login screen, asking just for the OTP.
The user enters the OTP received by SMS, the ASA sends this to the SMS server via Radius, the SMS server responds with a Radius access-accept or access-reject.
I know there are SMS servers available from multiple vendors so they may not all work in the same way. If you think the above is not the way yours works then please send me the documentation provided by your vendor (I assume it comes with a deployment guide or something similar) or let me know the name of the Vendor or product.
Please let me know if this helps.
thanks for the quick response. Using the information you provided last week we configured ASA authentication for SMS. Also had to change settings in SMS text message server and settings in Anyconnect client profile settings, but now everything works like a charm.
I have a question: I am using Radius for authenticating VPN users and having multiple tunnel-groups on the ASA, how can I make sure that users can only connect to the tunnel-group they are supposed to connect to (i.e. sales people to the sales group etc.)?
this can be accomplishes by configuring the Radius server to send the Tunnel-Group-Lock attribute, the value of this attribute should be the name of a Tunnel-Group on the ASA.
If a user then attempts to connect to another group, the connection will fail.
On Cisco ACS 3.x this attribute is known as cVPN3000-Tunnel-Group-Lock, from ACS 4.x on it is simply named Tunnel-Group-Lock and can be found under VPN3000/PIX/ASA attributes.
On a Radius server that does not know these Cisco specific attributes, you can speficy it as:
vendor code 3076
attribute number 85
For a complete list of attributes that you can push from LDAP and Radius, see: