12-06-2017 05:28 AM
12-06-2017 05:28 AM
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?
12-06-2017 11:19 AM
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.
12-08-2017 12:38 AM
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.
12-21-2017 01:36 PM
12-27-2017 09:07 AM
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?
12-27-2017 09:08 AM
I am not sure how I would do this -- do you have an example of where you can link me to?
01-20-2018 02:33 PM
02-05-2018 11:00 AM
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?
02-12-2018 12:30 PM
02-12-2018 12:30 PM
Quick question, are these windows 10 devices? If yes, please have a look at:
02-14-2018 05:36 AM
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.
02-14-2018 06:27 AM
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!
02-15-2018 04:30 AM
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.
02-15-2018 05:49 AM
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?
02-16-2018 06:03 AM
02-16-2018 06:26 AM
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.
03-15-2019 12:22 PMSolution
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
03-15-2019 12:30 PM
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!