Hello all,

I encountered a wierd task when i was doing the INE vol1 lab. The task was like this

Configure 2 contexts :

• CONTEXT_1
• CONTEXT_2

Configure 2 users

• USER_1
• USER_2

Ensure that user USER_1 can only login when connecting to context “CONTEXT_1″ and USER_2 can only login when connecting to context “CONTEXT_2″

What this task was asking us to do is basically a “group lock” , akin to the ones we do in the ASA for the WEBVPN. I didn’t understand the explanation in the Solution guide, so i went out and did some studies. Here’s an awesome article i found ( through google. I know, i’m sorry! ) http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6657/prod_white_paper0900aecd80512065.html and this helped me to get this working.

Here’s a quick explanation of how this works on the ASA first.

If we want a user , say for example USER1 to connect only to tunnel-groupA , then we can enter the username attributes section and specify a command which will link the username to the tunnel-groupA. So when you login, the attributes are retreived at the beginning of the connection ( either locally or from an ACS ) , and the group-lock value is checked against the tunnel-group that you select when you connect. If they both don’t match then the connection is denied. If they match, magic happens and you’re cleared to proceed further.

Syntax :

#username USER1 password cisco

#username USER1 attributes

#group-lock value tunnel-groupA

Now that we’ve understood that, let’s head over to the IOS.

We’ve to achieve the same result, except that we are now tying the username to a “context” . The way it works here is as follows

• In the context configuration, specify a “domain” along with the gateway, so that the user can choose which context to connect to.
  • #webvpn context CONTEXT_1
    #gateway WEBVPN_GATEWAY domain CTX_1
    (and similarly for CONTEXT_2)
    #webvpn context CONTEXT_2
    #gateway WEBVPN_GATEWAY domain CTX_2
    
• Next, i’m assuming that we have already configured the “aaa authentication login” command in the contexts to point to aaa for the login authentication
• After , this we add in the magical command “aaa authentication domain @CTX_1″ in CONTEXT_1’s configuration and “aaa authentication domain @CTX_2″ in CONTEXT_2’s configuration. What this command does is, it will “APPEND” the domain-name that you specify in the command to the username that you are using to login and THEN send it for login authentication.
• So, after connecting to context 1, if we login using the username “USER1” , the context adds the domain name of “@CTX1” to it and shoots it over to the aaa engine for authentication.
• Now, instead of configuring “#username USER1 password cisco” , we will configure the username to include the appended context also.
  • #username USER1@CTX_1 password cisco
  • #username USER2@CTX_2 password cisco

So now we have everything setup and ready to work, but how does it work. Suppose i connect to context 2. I then login as “USER2″ with a password of cisco. The context appends “@CTX_2” to the username and sends it for authentication. This matches the second username i’ve configured and hence the tunnel goes through. Now , suppose i tried connecting to the same context ( context_2) and instead of USER2 i tried USER1. Just like the previous example, the context will append the context “@CTX_2″ to it and now it’ll check against the aaa database. There is no user configured which corresponds to “USER1@CTX_2” , so authentication fails.

I hope my explanation is understandable .  Here unlike ASA , where the ASA actually “checks” the tunnel-group that the user is allowed to connect to, IOS achieves the same result by playing dumb and using aaa to take care of group-locking.

Please feel free to ask questions if this confuses you. It did confuse me for quite sometime

Cheers,

TacACK