Easily Enhance Microsoft Search with Organizational Data

Microsoft Search, particularly when effort is put in to build metadata and Organizational Information is an extremely useful tool that doesn’t always get the credit it deserves (probably partially stemming from the consumer experience with ‘bing’ over the years).

Organizations can leverage Microsoft Search to help their users locate information extremely quickly and efficiently – Providing the right change management and training plans have been put in place to help change user behavior.

Microsoft have recently made available a host of cool admin tools to assist with configuring Microsoft Search to give users the best experience. Features like the Graph Connectors for Microsoft Search unlock a host of possibilities for extending Microsoft Search outside of just Microsoft 365.

An even easier method of enriching the Search experience is to add some organization data in the Microsoft 365 Admin Portal. In the below screenshots, we have added a few options into the Microsoft Search config:

An Acronym:

A bookmark:

A Q&A entry:

We can even enhance some of our options by linking to PowerApps, external sites and scoping the results to specific user groups.

Our users can then search within Office 365 and find our predefined results:

That’s really cool, our users can search in the Office Portal but it could probably be fancier. This is where Edge (Chromium) comes into play. The built in Microsoft Search functionality allows these result to surface as part of a regular web search:

Once the user is signed into Edge with their corporate account they will see the “Work” option in their search results. The search functionality can be used to search our entire organizations Microsoft 365 data including any Graph connectors to external systems and can even be triggered from Windows 10 machines local search bar. This is an extremely powerful tool for users to navigate very quickly and find the answers they need.

Prevent Office 365 Groups/Teams from provisioning Power Bi Workspaces

Office 365 Groups/Microsoft Teams contain a host of useful components such as SharePoint, Exchange Online and Planner. Another component of Office 365 groups by default is a Power BI Workspace.

There are two types of Power BI Workspaces: Classic and Modern Workspaces. Modern Workspaces allow for granular permissions and are standalone objects with an enhanced feature set . Classic Workspaces however, are essentially Office 365 groups and access is managed by group membership. For most use cases Modern Workspaces meet all requirements for Power BI.

The impact of having many Classic Workspaces is that you also have many Office 365 Groups, potentially not following governance process that is applied to something like Microsoft Teams. You also do not necessarily want a new Power BI Workspace to be provisioned for every Team, Group, Planner, Modern SharePoint Site etc. that is created in the environment.

Luckily, by setting the option: “Power BI Block classic workspace creation” to Enabled, we can prevent the creation of Classic Workspaces. With this enabled, new Office 365 Groups and any associated objects will not provision a new Power BI Workspace. This helps keep our Power BI environment tidy and limit sprawl.

While here, there are a lot of options that can help us control the Power BI platform and protect against external sharing, data export etc. It’s also worthwhile limiting the creation of Modern Workspaces to a specific group of users who have received training and you can trust to adhere to corporate policy.

There are a lot of configuration items in Power BI that tend to be missed as Power BI itself can be user driven with little IT input into usage. I recommend reviewing these settings periodically to ensure there are no potential risks with the default functionality.

For more information of what makes and Office 365 Group, I highly recommend this page.

Azure AD Sign-ins Conditional Access Policy Details (Preview)

Azure AD Sign-in logs are the go-to place for troubleshooting user sign-ins, tracking malicious login attempts and analyzing Conditional Access policies for Microsoft 365. There are a lot of recent updates which make traversing the Sign-in logs more user friendly and speed up troubleshooting. Some of the recent updates are visibility of refresh tokens and application sign-ins. Another interesting feature currently in Preview is Conditional Access Policy Details.

The new Policy Details slide out gives us a fantastic, easy to interoperate view of the logic behind if a policy has been applied or not. To access the Policy Details feature, simply navigate to a user sign-in as normal and open the Conditional Access tab.

From here, click on the name of the policy and the Policy Details pane will slide out from the right of the page.

Here we can see step by step exactly what happened with our Conditional Access policy. We see the criteria applied in the policy and the results of each step. This feature adds to the already brilliant Azure AD Sign-In logs experience and will save admins a lot of time troubleshooting and testing Conditional Access Policies.

For more information on using the Sign-in Logs, check out this Microsoft Article:

PSA: The importance of disabling legacy authentication in Microsoft 365

This topic seems talked to death nowadays. Almost everyone has come across the strong recommendation to disable legacy authentication in their Microsoft 365/Azure AD tenancy. If you haven’t done this yet then the clock is ticking down to the day Microsoft disable the functionality automatically – October 2020 for new tenants at the time of writing. 2021 for existing.

Something that I find is not as widespread as the recommendation to disable, is the reason behind disabling it. Other than stating it is ‘unsecure’ and vulnerable to password spray and brute force type attacks, there are not a whole lot of real world examples of the issues with legacy auth for Microsoft 365 readily available. A lot of the high level messaging relates to Modern Authentication allowing us to use Conditional Access and MFA but not many examples of why.

