There's a bug on ASA with regards to the implementation of SAML authentication for anyconnect. The bug means that if you change any SAML configuration, it does not get applied to the ASA until you reboot the ASA. This prevents issues from being fixed (such as incorrect initial configuration) and also prevents future changes from being applied.
The listed workaround is either:
1. to completely remove the SAML config, apply the config and then re-apply the SAML config
OR
2. reboot the ASA.
However, the remove config / reapply config is not always working (it never works for me and Cisco TAC confirmed it does not always work for them either).
This bug means that I am currently unable to bring up anyconnect SAML auth. which I need for 2FA until I reboot the ASAs. I'm unable to reboot the ASAs because it is a service-impacting operation.
Cisco have lodged this bug as an enhancement with severity 6 (not important) and have advised me to liaise with my account manager (don't have an account manager because here in Australia they are incentivised to churn sales rather than liaise with customers over these sorts of requests) to get the priority increased. Basically, the bug is not being treated as a bug, even though the number of cases lodged for this is currently showing 41 TAC cases.
The reason for the bug is because the service that provides SAML auth, internally to the ASA loads the configuration to memory when it is enabled. When you update the config, this service needs restarting to refresh the config. This service restart is not presently occurring, hence the requirement to reboot the device.
:itcrowd:
:smug:
Yosemite SAML
^ I lol'd.
:awesome:
:XD: