Protect Your Office 365 Accounts By Disabling Basic Authentication

Posted on by Adam Fowler

(AKA Legacy Authentication)

This had been on my to-do list for a little while since I heard about it (mostly from Daniel Streefkerk who quite rightly has been drawing attention to this via Twitter, thanks!)– and it should be on yours too.

By default, Basic Authentication is allowed as an authentication method in Exchange Online. This is because that’s the ‘standard’ way things have worked for a very long time – you want to get your emails, you provide a username and password and you’re done.

In our modern world, that doesn’t work too well anymore. It’s too risky in that many ways, and things like 2FA and Conditional Access add an extra layer of security when logging in. That’s great, but many systems weren’t built or haven’t been updated to support this – they’ll just fail when logging in.

What this leaves us with, is an internet exposed authentication system that accepts username and password logins without any other layers of authentication, even if you have 2FA and conditional access turned on.

As per Microsoft’s documentation around disabling basic authentication covers, this lets attackers use brute force or spray attacks to try different credentials to get into your tenant. With the amount of leaks we see these days (register on Troy Hunt’s https://haveibeenpwned.com/ if you haven’t already), it’s likely attackers are hitting Microsoft servers with correct accounts of your staff members. If they manage to get the right password – which is very possible if people end up using an old password they used years ago, or password changes were disabled because you thought you were covered with 2FA – they now have valid credentials to get in and pretend to be that staff member, often to then send emails to all their contacts with a malicious link or some other scam.

If you want to see what’s going on for your tenant, go to the Azure portal and into Azure Active Directory > Monitoring – Sign-ins. Set the Status to ‘failure’ and apply, and see what’s there.

Here’s an example, where you can see the client app is ‘Other clients, IMAP’. This account is disabled, and if you look in the device info there’s no data.

Once you have a look here, you might start to get worried – so it’s time to see if you can disable basic auth!

Only certain email clients will work without basic auth, so your first step is to work out what people are using, and get approval to force the usage of only these:

  • Outlook 2013 or later (Outlook 2013 requires a registry key change)
  • Outlook 2016 for Mac or later
  • Outlook for iOS and Android
  • Mail for iOS 11.3.1 or later

That can be a tough ask, and you’ll need to weigh up the risk of leaving basic authentication in place (to me this is an easy choice, but can still be difficult to get approved and implement).

Again, the Microsoft documentation explains how to do this quite easily – create a new Authentication Profile which has Basic Auth disabled by default, and apply it to test users:

New-AuthenticationPolicy -Name “Block Basic Auth”

Set-User -Identity [email protected] -AuthenticationPolicy “Block Basic Auth”

Set-User -Identity [email protected] -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

That’s all you need to do to test. The third command forces an immediate refresh on the test user.

I would recommend leaving this in place for a while, and get as many test users on as possible as you might find certain systems using basic authentication that you weren’t aware of.

If you need to drop the policy off of a user, use this command:

Set-User -Identity [email protected] -AuthenticationPolicy $null

If you’re then ready to apply this policy to all accounts company wide, these three commands will do it:

$users = Get-User -ResultSize unlimited
$usersid = $users.MicrosoftOnlineServicesID
$usersid | foreach {Set-User -Identity $_ -AuthenticationPolicy “Block Basic Auth”}

You’ll also want any new accounts to get your new policy by default, which can be done with this command:

Set-OrganizationConfig -DefaultAuthenticationPolicy “Block Basic Auth”

And with that, you’ll have all existing and future accounts protected from the risks of leaving Basic Auth enabled. Of course if you have a special requirement where a few accounts do need Basic Auth, create another policy, enable basic auth on it, and apply it to those accounts. Your attack surface will still be greatly decreased, and hopefully you’ll eventually be able to disable basic auth on those too.

Note: There’s also an option for OneDrive for Business around this same setting, more details here: https://www.adamfowlerit.com/2019/03/onedrive-for-business-rollout-considerations/

Update 26th April 2019:

There’s also now a Conditional Access option that supports ‘other clients’ –
“This includes older office clients, other mail protocols(POP, IMAP, SMTP, etc), and ACS”. This might help you if you either want to block those older clients, or allow them through in certain circumstances:

Another Addon Released

Posted on by Adam Fowler

Back in 2015, I wrote about the first addon. Now here we are in 2019, and somehow I’ve ended up with another.

There he is, the reason my wife and I get little sleep – Oscar. Thankfully we are all happy and healthy with Oscar doing really well.

I knew what I was getting into a bit more this time with #2, and I knew it wasn’t going to be easy. The way I mentally coped with this was to wind down a lot of the extra bits and pieces I had going on – writing gigs, blogging here, handing off my user group for a bit and other extra curricular activities – for me personally, I needed to put myself in a position where I would have the time I needed to look after a baby (along with a soon-to-be 4 year old!).

My wife is great, as she takes the after midnight shift which is the hardest, and with any luck will get some sort of rest during the day – but this will continue to take a toll on us for the next few months.

This is why my blog hasn’t been updated since early December, and I’ve been generally quiet elsewhere. I partly feel guilty for doing it, I’ve got things like my Microsoft MVP award to maintain, but all that is secondary to family.

Thankfully everyone I’ve spoken to has been incredibly accommodating and supportive when I’ve said I need a break. My day job is enough of a time eater already, and I need to save all the energy I have for that!

I’ll get back into more things eventually, but I’m making sure I don’t rush into too much.

I appreciate everyone who reads, comments or even tells me when I’ve got something wrong (like a typo!). Hopefully I’ll start coming across things worth writing really soon (I have something in mind already), but if I’m less responsive than normal you now know why.

Hide ‘Do not forward’ in Outlook

Posted on by Adam Fowler

If you’ve noticed this option in Outlook, you might wonder where it comes from:

On a new/reply email window in Outlook, under the ‘Options’ tab is a button called ‘Permission’ (which in the future based on the time of writing, is changing to be called ‘Security’). This by default has three or four options, which seem to be dependent on the version of Outlook being run (MSI vs CTR). Click To Run has another called ‘Encrypt-Only’ which I haven’t tested yet.

These options are actually using Azure Information Protection (AIP) to encrypt your email. That’s a giant topic in itself, but the one liner is that wherever you send an encrypted email to, needs to sign in to view the message. In some scenarios this works seamlessly, such as sending to an external user also using Exchange Online. In other scenarios they’ll need to click a button to log in and view the email via their browser.

The ‘Tenant name – Confidential’ and ‘Tenant name – Confidential View Only’ are default AIP labels. You can view/edit these by going to your Azure portal and looking under Azure Information Protection > Classifications > Labels. 

As you’ll see in the screenshot above, the two labels I mentioned are listed, and you can go into those and disable them if you don’t want them to appear for your users (there’s a toggle for ‘Enabled’ set to ‘On’, set that to ‘Off’). You could also completely disable Azure Information Protection, but that might cause you other problems if you want to use AIP in any way.

You might be wondering why you’d want to turn these off, encryption and security is good right? You might not be ready for users to start using this yet for support reasons, you might have a different method of securing emails, or you might be using a 3rd party backup system. That backup system won’t be able to read encrypted emails by default – so unless you can get that working somehow, you will only have copies of emails that contain a link to the actual content that require the right access to get to the contents – not a true backup.

Getting back to the title of this article – Do No Forward. If you’re at this stage, you may have noticed that it’s not actually a label listed. As covered in this documentation, it’s inbuilt rather than being a customisable policy, template or tag.

You can turn off this single function in the Azure portal under Azure Information Protection > Policies > Policy: Global and toggling the ‘Add the Do Not Forward button to the Outlook ribbon’ to Off:

There is a registry trick to disable this from Outlook too, which was given to me by Microsoft Support:

Open registry key editor:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\DRM
14.0 = 2010
15.0 = 2013
16.0 = 2016
2.On the Edit menu, point to New, and then click DWORD (32-bit) Value.

Type DisableDNF, and then press ENTER.

In the Detailspane, right-click DisableDNF, and then click Modify.

In the Value databox, type 1, and then click OK.

Exit Registry Editor.

This will at least grey out the option so it can’t be used. The option will still be usable in Outlook via Web, and if I find a solution to that I’ll update this post. As far as I know at this stage, it can’t be hidden or removed.

Update: It’s possible to hide this in OWA also.

The ‘Encrypt’ or ‘Protect’ button (Right now I see different options in different tenants) can be hidden with this PowerShell command:

Set-IRMConfiguration -SimplifiedClientAccessEnabled $false

Although this hides the option, there’s also a ‘Set Permissions’ menu options in the ellipsis that can be hidden with this PowerShell command:

Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -IRMEnabled $false 

Those two together should stop any user being able to encrypt an email themselves via OWA.

Finally, you could look at completely disabling rights management in all forms on Azure Active directory, which can be done here:

https://account.activedirectory.windowsazure.com/RmsOnline/Manage.aspx?brandContextID=O365

Exchange Online Migration Clears ‘Recent’ Document Lists from Word and Excel

Posted on by Adam Fowler

I struggle to fit these issues into a short but descriptive headline sometimes :)

