But the profile shown uses cisco.com for the dns suffix. My guess is this is because its just an example. But this doesn't work when I test it using customer dns suffix and dns servers.
We are using auto-generate certificates and DDNS, is this even possible or do I need custom hostname certificates?
UPDATE - I did get this working for basic Meraki Authentication, Always on and Trusted Network Detection, but I need it to work with SAML (Azure AD).
When on an untrusted network, SAML not be able to reach single sign on web page for Azure AD because Internet access is blocked, so it doesn't allow you to even attempt to authenticate. I will keep at it and update if I find a solution.
I experienced the same issue and i was able to find a solution. The reason why this is happening is because all internet traffic is blocked until there is a successful VPN connection.
In order to push from your MX a custom DNS suffix to your client devices, please review this.
Regarding the SSO issue, there is a feature under preferences part 2 of your screenshot "Allow access to the following hosts.." that allows you to include URLs, which will be accessible before there is an established VPN connection. I run packet captures and filtered the traffic to capture the the URLs used for Azure AD SSO, and i added them to the profile. login.microsoftonline.com works for authentication, login.live.com works for password resets.
Please see sample XML below. There is no enforcement of "Always On" policy with this; whenever users connect to an unknown network, the get prompted through the anyconnect SSO popup authenticate and start a VPN connection; they can browse the internet with or without an established VPN connection. Always On can always be enabled, it will work as well, however, the only accessible hosts before a VPN connection gets established, will be the ones under Allowed Hosts.
<TrustedDNSDomains> Connection Specific DNS Suffix</TrustedDNSDomains>