locked
ADFS 3.0 + Chrome Basic auth prompt RRS feed

  • Question

  • I have an ADFS 3.0 (2012 R2) farm which has a federation against an internal SAML-enabled application.
    The ADFS is configured to use IWA/WIA from internal networks with Mozilla/5.0 added to WIASupportedUserAgents.

    The problem I have is that when I'm trying to use Google Chrome from the internal network to access the application the ADFS prompts me for authentication, and it's not the regular FBA window from ADFS but a basic authentication prompt in Google Chrome. When I'm trying with Internet Explorer 11 IWA/WIA is working perfectly fine all the time.

    So it seems like the Chrome is falling back to basic authentication when IWA/WIA does not work.
    But the really strange part is that this ONLY occurs if the user object is located in a specific Organizational Unit related to user objects, for example OU=CompanyUsers.
    If I move the user object to another Organizational Uniz, for example OU=CompanyTest, it works perfectly fine with IWA/WIA when using Chrome.

    Chrome version is 55.0.xxxx 

    So it's a GPO related issue for sure, where a policy setting somehow block IWA/WIA from working.
    But is there anyone who might know which GPO-setting that might prevent IWA/WIA form working with Google Chrome and what cause it to fallback to basic authentication?

    Tuesday, March 7, 2017 5:08 PM

All replies

  • If I start Chrome with the following command it works with IWA/WIA,
    chrome.exe --auth-server-whitelist="*domain.com"

    But the question still remains, why does it work when I specify the --auth-server-whitelist?
    I assumed that Chrome is using IE configuration/settings for newer versions.

    Wednesday, March 8, 2017 7:49 PM
  • For the --auth-server-whitelist it's more of a Chrome thing really. On the ADFS side, you need to ensure that the browser is listed as supported in the WIASupportedUserAgents. If it is already the case, I've also seen that certain version of Chrome require to disable the Extended Protection too (Set-ADFSProperties -ExtendedProtectionTokenCheck None).

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, March 13, 2017 2:08 PM
  • Hi Jorrk,

    Chrome should be honoring the same settings as IE. However it is possible to configure override settings - perhaps these are set in your environment:

    https://support.pingidentity.com/PingFederate/Integrations/Using-Group-Policy-to-Configure-Supported-Browsers-for-Integrated-Windows-Authentication

    Good Luck!

    Shane

    Tuesday, March 14, 2017 1:27 AM
  • For the --auth-server-whitelist it's more of a Chrome thing really. On the ADFS side, you need to ensure that the browser is listed as supported in the WIASupportedUserAgents. If it is already the case, I've also seen that certain version of Chrome require to disable the Extended Protection too (Set-ADFSProperties -ExtendedProtectionTokenCheck None).

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thank you Pierre!
    I've added "Mozilla 5.0" to WIASupportedUserAgents which should cover Chrome.
    I'll try to set the -ExtendedProtectionTokenCheck to None even though the Chrome version is 55.0.xxx.
    Monday, March 20, 2017 6:27 PM
  • Hi Jorrk,

    Chrome should be honoring the same settings as IE. However it is possible to configure override settings - perhaps these are set in your environment:

    https://support.pingidentity.com/PingFederate/Integrations/Using-Group-Policy-to-Configure-Supported-Browsers-for-Integrated-Windows-Authentication

    Good Luck!

    Shane

    Hi Shane!

    That is my thought as well, that IE and Chrome use the same settings.
    But I'll definitly investigate it, there might be something specific configured for Chrome.

    Thank you!

    Monday, March 20, 2017 6:31 PM