Now we have a working portal and it’s time to do something with it. Let’s recall how our portal looks like:
For now let’s focus on red number marked areas:
- Drop down list marked with red one is a list of protocols supported by clientless mode. We can se that we are limited only to so called web protocols: HTTP, HTTPS, CIFS and FTP. This is not much, but we can extend this list with other two modes that will be described later
- The address field marked with red two is a place where we type in an address we want to reach
- After we select a protocol and type in an address or a host name, we use browse to connect
- When finished, we use red number four to log out. This is nice thing to do, because the number of SSL connections is a license based feature and we should not let connections stay opened when not used
I guess this is simple enough and does not need special explanation except for one thing. So far we did not set up any domain resolving. This means that in the address field we could type in “192.168.1.5” but not “fileserver1”. In order to fix this, we need to set up a domain name resolution:
Now we can use both IP addresses and host names in the address fields.
At this time we have this clientless thing working and is time to mention some advantages and disadvantages:
- We don’t need a client. Actually we do and that client is a browser. Not all browsers are supported
- We don’t have to be admins on a remote PC
- Only few protocols are supported
- Easiest for admins to implement and for users to use
One more thing came to my mind: we can use our SSL portal to browse internal resources and normal browsing through another browser session, or we can use SSL portal for both. Whatever the case may be, we could do some filtering on a traffic that goes through SSL portal by means of access lists of type “webtype”. Something like this:
I think that this webtype access list and the way of using it is straight forward. Beside filtering http we could do filter on TCP ports and other supported protocols:
Some protocols are supported by clientless mode (HTTP://, HTTPS://, CIFS:// and FTP://) but to support others we need another method which we will discuss later.
Ok, let me see what else can be shown in this blog … Aside for customizations which we will cover in separate blog. Yes, we can deal with tunnel-group memberships and group-policy assignments…
Like said previously, by default there is only one group called “DefaultWEBVPNGroup” and one group-policy called “DfltGrpPolicy” with a connection between them stated with “default-group-policy” command inside of DefaultWEBVPNGroup pointing to DfltGrpPolicy. Well, this is not scalable. We don’t want all of our users to share the same params. What can we do? Three things:
- Let user choose group he or she will belong to
- Assign a user to a group by setting local or AAA attribute
- Assign a user to a group by selecting appropriate field from a client’s certificate
One thing at a time:
- Let user select a group membership
First we need to create a tunnel-group and group-policy and bind them together:
We created a tunnel-group called ADMINS, group-policy called also ADMINS, linked them together and enabled group selection. Now our login screen looks like this:
Now we can select this and any other groups we set up. Let’s verify:
Now user belongs to the group ADMINS and uses policy ADMINS. It’s easy now to set up parameters we want for users to have.
- We could assign a user to a particular policy on AAA server:
Once logged in, a user will be assigned ADMINS policy with all attributes from it. This policy can be local to the ASA such as in our case, and can be created on an AAA server, but that’s another story.
- Certificate maps. We could issue so called client certificates to our users, for instance using Active Directory Certificate Services. Those certs have some fields that we could use to map a user to a tunnel-group and hence to a group-policy. You can read about certificates and ASA in my previous blogs: Cisco ASA and Microsoft Enterprise CA and Cisco ASA and VPN Client with certificate authentication (RSA-SIG).
The basic idea behind this is: our users belong to different departments and most probably have certs that have fields with different values, such as OU field that normally contains the name of department to which user belongs. We could use those fields to map users to groups. Something like this:
First we created a certificate map called CERT_MAP_1 that we could explain like this: take a user cert, extract a subject-name from it and if OU field contains “direkcijait” then sequence number 10 will be satisfied. If, on the other hand, subject-name contains a CN field with a value of “sasa popravak”, sequence number 20 will be satisfied. We then enable a cert map processing with the “tunnel-group-map enable rules” and under the global webvpn config, we give the whole thing a sense: map a user to a group “DirekcijaIT” if CERT_MAP_1 sequence 10 is satisfied and map him/her to a group “ADMINS” if CERT_MAP_1 sequence 20 is satisfied. Simple, huh?
Now if a user tries to log in with a certificate that has an OU field with a value of “DirekcijaIT”, here is what happens:
So, this concludes our first WebVPN access type. Next time we will cover “thin client” in order to support so called non-web protocols. Stay tuned…