The shared account's SSO automatically passes the workstation credentials through to Azure for a seamless experience.
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Ĭredentials.
So we leave out the ADFS URL, effectively not trusting that site and keeping it out of the intranet zone when browsing from Firefox. Firefox can be packaged forĮnterprise deployment using System Center Configuration Manager (or any other similar tool) with preconfigured settings. 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). You must set the browser versions supporting WIA using this command. ) which is set via the Set-AdfsProperties PowerShell cmdlet. The other important concept is that for ADFS SSO to work, it uses Windows Integrated Authentication ( WIA docs, We do this using Group Policy administrative template. The important factoid from that blog is that theĪDFS URL should be added to the IE > Security >Intranet zones > sites. (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įirst, here is a level-setting document explaining the background, limitations, and requirements for ADFS SSO: ( adfs I thought it would be helpful to the TechNet community to explain how we dealt with this issue.
In short: What is the URL into that ignores the passed credentials from ADFS SSO? Uses the computer (same shared domain account) in Internet Explorer or Chrome browser to view other content on (will user#2 see user#1 email)? Is there a back door / side door URL available within that will prompt for a different domain account and password, allowing user to open Outlook on the O365 site?Īssuming user#1 can override the ADFS SSO to login and connect to their business email in, 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 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. 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
0 kommentar(er)