To understand, let’s take a typical Azure AD Conditional Access Policy which enforces Muti-Factor Authentication on all Android Devices:

The above policy should enforce MFA on Android devices connecting to our Office 365 service. Now when we log in as this user from an Android device and app/protocol that support Modern Authentication, we can see Conditional Access applies and our user is prompted for MFA.

We can check the Policy Details to see the Conditional Access criteria too.

Great, our user is protected by our Conditional Access policy, we’re secure….right? We can sleep soundly knowing we have the extra protection needed…

Well, now lets try sign in with a third party app using POP3 and Legacy Authentication.

Looks like our user got in without issue and Conditional Access checked the sign-in attempt successfully, however when we look at the details of the policy applied, we see a problem…

Our Conditional Access policy didn’t apply! Looking at the Conditional Access Policy Details we can see that the Device Platform condition wasn’t met.

When we look at the sign in logs we see why.

We don’t have any of the additional details we would generally see with a sign-in using Modern Authentication. As this detail is missing (In this case, Conditional Access is unaware we are coming from an Android device), our Conditional Access policy doesn’t know it should apply and the user bypasses our MFA requirement.

This is just one of many real world examples of where Legacy Authentication creates gaps in our security policy. By now, hopefully almost every tenancy is disabling or working to disable Legacy Authentication. As it stands Microsoft will enforce this change in the very near future so there is still time for anyone who hasn’t taken this step to prepare for that date.

Hopefully this post helps to put the associated risk into real world context. For information on how to disable Legacy Authentication, check out the Microsoft Documentation.

Turn off message preview for Teams notifications

With the extraordinary uptake of Teams in recent months, a lot of users are still finding their way around what they can and can’t do and how to customize their Teams client settings. One thing I’ve seen cause problems (particularly on screen shares during meetings) is the Teams notification message preview.

When sharing a screen through Teams or any other app, there’s always the possibility that something might pop up that not everyone should see. I’m always nervous when I see something like this pop up during a meeting screen share:

Sharing a single app can help to minimize this risk but it’s not always practical. It also doesn’t help when presenting a screen in person. Beginning in October 2020, Microsoft are rolling out the ability to turn off the message preview function to Teams clients. This will be available in the Teams client settings notifications section.

Teams notification settings

This is another great quality of life feature that users will enjoy. It may help prevent some embarrassing pop ups going forward. I’d also recommend looking at the focus-assist settings in Windows 10 to minimize notifications.

Auto-Forwarding Default Change for ATP Outbound Spam Policy

A very popular attack upon breached email accounts since the forwarding feature became available is for the attacker to create a auto-forwarding rule in the users mailbox to essentialy receive a copy of all mail that is sent to that account. This forwarding is extremely quick to set up and not easily found as most users do not regularly check their mailbox rules.

It has become common practice to disable external auto-forwarding as part of a standard build of any mail system and for Exchange Online, it has been built in as an option to disable. Previously this needed to be changed for most tenancies as the default setting “Automatic”, allows auto-forwarding.

As of 16/09/20, Microsoft are rolling out a change to this default setting. Going forward, the “automatic” setting will disable auto-forwarding. Any tenancies which have the default setting should review their requirement for auto-forwarding and assess if it is required.

If auto-forwarding is unavoidable in the organization, there are several options to help protect against malicious attacks.

New inbox rules which set up auto-forwarding can be detected using an alert policy in the Security and Compliance Center to help give visibility of when forwarding rules are enabled. This is a default alert but I’d recommend increasing the severity.

Existing inbox rules can be assessed with some quick Exchange Online PowerShell. For large environments it may be worthwhile exporting this out to CSV for review.

Get-mailbox -ResultSize unlimited | foreach{get-inboxrule -Mailbox $_.identity | ?{($_.redirectto -ne $null) -or ($_.forwardto -ne $null) -or ($_.forwardasattachmentto -ne $null)}}

Finally, if auto-forwarding is a must, we can lock down who we auto-forward to. We can do this by first creating a new remote domain in Exchange Online and allowing auto-forwarding on that domain. Then we can freely disable auto-forwarding on the Default remote domain.

Ideally the changes Microsoft are making do not affect your environment as auto-forwarding is not enabled currently but if it is a business requirement, hopefully the above suggestions will help to secure and control auto-forwarding.

Azure Active Directory Administrative Units

Segregation of admin roles in Microsoft 365 has always been a challenge. Different admin roles help to apply the principal of least privilege for admins but there was always an issue where multiple logical groupings existed in a single tenant. They are not always managed globally and not every admin should have access to every user where divisional barriers exist. Exchange Online Management Role Scopes do a good job of facilitating different groupings in Exchange Online but for user management in Azure AD or Microsoft 365, this became a challenge.

Do we give the local IT support for a particular division access to our entire userbase or do we take on the support of the M365 accounts for these users at a group level?

When we use AD Connect and local Active Directory as our identity source, we can use delegated permissions to provide a lot of the required access. Couple this with some cool features like group-based licensing and we can effectively delegate management to local or divisional IT support.

With more organizations forgoing local AD completely for cloud based Azure AD/Intune, this management delegation became trickier. Microsoft appreciate this challenge in the platform and have made available (in preview) Azure AD Administrative Units.

Administrative Units allow us to define logical groupings of users and delegate admin roles for these specific groups to our administrators.

To achieve this we first create an Administrative Unit in the Azure AD Portal.

From here we can add our users / groups to the unit so they can be managed.

We can then assign our administrators and grant the the appropriate roles.

Once complete, our administrator can log in to the Admin Portal and only see the Administrative Units they have been assigned.

This feature is bound to be a blessing for large organizations who can now feel more confident to delegate day to day management to divisional or local IT, reducing the management overhead involved in new user creation, Group Membership, Licensing and password resets

Office 365 ATP Preset Security Policies

Office 365 ATP is a fantastic tool for protecting Office 365 users from threats such as spam, phishing and malicious content. A lot of the time, as consultants, the initial set up of these policies is pretty similar from customer to customer with some potential change on granular items such as thresholds and actions.

Often a customer will look for a “best practice” implementation so they can assess without going into each configuration item and making a decision based on past experience with other products or gut feeling. “Should we send suspected Phishing mails to junk or quarantine? What about high-confidence Phishing?”

There is some guidance available from Microsoft for the initial set up in the documentation and the Office 365 ATP Recommended Configuration Analyzer (ORCA) is great for assessing gaps from this perspective but still requires knowledge of the configuration and monitoring of any new features released or changes to recommendations.

The new Office 365 ATP Preset Security Policies option allows for a more ‘hands off’ approach of accepting best practices for ATP configuration. The policies allow for a selection of “Standard” and “Strict” Protection of users and can be assigned to separate user groups. This allows organizations who want to be protected, but aren’t too concerned with understanding the “nuts and bolts” of it all a nice option to deploy best practice protection to users rapidly.

While this is probably not a good option for a large enterprise looking to replace something like Mimecast, for SME’s the Presets should save time and effort in deploying some extremely powerful features to protect users.

The individual configuration items in these policies can be found in the Recommended settings for EOP and Office 365 ATP security documentation.

Exchange Online Migrations and EWS Throttling

Merging and splitting Office 365 data from tenant to tenant is becoming more and more common recently as the platform grows and more organizations are stepping down on-premise systems in favor of leveraging cloud services for mail and collaboration.

A cornerstone of Microsoft’s cloud offering is Exchange Online, which has been active now for more than a decade, since the BPOS days. It stands to reason that in that time organizational structures change, divestitures and acquisitions happen, and data needs to move to support these changes.

Microsoft’s Exchange Hybrid Configuration does a fantastic job of facilitating the move from on-premise Exchange systems to Exchange Online but when we look at large complex organizations, a simple Exchange on-premise to Exchange Online migration is becoming rare.

When you consider non-Exchange source systems such as Lotus Domino or G-Suite, and existing Exchange Online tenancies. The migration path becomes more complex.

There are Native Microsoft migration paths for G-Suite and IMAP migrations (I’m even a big fan of the PST and File Ingestion Service which leverages Azure storage) but depending on the scope and cadence of the migration, they often aren’t as robust as some of the third party offerings such as MigrationWiz or CloudM Migrate.

These tools add a variety of extra possibilities for synchronization of mail/contacts/calendars as well as Microsoft Teams, SharePoint Online, OneDrive with some great quality of life features such as permissions mapping, scheduling and filtering capabilities.

When it comes to Exchange Online Migrations, the preferred method by most of the tools is using Exchange Web Services (EWS) and user impersonation to migrate mailbox items. The EWS API (which is currently being edged out by the Graph API), has been a mainstay of Exchange Server since Microsoft Exchange 2007 is highly flexible and extremely powerful tool to accomplish those “non-standard” tasks in Microsoft Exchange (I once had to de-duplicate about 1TB of mail in a Shared Mailbox after a bad migration attempt).

While EWS is extremely powerful, it’s important to consider the load large scale actions take on the back-end infrastructure. To protect Exchange servers from overload, EWS is controlled via throttling policies. For Exchange on-premise if a large scale migration or other action is planned, these policies can be altered for specific service accounts to bypass what would be considered acceptable per-user usage.

Some of the errors we may see in a migration when EWS throttling kicks in.

In Exchange Online however, we don’t own the servers and Microsoft needs to protect it’s cloud services so we do not have access to the throttling policies directly. Previously, if a migration was planned, a call to Microsoft Support was required to bypass throttling for a period of time to ensure the throughput needed for migration.

This process has become a lot smoother these days using the built in support tools. To temporarily increase the limits on a throttling policy, we just need to open the support tab in the Office 365 Portal, search for EWS Throttling and run the diagnostic tool. If throttling is affecting the migration, we will get a prompt to bypass for 30, 60 or 90 days.

Once done, the change should take affect withing 15 minutes and we can migrate without these errors!