locked
Seamless SSO keeps asking for credentials RRS feed

  • Question

  • Hi,

    We have implemented Seamless SSO in the company and it is working for some devices only.

    To set this up, we have followed this page: docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start, and also reviewed known issues under here: docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sso#known-issues.

    The result is following. The Seamless SSO is working on Windows 10 devices running on release earlier than 1809. For Windows 10 1809 we have additionally deployed Microsoft Security Baseline: blogs.technet.microsoft.com/secguide/2018/11/20/security-baseline-final-for-windows-10-v1809-and-windows-server-2019/. The IE Computer policies are amended so that for example IE Enhanced Protected Mode is set to Not Configured, as it is listed under Know Issues page.

    Despite multiple tries, the SSO is not working as expected. It keeps asking for username and password. We are running out of ideas what other thing me should configure/amend when MS Security Baselines are also in place.

    Maybe you have similar experience?

    Best regards,

    Marcin


    Edit: Site note to add - when I set policy to deny apply, the SSO works. So some other setting is causing this, but not sure which one yet.
    Wednesday, July 3, 2019 6:12 AM

Answers

  • I have found the root cause of it. The baselne security policy for IE 11 Computer settings, have following option "Security Zones: Use only machine settings" set to Enabled. The Seamless SSO GPO on the other hand is adding "https://autologon.microsoftazuread-sso.com" site to local intranet zone in user context. Once the mentioned setting is set to Not ocnfigured, then this is working.

    I guess that somebody at Microsoft should review and do more thorough testing of the recommendations being published.

    • Marked as answer by Marcin C1985 Tuesday, July 16, 2019 6:02 AM
    Tuesday, July 16, 2019 6:02 AM

All replies

  • If it is related to the version and we have evidence to back that up, we can pass that feedback along to the product team and ask for a fix. Are you certain that it has to do with the release version and that there aren't other factors that might be causing it? Seamless SSO can fail for a number of reasons.

    Some known issues are: 

    - In a few cases, enabling Seamless SSO can take up to 30 minutes.
    - If you disable and re-enable Seamless SSO on your tenant, users will not get the single sign-on experience till their cached Kerberos tickets, typically valid for 10 hours, have expired.
    - Microsoft Edge browser support is not available.
    - If Seamless SSO succeeds, the user does not have the opportunity to select Keep me signed in. Due to this behavior, SharePoint and OneDrive mapping scenarios don't work.
    - Office 365 Win32 clients (Outlook, Word, Excel, and others) with versions 16.0.8730.xxxx and above are supported using a non-interactive flow. Other versions are not supported; on those versions, users will enter their usernames, but not passwords, to sign-in. For OneDrive, you will have to activate the OneDrive silent config feature for a silent sign-on experience.
    - Seamless SSO doesn't work in private browsing mode on Firefox.
    - Seamless SSO doesn't work in Internet Explorer when Enhanced Protected mode is turned on.
    - Seamless SSO doesn't work on mobile browsers on iOS and Android.
    - If a user is part of too many groups in Active Directory, the user's Kerberos ticket will likely be too large to process, and this will cause Seamless SSO to fail. Azure AD HTTPS requests can have headers with a maximum size of 50 KB; Kerberos tickets need to be smaller than that limit to accommodate other Azure AD artifacts (typically, 2 - 5 KB) such as cookies. Our recommendation is to reduce user's group memberships and try again.
    - If you're synchronizing 30 or more Active Directory forests, you can't enable Seamless SSO through Azure AD Connect. As a workaround, you can manually enable the feature on your tenant.
    - Adding the Azure AD service URL (https://autologon.microsoftazuread-sso.com) to the Trusted sites zone instead of the Local intranet zone blocks users from signing in.
    - Seamless SSO uses the RC4_HMAC_MD5 encryption type for Kerberos. Disabling the use of the RC4_HMAC_MD5 encryption type in your Active Directory settings will break Seamless SSO. In your Group Policy Management Editor tool ensure that the policy value for RC4_HMAC_MD5 under Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> "Network Security: Configure encryption types allowed for Kerberos" is enabled. In addition, Seamless SSO can't use other encryption types, so ensure that they are disabled.

    Source: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sso

    If none of the above issues apply feel free to email me at AzCommunity@microsoft.com and include your subscription ID, and I can open a support case for you. We can also pass your info along to the product team.


    Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!

    Wednesday, July 3, 2019 11:07 PM
    Owner
  • Hello Marilee,

    The list of known issues is something we have already reviewed thoroughly with my colleagues, we are aware on the limitations, we added exceptions to these items where applicable.

    We believe that the culprit are the Microsoft Baseline policies, which we have applied to all Windows 10 1809 devices.

    https://blogs.technet.microsoft.com/secguide/2018/11/20/security-baseline-final-for-windows-10-v1809-and-windows-server-2019/

    Under the download, you get "GP Reports" folder with policy reports. We have linked the following ones:

    Internet Explorer 11 - Computer.htm
    Internet Explorer 11 - User.htm
    Windows 10 1809 - Computer.htm
    Windows 10 1809 - User.htm

    On few test computers we have denied the "Internet Explorer 11 - Computer.htm" to apply and the Seamless SSO started to working as desired. We tried to figure out which setting(s) can cause such behaviour, but with no luck so far.

    We have a support case opened for more than a month already...

    Thursday, July 4, 2019 11:17 AM
  • Hi Marcin,

    I'm so sorry to hear that this case is still going on with you! If you send me your support ticket number to AzCommunity@microsoft.com I can get it escalated for you and loop in the product team. It's hard for me to tell what's going on without looking into your environment.


    Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!

    Friday, July 12, 2019 10:21 PM
    Owner
  • I have found the root cause of it. The baselne security policy for IE 11 Computer settings, have following option "Security Zones: Use only machine settings" set to Enabled. The Seamless SSO GPO on the other hand is adding "https://autologon.microsoftazuread-sso.com" site to local intranet zone in user context. Once the mentioned setting is set to Not ocnfigured, then this is working.

    I guess that somebody at Microsoft should review and do more thorough testing of the recommendations being published.

    • Marked as answer by Marcin C1985 Tuesday, July 16, 2019 6:02 AM
    Tuesday, July 16, 2019 6:02 AM
  • Helll Marilee,

    Thank you. I have found the cause, please see above note.

    Best regards,

    Marcin

    Tuesday, July 16, 2019 6:03 AM