Long story short one of our vendors got hacked and sent out a phishing scam email using a SharePoint link and session hijacking that was able to bypass MFA. One of my users, who was waiting on a quote from this vendor, clicked it and entered their credentials. A week later their email was used to send out the same phishing email.

We followed the recommended Microsoft steps to clean things up. I did a content search on his account to see what he sent out and then emailed everyone letting them know it was a phishing attempt and if they fell for it they should reset their own passwords and contact their IT people. I then sent out a internal email saying if anyone clicked on the link they also need to change their password and to remind everyone about phishing emails. Then to be extra careful we forced a logout of all 365 sessions using PowerShell:

Connect-AzureAD
Get-AzureADUser | Revoke-Azureaduserallrefreshtoken

Which should have been the equivalent of going into the admin center on each user and clicking “Sign out of all sessions”. We told everyone that they might have to re-login to things and to reboot. Then followed up with some exports of everyones inbox rules, forwarding rules, etc, to make sure no one else was affected. It was a super fun Friday afternoon into evening.

The following Monday 95% of our users are completely fine, no issues, everything works. 5% of our users are getting the “Need Password” prompt at the bottom right in Outlook right after it finishes syncing all folders. If they try to get to public folders, other mailboxes they have access to, etc Outlook hard locks for a couple minutes and then connects and looks fine. Opening up the “Outlook Connection Status” during this time and you can see under status it saying “Connecting….” for each one then disconnected, over and over until it figures it out and connects. But then will go back to Need Password after a couple minutes. But if you simply click on where it says “Need Password” as soon as it pops up it connects the user with no other issues and works fine. So they were operational but with a annoying work around.

So I search google and the majority of things tell people to set a couple of registry keys which Microsoft has a entire article about not doing. Instead I followed the steps in that article which didn’t help at all. Tried the Microsoft support assistant for this issue, also didn’t work. Then moved on to having users change passwords and reboot, disconnect their accounts under “Access work or school” and reconnect, delete the Outlook profile and recreate, etc. All the standard Outlook is broken things to try but nothing seemed to work.

Well it turns out Microsoft put out a advisory that users with a Online Archive in a Exchange Hybrid setup were having trouble if the Autodiscover URL was pointing to the on prem server. So it ended up being a really bad coincidence. But this got me thinking why do I need to point Autodiscover to the on prem server at all if 100% of our mailboxes are migrated. It’s just a extra unneeded step which at best adds a little time to autodiscover compared to going directly to Microsoft and at worst if our internet or Exchange is down could prevent users from connecting.

Time to change that. I deleted my internal DNS autodiscover HOST record and put in a autodiscover CNAME record pointing to Microsofts autodiscover.outlook.com. Did the same for my GoDaddy DNS record. Once that was done I removed the SCP value from the internal server:

Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri $Null

Flushed DNS on my own computer, rebooted, and verified Outlook connected without issues. I then updated the SRV records to also point directly up just in case in DNS under Domain -> _tcp -> _autodiscover and pointed that to autodiscover.outlook.com.

It’s now been like this for a couple months with no issues and since we have 0 mailboxes hosted locally there is no reason not to go directly to Microsoft for autodiscover.