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:
And it’s a success!
Now, while we are still on authentication topic, let us see how easy it is to switch from LOCAL authentication to something else.
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:
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:
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:
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: