Basically there are two ways the ASA administrator can allow clients to select an authgroup (aka tunnel-group, aka Connection Profile):
1) Set up a group-alias for the tunnel-group, and turn on tunnel-group-list to show the dropdown menu:
ciscoasa(config-webvpn)# show run webvpn
webvpn
enable outside
anyconnect image disk0:/anyconnect-win-3.0.5080-k9.pkg 1
anyconnect enable
tunnel-group-list enable
ciscoasa(config-webvpn)# show run tunnel-group
tunnel-group default type remote-access
tunnel-group default webvpn-attributes
proxy-auth sdi
group-alias d enable
When the dropdown menu appears on the auth form, openconnect will use the --authgroup parameter (if present) to match the group label "d" and fill it in automatically:
The current (git.infradead.org) openconnect HEAD of tree still has some issues with authgroup selection when XML POST is enabled, but we're converging on a solution. This isn't relevant to your situation, however.
2) Set up a group-url, so clients who navigate directly to that URL do not see a dropdown at all:
ciscoasa(config-webvpn)# show run tunnel-group
tunnel-group default type remote-access
tunnel-group default webvpn-attributes
proxy-auth sdi
group-url https://asa/hidden-d enable
Since there is no dropdown menu (<select> node) in this case, specifying --authgroup doesn't actually do anything. You should be able to safely omit it.
Note that the same tunnel-group (or different sets of tunnel-group's) can be selected through both methods, and the group-alias doesn't need to match the path in the group-url.
I set up both types of groups locally, and verified that the issue shown in your log was fixed by this commit from the openconnect HEAD of tree:
On v5.01, the <group-access> node is missing the URL path:
> POST /AUTHGROUP HTTP/1.1
> Host: HOSTNAME
[...]
<group-access>https://HOSTNAME</group-access>
so in XML POST mode on v5.01 you are only able to use the groups that have a group-alias defined, not the group(s) which need to be accessed via group-url. This will be fixed in the next release.
@Cory
Basically there are two ways the ASA administrator can allow clients to select an authgroup (aka tunnel-group, aka Connection Profile):
1) Set up a group-alias for the tunnel-group, and turn on tunnel-group-list to show the dropdown menu:
ciscoasa( config- webvpn) # show run webvpn anyconnect- win-3.0. 5080-k9. pkg 1 group-list enable
webvpn
enable outside
anyconnect image disk0:/
anyconnect enable
tunnel-
ciscoasa( config- webvpn) # show run tunnel-group
tunnel-group default type remote-access
tunnel-group default webvpn-attributes
proxy-auth sdi
group-alias d enable
When the dropdown menu appears on the auth form, openconnect will use the --authgroup parameter (if present) to match the group label "d" and fill it in automatically:
< <select name="group_list" label="GROUP:"> "true"> d</option>
< <option selected=
< </select>
The current (git.infradead.org) openconnect HEAD of tree still has some issues with authgroup selection when XML POST is enabled, but we're converging on a solution. This isn't relevant to your situation, however.
2) Set up a group-url, so clients who navigate directly to that URL do not see a dropdown at all:
ciscoasa( config- webvpn) # show run tunnel-group /asa/hidden- d enable
tunnel-group default type remote-access
tunnel-group default webvpn-attributes
proxy-auth sdi
group-url https:/
Since there is no dropdown menu (<select> node) in this case, specifying --authgroup doesn't actually do anything. You should be able to safely omit it.
Note that the same tunnel-group (or different sets of tunnel-group's) can be selected through both methods, and the group-alias doesn't need to match the path in the group-url.
I set up both types of groups locally, and verified that the issue shown in your log was fixed by this commit from the openconnect HEAD of tree:
commit 06ac20e005b6cab a0a58fca13346ad 01ae0989c5
Author: Murilo Opsfelder Araujo <email address hidden>
Date: Thu Sep 12 14:53:54 2013 -0300
Append vpninfo->urlpath to <group-access>
Some ASA gateways may need the relative path specified in <group-access> XML
entry so it makes sense to verify if it exists and append it.
On v5.01, the <group-access> node is missing the URL path:
> POST /AUTHGROUP HTTP/1.1 /HOSTNAME</group-access>
> Host: HOSTNAME
[...]
<group-access>https:/
so in XML POST mode on v5.01 you are only able to use the groups that have a group-alias defined, not the group(s) which need to be accessed via group-url. This will be fixed in the next release.
Hope that clears things up...
For further reading: http:// www.cisco. com/en/ US/products/ ps6120/ products_ configuration_ example09186a00 808bd83d. shtml