SSL VPN Aliases

[WILLIAM STEGMAN]

I'm trying to restrict the aliases user accounts can log in to when using SSL VPN. Right now I have several groups with different customizations, but every user is able to login to each of the aliases I've setup. The authentication portion is taken care of by radius and AD. Do I need to create multiple authentication groups and use those different authentication methods in the group policy of the vpn group, so that back at the radius server I can have a different group being used in the remote access policy rules on the radius server, or is there a way to use the group lock group policy attribute to accomplish the same thing?

thank you,

Bill

[Richard Burts]

Bill

Am I correct in assuming that you are doing this on an ASA to terminate the VPN tunnels?

I have recently been working through this with a customer. If the Radius server has the group identified which each user should be using then you can use the tunnel group lock policy attribute to limit what group they can log in.

The Radius server will pass the group name in attribute 25 (CLASS). If a user should belong to a certain group (perhaps group1 as an example), and if the user is attempting to log in to another group (group2 as an example), and if group1 has the tunnel group lock enabled, then the user attempt to login to group2 is denied.

HTH

Rick

[WILLIAM STEGMAN]

yes, it's an ASA. I'm having trouble understanding. Maybe it's the term group. When you say a user belonging to a ceratin group, do you mean active directory group or vpn group name? Is the trick making the active directory group and the vpn group the same name?

If I have an active directory group that I use for authenticating users that correlates to a certain vpn group ID, I'm locking it down. This gets confusing to explain, but as an example, I have a vpn group called Consultants. I don't want members of the AD group Consultants VPN to be able to login to the vpn group I have setup for our employees. So if I create a separate authentication server group on the ASA and point it to a different radius server, which has a policy stating the member must be in an AD group different than the one used for employees, is that the same thing?

[Richard Burts]

Bill

It can be a challenge trying to understand what a particular term means, especially when that term might different meanings in different contexts. In my discussion I am talking about groups the ASA connection profile.

In configuring the attributes for the connection profile/group you can enable the group lock. In enabling the group lock you supply a text string. The value of that text string must match what the Radius server sends in the class attribute of the authentication message.

I am not familiar with your situation. But I would assume that the easy way would be to make the group lock value match the AD group.

HTH

Rick

[WILLIAM STEGMAN]

I've changed the active dir name of the group used to authenticate on our radius server to match the vpn group and enabled group lock on the group policy used for the vpn group, but it still allows a user to login to mulitple aliases(groups). I'm not sure what I could be missing.

[Richard Burts]

Bill

Are both the group the user should belong to, and the group to which they are logging in, configured to authenticate with Radius? And do both groups (aliases) have the tunnel group lock enabled? In my experience that prevents a user from logging in to the wrong group.

Perhaps a debug of the authentication might be helpful. And a debug radius should show what the Radius server is sending back in the authentication message - especially for the class attribute (group).

HTH

Rick

[WILLIAM STEGMAN]

Rick, yep, both the aliases, or groups, have a vpn group policy that has the group lock attribute. I don't see a group in the debug radius output. Is it an attribute that might not exist by default on a windows radius server?

rsed packet data.....

Radius: Code = 1 (0x01)

Radius: Identifier = 89 (0x59)

Radius: Length = 111 (0x006F)

Radius: Vector: 021350494E6F7C055A8B6881266714BD

Radius: Type = 1 (0x01) User-Name

Radius: Length = 10 (0x0A)

Radius: Value (String) =

6c 73 74 65 67 6d 61 6e | lstegman

Radius: Type = 2 (0x02) User-Password

Radius: Length = 18 (0x12)

Radius: Value (String) =

08 18 f5 e2 e0 14 ff a9 7d 7d 81 22 0e e5 a7 44 | ........}}."...D

Radius: Type = 31 (0x1F) Calling-Station-Id

Radius: Length = 13 (0x0D)

Radius: Value (String) =

37 34 2e 39 32 2e 38 34 2e 37 30 | x.x.x.x

Radius: Type = 61 (0x3D) NAS-Port-Type

Radius: Length = 6 (0x06)

Radius: Value (Hex) = 0x5

Radius: Type = 4 (0x04) NAS-IP-Address

