none
Outlook for Android / iOS prompting for Google Login

    Question

  • Hi,

    Would anyone be able to shed any light on a strange issue we are seeing with one of our domains and the Microsoft Outlook for Android and iOS apps. This issue occurs across many devices.

    Our topology is Exchange Hybrid and auto-discover works fine for all our active mail domains. ADFS sso is configured in Office 365. MX records for all domains point at Office 365.

    For arguments sake lets say two domains are involved: @sub.domaina.com and @domaina.com

    Whenever anyone tries to login to their account @sub.domaina.com they are immediately taken to a 'google' login page. Even if we use a made up email address @ said domain, a google login box is presented. This is before any password prompts. If someone uses @domaina.com they are taken to our institutions adfs login page. Which is what we want to happen with all our domains.

    This is proving very confusing for our customers. We do have a gsuite tenant for each of these domains but the MX is pointing at office 365. We have recently (over ten days ago) migrated our email service for sub.domaina.com from Google to Office 365. Other support channels are yet to shed any lights on why this could be happening.

    I would be grateful for any ideas on why this could be occurring or perhaps insights on the login process for Microsoft Outlook for Android / iOS.

    Monday, September 18, 2017 5:33 PM

All replies

  • Hello Mark,

    Understood the sub domains MX record is pointed to office 365. 

    How about the Autodiscover (CNAME) Record for sub domain?

    -Vishagan

    Monday, September 18, 2017 6:47 PM
  • Hi Vishagan,

    Autodiscover for both domains is pointing at the same place and "https://testconnectivity.microsoft.com/" works for both.

    Thanks,

    Mark

    Monday, September 18, 2017 7:12 PM
  • what if you try the default Mail app for Andriod/iOS, instead of Microsoft Outlook app?

    or have you tried the OWA app for andriod/iOS?

    Just i would like to understand the behavior.

    -Vishagan

    Tuesday, September 19, 2017 2:05 PM
  • Did you add a Google mailbox in Accounts?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, September 20, 2017 1:14 AM
    Moderator
  • Hi Ed / Vishagan,

    Many thanks for your responses and sorry for the delay. Spent a good portion of the day digging on this. As they say, the plot thickens.

    Vishagan, OWA (Pre Release) app works fine. Presumably because it uses the exchange autodiscover process where Microsoft Outlook does not, or least it doesn't solely do so.

    Ed, If I am understanding your question correctly, the presence of a Google account seems to make no difference to the process as the issue occurs on iOS, Android (inc Emulators) etc...where both Google accounts are present and are not. The Microsoft Outlook app certainly does not have a Google account connected either. At this point I could take an iPhone out of the box, download the Microsoft Outlook app, enter a 'made up' email address at the problematic domain (i.e. madeup@sub.domaina.com) and I would immediately get taken to a Google login page.

    After some digging the problem seems to be (and happy to be corrected) that Microsoft Outlook 'app' does not use autodiscover as we know it. Instead it seems to use it's own process via https://prod15-api.acompli.net/autodetect/detect.

    Based on Fiddler traces of an Android phone, the app makes a REST get request to this service first. When we do this for our problematic domain the REST response is that the domain is Google. There is absolutely no way an Exchange autodiscover process has happened when it does this, as I know how long it takes our Hybrid domain to process one of those, and sadly it's not 92ms. (Also no password has been provided at this point and autodiscover is simply not capable of returning Google as the answer. That would be a neat trick indeed) 

    We can repeat this process in a test REST client for both our parent domain and the child one. The parent domain returns office 365, the problematic domain, Google.

    I do have an active support call with O365 support, but as you can see the problem seems to lie with an auto discover process written by a different team or possibly company, given this was an acquisition.

    Would anyone be able to offer any insights into this acompli 'discovery' process and perhaps how to clear any residual cache records it may hold.

     

    Sample header data.

    GET https://prod15-files.acompli.net/autodetect/detect?services=office365,outlook,yahoo,google,icloud&protocols=eas,imap,smtp,rest-cloud
    HTTP/1.1
    Accept-Language: en_GB
    X-Email: bob@sub.domaina.com
    User-Agent: Outlook-Android/2.2.17.224.prod Dalvik/2.1.0 (Linux; U; Android 6.0.1; D5803 Build/23.5.A.1.291)
    Host: prod15-files.acompli.net
    Connection: Keep-Alive
    Accept-Encoding: gzip


    • Edited by Mark Needham Wednesday, September 20, 2017 6:09 PM
    Wednesday, September 20, 2017 6:08 PM
  • Mark, Thanks for sharing your findings!

    yes, Office 365 support team can't provide resolution as issue lies with the outlook app. 

    Hope you might have tried reinstalling the Outlook app. 

    -Vishagan

    Wednesday, September 20, 2017 6:23 PM
  • Hi Vishagan,

    Sorry to say, but that is not going to help. This domain support 27,000 users and the number of support queries we've had on this already runs into the hundreds. Our customers use every device type on pretty much every network type you could reasonably expect. If this issue was with my device I'd of moved on to a different app by now.   

    The problem demonstrably lies within the acompli autodiscover process. Either in it's entirety or how it then queries our domain. Unlike exchange autodiscover, there seems to be very little information on this processes existence, let alone how it works. I can conceptually understand the benefits of caching a particular domains email server, to speed up account discovery, but what I cannot fathom is the idea that there would be no equivalent of a DNS TTL on said caching.

    Wednesday, September 20, 2017 8:16 PM
  • I agree that application re installation won't work. Not sure how to proceed with this situation, if it is with default mail application or any application that use Active Sync protocol. we could enable the active sync logging and get help from Microsoft Office 365 Support.

    Thanks,
    Vishagan Ramasamy
    -----------------------------------------
    https://vishaganr.wordpress.com/info/

    Wednesday, September 20, 2017 8:57 PM
  • I had this exact same problem and Microsoft Tech Support was no help, with 2 different techs insisting for over 4 hours on the phone over the course of a week that the problem had to be DNS (though they couldn't really tell me what was wrong, since all the DNS autodiscover checks passed just fine).  In the end, I figured out the problem, not Microsoft, but by the time we found it after a week, the cache had finally cleared on its own.

    For anyone else dealing with autodiscover not returning the correct service, here's what you need to do:

    1. If possible, verify that this is the acompli.net problem by proving that the issue does NOT exist using Outlook 2010 or 2013.  As far as I can tell, this problem is isolated to Outlook 2016, Outlook for iOS, and Outlook for Android.

    2. On the desktop client, install Telerik Fiddler, and configure it to capture and decrypt all HTTPS traffic.

    3. Start Outlook, enter your email address, then once the Google (or other?) login screen pops up, stop capturing in Fiddler.

    4. You should see an HTTPS call to prod-global-autodetect.acompli.net (or something similar?)  In the TextView of the traffic, you should see a reference to your email address, with Google auth information returned.

    Acompli is the messaging app that Microsoft purchased and rebranded as Outlook mobile.  Armed with the above information, you should now be able to call Microsoft and wade through a bunch of the crap to actually get to a solution.

    Friday, October 13, 2017 12:24 AM
  • Hi Jeremy,

    Sorry you are having the same pain as me. I too was taken down the road of 'it must be something wrong with your set up", even though all Microsoft' own tests passed and I had already proven it wasn't. My issue was three weeks in the making before I got anywhere. We complained in many places to get that turn around. I believe it was account management support that pushed the issue in the end.

    If anyone is having this issue I would encourage them to read this other thread here Clear data from prod-nam-autodetect.acompli.net. As you will observe there is a cache and it can be cleared. Sadly you have to have found the problem yourself, before you can find the thread. 

    Also if anyone wanted to quickly prove the issue, download the Google Chrome ARC plugin. Then using the sample header data I posted above send a request to the acompli servers (address in sample, remember to change the domain to yours). If you are behind a proxy that may not work, so use a different network or bypass them. You will get a response and it will tell you what Acompli have cached.

    Note that prod15-files is just one of a number of servers in this service. There are a number of -files and -api servers in their clusters.

    Friday, October 13, 2017 7:34 AM