CSCvm86891 - ENH SAML support with SBL (Start Before Logon) - 1

[jknetservices]

Anyone else clamoring for this? 

SAML support with SBL would be absolutely perfect for what our organization is trying to accomplish.  It would bridge the gap between Always-on VPN, with the security handled almost entirely via certificates stored on the local workstation, and organizations like mine where we would prefer to require multi-factor authentication.  I would assume it has to be possible from a technical standpoint, since I know that vendors such as Duo can enable SAML with MFA at initial login. 

If Cisco enables support for SAML with SBL, we can provide VPN services to our remote workforce with a high level of security while also ensuring that critical system services and network connections can be established prior to logon.

[eric_stephens]

We were looking for this capability as well, but rec'd the following from Cisco:

“Unfortunately we have serious reservations about implementing a browser based capability during SBL since all the components run as SYSTEM user. We don’t have plans to implement this enhancement at this time.”

Unsure if this is something they are still considering since the enhancement is still open...but based on the above feedback...it doesn't sound promising.

[JamesL7733]

I do understand the reservation if using the OS embedded browser. However, we need to be able to use SAML auth with Start Before Logon (SBL). This is crippling the ability to use AnyConnect in a secure fashion with Azure MFA when deploying the remote workforce. Basically SBL is useless to us. The only option is to use Always-on VPN which is currently against our security best practice. 

[SMC007]

I am in the exact same position, all VPN access hedges on Azure AD SAML authentication and with our Active Directory, there are frequent times our global users need to VPN in before login to resolve cached credential issues. It's not an option to NOT use SAML.  Figure a way to make it work securely please.

[tecancisco]

Same here. Using MFA NPS servers as workaround which increases the complexity and effort of the whole system a lot. SAML with SBL would be very much appreciated.

[MEarley]

This has put a complete stop to our Windows Autopilot Hybrid deployment testing (Intune), which requires SBL (Start Before Logon) to be able to see a domain controller to authenticate the device, I was shocked to find this was the only Supplier that does not support this during SBL

[Entry]

Same here, did you find any workaround except changing the VPN supplier (which we will not do) ?

[SMC007]

In addition to SBL not living up to expectations the overall experience with Cisco AnyConnect SAML authentication is horrible due to AC 4.x using it's own browser that doesn't keep cookies, therefore our AAD login always asks the user if they want to be remembered and have two additional clicks every time they login. Users ask us to remove the "stay logged in" but you cannot and it doesn't work with AC 4.x SAML.  On a positive front, Secure Client 5.x replacing AC 4.x will have an option to use the system browser of which will keep cookies for the session, but that is likely months away.

[tecancisco]

This is a bit off topic, but at least the "stay logged in" prompt can be removed with a Conditional Access Policy in Azure. Just create (or update) a policy with Session control > Persistent browser session > Always Persistent. Once this is set, users will not be asked anymore. There is also a global setting under "Azure AD > Company branding > Show Option to remain signed in" to achieve the same.

[martins@netxuk.com]

Hi jknetservices,

We have this problem too. Did you ever find any kind of workaround that would allow for use of both SBL and MS MFA/SAML?

Thanks

[jknetservices]

Unfortunately no, we never did, and Cisco stated that they have no plans to fix it anytime soon due to security concerns with regards to the browser portion necessary in order to facilitate the login.

[martins@netxuk.com]

Thanks for letting me know.

[Scott Lehman]

Well this may have just become a show stopper for us.  We require SBL to ensure things like group policy run correctly when a user logs in remotely.  Secure Connect requires a third party IDP, Azure for us in this case.  Now I'm looking at dumping Secure Connect.  Nice job Cisco.