AnyConnect w/ SAML & Azure AD - Authentication not prompted for

Solved
lesliebright
Here to help

AnyConnect w/ SAML & Azure AD - Authentication not prompted for

I have one network working with AnyConnect using SAML and Azure AD and it works as expected. Users can connect using their Azure AD credentials and things seems to be great there. When I've tried to set up any second site, there is no prompt for authentication at all, just a successful connection message and they are truly connected. I have deleted and recreated and Azure application and retested it. I currently have a case open about this issue but wanted to see if anyone else in the community has run into this or might have a clue for me. Thanks for any replies.

1 Accepted Solution
Bsalami
Meraki Employee
Meraki Employee

Could have been firmware related. In 16.16.2+ and 17.7+ firmware versions a change was made to set the Forceauthn= value to true in the SAML request sent by the MX to the Identity Provider. This means that each time a user tries to re-authenticate, user credentials will be required. Prior to this change users were able to disconnect and reconnect to the VPN without credentials within a given time - if the user's auth token was considered still valid by the Identity Provider.

View solution in original post

28 Replies 28
jmeyer
New here

Are you using the default port or a different port?

lesliebright
Here to help

Default.

jmeyer
New here

One thing I noticed that confused me was that once a user connected successfully to Azure AD it seems to remember it and not prompt for the multifactor. It freaked me out a little. It is kind of like the o365 MFA it doesn't require MFA if the user has recently authenticated via MFA.

lesliebright
Here to help

The original network I set this up with prompts every time. Any new network I try to set up with AnyConnect and SAML never prompts, even the first time. 

ToryDav
Building a reputation

I don't think you can use the same cisco anyconnect enterprise application with different anyconnect servers 

lesliebright
Here to help

I think you're correct but I haven't seen definitive documentation on that. To be clear, this is a second discrete application from the first network. 

PhilipDAth
Kind of a big deal
Kind of a big deal

You can't share enterprise applications.  You need an AnyConnect enterprise application for each MX head end.

lesliebright
Here to help

I do have an enterprise application for each MX. I did try sharing one at one point, but that is not what is causing this behavior now. Now it seems that the Forceauthn= value isn't being set to True by the MX. The MX is picking up on an Azure token rather than forcing authentication at connection time. 

lesliebright
Here to help

Update: Azure application sign-in logs for both locations give successful authentication results and each knows the identity of the user(s). Both logs claim that the first and second factors are satisfied by an existing token, but again, one network prompts for credentials every time and other one never does. 

PhilipDAth
Kind of a big deal
Kind of a big deal

One thing to note about SAML is that it is an SSO technology (single sign-on).  To spell this out further - if a user is already signed on, they don't have to sign in for any other SAML app - single sign-on.

 

Most likely, in this case, the user has already SAML authenticated to something else, and hence Azure is not making them authenticate again.

 

More than likely, you are experiencing normal and correct operation.

lesliebright
Here to help

Thanks for the reply! I agree and think you are correct that this would, under most circumstances, be normal behavior. The mystery in this case is that there are two networks, with two Azure applications, and they behave differently. "Network 1" prompts for credentials, including MFA, every time. "Network 2" never prompts for credentials at all. The sign-on log in Azure shows the same authentication successes for both networks. So, I can connect to network 1 by entering all credentials, then disconnect, and connect right back, and I am still prompted for credentials. i could then disconnect from network 1 and connect to network 2 and not be prompted. I could disconnect and reconnect to network 2 repeatedly and not be prompted. if I go back to network 1, I am prompted again, including for the second factor. 

PhilipDAth
Kind of a big deal
Kind of a big deal

What is the Azure session length configured for network 2?  Perhaps try dropping it to 1 hour.  Another option, go into network 2, and force sign out the user.

The user doesn't have a FIDO token (like a Ubikey) for network 2 plugged into their computer's USB port?

 

It sounds to me like the user is not already logged into network 1 (and gets prompted) but is signed into network 2 (and is not getting prompted).

lesliebright
Here to help

I did not deliberately configure either application's session length and don't even know where to look for that. 

 

I am one of the users for this and use my own account for testing the authentication. I do not have any FIDO tokens and I am testing both from Windows and iOS. 

 

