Forum Discussion
ADFS and SSO for Exchange Online
- Mar 15, 2019
Our organization was able to solve this problem and I documented the solution over on https://social.technet.microsoft.com/Forums/en-US/79c2050b-9977-4524-83a5-eb47d86e2f96/bypass-adfs-sso-url-side-door-into-portalofficecom?forum=ADFS ("https://social.technet.microsoft.com/Forums/en-US/79c2050b-9977-4524-83a5-eb47d86e2f96/bypass-adfs-...) Stephen Bell
They are effectively logging in with the current windows credentials, as per the "magic" bit. Either disable the WIA auto-login in the browser options on those devices or remove the AD FS URL from the Intranet zone.
You can also alter the AD FS Claim Issuance Rules so that those devices would be treated as externals (i.e. loggin in outside your internal network). That way they would be offered a login form instead of signing in automatically.
- Stephen BellDec 27, 2017Iron Contributor
I am not sure how I would do this -- do you have an example of where you can link me to?
Thanks
Steve
- Stephen BellJan 12, 2018Iron Contributor
Still struggling with this one. Anyone have any input?
Thanks
- Brian ReidJan 20, 2018MVPBrowsing to the OWA URL with the domain at the end is giving AAD a hint as to what domain to use. This redirects you to ADFS. As you have set ADFS to hit the external IP, I will.assume you are hitting the WAP endpoint. WAP does not (should not) proxy WIA auth, and should present a forms auth page to the user.
You also said you removed the ADFS URL from local intranet zone, which means it should not do WIA either.
Your standard user devices should hit a WIA endpoint on ADFS and the URL of ADFS should be in Local Intranet Zone. Your external devices should hit WAP and get proxied to ADFS and get Forms Auth. Your shared devices should not get the URL in Local Intranet, but should still hit ADFS internal IP (not via WAP), but as not a trusted endpoint should not seamless sign-on.