IT

Office 365 Group as a Distribution List Gotchas

Office 365 Groups aren’t that new, but they still sound more alluring than a plain Distribution List or Shared Mailbox (yes this is why I chose the article photo). 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:

  • 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.
  • 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.
  • 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 “user1@domain.com”) -or (user.mail -eq “user2@domain.com”) -or (user.mail -eq “user3@domain.com”) -or (user.mail -eq “user4@domain.com”)

  • 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.

Force Multi-Factor Authentication Registration in Azure Active Directory

If you’ve gone down the path of Azure Active Directory (Azure AD), then I dare say you’re not at the end. It’s a long but rewarding path, with new features constantly being added to enhance a critical service in the Microsoft offerings.

It’s also likely you didn’t start with Mutli-Factor Authentication (MFA) in place and ready to go. Maybe you did and well done! For the rest of us though, we slowly move into these systems while turning more options on.

Just enabling MFA with Conditional Access is great, but getting all users to actually register for MFA https://aka.ms/mfasetup can be a challenge. If you’re fortunate enough to have Azure AD Premium P2 licensing, you can use a MFA registration policy to do a nicely managed rollout and force people on. Those without P2 however, have an option that’s a bit hidden, not as well known and slightly scary:

Require users to register when signing in?


Under the question mark: Designates whether unregistered users are prompted to register their own authentication information when they sign in for the first time. If set to “No,” administrators must manually specify the necessary password reset authentication information in the properties for each user in this directory, or instruct users to go to the registration portal URL directly.

The description for this option is a bit misleading, it actually means that they’ll be prompted the NEXT time they log in, rather than the first time.

This option is found under Azure Active Directory > Password reset > Registration, and is off by default.

Turning this option on is a company wide setting and from my testing, worked pretty much immediately. As soon as someone who hadn’t signed up for MFA logged onto office.com, they were prompted to go through the MFA registration process. There’s no way to point this at certain users or test it, you just have that one little switch to turn it on for every single account in your tenant.

For someone who had signed up for MFA, they were asked to confirm the details entered previously.

I’d recommend letting your staff know before this option is toggled, but at least it can easily be turned off again if you run into any issues.

Update 2nd May:

After publishing this, Sean Flahie on Twitter mentioned his experience if Azure Self-Service Password Reset (SSPR) wasn’t enabled for users, and enabling the combined experience – both of which I have in place already. If you’re having any issues then please look into both of these.

Microsoft DOESN’T admit expiring-password rules are useless

Update 6th June 2019: The final version of the Security Baseline has been released by Microsoft, and explains the password recommendations very clearly. Here’s one paragraph quoted, bold is my emphasis, but please go and read the whole article:

Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Original blogpost:

CNET has an article titled “Microsoft admits expiring-password rules are useless” which I strongly disagree with, and thought it was worth explaining why.

Beyond the actual blog post from Aaron Margosis at Microsoft not actually containing the word ‘useless’, it’s an inaccurate summary of what is a well written and clear write-up from where I sit.

This all came out of publishing the draft of the Security Baseline recommendations for Windows 10 1903, which details out what settings Microsoft recommend and why. If you’re managing a Windows environment, these are a must read, and should be reviewed with each version of Windows 10 you plan to move to.

The general take of the CNET article was that password changes have been useless for years, suggests Microsoft should completely ‘yank’ the ability to force passwords to expire, and if your IT staff don’t remove password expiry immediately, they’re living in a ‘security Stone Age’. It’s rather insulting and coming from someone in my opinion, who doesn’t know what they’re talking about. They might say the same about me, of course :)

On the other hand, Microsoft’s blog post tells a different story. Yes, passwords are problematic and forcing them to change frequently causes other issues where people just change the number on the end by ‘1’, but they aren’t saying password changes are useless.

Microsoft used to recommend 90 day expiries, then to 60 days. The idea there was that if a credential is leaked somehow, the smaller window that the password is known by third parties, the better. But, if your password M0nkey34! is now M0nkey35!, that’s probably going to be the first thing a targeted attacker tries if the password they had for you didn’t work.

