none
Bypass ADFS SSO, URL side door into portal.office.com RRS feed

  • Question

  • We have shared domain accounts for certain domain computers in labs, and are moving to Office 365 for the corporate intranet using ADFS-integrated single sign-on (SSO) to connect to these applications (both Microsoft O365 hosting, like SharePoint, and 3rd-party hosting using ADFS SSO). During testing we learned that SSO will not allow the logout of the shared account to override the SSO shared login to access (for example) another account for email in O365 Outlook.

    Is there a back door / side door URL available within portal.office.com that will prompt for a different domain account and password, allowing user to open Outlook on the O365 site?

    Assuming user#1 can override the ADFS SSO to login and connect to their business email in outlook.office365.com, then closes the Internet Explorer or Chrome browser, but does not restart the computer and does not logoff of the computer and a different user#2 uses the computer (same shared domain account) in Internet Explorer or Chrome browser to view other content on portal.office.com (will user#2 see user#1 email)? [The existing not-ADFS not-SSO user and computer account relies on user closing browser to disconnect and time out the session with portal.office.com.]

    In short: What is the URL into portal.office.com that ignores the passed credentials from ADFS SSO?


    • Edited by Geo Perkins Monday, February 25, 2019 9:43 PM spelling
    Monday, February 25, 2019 9:42 PM