Networks 1 and 2 refer to my Meraki networks, so I assumed "disconnecting" the VPN client also "logged out". 

lesliebright
Here to help

We replaced the MX in the affected network for another reason, and that solved this issue as well. I am still not certain what went wrong with the MX, but I wanted to update this in case anyone else runs into the same issue and comes here looking for answers. 

Bsalami
Meraki Employee
Meraki Employee

Could have been firmware related. In 16.16.2+ and 17.7+ firmware versions a change was made to set the Forceauthn= value to true in the SAML request sent by the MX to the Identity Provider. This means that each time a user tries to re-authenticate, user credentials will be required. Prior to this change users were able to disconnect and reconnect to the VPN without credentials within a given time - if the user's auth token was considered still valid by the Identity Provider.

lesliebright
Here to help

Both networks that are working as expected, with prompts for credentials at every connection, are on 16.16.3, including the MX that was replaced. The currently affected network was on 16.16.3 and I tried updating it to 16.16.4 last night, with no change to the symptoms.

lesliebright
Here to help

I think you're onto something here, but I don't know that it is always working correctly or always being applied. I just had a discussion with some Microsoft Azure engineers and as far as we can all tell, authentication is working as expected from Azure. We can see the sign-in logs and can see that the sessions are being authenticated from existing tokens. I can provide some level of control using conditional access policies from the Azure side, but I cannot require a prompt for every connection...at least not yet. Apparently that feature is still in testing and may be available in the future. Right now, the best I can do is set a frequency of one hour. Which only works if I also disable enforcement of MFA at the user object. If MFA is enforced at the user object, then the conditional access policy is not applied. If the MX truly sets the forceauthn= value to true, then I believe the prompt for credentials every time works. Since that isn't happening, I don't think that the value is getting changed every time.  

lesliebright
Here to help

This turned out to be the issue. The first network we enable with SAML worked as expected, and must have been configured by support to have Forceauthn=true. Then we asked for two additional networks to have SAML enabled, but that engineer must have configured them with Forceauthn=false. The firmware for all of these were 16.16.3. The last network was manually changed to Forceauthn=true yesterday and it is working as expected now. Thank you for this clue as it was the key to finally getting this working. 

 

As a side note, I have "wished" in the dashboard to have a toggle switch for this value. In troubleshooting this issue, I learned some more about Azure AD's conditional access policies and may want to utilize them in the future for AnyConnect to improve our users' experience. Doing so would require Forceauthn to be set to "false" and it would be more convenient for both me, and for Meraki support, if I don't have to trouble them with this request. 

bjohndoe
Here to help

Was the Forceauthn option found on the Azure side?

 

I have been thinking about this and am considering changing mine to true for better security.

lesliebright
Here to help

Negative. That is part of the configuration of the MX itself that only Meraki support has access to. Support was helpful and prompt about making the requested change, though. I believe it happened within 1 business day of my request. 

bjohndoe
Here to help

Thanks.

lesliebright
Here to help

You're welcome. I "wished" for the ability to be able to change this value ourselves in the dashboard. If enough of us make the request, they might do it.

bjohndoe
Here to help

I will make the request.

Don_Eli
New here

Hello Bsalami. I have the opposite problem.  I setup SAML for Anyconnect with the dashboard and it requires the user to authenticate with MFA everytime. My company requires authentication after 10 days. Please ho can i achieve this result. I see you mentioned above about Forceauthn = Value True. Please were do i find this settings to change. 

PhilipDAth
Kind of a big deal
Kind of a big deal

You have to open a support case to get the value of  Forceauthn changed.

Jyrki_Halonen
Getting noticed

Thank you for the solution description. I was wondering what is the time-frame by default for user auth token is still valid ?

PhilipDAth
Kind of a big deal
Kind of a big deal

With Azure it is quite long.  Maybe 3 or 6 months.

lesliebright
Here to help

I'm starting to lean toward this being hardware related. The first network I set up for AnyConnect w/ SAML was an MX100. It never exhibited the symptoms at all and worked perfectly. The second network I tried was an MX105 and didn't work until that device was RMA'd for a different trouble. The third network is also an MX105 and hasn't been resolved yet, even after trying firmware v17.8. Possible batch/generational component change in the MX105?

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels