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. ... View more

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.  ... View more

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.  ... View more

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.  ... View more

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.   ... View more

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? ... View more

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. ... View more

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.  ... View more

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".  ... View more

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.  ... View more

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.  ... View more

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.  ... View more

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.  ... View more

Default. ... View more

I think you're right. I believe the setup creates a 1:1 relationship between the MX and the Azure application. This makes me want to limit the number of possible connection points for a whole other reason now... ... View more