WebVPN on ASA part two: it’s a time to log in

Ok, so far we have managed to connect to WebVPN portal and now it’s time to log in. There are several methods we can use to log in: locally defined users, RADIUS/TACACS+, RSA SecurID, LDAP, … But before we actually configure our box to let us in, let’s briefly discus the concepts of groups and policies.

A group (tunnel-group) is a way of grouping users that need to share common attributes. These parameters can be classic IPSec params, WebVPN params and so on. We will deal a lot more with these later on. Some parameters are defined inside of a tunnel-group and another in a group-policy. Of course, there could be some parameters defined on a user level as well. When a user logs on, he or she is assigned to some tunnel-group and recive his or hers attributes from there. There is a link between a tunnel-group and a group-policy created by “default-group-policy” command, so a user gets additional attributes from a group-policy as well. By default there is one WebVPN tunnel-group named “DefaultWEBVPNGroup” with all attributes set to its defaults, and there is a default group-policy named “DfltGrpPolicy”. They are bond together by a command “default-group-policy DfltGrpPolicy” inside of DefaultWEBVPNGroup. And by the way, you can list all parameters and their values with:

  • show run all tunnel-group DefaultWEBVPNGroup
  • show run all group-policy DfltGrpPolicy

The key word here is “all”, otherwise you will se only changed parameters. If we issue previous commands without “all” keyword you should receive an empty output, which means nothing has been changed so far.

If we now create a local user, we should be able to log on to our SSL portal:

image

And it’s a success!

SNAGHTML343f86be

Now, while we are still on authentication topic, let us see how easy it is to switch from LOCAL authentication to something else.

image

As we can see, we have set of two RADIUS servers configured. If we had a user defined on those RADIUS servers, we could change a login method:

image

Now we need to use our ACS credentials to log in.

We can go one step further and use a RSA SecurID authentication. You can find how to set it up on ASA here. Of course we could integrate our ACS server with SDI server and use previous RADIUS technic.

Finally, we can authenticate against our Active Directory infrastructure:

image

The only thing we need to change is the authentication method we want to use like already described. Finally, at the end of this blog post let’s see how does it look like when user gets authenticated:

image

If you pay attention to red arrows, you will see the type of access (clientless-thin-thick from my introductory blog on SSL VPN) as well as algorithms negotiated. Blue arrow show that our user fit in the default tunnel-group and uses attributes from that group plus attributes from default group-policy. We will deal with this later.

And one last thing regarding authentication. If we are accessing our SSL portal from public PC (most often we do) and we are afraid of some key logger, we could activate a virtual keyboard and use our mouse to type in a password:

Advertisements
This entry was posted in ASA, Cisco, VPN, WebVPN and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s