Answers

  • I am answering my own question. I thought it would be helpful to the TechNet community to explain how we dealt with this issue. (It amazes me that a solution is so difficult to find on the Internet; anyone using O365 and ADFS SSO is bound to encounter this problem!).

    First, here is a level-setting document explaining the background, limitations, and requirements for ADFS SSO: (adfs technet blog, https://blogs.technet.microsoft.com/abizerh/2013/04/11/more-information-about-sso-experience-when-authenticating-via-adfs/). The important factoid from that blog is that the ADFS URL should be added to the IE > Security >Intranet zones > sites. We do this using Group Policy administrative template.

    The other important concept is that for ADFS SSO to work, it uses Windows Integrated Authentication (WIA docs, https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia) which is set via the Set-AdfsProperties PowerShell cmdlet.  You must set the browser versions supporting WIA using this command. If WIA fails, authentication will fall back to Basic.

    So we established that Firefox browser does not consume the Group Policy administrative template settings (Internet Explorer and Chrome, however, do - and those two browsers are the corporate standard here for accessing O356). Firefox can be packaged for Enterprise deployment using System Center Configuration Manager (or any other similar tool) with preconfigured settings. So we leave out the ADFS URL, effectively not trusting that site and keeping it out of the intranet zone when browsing from Firefox. 

    When a computer with an automatic login to a shared (no O365 mailbox, no OneDrive, etc.) account is used by an employee, the IE11 or Chrome browser will allow them to get to O365 SharePoint, which is where our company Intranet is hosted, using the shared credentials. The shared account's SSO automatically passes the workstation credentials through to Azure for a seamless experience. This is the desired state. Then if the employee wishes to use the shared workstation to check their own e-mail, they launch a Firefox shortcut which we have pushed to the desktop of the shared computers. The packaged Firefox browser hits ADFS which prompts for a user account name and password on its way to portal.office.com URL. The user enters their credentials and their personal e-mail and other O365 applications are allowed. The user of course must remember to logout of O365 when they close Firefox.

    The other benefit is that we push the Firefox configuration to administrative desktops where a typical admin logs in with their non-privileged account to access O365 applications. If they need to log into Azure to do Azure administration, they use Firefox and can enter a different Azure account login/password credential. Without the Firefox solution, we had to resort to using a VM which was not a member of the corporate domain! (As I type this I find it utterly amazing that his is Microsoft's solution to administration of Azure for customers who use ADFS to implement SSO).

    A screenshot of the login prompt from ADFS from the Firefox browser is shown below.

    adfs login

    Hopefully the above is useful to others.

    • Marked as answer by Geo Perkins Friday, March 15, 2019 6:43 PM
    Friday, March 15, 2019 6:33 PM

All replies

  • Hello,

    I don't believe there is a backdoor. once you enable sso with adfs, and try to access any sso enable application, the current ssession user creds will auto open the app. For share PCs a recommendation might be to use gpo to to foce prompt for authenitcation to the app after certain interval etc. You may probaly only have them access using IE to get that working. I worked in a hospital IT with lots of shared workstation. We moved all shared machines to an specific OU and setup some GPOs to prompt for login etc.


    Isaac Oben MCITP:EA, MCSE,MCC <a href="https://www.mcpvirtualbusinesscard.com/VBCServer/4a046848-4b33-4a28-b254-e5b01e29693e/interactivecard"> View my MCP Certifications</a>

    Wednesday, February 27, 2019 5:02 AM
  • Thanks for the reply Isaac. Any chance you can provide the specific GPO settings?

    Sounds like your situation is the same (healthcare). We need some applications to always use SSO and login successfully using the shared/generic account to intranet SharePoint in O365 (among others) while other apps should allow the user to "logoff" from the shared/generic and re-login manually using a personal credential (ADFS integrated training application, e-mail in O365, OneDrive in O356, etc.).

    If we enable IE, Chrome/Mozilla, and Edge in the ADFS forms, then all are using SSO and the generic/shared account. A Google search for your suggestion offers up these ideas:

    Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies/Security Options

    • "Network access: Do not allow storage of credentials or .NET Passports for network authentication" 
    • "Network access: Do not allow storage of passwords and credentials for network authentication"

    Registry:

    • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
    • EnableNegotiate REG_DWORD Value 0x00000001

    Internet Explorer Settings:



    Testing trial-and-error is very difficult, so having some clear direction on this would be very helpful.

    • Edited by Geo Perkins Wednesday, February 27, 2019 2:42 PM add screenshot
    Wednesday, February 27, 2019 2:30 PM
  • Hello

    I no longer work with that company and don't have the details. but I remember correctly, These is what you need to do for standard ADFS integrated authentication

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/configure-client-computers-to-trust-the-account-federation-server

    And for the affected workstations that are shared, you tweak this configuration to prompt for login each time they access the ADFS url. I th

    Set the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Internet Zone -> "Logon options" to "Enabled", and select "Prompt for user name and password" from the drop-down box.

    and this to make the adfs page as a internet or restricted zone

    http://clintboessen.blogspot.com/2013/09/ie-10-prompting-for-credentials-windows.html


    Isaac Oben MCITP:EA, MCSE,MCC <a href="https://www.mcpvirtualbusinesscard.com/VBCServer/4a046848-4b33-4a28-b254-e5b01e29693e/interactivecard"> View my MCP Certifications</a>

    Thursday, February 28, 2019 6:22 PM
  • I am answering my own question. I thought it would be helpful to the TechNet community to explain how we dealt with this issue. (It amazes me that a solution is so difficult to find on the Internet; anyone using O365 and ADFS SSO is bound to encounter this problem!).

    First, here is a level-setting document explaining the background, limitations, and requirements for ADFS SSO: (adfs technet blog, https://blogs.technet.microsoft.com/abizerh/2013/04/11/more-information-about-sso-experience-when-authenticating-via-adfs/). The important factoid from that blog is that the ADFS URL should be added to the IE > Security >Intranet zones > sites. We do this using Group Policy administrative template.

    The other important concept is that for ADFS SSO to work, it uses Windows Integrated Authentication (WIA docs, https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia) which is set via the Set-AdfsProperties PowerShell cmdlet.  You must set the browser versions supporting WIA using this command. If WIA fails, authentication will fall back to Basic.

    So we established that Firefox browser does not consume the Group Policy administrative template settings (Internet Explorer and Chrome, however, do - and those two browsers are the corporate standard here for accessing O356). Firefox can be packaged for Enterprise deployment using System Center Configuration Manager (or any other similar tool) with preconfigured settings. So we leave out the ADFS URL, effectively not trusting that site and keeping it out of the intranet zone when browsing from Firefox. 

    When a computer with an automatic login to a shared (no O365 mailbox, no OneDrive, etc.) account is used by an employee, the IE11 or Chrome browser will allow them to get to O365 SharePoint, which is where our company Intranet is hosted, using the shared credentials. The shared account's SSO automatically passes the workstation credentials through to Azure for a seamless experience. This is the desired state. Then if the employee wishes to use the shared workstation to check their own e-mail, they launch a Firefox shortcut which we have pushed to the desktop of the shared computers. The packaged Firefox browser hits ADFS which prompts for a user account name and password on its way to portal.office.com URL. The user enters their credentials and their personal e-mail and other O365 applications are allowed. The user of course must remember to logout of O365 when they close Firefox.

    The other benefit is that we push the Firefox configuration to administrative desktops where a typical admin logs in with their non-privileged account to access O365 applications. If they need to log into Azure to do Azure administration, they use Firefox and can enter a different Azure account login/password credential. Without the Firefox solution, we had to resort to using a VM which was not a member of the corporate domain! (As I type this I find it utterly amazing that his is Microsoft's solution to administration of Azure for customers who use ADFS to implement SSO).

    A screenshot of the login prompt from ADFS from the Firefox browser is shown below.

    adfs login

    Hopefully the above is useful to others.

    • Marked as answer by Geo Perkins Friday, March 15, 2019 6:43 PM
    Friday, March 15, 2019 6:33 PM
  • Interesting solution indeed! AFAIK, there are at least two other options to bypass the ADFS-SSO.

    First, as the SSO only takes place when using the on-premise ADFS, one could try to login using the proxy servers. In practice, you either need to login from internet, or change the DNS or hosts -file to point to the proxy instead of on-prem ADFS.

    Second, from the ADFS server point of view the SSO is "offered" only for browsers defined in ADFS configuration (WIASupportedUserAgents). So, you could  change the User-Agent string of Chrome (search for User-Agent Switcher) to something that is not listed in the ADFS configuration. This way ADFS would always show the form-based authentication.

    And finally an observation: Because your Firefox shows the basic authentication prompt, it means that ADFS assumes it supports SSO. This is because your Firefox is not configured properly for SSO. If you'd like to enable SSO for Firefox too, see my blog post at http://o365blog.com/post/sso-for-non-ie-browsers/

    Monday, March 18, 2019 7:33 AM
  • Just opening an 'In Private' tab seems to work for us in IE11 ...

    Wednesday, July 17, 2019 11:47 AM
  • The solution we use at my workplace (at least for IT/admin staff) is to Shift-Right click on applications, and choose "run as a different user," then enter separate credentials for any administrative activities. It takes some shenanigans to get this menu sometimes, because of the Aero menus (or whatever you call them); in case of the screenshot (link in next paragraph), where I already have PowerShell open, I had to right click first, then shift-right click on the correct menu option under "Tasks."

    I was unable to post the screenshot because my account is new. Here's a link to it instead. https://imgur.com/a/evECE3U

    When you open IE this way, and navigate to resources secured by ADFS, you then have to enter your admin credentials again when you reach the website, because it's not backed by integrated security the way it would be if you logged in as that user account. I've never tried this in another domain or off our domain, so I'm unsure whether this special menu needs to be configured via group policy.

    I'm also aware that even our non-IT staff are able to use shared accounts to access intranet stuff through Chrome or IE, so I assume that must have to do with either group policy for those browsers, or the configuration of ADFS, or the configuration of the domain itself. So, it is possible; but I can't be more helpful than that. (You might note from the screenshot that I'm a software developer, not a Windows admin. ;-)



    Tuesday, September 3, 2019 6:02 PM