locked
SSO with Office 365: ADFS Logon Web Site / Authentication / Browser Support RRS feed

  • Question

  • Have got the task to make SSO with Office 365 working. Unfortunately, other people tried to make it work before, and we have a bit a mess. ADFS on Server 2012 R2 is impelmented. Office 365 is not yet productive. Have the following questions:

    1. There was a "customized ADFS logon page" which I suspect causing problems. The guy who configured that didn't wrote it down ond doesn't remember what he has configured. He did it according https://technet.microsoft.com/en-us/library/dn636121.aspx? My question: What is the easiest way to reset this ADFS logon page to the standard, "unconfigured" Web Site? Or does uninstalling and reinstalling ADFS completely reset and recreates the standard ADFS Login Web Site?
    2. What are the correct ADFS Primary Authentication Settings? We have "Form Based" for Extranet and "Form Based" and "Windows Authentication" for Intranet Access. With these settings, SSO works with IE from Extranet and Intranet. As soon as the cursor is moved to the password field, there is a short redirection visible to ADFS without displaying the ADFS Logon Page. When I disable "Windops Authentication" for Intranet Access, it doesn't work anymore from the Intranet. The ADFS Logon Page is displayed. The ADFS Web Page is published externally over a Citrix Netscaler. What I don't unterstand is why "Form Based Authentication" is working for External Access, but not from the Intranet.

    3. Is it possible to get a similar logon experience with other browsers? With Chrome, Edge, Firefox, the ADFS Logon Page is ALWAYS displayed. And we have the problem (probaly due to the misconfigured ADFS Logon page), that the user has to enter the UPN name (Email address) on the Microsoft Online Logon page, but <domain>\username on the ADFS lgon page.

    Thank you all in advance for any help.

    Kind regards, Franz

    Monday, November 30, 2015 9:11 AM

Answers

  • It is unlikely that the previous admin broke anything by customizing the default theme. Modifications of the default theme are limited. Can you make sure what theme is currently active? You can use the following PowerShell cmdLet:

    Get-AdfsWebConfig | Format-List ActiveThemeName

    Authentication policies enable you to adapt the authentication method used depending on where the user is connected from. If the user is directly connected to the ADFS server, the intranet policy will apply. This policy is by default: Windows Integrated Authentication. If the user is coming through a Web Application Proxy (aka WAP, aka ADFS proxy), then the extranet policy will be used. This policy is by default: Form Based Authentication (since Windows Authentication does not work through proxies). If you do not use WAP then everybody is likely applying the intranet policy. Which will likely fail for client connected externally. You can add a WAP server to your infrastructure if you want to beneficiate of the ADFS authentication policies, or reach out Citrix for support if you want to know how to do the same thing with them.

    If you enabled both Windows Integrated Authentication and Form Based Authentication in the same authentication policy, you will always use the Windows Integrated Authentication if your browser supports it. And to know if the browser supports it, it needs to be listed as a support browser agent in the following list (use PowerShell):

    (Get-AdfsProperties).WIASupportedUserAgents

    And here is the default list:

    MSAuthHost/1.0/In-Domain
    MSIE 6.0
    MSIE 7.0
    MSIE 8.0
    MSIE 9.0
    MSIE 10.0
    Trident/7.0
    MSIPC
    Windows Rights Management Client

    So you can add the user agent from FireFox and Chrome. It seems that adding "Mozilla/5.0" to the list does the trick. In PowerShell it would go like this:

    $currentagentlist = (Get-AdfsProperties).WIASupportedUserAgents
    $updatedlist = $currentagentlist + "Mozilla/5.0"
    Set-AdfsProperties -WIASupportedUserAgents $updatedlist

    Other issue with Chrome though. According to Chrome's official blog, Chrome does not support Extended Protection for the Windows Integrated Authentication. So you would need to disable it to support Chrome clients. So yes you would have to lower the security level of your ADFS environment to support them, hence it is not really recommended... But if you want to test, here you go:

    Set-ADFSProperties –ExtendedProtectionTokenCheck None

    When you have the ADFS signin page, the login format is either UPN (username@contoso.com) or the legacy format: CONTOSO\username. You can enable what is called Alternate ID and use the email address instead. If you want to do that, there are a couple of considerations to look at. Some of the Office 365 workflow will not work properly if you use the email address for login format in your ADFS:

    - Configuring Alternate Login ID https://technet.microsoft.com/en-us/library/dn659436.aspx


    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.

    • Marked as answer by FranzSchenk Monday, November 30, 2015 4:24 PM
    Monday, November 30, 2015 2:44 PM