Although all this is true, it works on the assumption that someone is actively targeting you. It happens, but it’s much more common for attackers to just do spray attacks based on millions of credentials they have. Why are they going to pick your account and try a bunch of combinations of passwords, when they could just go through stupid amounts of records with no effort and find weaknesses there?

Say you are a target for some reason; it’s likely that the password leaked from somewhere isn’t new – it’s probably months or years old. If you’d never changed your password because your company never forced it to change, then the attacker now has a valid password for you.

It’s also much more likely your password was stolen from a 3rd party service, nothing to do with your corporate systems. You might have signed up with your work email address, but the password ‘should’ be unique to the service signed up for. We all know users don’t work that way, and use the same password all over the place. Having a password they know will change frequently, may mean that they use something at least unique, even if it does increment.

All of this is moot of course, if you have multi-factor authentication (MFA) in place, because the requirement of something else (a phone, bio-metrics etc) means a username and password by themselves are actually useless. However, most companies do have systems in place that have no options around MFA, so what do they do?

To re-iterate, I agree with everything said in Microsoft’s blog post. This is where one paragraph in the blog post sums it up nicely:

Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Work out your risks, your userbase, what systems might be impacted, what extra protection you have in place and make an informed decision around what frequency works for you.

The focus shouldn’t be on password changes, but should be on implementing those other protections in all scenarios – but before that happens (which for many companies can easily take several years), you’ll need to work out what policy you do. There is no single best-fit recommendation on what that is when using pure passwords, because they’re inherently bad however you look at them.

Look at Conditional Access, Password Protection and Azure AD Identity Protection for starters on adding in these extra protections!

The answer isn’t a pure ‘password changes are useless’, and it’s irresponsible to say so.

Outlook Search Results Won’t Delete

I ran into this issue when migrating users to Exchange Online, while running Outlook 2016 MSI 32 bit.

Once a user is on Exchange Online, Outlook starts leveraging the power of FAST search. This search occurs on the Exchange Online end, rather than the device end, and is designed to give quicker results while being more reliable than Windows Desktop Search. There’s a great write-up on this on Microsoft’s TechCommunity that goes into much more detail.

It does depend what sort of search you do as to whether it’ll use FAST or Windows Desktop Search too, but the most basic of searches will use FAST. There’s also timeouts and speed checks that can force it to fail back to Windows Desktop Search.

However, there are some catches with this search from my testing. If you do an email search and decide to delete one of the emails in the results, it appears that nothing has happened. You can delete and delete, right click, press the delete key, click the X to delete and it all appears to do the same – nothing. In the background though, it has actually deleted your email, it just doesn’t display this in any way. It’s like the search results are a static result and won’t update on an action like this.

This behavior can be confusing for a user, especially when they’re used to seeing emails disappear and react when something’s done to them.

There’s another catch that depending on your environment, might be more of a deal breaker. If you use the category field, flag, or extra fields, for example when filing a document into a DMS system, those aren’t displayed or updated in a FAST search. If your users need this to effectively manage their emails, then it’s worth looking at just disabling FAST search via Outlook altogether.

As mentioned in the above post and this Technet article, there’s a single registry setting that can disable FAST search:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Search

Value name: DisableServerAssistedSearch

Value type: REG_DWORD

Value: 1

A restart of Outlook is needed after this change, and users won’t be alerted of anything different. Search will just start using Windows Desktop Search (which was always running anyway) and not know any better.

How many cleaners does it take to take down a datacentre?

The answer is just one, and either this cleaner gets around a lot, or a lot of cleaners just need a free power point.

I thought I’d ask this question on Twitter to see what interesting stories people had to share:

Worth reading the entire thread, but it turns out unknowing cleaners seem to have cause a lot of outages!

I’ll let the responses speak for themselves:

(OK that last one was not really a cleaner, but involved cleaning!)

I’d be hoping these incidents happened a while ago, but in reality it’s a good demonstration of how things can happen that you really didn’t plan for. It’s also a good argument for having your important gear in a secure room!