Radius: Length = 6 (0x06)

Radius: Value (IP Address) = 192.168.255.2 (0xC0A8FF02)

Radius: Type = 5 (0x05) NAS-Port

Radius: Length = 6 (0x06)

Radius: Value (Hex) = 0xB54

Radius: Type = 26 (0x1A) Vendor-Specific

Radius: Length = 32 (0x20)

Radius: Vendor ID = 9 (0x00000009)

Radius: Type = 1 (0x01) Cisco-AV-pair

Radius: Length = 26 (0x1A)

Radius: Value (String) =

69 70 3a 73 6f 75 72 63 65 2d 69 70 3d 37 34 2e | ip:source-ip=74.

39 32 2e 38 34 2e 37 30 | 92.84.70

send pkt x.x.x.x/1645

rip 0xd5b673dc state 7 id 89

rad_vrfy() : response message verified

rip 0xd5b6b0f8

: chall_state ''

: state 0x7

: timer 0x0

: reqauth:

02 13 50 49 4e 6f 7c 05 5a 8b 68 81 26 67 14 bd

: info 0x6522

session_id 0x6522

request_id 0x59

user 'lstegman'

response '***'

app 0

reason 0

skey '******'

sip 172.21.4.18

type 1

RADIUS packet decode (response)

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

Raw packet data (length = 88).....

02 59 00 58 e1 89 f0 c5 9b 4a c2 ea 54 19 b7 7c | .Y.X.....J..T..|

95 4c d6 c2 07 06 00 00 00 01 06 06 00 00 00 02 | .L..............

19 20 39 aa 04 89 00 00 01 37 00 01 ac 15 04 12 | . 9......7......

01 ca 1e 0d 54 f9 1a a0 00 00 00 00 00 00 04 77 | ....T..........w

1a 0c 00 00 01 37 07 06 00 00 00 02 1a 0c 00 00 | .....7..........

01 37 08 06 00 00 00 0e | .7......

Parsed packet data.....

Radius: Code = 2 (0x02)

Radius: Identifier = 89 (0x59)

Radius: Length = 88 (0x0058)

Radius: Vector: E189F0C59B4AC2EA5419B77C954CD6C2

Radius: Type = 7 (0x07) Framed-Protocol

Radius: Length = 6 (0x06)

Radius: Value (Hex) = 0x1

Radius: Type = 6 (0x06) Service-Type

Radius: Length = 6 (0x06)

Radius: Value (Hex) = 0x2

Radius: Type = 25 (0x19) Class

Radius: Length = 32 (0x20)

Radius: Value (String) =

39 aa 04 89 00 00 01 37 00 01 ac 15 04 12 01 ca | 9......7........

1e 0d 54 f9 1a a0 00 00 00 00 00 00 04 77 | ..T..........w

Radius: Type = 26 (0x1A) Vendor-Specific

Radius: Length = 12 (0x0C)

Radius: Vendor ID = 311 (0x00000137)

Radius: Type = 7 (0x07) Unknown

Radius: Length = 6 (0x06)

Radius: Type = 26 (0x1A) Vendor-Specific

Radius: Length = 12 (0x0C)

Radius: Vendor ID = 311 (0x00000137)

Radius: Type = 8 (0x08) Unknown

Radius: Length = 6 (0x06)

rad_procpkt: ACCEPT

RADIUS_ACCESS_ACCEPT: normal termination

RADIUS_DELETE

remove_req 0xd5b673dc session 0x6522 id 89

free_rip 0xd5b673dc

radius: send queue empty

un all

[Richard Burts]

Bill

Here is the class attribute in the debug message:

Radius: Type = 25 (0x19) Class

Radius: Length = 32 (0x20)

Radius: Value (String) =

39 aa 04 89 00 00 01 37 00 01 ac 15 04 12 01 ca | 9......7........

1e 0d 54 f9 1a a0 00 00 00 00 00 00 04 77 | ..T..........w

It looks like the attribute does exist but does not have values as you expect them. I am not sure whether this is a setup issue in Radius or something about the interaction between Radius and AD. Is AD passing the group info to Radius?

HTH

Rick