All replies

  • It is unlikely that the previous admin broke anything by customizing the default theme. Modifications of the default theme are limited. Can you make sure what theme is currently active? You can use the following PowerShell cmdLet:

    Get-AdfsWebConfig | Format-List ActiveThemeName

    Authentication policies enable you to adapt the authentication method used depending on where the user is connected from. If the user is directly connected to the ADFS server, the intranet policy will apply. This policy is by default: Windows Integrated Authentication. If the user is coming through a Web Application Proxy (aka WAP, aka ADFS proxy), then the extranet policy will be used. This policy is by default: Form Based Authentication (since Windows Authentication does not work through proxies). If you do not use WAP then everybody is likely applying the intranet policy. Which will likely fail for client connected externally. You can add a WAP server to your infrastructure if you want to beneficiate of the ADFS authentication policies, or reach out Citrix for support if you want to know how to do the same thing with them.

    If you enabled both Windows Integrated Authentication and Form Based Authentication in the same authentication policy, you will always use the Windows Integrated Authentication if your browser supports it. And to know if the browser supports it, it needs to be listed as a support browser agent in the following list (use PowerShell):

    (Get-AdfsProperties).WIASupportedUserAgents

    And here is the default list:

    MSAuthHost/1.0/In-Domain
    MSIE 6.0
    MSIE 7.0
    MSIE 8.0
    MSIE 9.0
    MSIE 10.0
    Trident/7.0
    MSIPC
    Windows Rights Management Client

    So you can add the user agent from FireFox and Chrome. It seems that adding "Mozilla/5.0" to the list does the trick. In PowerShell it would go like this:

    $currentagentlist = (Get-AdfsProperties).WIASupportedUserAgents
    $updatedlist = $currentagentlist + "Mozilla/5.0"
    Set-AdfsProperties -WIASupportedUserAgents $updatedlist

    Other issue with Chrome though. According to Chrome's official blog, Chrome does not support Extended Protection for the Windows Integrated Authentication. So you would need to disable it to support Chrome clients. So yes you would have to lower the security level of your ADFS environment to support them, hence it is not really recommended... But if you want to test, here you go:

    Set-ADFSProperties –ExtendedProtectionTokenCheck None

    When you have the ADFS signin page, the login format is either UPN (username@contoso.com) or the legacy format: CONTOSO\username. You can enable what is called Alternate ID and use the email address instead. If you want to do that, there are a couple of considerations to look at. Some of the Office 365 workflow will not work properly if you use the email address for login format in your ADFS:

    - Configuring Alternate Login ID https://technet.microsoft.com/en-us/library/dn659436.aspx


    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.

    • Marked as answer by FranzSchenk Monday, November 30, 2015 4:24 PM
    Monday, November 30, 2015 2:44 PM
  • Thank you very much for your excellent support!

    With the added user agent and switching off extended protection for Windows authentication, SSO with automatic redirection works perfect! The ADFS Logon Web Site is no longer displayed, the user gets to the Office 365 Website directly after entering the username.

    Before implementing your suggestions, we have already configured Chrome for Windows authentication on the ADFS Website. What is astonishing for me is that even the Microsoft Edge Browser works exactely the same way than Chrome or IE. I always thought that Edge does not support Windows Authentication.

    Kind regards,

    Franz

    Monday, November 30, 2015 4:41 PM
  • Thanks that helped a lot. 

    I have one question: when signing out of outlook./portal.office.com in IE now, it always logs me back in using my Windows credentials, rather than staying on the AD FS log out page. 

    When clicking on 'sign out', a small window appears 'Are you sure you want to leave this page?' Message from webpage: Null - two options: -> Leave this page; -> Stay on this page

    Clicking '-> Leave this page' twice leads into the logout / re-login loop

    The same behaviour is not observed in Chrome. There, you're guided to our AD FS's logout page, then back onto www.office.com, without being logged on.

    Can this logout behaviour be tweaked somehow? 

    Thanks very much,

    Markus

    Tuesday, April 11, 2017 12:13 PM