ADFS and SSO for Exchange Online

[Stephen Bell]

I hope this is the right spot for this post...

We have Office 365 E3 in our environment, setup using ADFS.  All of our email is in Exchange Online.

Because of this - when a user opens up MS Edge, and browses to https://outlook.office.com/ourdomain.dom they are *magically* auto-signed into their mailbox.  Who doesn't like magic :) ?

This is great for most of our users - however I have a small set of desktop computers that are shared workstations, with an auto-login, shared user account.  Because it is a shared workstation and shared user account - they do not have an email account.

I recently got a request to add a desktop shortcut to these machines for people to login to their exchange online mailbox via the web browser.  When I try to go to the login page I either get a failed to login error OR a loop to select my timezone.  I am guessing because the logged on user does not have a mailbox, and the ADFS is trying to perform SSO.

Any ideas how to get around this issue for these machines?

Thanks

Steve

[#2]

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.

[#3]

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.

[#4]

Or you can ask them to browse to the site via an InPrivate session in the browser, as that does not auto submit credentials

[#5]

I think I have this done -- 

I removed our ADFS URL from the intranet zone, removed the internal DNS record that points to the inside of the ADFS environment.  I now ping from this client and get an external IP address.

The WIA (or IWA? - I've seen it both ways??) - I went into IE on one of the clients, Security Tab --> Custom Level --> Login --> Prompt for user name and password.  

Rebooted the PC 2 times and I am still getting auto login for my OWA url?  What am I missing?

Thanks

Steve

[#6]

I am not sure how I would do this -- do you have an example of where you can link me to?

Thanks

Steve

[#7]

Still struggling with this one.  Anyone have any input?

Thanks

[#8]

Browsing 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.

[#9]

So if I am understanding this correctly - to make this work:

Standard Devices - Have OWA URL in Local Intranet Zone, and hit the internal ADFS endpoint.  This should result in SSO

My shared devices - Have OWA URL removed from Local Intranet Zone, and hit the internal ADFS endpoint.  This should result in forms based auth

External devices - No OWA URL in Local Intranet Zone, hit WAP endpoint.  Should receive forms based auth.

You mention that my WAP should not proxy WIA.  Would it be possilbe to proxy WIA?  If it were, where would I look to see if this is configured?

Thanks

Steve

[#10]

Quick question, are these windows 10 devices? If yes, please have a look at:

https://jairocadena.com/2016/11/08/how-sso-works-in-windows-10-devices/

[#11]

In the ADFS management console there is a setting to show what is published to the proxy. You cannot publish Windows Integrated to the internet though, and ADFS Global Authentication Policy allows Forms or Certificates externally and Forms, WIA or Certs internally

Regards the above question, yes is the answer - but for "shared devices" you will only get Forms on the Intranet if you enable it as mentioned above.

Also, for your shared devices - why not use the URL without the domain hint at the end (outlook.office.com only) and then Azure AD will ask them for their username.

Brian

[#12]

Ok - so I just re-added the DNS entry on my internal network to point the clients to the internal ADFS endpoint.  

I verified that my shared device is resolving to the internal ADFS endpoint, browse to the generic URL https://outlook.office.com and it is still attempting SSO.

Admittedly, ADFS for us has kind of been a set it and forget it implementation.  Where is the setting that shows what is published to the proxy?  I am in the management console, on my server 2012 R2 but I am not quite sure what I am looking for.  I am wondering if, when initially setting this up a few years back if we have something misconfigured.

Thanks for the reply!

[#13]

If you go directly to the service endpoint without a domain hint and you are not already logged into another Office 365 service in the same browser window then it will not do SSO. It needs to do Realm Selection before it can route you to the ADFS server (realm selection is to determine what tenant you are so that it know who does the authentication).

If you already have something else open in O365/Azure AD then there is an AAD cookie set that says who you are and that you are logged in already.

Delete all your cookies and try again. No browser windows open, and start by going to the service endpoint. You will be redirected to AAD and then when and only when you enter an email address will you be routed to ADFS for SSO.

If you go to the service endpoint with domain hint (outlook.office365.com/owa/tenant.com for example) or set up webmail.tenant.com as an CNAME to outlook.office365.com in DNS) then realm selection is automatic.

[#14]

Here is where I am at --  If I open chrome and browse to outlook.office.com, I get prompted with forms authentication.  

In IE and Edge, it attempts SSO.  I deleted cookies and still get an SSO attempt.  If I do a InPrivate window, I do get forms auth - however, this seems like a less than ideal solution.  

When you say "have something else open in O365/Azure AD" - would Office Pro Plus be included in this?  If Excel or Word had been opened during the current logon session?

[#15]

Office being open constitutes a login, and we will assume you have Modern Auth enabled, so the login control uses the web control in Windows (IE/Edge). Therefore you have a current valid cookie in play, so you get logged in.

For Chrome, you do not mention where you are (intranet or extranet), or what endpoint you would be hitting. Also you can enable WIA for Chrome and get SSO in Chrome.

Note that on the intranet they will always try to do SSO - I think where we are getting confused here is what you are describing as SSO and what I am talking about. SSO is where I do nothing and I am signed in. If I go through realm selection first I will get asked my email address and if I am already signed out from a previous session I will get a prompt to select my username. This is all done at Azure AD. After I provide my email or click on the button indicating my email address I get forwarded to my auth provider. In your case that is ADFS. Until this point we are not doing SSO, we are doing realm selection. Domain hints allow us to bypass that, but with outlook.office.com as my signin I do not provide a domain hint. And with ADFS in play I will see the ADFS forms and not the Azure AD form for password entry. I will assume you are seeing the forms I am describing.

It might be in your best interested to get someone to come in (or remote) and take a look at your config or ensure that what you are seeing is (or is not) what is expected and how to solve your original question.

Yours

Brian Reid
Office and Office Services MVP
Exchange Server and Office 365 Microsoft Certified Master

[#16]

Thank you again for your replies, I appreciate you taking the time.  

I believe I understand exactly what you are saying regarding SSO / realm selection. 

Currently, I am not seeing any realm selection when I open IE/Edge and browse to https://outlook.office.com  -- without domain hint.  This should send me to the external, Microsoft login page. Once I enter my email address, because my domain is federated, I would be redirected to my company login page - which in this instance is INTRANET, as these shared devices are on my internal network and DNS resolves the sts.mycompany.com to our ADFS server, not our WAP. 

As for modern auth, yes, I believe it is enabled.  I will check further to confirm.  I guess I always thought of modern auth being for outlook only, not thinking about the implications with the other Office Pro Plus applications.  These machines I am working with do not have Outlook currently installed.

Thanks again!

Steve

[#17 · Accepted solution]

Our organization was able to solve this problem and I documented the solution over on TechNet ("https://social.technet.microsoft.com/Forums/en-US/79c2050b-9977-4524-83a5-eb47d86e2f96/bypass-adfs-...) @Stephen Bell 

[#18]

@geoperkins 

Interesting approach.  A few months ago, due to some password spray attacks we disabled our ADFS and went back to O365 authentication. Given that we were only ADFS to gain conditional access functionality, which is part of EMS now.

Thank you for sharing!