This article describes the group-locking features on the Cisco Adaptive Security Appliance (ASA) and in Cisco IOS® and presents the behavior for different Authentication, Authorization, and Accounting (AAA) attributes. For Cisco IOS, the difference between the group-lock and the user-vpn-groups is explained along with an example that uses both complementary features at the same time. There is also a Cisco IOS WebVPN example with authentication domains.
Cisco recommends that you have baisc knowledge of these topics:
The information in this document is based on these software versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
You can define this attribute under the user or the group-policy. Here is an example for the local user attribute.
username cisco password 3USUcOPFUiMCO4Jk encrypted
username cisco attributes
group-lock value RA
username cisco2 password BAtr3u1T7j1eEcYr encrypted
username cisco2 attributes
group-lock value RA2
tunnel-group RA type remote-access
tunnel-group RA general-attributes
default-group-policy MY
tunnel-group RA webvpn-attributes
group-alias RA enable
tunnel-group RA2 type remote-access
tunnel-group RA2 general-attributes
default-group-policy MY
tunnel-group RA2 webvpn-attributes
group-alias RA2 enable
group-policy MY attributes
address-pools value POOL
webvpn
enable inside
anyconnect enable
tunnel-group-list enable
The cisco user is able to use only the RA tunnel-group, and the cisco2 user is able to use only the RA2 tunnel-group.
If the cisco2 user chooses the RA tunnel-group, then the connection is denied:
May 17 2013 17:24:54: %ASA-4-113040: Group <MY> User <cisco2> IP <192.168.1.88>
Terminating the VPN connection attempt from <RA>. Reason: This connection is
group locked to <RA2>.
Attribute 3076/85 (Tunnel-Group-Lock) that is returned by the AAA server does exactly the same. It can be passed along with the user or the policy-group (or Internet Engineering Task Force (IETF) attribute 25) authentication and locks the user in a specific tunnel-group.
Here is an example authorization profile on the Cisco Access Control Server (ACS):
When the attribute is returned by AAA, the RADIUS debugs indicate it:
tunnel-group RA2 general-attributes
authentication-server-group ACS54
Parsed packet data.....
Radius: Code = 2 (0x02)
Radius: Identifier = 2 (0x02)
Radius: Length = 61 (0x003D)
Radius: Vector: E55D5EBF1558CA455DA46F5BF3B67354
Radius: Type = 1 (0x01) User-Name
Radius: Length = 7 (0x07)
Radius: Value (String) =
63 69 73 63 6f | cisco
Radius: Type = 25 (0x19) Class
Radius: Length = 24 (0x18)
Radius: Value (String) =
43 41 43 53 3a 61 63 73 35 34 2f 31 35 38 33 33 | CACS:acs54/15833
34 34 38 34 2f 33 | 4484/3
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 10 (0x0A)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 85 (0x55) The tunnel group that tunnel must be associated with
Radius: Length = 4 (0x04)
Radius: Value (String) =
52 41 | RA
rad_procpkt: ACCEPT
RADIUS_ACCESS_ACCEPT: normal termination
The result is the same when you try to access the RA2 tunnel-group while group-locked within the RA tunnel-group:
May 17 2013 17:41:33: %ASA-4-113040: Group <MY> User <cisco> IP <192.168.1.88>
Terminating the VPN connection attempt from <RA2>. Reason: This connection is
group locked to <RA>
This attribute is also taken from the VPN3000 directory inherited by the ASA. It is still present in the 8.4 configuration guide (although it is removed in a newer version of configuration guide) and described as:
IPsec-User-Group-Lock
0 = Disabled
1 = Enabled
It appears that the attribute could be used in order to disable group-locking, even if the Tunnel-Group-Lock attribute is present. If you try to return that attribute set to 0 along with the Tunnel-Group-Lock (this is still just user authentication), here is what happens. It looks strange when you try to disable group-locking while returning a specific tunnel-group name:
Debugs show:
Parsed packet data.....
Radius: Code = 2 (0x02)
Radius: Identifier = 3 (0x03)
Radius: Length = 73 (0x0049)
Radius: Vector: 7C6260DDFC3E523CCC34AD8B828DD014
Radius: Type = 1 (0x01) User-Name
Radius: Length = 7 (0x07)
Radius: Value (String) =
63 69 73 63 6f | cisco
Radius: Type = 25 (0x19) Class
Radius: Length = 24 (0x18)
Radius: Value (String) =
43 41 43 53 3a 61 63 73 35 34 2f 31 35 38 33 33 | CACS:acs54/15833
34 34 38 34 2f 34 | 4484/4
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 12 (0x0C)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 33 (0x21) Group-Lock
Radius: Length = 6 (0x06)
Radius: Value (Integer) = 0 (0x0000)
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 10 (0x0A)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 85 (0x55) The tunnel group that tunnel must be associated with
Radius: Length = 4 (0x04)
Radius: Value (String) =
52 41 | RA
rad_procpkt: ACCEPT
This yields the same result (group locking has been enforced, and the IPSec-User-Group-Lock has not been taken into consideration).
May 17 2013 17:42:34: %ASA-4-113040: Group <MY> User <cisco> IP <192.168.1.88>
Terminating the VPN connection attempt from <RA2>. Reason: This connection is
group locked to <RA>
The external group-policy returned IPSec-User-Group-Lock=0 and also got Tunnel-Group-Lock=RA for user authentication. Still, the user has been locked, which means that Group Locking has been performed.
For the opposite configuration, the external group-policy returns a specific tunnel-group name (Tunnel-Group-Lock) while it tries to disable group-locking for a specific user (IPSec-User-Group-Lock=0), and group-locking has still been enforced for that user.
This confirms that the attribute is not used anymore. That attribute was used in the old VPN3000 series. Cisco bug ID CSCui34066 has been opened.
The local group-lock option under the group configuration in Cisco IOS works differently than on the ASA. On the ASA, you specify the tunnel-group name to which the user is locked. The Cisco IOS group-lock option (there are no arguments) enables additional verification and compares the group provided with the username (format user@group) with IKEID (group name).
For more information, refere to the Easy VPN Configuration Guide, Cisco IOS Release 15M&T.
Here is an example:
aaa new-model
aaa authentication login LOGIN local
aaa authorization network LOGIN local
username cisco1@GROUP1 password 0 cisco1
username cisco2@GROUP2 password 0 cisco2
crypto isakmp client configuration group GROUP1
key cisco
pool POOL
group-lock
save-password
!
crypto isakmp client configuration group GROUP2
key cisco
pool POOL
save-password
crypto isakmp profile prof1
match identity group GROUP1
client authentication list LOGIN
isakmp authorization list LOGIN
client configuration address respond
client configuration group GROUP1
virtual-template 1
crypto isakmp profile prof2
match identity group GROUP2
client authentication list LOGIN
isakmp authorization list LOGIN
client configuration address respond
client configuration group GROUP2
virtual-template 2
crypto ipsec transform-set aes esp-aes 256 esp-sha-hmac
mode tunnel
crypto ipsec profile prof1
set transform-set aes
set isakmp-profile prof1
crypto ipsec profile prof2
set transform-set aes
set isakmp-profile prof2
interface Virtual-Template1 type tunnel
ip unnumbered Ethernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile prof1
interface Virtual-Template2 type tunnel
ip unnumbered Ethernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile prof2
ip local pool POOL 10.10.10.10 10.10.10.15
This shows that group-locking verification is enabled for GROUP1. For GROUP1, the only allowed user is cisco1@GROUP1. For GROUP2 (no group-lock), both users are able to log in.
For successful authentication, use cisco1@GROUP1 with GROUP1:
*May 19 18:21:37.983: ISAKMP:(0): Profile prof1 assigned peer the group named GROUP1
*May 19 18:21:40.595: ISAKMP/author: Author request for group GROUP1successfully
sent to AAA
For authentication, use cisco2@GROUP2 with GROUP1:
*May 19 18:24:10.210: ISAKMP:(1011):User Authentication in this group failed
The ipsec:user-vpn-group is the RADIUS attribute returned by the AAA server, and it can be applied only for user authentication (group-lock was used for the group). Both features are complementary, and they are applied at different stages.
For more information, refer to the Easy VPN Configuration Guide, Cisco IOS Release 15M&T.
It works differently than the group-lock and still allows you to achieve the same result. The difference is that the attribute must have a specific value (like for the ASA) and that specific value is compared with the Internet Security Association and Key Management Protocol (ISAKMP) group name (IKEID); if it does not match, then the connection fails. Here is what happens if you change the previous example in order to have client AAA authentication and disable group-lock for now:
username cisco password 0 cisco #for testing
aaa authentication login AAA group radius
crypto isakmp client configuration group GROUP1
no group-lock
crypto isakmp client configuration group GROUP2
no group-lock
crypto isakmp profile prof1
client authentication list AAA
crypto isakmp profile prof2
client authentication list AAA
Notice that the ipsec:user-vpn-group attribute is defined for the user and group-lock is defined for the group.
On the ACS, there are two users, cisco1 and cisco2. For the cisco1 user, this attribute is returned: ipsec:user-vpn-group=GROUP1. For the cisco2 user, this attribute is returned: ipsec:user-vpn-group=GROUP2.
When the cisco2 user tries to log in with GROUP1, this error is reported:
debug radius verbose
debug crypto isakmp
debug crypto isakmp aaa
*May 19 19:44:10.153: RADIUS: Cisco AVpair [1] 29
"ipsec:user-vpn-group=GROUP2"
*May 19 19:44:10.153: RADIUS(00000055): Received from id 1645/23
AAA/AUTHOR/IKE: Processing AV user-vpn-group
*May 19 19:44:10.154:
AAA/AUTHOR/IKE: User group GROUP2 does not match VPN group GROUP1 - access denied
This is because the ACS for the cisco2 user returns ipsec:user-vpn-group=GROUP2, which is compared by Cisco IOS to GROUP1.
This way, the same goal has been achieved as for the group-lock. You can see that right now, the end user does not need to provide user@group as the username, but can use user (without the @group).
For group-lock, cisco1@GROUP1 should be used, because Cisco IOS stripped the last part (after @) and compared it with IKEID (group name).
For the ipsec:user-vpn-group, it is sufficient to use only cisco1 in the Cisco VPN Client, because that user is defined on the ACS and the specific ipsec:user-vpn-group is returned (in this case, it is =GROUP1) and that attribute is compared against IKEID.
Why should you not use both features at the same time?
You can add group-lock again:
crypto isakmp client configuration group GROUP1
group-lock
crypto isakmp client configuration group GROUP2
group-lock
Here is the flow:
*May 19 20:14:31.678: ISAKMP/xauth: reply attribute XAUTH_USER_NAME_V2
*May 19 20:14:31.678: ISAKMP/xauth: reply attribute XAUTH_USER_PASSWORD_V2
*May 19 20:14:31.678: ISAKMP:(1041):User Authentication in this group failed
AAA/AUTHOR/IKE: User group GROUP2 does not match VPN group GROUP1 - access denied
On the ASA, the Tunnel-Group-Lock can be used for all remote access VPN services (IPSec, SSL, WebVPN). For the Cisco IOS group-lock and the ipsec:user-vpn-group, it works only for IPSec (easy VPN server). In order to group-lock specific users in specific WebVPN contexts (and attached group-policies), authentication domains should be used.
Here is an example:
aaa new-model
aaa authentication login LIST local
username cisco password 0 cisco
username cisco1@C1 password 0 cisco
username cisco2@C2 password 0 cisco
webvpn gateway GW
ip address 10.48.67.137 port 443
http-redirect port 80
logging enable
inservice
!
webvpn install svc flash:/webvpn/anyconnect-win-3.1.02040-k9.pkg sequence 1
!
webvpn context C1
ssl authenticate verify all
!
policy group C1
functions file-access
functions file-browse
functions file-entry
functions svc-enabled
svc address-pool "POOL"
svc default-domain "cisco.com"
svc keep-client-installed
default-group-policy C1
aaa authentication list LIST
aaa authentication domain @C1
gateway GW domain C1 #accessed via https://IP/C1
logging enable
inservice
!
!
webvpn context C2
ssl authenticate verify all
url-list "L2"
heading "Link2"
url-text "Display2" url-value "http://2.2.2.2"
policy group C2
url-list "L2"
default-group-policy C2
aaa authentication list LIST
aaa authentication domain @C2
gateway GW domain C2 #accessed via https://IP/C2
logging enable
inservice
ip local pool POOL 7.7.7.10 7.7.7.20
In the next example, there are two contexts: C1 and C2. Each context has its own group-policy with specific settings. C1 allows for AnyConnect access. The gataway is configured in order to listen to both contexts: C1 and C2.
When the cisco1 user accesses the C1 context with https://10.48.67.137/C1, the authentication domain adds C1 and authenticates against the locally defined (list LIST) cisco1@C1 username:
debug webvpn aaa
debug webvpn
*May 20 16:30:07.518: WV: validated_tp : cert_username : matched_ctx :
*May 20 16:30:07.518: WV-AAA: AAA authentication request sent for user: "cisco1"
*May 20 16:30:07.518: WV: ASYNC req sent
*May 20 16:30:07.518: WV-AAA: AAA Authentication Passed!
*May 20 16:30:07.518: %SSLVPN-5-LOGIN_AUTH_PASSED: vw_ctx: C1 vw_gw: GW remote_ip:
10.61.218.146 user_name: cisco1, Authentication successful, user logged in
*May 20 16:30:07.518: WV-AAA: User "cisco1" has logged in from "10.61.218.146" to gateway "GW"
context "C1"
When you try to log in with cisco2 as a username while you access the C1 context (https://10.48.67.137/C1), this failure is reported:
*May 20 16:33:56.930: WV: validated_tp : cert_username : matched_ctx :
*May 20 16:33:56.930: WV-AAA: AAA authentication request sent for user: "cisco2"
*May 20 16:33:56.930: WV: ASYNC req sent
*May 20 16:33:58.930: WV-AAA: AAA Authentication Failed!
*May 20 16:33:58.930: %SSLVPN-5-LOGIN_AUTH_REJECTED: vw_ctx: C1 vw_gw: GW
remote_ip: 10.61.218.146 user_name: cisco2, Failed to authenticate user credentials
This is because there is no cisco2@C1 user defined. the cisco user is not able to log in to any context.
There is currently no verification procedure available for this configuration.
There is currently no specific troubleshooting information available for this configuration.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
25-Apr-2014 |
Initial Release |