ASA5520 - WebVPN authenticating to ACS, unable to lock users to specific groups/policies

Hello there,

I have an ASA5520 with two WebVPN tunnel groups configured. One is very limited in the sites the users can access, the other is much more open and allows most of the features of WebVPN. Both tunnel groups are configured to authenticate users against ACS. I need to be able to lock users into the correct tunnel group based on their ACS credentials. The most ideal scenario would be to have this happen "behind the scenes", meaning I wouldn't have to enable the drop-down box on the WebVPN login page, which allows users to select the tunnel group manually; however, if the drop-down is required, I need the ASA5520 to be able to lock a user to a group, so that a user who is supposed to be in the limited group can not simply select the more open tunnel group in the drop-down list and authenticate, gaining more access than they are supposed to have (this is what happens currently... the ASA5520 completely ignores and and all tunnel-group information passed back to it from the ACS server).

What I've been able to find in my searches indicates that I should be able to pass an IETF RADIUS attribute 25 back to the 5520 during authentication. This attribute supposedly just needs to contain "tunnel-group=WebVPN_Limited" in the case of my restricted WebVPN. Using debug on the 5520 shows that the attribute is indeed passed:

-------------------------------------- RADIUS packet decode (response)

-------------------------------------- Raw packet data (length = 85).....

02 6d 00 55 b2 b9 f8 70 0b 1c 53 fd cf dd 62 48 | .m.U...p..S...bH 93 f0 6a 05 19 1c 54 75 6e 6e 65 6c 2d 47 72 6f | ..j...Tunnel-Gro 75 70 3d 4f 50 55 42 43 4f 57 45 42 56 50 4e 3b | up=OPUBCOWEBVPN; 08 06 ff ff ff ff 19 1f 43 49 53 43 4f 41 43 53 | ........CISCOACS 3a 30 30 30 34 62 66 61 31 2f 64 30 39 31 37 65 | :0004bfa1/d0917e 31 35 2f 38 31 | 15/81

Parsed packet data..... Radius: Code = 2 (0x02) Radius: Identifier = 109 (0x6D) Radius: Length = 85 (0x0055) Radius: Vector: B2B9F8700B1C53FDCFDD624893F06A05 Radius: Type = 25 (0x19) Class Radius: Length = 28 (0x1C) Radius: Value (String) =

54 75 6e 6e 65 6c 2d 47 72 6f 75 70 3d 4f 50 55 | Tunnel-Group=OPU 42 43 4f 57 45 42 56 50 4e 3b | BCOWEBVPN; Radius: Type = 8 (0x08) Framed-IP-Address Radius: Length = 6 (0x06) Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF) Radius: Type = 25 (0x19) Class Radius: Length = 31 (0x1F) Radius: Value (String) = 43 49 53 43 4f 41 43 53 3a 30 30 30 34 62 66 61 | CISCOACS:0004bfa 31 2f 64 30 39 31 37 65 31 35 2f 38 31 | 1/d0917e15/81 rad_procpkt: ACCEPT RADIUS_ACCESS_ACCEPT: normal termination RADIUS_DELETE remove_req 0xdccb720 session 0x94e id 109 free_rip 0xdccb720 radius: send queue empty

--------------------------------------

In the decode above, you see the "Tunnel-Group=OPUBCOWEBVPN;" attribute included in the response. However, the ASA5520 pays no attention at all. I was successfully logged into the less restricted WebVPN tunnel group using a test username that is configured to be locked down, simply by selecting the less restricted group from the drop-down list. Indeed, if the ASA5520 would accept the attributes being passed to it, this would be working as desired. If I change everything to LOCAL auth instead of using ACS, it all works perfectly. Unfortunately there are going to be hundreds of users, so the idea of doing local auth is out of the question.

Does anyone know the magic setup to get the ASA5520 to behave as it is supposed to? Is attribute 25 (Class) not the right place to pass this tunnel group information back during authentication? Our local Cisco guy has replied to me indicating that attribute 25 is the right way to do it, to his knowledge. Unfortunately, it clearly doesn't work. Maybe the syntax is incorrect on the ACS server? I've entered the tunnel group info these four different ways:

tunnel-group=OPUBCOWEBVPN tunnel-group=OPUBCOWEBVPN;

Reply to
mrolen
Loading thread data ...

Not that this helps you with what you are looking for, but I could not get what you want to work and neither could Cisco. We litterally tried for over a month. What we ended up doing was pointing the groups to different authentication servers. We still had to use the drop down box, but if they selected the wrong one they didn't pass authentication.

Reply to
Brian V

We recently set this up similar to what your describing.

On the ASA We only define different tunnel groups for site to site (hardware VPN's). We used the default DefaultWEBVPNGroup for the tunnel group they would come in on and set the authentication to your Radius server. Next create a new group policy named GP-REMOTEGROUPA. Enable split tunneling so they "tunnel networks listed below". Next define your networks you will allow the client to access inside the network list.

Inside AD create a group "GG-REMOTEGROUPA" and add any members you want to pull this policy.

On to RADIUS - I am assuming your using IAS for RADIUS Create a new policy under "Remote Access Policies". Setup a custom policy "GG-REMOTEGROUPA". Inside Policy Conditions set your "Windows Group" to "GG-REMOTEGROUPA" (we defined that earlier inside AD). Grant access and click to "Edit Profile". Under "Authentication" tab untick everything but "Unencryped Access". Under "Encryption" tab untick everything but "No Encryption". Under "Advanced" tab remove everything and add back "Class" for the string value enter "OU=GP-REMOTEGROUPA". The OU part must match the group policy you setup on the ASA.

That should do it. BTW we dont event display the drop down box at all.

Reply to
Its me Earnest T.

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.