cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2733
Views
20
Helpful
4
Replies

AnyConnect + ISE + Swisscom Mobile ID two factor authentication

Network Diver
Level 1
Level 1


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:

 

  1. Start AnyConnect and connect to VPN peer.
  2. Enter the first password in the AnyConnect window and click OK.
  3. AnyConnect answer window pops up with the message to sign the request on the mobile phone.
  4. On the mobile phone a window pops up where one has to enter the Mobile ID PIN.
  5. Authentication is completed. There no need to enter a second token in the AnyConnect answer input field.
  6. 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

1 Accepted Solution

Accepted Solutions

Network Diver
Level 1
Level 1

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

 

 

View solution in original post

4 Replies 4

Milos_Jovanovic
VIP Alumni
VIP Alumni

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

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

Milos_Jovanovic
VIP Alumni
VIP Alumni

I don't think you'll be able to avoid that.

BR,

Milos

Network Diver
Level 1
Level 1

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