This issue is a little strange. If you didn’t know any better (like me), you’d expect the location of a user’s mailbox to have no impact whatsoever on the function of ‘Recent’ document history inside of Microsoft Excel and Word, but it actually does.

I found this out the hard way of course, when a couple of staff mentioned their recent lists had disappeared and it co-coincided with their Exchange on-prem to Exchange online migration.

After some digging, I came across this Reddit post: 
Users losing Recent Documents lists in Office 2016 due to upgrade to ADFS. It’s the same problem with a slightly different root cause, and goes into a much deeper technical explanation than what I’ll do here.

The short of it is that the Office applications detect what sort of login you’re using – if it’s Active Directory (AD) or Azure Active Directory (AAD). When that state changes, it uses a different registry path for a few things, including those recent documents.

Without knowing for sure but based on my testing, it must be doing some check to see if the associated account’s mailbox is in Exchange Online or not – and if not, it considers it an AD account. It doesn’t matter if you already have the users in Azure AD, Single Sign on and all that other good stuff set up – the single change of changing the mailbox location to online triggered the change for me.

For an AD account, the history paths are saved in the registry here:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Word\User MRU\AD_1234567890 (the number on the end is some sort of unique GUID).

For an Exch account, it’s in this slightly different path:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Word\User MRU\ADAL_1234567890 (again, unique GUID at the end).

