
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-12-2021 11:17 PM - edited 10-12-2021 11:19 PM
Hello,
We are currently using AnyConnect that does two factor authentication with Swisscom Mobile ID. Maybe other phone companies have a similar service with another name. Login procedure with that service is as follows:
- Start AnyConnect and connect to VPN peer.
- Enter the first password in the AnyConnect window and click OK.
- AnyConnect answer window pops up with the message to sign the request on the mobile phone.
- On the mobile phone a window pops up where one has to enter the Mobile ID PIN.
- Authentication is completed. There no need to enter a second token in the AnyConnect answer input field.
- Click on Continue and one is connected.
This worked fine for years while the ASA firewall directly authenticates against the RADIUS server doing Swisscom Mobile ID. The firewall just ignored that the second input field was empty.
However, we have to put Cisco ISE in the middle of the authentication path to do posture on the connecting client and reject connection if it is not compliant. In that setup the authentication only works if the user ends something in the second input field from AnyConnect. If it is left empty, then ISE returns authentication failed.
Is there a way to tell ISE to ignore the second input field? With normal two factor authentication there the TAN number received by SMS is entered. This is not required with Swisscom Mobile ID.
Thanks in advance,
Bernd
Solved! Go to Solution.
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-18-2021 05:30 AM - edited 11-19-2021 12:32 AM
It's a bug! https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs59715
A possible workaround is to do the authentication part directly on the RADIUS server and do authorization on ISE.
aaa-server MobileID protocol radius
reactivation-mode depletion deadtime 3
max-failed-attempts 1
aaa-server MobileID (inside) host 1.1.1.1
timeout 300
key *****
aaa-server MobileID (inside) host 2.2.2.2
timeout 300
key *****
aaa-server ISE protocol radius
authorize-only
reactivation-mode depletion deadtime 3
max-failed-attempts 1
merge-dacl before-avpair
dynamic-authorization
aaa-server ISE (inside) host 3.3.3.3
timeout 300
key *****
radius-common-pw *****
aaa-server ISE (inside) host 4.4.4.4
timeout 300
key *****
radius-common-pw *****
tunnel-group vpn_mobileid type remote-access
tunnel-group vpn_mobileid general-attributes
authentication-server-group MobileID
authorization-server-group ISE
accounting-server-group ISE
authorization-required
tunnel-group vpn_mobileid webvpn-attributes
radius-reject-message
group-alias "MobileID" enable
group-url https://vpn.example.com/mobileid enable
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-12-2021 11:28 PM
Hi @Network Diver,
I faced something similar back in the days, with another product, but principle was the same. As you are prompting used to enter credentials, then the password field must not be empty when request is passed to ISE, as otherwise, ISE won't proceed with processing of such packet.
Workaround that we implemented was to put some dummy, predefined password, communicated to all users (I believe we used something like '0000'). In this case flow is a bit different:
- User initiates AC connection and receives credentials prompt
- Earlier, you just entered username, blank password and selected 'OK'. Now, you have to use username and password of '0000', and then select 'OK'.
- You get a popup asking to enter OTP/acknowledge notification or whatever
- Everything else is the same
BR,
Milos
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-12-2021 11:53 PM
Hello @Milos_Jovanovic,
Thanks. I was also thinking about something like that but hoping for a solution that does not involve behaviour change of our users.
Regards,
Bernd
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2021 02:40 AM
I don't think you'll be able to avoid that.
BR,
Milos

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-18-2021 05:30 AM - edited 11-19-2021 12:32 AM
It's a bug! https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs59715
A possible workaround is to do the authentication part directly on the RADIUS server and do authorization on ISE.
aaa-server MobileID protocol radius
reactivation-mode depletion deadtime 3
max-failed-attempts 1
aaa-server MobileID (inside) host 1.1.1.1
timeout 300
key *****
aaa-server MobileID (inside) host 2.2.2.2
timeout 300
key *****
aaa-server ISE protocol radius
authorize-only
reactivation-mode depletion deadtime 3
max-failed-attempts 1
merge-dacl before-avpair
dynamic-authorization
aaa-server ISE (inside) host 3.3.3.3
timeout 300
key *****
radius-common-pw *****
aaa-server ISE (inside) host 4.4.4.4
timeout 300
key *****
radius-common-pw *****
tunnel-group vpn_mobileid type remote-access
tunnel-group vpn_mobileid general-attributes
authentication-server-group MobileID
authorization-server-group ISE
accounting-server-group ISE
authorization-required
tunnel-group vpn_mobileid webvpn-attributes
radius-reject-message
group-alias "MobileID" enable
group-url https://vpn.example.com/mobileid enable
