Now that we have configured WebVPN its time to talk about how we go about keeping it secure as well as ensuring proper user privilege. If you’ll notice in our last post when we configured different customizations for the WebVPN portal we were using the same user name to login to both of the portals. This isn’t an ideal configuration. In most cases you will want user to only be able to login to their version of the WebVPN portal. That is, you don’t want someone from marketing selecting MIS/IT from the drop down menu on the logon page and gaining elevated access to your systems. If you are dead set on staying with local authentication (locally defined users on the ASA) then you should consider configuring group-lock. Group-lock is exactly what it sounds like, a way to lock a user into a group. For instance, let’s say that we have two users, we’ll call them UserSales and UserMarketing. We only want UserMarketing to be able to logon to the marketing tunnel group and UserSales to be able to logon to the Sales tunnel group. To do this we simply assign each user a group-lock for their correct tunnel group. The syntax is simple and as I said, if you are doing local authentication and have multiple tunnel groups, this is a necessity.
-Insert your relevant information between <>
-Console prompts are show in green
-Text in blue are variable names I made up, feel free to change them
Define a group-lock for a user
CiscoASA(config)# username <username> attributes
CiscoASA(config-username)# group-lock value <Tunnel Group Name>
So let’s take a look at our scenario mentioned above. Without group-lock our UserMarketing can select IT from the tunnel group drown down (or browse to its group URL if it has one defined) and log right in to the IT portal.
However, after we specify the group-lock on UserMarketing they receive the error shown below when they attempt to login to any group besides marketing.
Summary – If you have a small basic WebVPN configuration and local authentication seem appropriate group-locking can keep your users separate. In the next post we are going to configure a RADIUS server to process our logon requests. Not only are there some really neat group policy features that come along with RADIUS but we also get all of the security features of a MS domain. Think password complexity, history, length, expiration, etc…