In case you were wondering, MRU stands for ‘Most Recently Used’. AD is to do with on-prem Active Directory, and ADAL is (according to that reddit post) Azure Active Directory Authentication Library.

Also note the example above is for Word, there’s corresponding paths for other Office applications such as Excel.

There’s two subkeys below this key, one for File MRU and the other Place MRU.

The good news on hitting this scenario is that the values can just be exported, the path changed and re-imported. To do this, via regedit find the registry key that has the values you want (probably the AD one) and right click > export.

Find the file you exported and use notepad to do a find and replace on all the entires for AD_1234567890 and replace to the new value (which you can find from just looking in the registry).

Now, re-import the registry file and you’ll have all the recent document paths restored.

This should only be a one time problem for migrations, and only for people who had a bunch of document paths saved in there and can’t find where they are easily.

Disable Windows Defender Summaries via Registry

Posted on by Adam Fowler

Windows Defender does some great stuff, but in my opinion one of the more ‘noisy’ things it does in Windows 10 is provide a frequent notification to say it’s working but hasn’t found anything.

Many users may find this notification unnecessary and breaking their work focus just to be told that their PC is fine. Especially in a business environment, they’d think that is someone else’s problem.

Windows Defender Security Center Settings

A user can turn these off themselves of course, in the Windows Defender Security Settings page under Virus & threat protection notifications. It’s possible to turn off all informational notifications, or untick certain types.

Although there is an inbuilt Group Policy to also turn off informational notifications, to me I’d still want users knowing a threat was found or something was blocked – those are useful to the user. However the recent activity and scan results is the one I’d suggest disabling, but there’s no Group Policy for that.

Luckily this is just a single registry key which I’ve found through using Procmon:


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender Security Center\Virus and threat protection\

REG_DWORD: SummaryNotificationDisabled

Value: 1 (decimal)

This setting can be rolled out through Group Policy (even as a run once and don’t reapply) if you’d like users to have control over turning the setting on.