Exchange Online

Office 365 Group as a Distribution List Gotchas

Posted on by Adam Fowler

Office 365 Groups aren’t that new, but they still sound more alluring than a plain Distribution List or Shared Mailbox. They aren’t the solution that applies to all situations however, and you’ll need to weigh up each scenario as to what fits best.

(for Office 365 Group fundamental considerations, please read Michael Mardahl’s blogpost “Getting off to a good start with Microsoft Office 365 Groups”)

Here’s some things around Office 365 Groups and using them as an email distribution list (DL) that caught me out, or are differences worth pointing out. If you’re thinking of migrating a DL or a shared mailbox to an O365 Group, these are worth considering:

  • If a member of an Office 365 Group sends an email to the group, they won’t get that email. It makes sense that you probably don’t want an email that you sent, but it is a change of behavior from traditional DLs. This may change in the future, at least as a toggle-able option.
  • An Office 365 Group mailbox can’t have folders created in it. If staff have access to a shared mailbox and use that to manage their emails under different folders, that’s a no-go for an Office 365 Group. There’s a bunch of other ways you can manage this, but if they specifically want that option, then an Office 365 Group won’t help them.
  • By default, users will see a ‘Groups’ option in Outlook (either client or web) which they can drop down, see the groups they’re in, and see the inbox. That’s the only folder that’s visible though, and it can be easy to assume that’s the only folder. There are however, several folders available. You can’t open an Office 365 Group as another mailbox, as you’ll be told via Outlook Web that you don’t have access to the mailbox, and Outlook client won’t recognise the name of the mailbox.
    You can however, use the ‘Open Shared Mailbox’ option in Outlook Web by right clicking on your mailbox in the folder view, or right clicking on ‘Folders’ (depending on if you’re using the ‘old’ or ‘new’ Outlook) and add the Office 365 Group that way. This will give you visibility of all folders and their contents:
  • Automating Office 365 Group membership is harder. You either automate membership with a dynamic group, or let the owner(s) do it themselves. Neither are bad options, but dynamic group membership exceptions to rules are harder to do. How do you have a group that’s all Finance, plus these 4 people that aren’t finance? You could have an expression like this, but that is something that could get rather messy to maintain:

(user.department -eq “Finance”) -or (user.mail -eq “[email protected]”) -or (user.mail -eq “[email protected]”) -or (user.mail -eq “[email protected]”) -or (user.mail -eq “[email protected]”)

  • Meeting responses work differently to a DL. Say you send a meeting appointment, and have the respones go to a DL – all members of the DL see the response. This can be useful in certain scenarios, but probably not that common. An Office 365 Group works differently, where the ‘Meeting Message Processing Agent’ in Exchange Online will see the meeting response, and send it directly to the Deleted Items folder. This action skips members receiving a copy of the response which might be good generally, but again it’s another different way that Office 365 Groups work when you’re expecting the same as a DL.

That’s what I’ve found so far – if you have any yourself please share and I’ll test/add to the list, and will update with any other tricky scenarios that I come across.

Access An Exchange Online Mailbox Without a License

Posted on by Adam Fowler

This is just a quick one. Most Office 365 admins will hopefully have a separate admin account to perform higher level tasks, compared to their normal user account.

Because of this, the admin accounts shouldn’t need any licensing, because they’re not being used like a normal user. One person shouldn’t need to have two sets of licenses – but there are some problems that can come up because of this.

For example, if you want to use your admin account to access someone’s mailbox, that can be difficult when you don’t have a mailbox yourself to log onto, to then open another user’s mailbox. Outlook can be used to work around this, where you set up a profile for the email address of the user you want to access, but enter your admin credentials when prompted:

Your Name is just a display name field, email address needs to be the user’s email. Don’t enter a password here and click ‘Next’
This login page will start by showing the user’s email address, use the option ‘Sign in with another account’ and use your admin account.

The above works OK, but is a little time consuming if you’re accessing a mailbox for a quick check.

If you try to go to Outlook Online, you’ll get a message saying your admin account doesn’t have a license or a mailbox. To get around this, you’ll need to use a URL like:

https://outlook.office.com/owa/[email protected]/?offline=disabled

or

https://outlook.office.com/mail/[email protected]/?offline=disabled
if you want the ‘new’ Outlook.

It will then jump straight to that user’s mailbox, assuming you have access rights to it, and have waited a few minutes for the rights to apply.

Using the URL method is really quick way of accessing another user’s mailbox without needing a license yourself.

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:

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.

Users Managing Email Groups and Exchange Online

Posted on by Adam Fowler

For a very long time, users have been able to manage email group members via the Outlook client. Going into the Address Book, finding the group in the Global Address list, going into Properties and choosing ‘Modify Members’:

From there, someone can add or remove members as long as they’d been added to the “Managed By” field against the object in Active Directory, as well as ticking the box “Manager can update membership list” below it.

Easy! Except, that no longer works if the user is in Exchange Online, and the Email Group is from on-premises AD rather than Azure AD/Office 365. It’s not supported. This problem has been around for a while, back in 2015 Perficent wrote about this same topic. The options given for managing these groups are:

  • Exchange Admin Center
  • Exchange Management Console
  • Exchange Management Shell

None of those are what you want your standard users touching in my opinion – although you can give someone access to the Exchange Admin Center and only see the distribution groups they own – but for me, I’m still on Exchange 2010 so this isn’t an option.  This leaves you with a few options:

1. Change all your email groups to Cloud based groups. If this makes sense for you, doing this will let the manager of a cloud based group add/remove members via the Outlook Address Book.
You can also look at changing distribution groups over to Office 365 Groups (which are also cloud based), which give a whole bunch of different features beyond a what a distribution group can do, while giving the same standard DG experience.

2. Make all requests come through to IT so you can make the changes yourself. Not great for anyone involved, as it’s double/triple handling something where the user could quickly do it themselves.

3. Create Dynamic Distribution Groups and let automation do it’s thing – which will work for some, but exceptions to rules and the inability to see who’s in a group can make this frustrating for some.

4. Provide another way for staff to change group members themselves.

I’ve gone with option 4 – as I’m a big fan of Adaxes which I’ve written about a few times on my blog before, and they have a nice way of giving users a web interface that only lets staff manage the groups they’re the owner of.

There’s other ways to do this as well of course and other 3rd party solutions that can expose ways of adding/removing members of a on-premises distribution group – but remember there could be up to a half hour delay in syncing the change from AD to AAD via Azure AD Connect. If possible, look at adding a trigger at the end of a group change to do a delta sync:

Start-ADSyncSyncCycle -PolicyType Delta

That’ll be the quickest way to get the change up quickly, as staff may be used to the change working immediately.

There’s a lot to consider on how you’ll manage this, so make sure it’s sorted before you migrate – or expect a lot more tickets going through your helpdesk.