A Community-Driven Security Configuration Analyzer for Entra ID Tenants

The irrepressible Merill Fernando, a product manager in the Microsoft Entra ID organization, came together with Security MVPs Faben Bader and Thomas Naunheim to create the Maester tool. Announced on April 10, Maester is labeled as a “Microsoft Security test automation framework” and installation instructions are available here. It is a great example of a community-driven project.

Maester is built using Pester and Microsoft Graph APIs. Basically, it runs a bunch of tests against an Entra ID tenant (usually a Microsoft 365 tenant) and measures tenant security configuration settings against the MITRE ATT&CK framework using the Entra ID Security Configuration Analyzer. The output is a report telling the administrator what tests passed and what failed. In my case, the first run of Maester said that my tenant failed 42 tests (Figure 1).

On the surface, failing 42 tests seems like a dreadful outcome and it did generate some concern. However, like anything else that measures something against benchmarks, you need to understand what’s being measured, why a configuration is in a certain state, and if the current settings are valid or should be adjusted.

Conditional Access Policies and Break Glass Accounts

If you use conditional access policies to check inbound connections, at least one break glass account should exist to prevent the possibility of policy misconfiguration locking everyone out (this happens – all the time). I’ve written a PowerShell script to check conditional access policies to make sure that they include exclusions for break glass accounts, adding the accounts to policies when necessary.

Unhappily, my script (which runs regularly as an Azure Automation scheduled job) only processes enabled (active) conditional access policies and ignores those that are in the report-only state. The lack of break glass accounts on some policies in report only mode caused Maester to be unhappy (Figure 2).

To make Maester happy, I adjusted the script to update all conditional access policies.

Another fail reported by Maester said that no conditional access policy existed to require multi-factor authentication for guest accounts. Obviously, something odd happened behind the scenes because that exact policy is in place since January 2022.

Use Your Knowledge to Put Tool Recommendations into Context

The point is that you should never accept a recommendation made by software unconditionally. Always be suspicious until the recommendation is proven, just like you should be suspicious of any text created by generative AI. Context is invaluable and tenant administrators know far more about their business and operations than any tool can aspire to learn.

An example is the use of Entra ID License Utilization Insights where Maester reported the same figures calculated by the Entra admin center to say that I have 5 Entra P1 licenses but 42 active B2B users that need these licenses because they use conditional access policies (to mandate MFA, see above). But my tenant is configured to use the monthly active user billing model for premium features and I pay for this usage every month through an Azure subscription. Microsoft has some work to do to get its insights sorted out, and anything built on top of their data will be flawed until the data is corrected.

Good Links to the Graph Explorer and Graph APIs

We’re discussing the V0.1 release of a community project here and some bugs are expected. To be more positive, I like the way that Maester includes links to the Graph Explorer when it’s possible to use the Explorer to patch configurations with a Graph request. An example is where the access granted to directory information for guest account is unrestricted. The recommendation is to restrict access to prevent guest accounts being able to enumerate directory information, which means that guest accounts should have a restricted access role (GUID 2af84b1e-32c8-42b7-82bc-daa82404023b instead of the default (10dae51f-b6af-4016-8d66-8c2a99b929b3).

It’s easy to fix this problem in the Entra admin center, but who can resist the chance to run a Graph request instead of clicking a button? The link provided opens the Graph Explorer with the request to list the authorization policy (Figure 3). This is a GET transaction so it only fetches the data to check, but for extra marks you can add a request body and PATCH the policy. A future version of Maester might do that work for you if the developers don’t think it too dangerous.

Support the Maester Tool!

It would be easy to keep nitpicking but that’s not the right thing to do. Community projects need to be cherished and supported. Things will improve in time as people find glitches to fix and knowledge grows. The important thing is that Maester is a new tool for Microsoft 365 tenant administrators to use to improve their knowledge of Entra ID security features that can make their tenant more secure and harder to compromise. That’s always a good thing, which is why I like Maester.

Make sure that you’re not surprised about changes that appear inside Microsoft 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

OAuth Apps Used to Automate Financially-Driven Attacks

The December 12, 2023 post for the Microsoft security blog covers how “Threat actors misuse OAuth applications to automate financially driven attacks.” The article describes how threat actors use OAuth applications planted in tenants to create virtual machines for crypto-mining, sending phishing email for business email compromise (BEC) attacks, and standard spamming. One of the targeted organizations ran up Azure compute fees of $1.5 million dollars for virtual machine usage.

Microsoft notes that most of the compromised accounts penetrated by attackers did not use multi-factor authentication (MFA). Enabling MFA is one thing. Making sure that the policies are enforced is another. The recent initiative to deploy Microsoft managed conditional access policies to “eligible tenants” might help, even if people still misunderstand and assume that all tenants receive these policies. Eligibility is determined by the presence of the necessary Entra ID P1 or P2 licenses in a tenant. If you don’t have at least Entra ID P1, you can’t use conditional access policies, and the Microsoft-managed policies won’t show up.

Compromised Accounts Create OAuth Apps

In all cases, attackers must compromise an account before they can create an OAuth app in the target tenant. The attacker’s task is easier if the compromised account has permissions, but even if the account is just a regular user account, it’s still useful because the attacker can use it to read directory information. To do this, the attacker must assign permissions to the app and seek consent to use those permissions to access data.

In some cases, tenants allow users to grant permission to apps. It’s best to configure the Entra ID user consent settings for a tenant to remove the ability of users to grant consent and either require administrator approval for all consents or to limit user consent for selected permissions to apps from verified publishers (Figure 1). In this context, the selected permissions are “low-impact,” meaning that they’re usually the permissions needed by users to access their own data but nothing else.

Reviewing App Permissions with Microsoft Defender for Cloud Apps

Tools are available to review the OAuth apps in a tenant. Microsoft Defender for Cloud Apps (now part of Microsoft Defender XDR) offers the ability to review the settings and consented permissions for OAuth apps. It can be surprising to discover how many OAuth apps exist in a tenant. For instance, Figure 2 shows the settings for the Microsoft Tech Community app. When people join the Microsoft Tech Community, they sign in and consent to access. That consent allows the app to read their profile details and email address.

Other apps do much the same thing, including apps used to register people for technical conferences like Microsoft Ignite.

Checking Consent Grants

Microsoft also recommends that administrators review consent grants within a tenant. If you allow users to grant consent for apps to receive some low-level permissions, administrators won’t know about these grants. However, they can check the audit log to find out when apps receive new permissions. I wrote about how to interrogate the audit log to find consent grant events a couple of years ago. Microsoft’s blog prompted me to go back and review the text.

The article contains a script that I’ve refreshed in two ways. First, I updated the use of the Search-UnifiedAuditLog cmdlet to accommodate the change Microsoft recently made to the way that the cmdlet works. That change was unannounced and can lead to situations where scripts that used to work perfectly well now do not retrieve all matching audit events. As Microsoft shows no appetite for reverting to previous behavior, it’s important to check scripts that use the Search-UnifiedAuditLog cmdlet to make sure that they work as expected.

Second, instead of simply returning an app identifier, the script now resolves the identifier into an app name. This can either be the name of a registered app (created in the tenant) or the service principal for an enterprise app. As you can see in Figure 3, it’s obviously easier to recognize an app name than it is to interpret the GUID returned for an app identifier!

The number of permission grants to the Microsoft Graph Command Line Tools app is high. This is the service principal used to hold permissions granted for interactive sessions with the Microsoft Graph PowerShell SDK. Over time, this service principal can accrue many permissions and it’s wise to keep an eye on this aspect and remove permissions (or reset the service principal) if necessary. Also consider securing access to the Graph SDK so that only selected users can run interactive sessions.

You can download the updated script from GitHub.

Attempts to Compromise Accounts Continue

Threat isn’t going to go away. Blocking basic authentication for Exchange Online connection protocols removed some tried-and-trusted methods for attackers to compromise user accounts. Attackers simply changed gear and try other methods to compromise accounts and they will keep on trying until they get in. That’s why it’s so important to use multi-factor authentication with a strong authentication method (like the Microsoft authenticator app or FIDO2 key) to stop attacks. But it’s also important to verify afterwards and make sure that no sneaky OAuth app appears in your tenant.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

KQL and Sentinel are Core Security Components, Even in an AI World

The December 7 post on Microsoft’s security blog is titled “New Microsoft Purview features use AI to help secure and govern all your data.” In reality, the post lays out two truths for Microsoft 365 tenant administrators. First, Microsoft wants to ingest security logs from multiple workloads and applications, including non-Microsoft sources, so that they can apply AI technology to sorting gems of security insight from logs. Although Microsoft doesn’t say so explicitly, I assume that Sentinel is the preferred destination for this data (Sentinel is listed as a key component on the Security Copilot page).

The Need to Learn KQL

Second, while AI will “Empower and advance the work of junior staff” and “alleviate tedious tasks for senior staff” in terms of chasing down potential issues in security data, it seems clear that some level of competence with KQL (Kusto Query Language) is a good thing to attain. Being able to query security logs with KQL, including Office 365 audit data and the Microsoft Graph activity log (preview) is becoming a core skill, even with AI. KQL is something I need to brush up on and improve the queries I can construct (Figure 1), maybe over the holiday period.

A good amount of information about KQL is available online, starting with Microsoft’s documentation. There’s also the “Must Learn KQL” initiative headed up by Rod Trent. Rod is now with Microsoft, but previously I worked with him at Penton Communications. He’s a good guy. Rod makes his KQL material available online and a paperback is also available.

A new book called the “Definitive guide to KQL (for operations, defending, and threat hunting)” is due for publication in March 2024. Let’s hope that the author team has a chance to incorporate topics like Security Copilot in that text.

Security Copilot Licenses

We don’t know yet how much Security Copilot licenses will cost or the licensing requirement. At this point, I assume that only those who use Security Copilot to analyze and interrogate security log data will need licenses, but I have been surprised by twists in Microsoft licensing before. Hopefully, Microsoft will keep things simple and arrive at a reasonable figure for a per-month license.

This raises the question of what is a reasonable price? Given the specialized nature of the analysis and the high value gained by finding security threats faster and more reliability, I don’t know, but I suspect that a Security Copilot license will be more than the $30 charged for Microsoft 365 Copilot. Is $50/month too much? Well, considering how much the salary and benefits for a security analyst are, $600 for an annual Security Copilot license doesn’t seem unreasonable, especially if its capabilities are anywhere close to what Microsoft claims (“Summarize vast data signals into key insights to cut through the noise, detect cyberthreats before they cause harm, and reinforce your security posture.”)

If customers follow Microsoft guidance and ingest data into Sentinel to make the information available to Security Copilot, there’s a bill for Azure log storage to be paid too. Tenants will have to pay attention to optimizing log storage to avoid large charges accruing against their Azure subscription. Obviously, as data from more logs flow into Azure storage, the higher those charges will be.

KQL is Important, Even with AI

I’m sure that AI processes will take on more of the hard work involved in sorting through security logs in the next few years. The key thing to keep in mind is that the AI is a digital helper driven by human directions rather than a source of truth that solves all problems. For the time being, human intelligence and insight will matter more than most AI interactions. And that’s why I’m focusing more on KQL. 

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Microsoft DART Likes the Office 365 Audit Log (Unified Audit Log)

On September 26, Microsoft’s Detection and Response Team (DART, aka the cybersecurity team you never want to meet) published an article on the Security, Compliance, and Identity blog called Forensic artifacts in Office 365 and where to find them. It’s a nice article that captures the standard and optional (requiring extra configuration or licenses) flows of data captured for Azure AD sign-in events, Azure AD admin events, and Office 365 activities (Figure 1). This data is of great help to forensic investigators as they attempt to understand what happened in cybersecurity incidents.

Regular readers of my written work or those who’ve heard me speak at conferences are well aware of my high regard for the Office 365 audit log. It’s a fantastic source of information about what happens inside a tenant and I believe that every administrator should be familiar with how to retrieve information from the audit log. I keep on coming back to the audit log to see what data shows up there for new features like reactions to Teams messages. It’s also my go-to place to find in-depth information about actions that might affect the tenant, like potential illicit consents.

Moving Office 365 Data to a SIEM

The downside of the Office 365 audit log is that data doesn’t stay there for very long. Even tenants with the Office 365 E5 plan have access to only 365 days of information. For Office 365 E3, the audit log only stores 90 days of information. In addition, Office 365 E3 tenants must enable auditing for every mailbox to make sure that Exchange Online sends mailbox events to the audit log. That’s a gap which I hope Microsoft closes soon.

A SIEM is a good place to hold audit data for longer periods. As Microsoft notes, it’s possible to ingest Office 365 audit data into Microsoft Sentinel. Not all data flows through as the connector used to transfer data to Sentinel is particular about the events it chooses, so that’s something to watch. Nevertheless, Sentinel is a good place to keep audit data if you use Azure.

As to other SIEM platforms, many PowerShell examples exist demonstrating how to use the Search-UnifiedAuditLog cmdlet to fetch audit events  (here’s an example). Once you have the data, it’s not hard to send them to a repository. Some SEIMs have more sophisticated ingestion mechanisms. For example, Splunk uses a registered Azure AD app to fetch audit data and bring it to its repository.

Poor Search Performance

I use PowerShell whenever I need to search the audit log. I have never liked the GUI Microsoft built for audit log search. It has always been unwieldly and inflexible, not to mention slow. Its sole benefit is that the GUI exposes some of the important information stuffed in the AuditData payload in audit records.

I was therefore taken aback by the enthusiasm shown about the new Audit search GUI (preview). According to Microsoft, the new GUI offers the following improvements:

• Search jobs initiated via the compliance portal UI no longer require the web browser window to remain open in order to complete. These jobs will continue to run even after the browser window is closed.
• Completed search jobs are now stored, giving customers the ability to reference historical audit searches. These search jobs are presented in the UI, listing the search name, search job status, progress %, Number of results, Creation Time, and Searched by.
• Each admin Audit account user can have a maximum of 10 search jobs in progress at a time.

I tried the new GUI with a very simple search looking for events for a single operation (someone changes a sensitivity label for a document) for the last 27 days. This search took less than three seconds by running the Search-UnifiedAuditLog cmdlet in PowerShell, but required 9 minutes and 24 seconds through the new search (Figure 2). This kind of performance is not usual in my experience.

Here’s the equivalent search in PowerShell:

Measure-Command { [array]$Records = Search-UnifiedAuditlog -Operations ComplianceSettingChanged -StartDate 1-Sep-2022 -EndDate 27-sep-2022 -Formatted -ResultSize 5000 }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 2
Milliseconds      : 470
Ticks             : 24701589
TotalDays         : 2.85898020833333E-05
TotalHours        : 0.00068615525
TotalMinutes      : 0.041169315
TotalSeconds      : 2.4701589
TotalMilliseconds : 2470.1589

Some overhead is expected to create and process search jobs in the background but this degradation in performance is extraordinary when you consider that both methods interrogate the same data source. You have to do more work with PowerShell when an audit search returns events, but anyone who’s worked with the event log will have that process well defined and understood, so the advantage of being able to view event details through the GUI (Figure 3) is probably only appreciated by those unfamiliar with the audit log.

Slow Interfaces are Unusable

The new audit search GUI reminds me about redesign of the content search interface, which also disappointed with its slowness and buggy nature. Microsoft introduced that redesign in May 2021 and it’s still slow. I hope that they manage to do a better job as they bring the new audit search from preview to general availability. If not, I doubt I would ever use the new audit search interface.

Microsoft DART considers that the new interface makes “large-scale data collection much simpler and more reliable.” However, that statement is softened considerably by saying that their “go-to approach here is to use PowerShell to extract the data we need.” I couldn’t agree more.

Learn more about how Microsoft 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

The Long Road to Progress

Sensitivity labels do an excellent job of protecting Office documents, largely because the applications include the necessary code to apply and access encrypted documents. The situation is less successful when dealing with other common business file formats (like protected PDFs). The now-almost obsolete unified labeling client contains an Explorer extension that allows users to Classify and protect files. This approach works for some file types (like the MP4 files generated by Teams meeting recordings), but needs to be tested to ensure that it works and is usable for other kinds of files.

Things would be much better if maintainers of file types incorporated code from the Microsoft Information Protection (MIP) SDK into their products. For example, Adobe PDF is a very common file format used for business purposes. In December 2018, Adobe and Microsoft announced the availability of an integration of MIP with Adobe Acrobat Reader. Essentially, Adobe added code to support the opening of protected PDFs using a plug-in created by Microsoft.

Edge and Protected PDFs

In 2020, Microsoft upgraded the Edge browser to open protected PDFs. This made life easier because Edge can use cached credentials (from accessing other Microsoft 365 apps like OWA or OneDrive for Business) to validate a user’s identity and establish their rights to access protected content.

One issue that continues with Edge is that although it displays a banner to inform the user that they’re accessing a protected PDF, it doesn’t reveal the name of the sensitivity label (Figure 1). By comparison, Adobe Acrobat Reader DC displays the label when it opens a protected PDF (Figure 2).

Considering their tendency to throw the kitchen sink into Edge in terms of new features, it’s a curious omission on the part of the Edge developers.

On small point: since the launch of the MIP plug-in for Adobe, a registry value controls the display of the information bar for sensitivity labels. Originally, it was necessary to have a single DWORD value called bShowDMB set to 1 at HKEY_CURRENT_USER\SOFTWARE\Adobe\Acrobat Reader\DC\MicrosoftAIP to expose the information bar.

For whatever reason, with the latest update, Adobe appears to have moved the value to HKEY_CURRENT_USER\SOFTWARE\Adobe\Adobe Acrobat\DC\MicrosoftAIP. Or maybe the value needs to exist in both locations. My PC currently only has bShowDMB set at Adobe Acrobat\DC\MicrosoftAIP and everything is working.

Issues with Protected PDFs

Although it became less difficult to open protected PDFs, two issues remained:

• Microsoft deprecated the unified labeling client. Its strategy is to build native MIP support into applications instead of depending on a separate client. The unified labeling client is now in maintenance mode.
• Having to download and install a separate MIP plug-in for Adobe Acrobat is a separate administrative operation that users often overlook. This leads to frustration when they can’t access protected PDFs.

Another issue is that you can’t apply sensitivity labels to items stored in SharePoint Online or OneDrive for Business through the browser GUIs. This doesn’t matter so much for Office documents because sensitivity label support is available in the application. However, it means that if you want to protect PDFs, you must apply sensitivity labels using the unified labeling client before uploading the PDFs to Office 365. This action requires users to have Azure Information Protection licenses.

Improving Sensitivity Label Support for PDFs

Help is on the horizon. Three developments are coming together to make protected PDFs easier to generate and use.

• The latest Office Insider build includes the ability to output protected PDFs when saving, exporting, or sharing Office documents with sensitivity labels. The output PDFs inherit the same protection as applied to the source documents. Some gotchas exist, like the need for developers of PDF add-ins to potentially update their code and the inability to retain protection when printing to PDF. Even so, this is a big step forward because it removes the need to use the unified labeling client to apply a sensitivity label to protect PDFs.
• The latest version of Adobe Acrobat Reader DC (version 22.001.20142 and later) bundles the MIP plug-in with its installer, removing the need for a separate installation. The benefit of hindsight is that bundling the plug-in is something that Adobe probably should have done sooner.
• Microsoft 365 roadmap item 93331 (due in preview in June with general availability in October 2022) describes an integration with Adobe Acrobat to allow users to apply sensitivity labels within the application on Windows and macOS. Apparently, this covers the paid-for versions of Acrobat rather than the free reader, but it’s still an improvement. (update: the integration is now available)

While the Office update is the most important, collectively, these changes will make it much easier to create protected PDFs.

Keep up to date with developments like changes in sensitivity labels and Office by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Joins Exchange, SharePoint, and OneDrive

Message center notification MC346909 (March 25) announces the general availability of an update to enable Teams support for the customer lockbox feature (Microsoft 365 roadmap item 86190). Microsoft expects full deployment to complete in late April with GCC availability in June and GCC-High/DOD in September.

Tenants need Office 365 or Microsoft 365 licenses or a Microsoft 365 information protection or compliance add-on to use customer lockbox. If the tenant has already enabled customer lockbox through the Org settings section of the Microsoft 365 admin center (Figure 1), no further action is necessary to add Teams to the set of covered services.

What is Customer Lockbox?

Customer lockbox is a mechanism to control access to user content when Microsoft engineers believe they require access to resolve support incidents. Without customer lockbox (for instance, in an Office 365 E3 tenant), it’s sufficient for Microsoft support to ask the tenant administrator if they can access content like a Word document in a SharePoint Online document library or messages in an Exchange mailbox (see this list of user content). When customer lockbox is enabled, it becomes mandatory for Microsoft to seek approval prior to any access to user content.

Access to user content should not be necessary very often. Most support incidents involve system components or are instances where a feature doesn’t work as it should. In these circumstances, it’s usually possible to replicate the problem and give the reproduction steps to the support engineers to verify and test. Indeed, experienced tenant administrators often attempt to replicate a problem in a development tenant to understand if the issue is specific to a tenant or more general.

Access to user content is problematic. Although tenant configuration and settings are confidential, user content like the documents in a library or conversations in a team channel are much more confidential. They expose the inner workings of an organization and could even reveal secrets that should not out outside the organization.

No one likes the idea of a stranger poking around in their content. Customer lockbox provides reassurance to customers that Microsoft engineers can only do this after tenant administrators give explicit approval for the action. Microsoft must raise a request for approval by the tenant administrators (users assigned the Customer Lockbox Access Approver administrative role can also approve these requests). Each request states a reason why access to user content is necessary and the duration of the requested access (usually four hours). This article explains how to report the membership of Microsoft 365 role groups, including the accounts holding the customer lockbox access approver role.

Figure 2 shows an example of the message sent to seek administrator approval. Customer lockbox is active in my tenant for the last four years. I have never had to report a problem which involved user content access, so I had to copy the example from Microsoft documentation. However, my experience is not typical because I don’t have to deal with many users likely to report problems requiring lockbox access.

Approval occurs through the Microsoft 365 admin center and must be received within 12 hours if the request is not to expire. If granted, Microsoft receives access to the customer content for the requested duration.

Customer Lockbox Doesn’t Cover All Support Data

As I note above, enabling customer lockbox doesn’t mean that every interaction with Microsoft support creates additional paperwork that slows down their ability to resolve problems. Customer lockbox is only involved with incidents where access to user content is absolutely necessary. For example, a sensitivity label protects an Office document, and the user cannot open the document even though the rights assignments inherited from the label should allow this. Hopefully, an administrator might be able to resolve the issue, but if they can’t, Microsoft support should be able to help.

Non-user tenant content required by Microsoft support is not covered by customer lockbox. For instance, last week I used PowerShell to run a message trace for Microsoft support and shared the output with a support engineer. Even though a message trace reveals email subjects, it’s not the same as when an support engineer wants to access user content.

Microsoft Should Make Customer Lockbox Available to More Tenants

It’s nice that Teams user content is now covered by customer lockbox. However, on a more fundamental note, my view is that this should not be an E5 feature. Although valuable, customer lockbox is probably not the kind of feature that convinces an organization to move from E3 to E5 or even purchase an information protection or compliance add-on. It seems like a fundamental protection which Microsoft should extend to tenants at a lower licensing point (E3 at the very least). I hope Microsoft will move to make customer lockbox available to more tenants, but I am not holding my breath.

Learn about protecting Microsoft 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.

Spring Clean Time for Apps Coming Soon

Last year, I wrote about the need to review and clean up Entra ID integrated applications. That article describes how to extract information from Entra ID o a CSV file and use the CSV to create a Microsoft List. To make it easy to access the list, we create a channel tab in Teams. Everything works to identify suspect apps that might need removal. I think that you should perform such a review periodically. It just makes sense.

Another way to monitor potentially suspicious app activity is to review sign in data for service principals. The intention is to identify unrecognized service principals signing into the tenant and figure out what apps are involved. Sign-ins can originate from well-known service principals used by Microsoft apps, third-party apps, or the service principals automatically created by Entra ID when tenants register apps to interact with the Graph (for instance, to authenticate calls made to Graph APIs in PowerShell scripts). Sign-in data for service principals is available through the Entra admin center (Figure 1) and now it’s accessible using the Microsoft Graph List SignIns API.

The reason why this update is important is that access to sign-in data via the Graph makes it possible to download the information for analysis or store it for long-term retention in an external repository. Although you can download sign-in data as a CSV file from the Entra admin center, it’s more flexible to access the information via Graph queries, especially when you want to probe the activity patterns of certain service principals.

Getting Sign-In Data from the Graph

Any application which wants to interact with the Graph requires consent for permissions to access data. In this instance, consent is needed the Directory.Read.All and AuditLog.Read.All application permissions. Delegate permissions can also be used, and in this case the account used must hold an administrative role capable of accessing the Entra ID sign-in logs.

A suitably-permissioned application can issue queries against the SignIns API. To fetch service principal sign-in data, the query executed by the application must use a Lambda qualifier to filter data. Apart from setting a date range to search for sign-in data, the important point is to filter against the signInEventTypes property to select sign-in events for service principals. Here’s an example of a query to fetch sign-in data for between 17:30 and 22:3 on 19 January.

https://graph.microsoft.com/beta/auditLogs/signIns?&$filter=createdDateTime ge 2022-01-19T17:30:00Z and createdDateTime le 2022-01-19T22:30:00Z and signInEventTypes/any(x:x eq 'servicePrincipal')

To test the query (or one which suits your purposes), use the Graph Explorer to see what the query returns.

I wrote a simple PowerShell script (downloadable from GitHub) to fetch service principal sign-in data for the last seven days. A quick summary of the data revealed that many sign-ins came from an app named Office 365 Reports. Curiously, an app used by a PowerShell script that I had posted on GitHub also showed up with 22 sign-ins. The Information Barrier Processor is the app used by Microsoft 365 to check user accounts against information barrier policies to ensure that no one is communicating with anyone when they shouldn’t.

$Report | Group SpName | Sort Count -Descending | Select Name, Count

Name                                         Count
----                                         -----
Office 365 Reports                             369
Graph Microsoft 365 Groups Membership Report    22
Information Barrier Processor                   21
Security and Audit                               5
PS-Graph                                         1

Resolving the large set of sign-ins was easy. The data stored in the list (Figure 2) revealed the service principal to belong to an Office 365 Reporting app originally published by Cogmotive (acquired by Quadrotech and then by Quest Software). I haven’t used the app in years, but the sign-ins kept on coming.

Over time, it’s easy to accumulate crud in the form of service principals installed for one reason or another. Testing an ISV product is a classic example, which is a good reason to always conduct tests in a test tenant instead of the production tenant. Or if you stop using an app, remember to clean up by removing service principals and other app debris that the app vendor might leave behind.

The sign-ins for the app used by the PowerShell script probably exist because I shared a copy of the script with my tenant identifier, the app identifier, and the app secret in place. I quickly replaced the script with a copy containing obfuscated credentials, but failed to change the app secret, meaning that anyone with an original copy could run the code. Now alerted, I removed the app secret. My suspicions were confirmed when a batch of failed sign-ins subsequently occurred for the app. This goes to prove how easy it is to create a potential compromise if you’re not careful.

Removing a Service Principal with PowerShell

You can clean up unwanted service principals with either the Entra admin center or PowerShell. I always have a PowerShell session open, so I chose that route. In this example, we find the object identifier for a service principal using its display name as a filter for the Get-MgServicePrincipal cmdlet. When sure that this is the right service principal to remove, we use the object identifier to remove the service principal with the Remove-MgServicePrincipal cmdlet.

$SP = Get-MgServicePrinicpal -filter "displayname eq 'Office 365 Reports'"

$SP

DisplayName        Id                                   AppId                                SignInAudience     
-----------        --                                   -----                                --------------     
Office 365 Reports 9ac957ae-160b-48d3-9a6f-f4c27acca040 507bc9da-c4e2-40cb-96a7-ac90df92685c AzureADMultipleOrgs 

Remove-MgServicePrincipal -ServicePrincipalId $Sp.id

Adding Context

A list of service principals known to the tenant is a valuable input to a review for unwanted or unnecessary apps holding some form of consent (permissions) to organization data. Adding context to the data by knowing which service principals are actively signing into the tenant makes it easier to prioritize action. The data is there, it’s available, and it’s up to you to decide what to do with it.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Important Microsoft 365 Workloads Respond to Critical Azure AD Events

Microsoft made a critical announcement on January 10 when they revealed that the base Office 365 workloads support continual access evaluation (CAE) for specific Azure AD events. What’s more, Microsoft has enabled this capability for all Microsoft 365 tenants.

Exchange Online, SharePoint Online, and Teams can now accept signals from Azure AD when an administrator:

• Deletes or disables an Azure AD user account.
• Changes or resets the password for a user account.
• Explicitly revokes all refresh tokens for a user account.
• Enables multi-factor authentication for a user account.

The top three actions correspond to highlighted options available at the top of the user account management card in the Microsoft 365 admin center (Figure 1). Multifactor enablement is at the bottom of the card.

In addition, Exchange Online can respond when Azure AD Identity Protection detects that higher risk of compromise exists for a user account.

Administrators can see details of sign-ins which use continuous access evaluation by applying a filter of (Is CAE Token = Yes) in the Azure AD admin portal. Figure 2 shows details of a CAE-enabled session.

Browsing the Azure AD sign-in log is enlightening in terms of understanding the degree of application support for CAE. Although currently limited to applications like OWA and the SharePoint Online browser interface, you’d anticipate that Microsoft will increase coverage over time.

Enlightened Applications

Continuous access evaluation means that the “enlightened” applications learn about changes in user accounts in almost real-time. For instance, if an administrator deletes a user account, the applications remove access immediately instead of waiting for the access token granted as the result of the last successful authentication by the account to expire.

Microsoft says that the use of continuous access evaluation means that “authentication session lifespan now depends on session integrity rather than on a predefined duration.” For example, if an event like a password change occurs to affect the integrity of a browser session where a user is connected to SharePoint Online, instead of waiting for the access token to expire, SharePoint Online will immediately demand that the user re-establishes session integrity by proving their credentials are still valid.

The effect is that users affected by these critical events must either reauthenticate (for instance, using a new password), or lose access to email, documents, calendar, and Teams. This makes it much easier to manage the possibility of data loss in cases like account compromise or the departure of disgruntled employees.

A benefit of continuous access evaluation is that in the case of outages, extended session lifetimes enabled by removing the dependency on the access token as the sole control over accounts mean that people can continue working without needing to revert to Azure AD (see this note about Microsoft’s Azure AD backup service).

Conditional Access Policy Support

While response to critical Azure AD events is available for all Microsoft 365 tenants, those with Azure AD Premium licenses can include continuous access evaluation in the criteria used by conditional access policies to decide to grant or deny user access to applications based on conditions like network location.

Zero Trust in Action

Microsoft talks about the Zero Trust model a lot. An action like enabling continuous access evaluation for critical events in all Microsoft 365 tenants is a practical and useful example of the Zero Trust initiative. Even if you don’t use conditional access policies (something I think all tenants should consider to improve their security posture), the fact that the base Microsoft 365 workloads now respond to critical Azure AD events almost in real time is a very welcome advance.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant. We cover continuous access evaluation in the chapter on Microsoft 365 identities.

Don’t Assume Everything a Computer System Spits Out is the Truth

As Office 365 for IT Pros subscribers know, we publish a new edition annually. Part of the preparation for a new edition is an end-to-end technical review of all content. This happens to make sure that our material is current and accurate. The review picks up issues like dead hyperlinks, unnecessary (some might say verbose) text, and outdated graphics. It’s a good process to keep our authors focused on delivering the best possible book, something that’s only possible because of our ePublishing model.

Office 365 Client App Security

Microsoft 365 applications update GUIs on an ongoing basis. Sometimes it’s just a matter of adding a new option or changing the words on a button. Other times it’s a more fundamental makeover, such as the introduction of a new interface for content searches. Office 365 Cloud App Security (OCAS) is available to tenants with Office 365 E5 licenses. OCAS is a subset of the full Microsoft 365 Cloud App Security product, tailored for Office 365.

Figuring Out Impossible Travel

OCAS analyzes the data ingested from multiple workloads into the Office 365 audit log to identify anomalies and other potential issues. As we reviewed the chapter on reporting and auditing, the technical editor highlighted the need to refresh some screen shots to reflect the new OCAS GUI, which brings us to Figure 1, which shows how OCAS highlights a potential impossible travel activity issue.

In other words, the IP addresses captured by OCAS for client connection events over a certain period originate in multiple countries where it would be impossible for the user to travel between those countries during that time. In this case, the alert flagged interactions from Ireland and the Netherlands within a 99-minute period. It’s possible to fly from Dublin to Schiphol in this time, so that’s probably why OCAS uses this period to test for suspicious connections.

Applying the Human Touch

On the surface, this looks like a problem which deserves investigation to understand if an attacker has compromised the user’s account. In fact, it’s a good example of how human intelligence can quickly make sense of activity which a computer deems suspicious. At first glance, the facts are:

• The user signed in from two different IP addresses within a short period.
• The IP addresses indicate connections from Ireland and the Netherlands.
• In both cases, the application was Teams.

But when we examine the detailed records, we see a continuous set of connections first originating from The Netherlands and then switching to Ireland, all within a very short time (Figure 2). Most of the records are for login events. Some others (not shown here) record SharePoint Online activities like opening a document.

Searching the audit log with the Search-UnifiedAuditLog cmdlet to find the underlying records confirms that the user connected multiple times to work with Teams and SharePoint Online over the period. The IP addresses are correct, the connections valid, so what’s happening? Everything makes more sense when you consider that:

• Teams and its associated applications use Azure AD secure token service (AzureActiveDirectoryStsLogon) logons to validate user credentials. The logged sign-in events all use the token service.
• The tenant is in Microsoft’s EMEA datacenter region, and the Teams service runs in the region.
• The EMEA datacenter region includes datacenters in Ireland and the Netherlands.

Therefore, the most likely explanation is that the Teams client attempted to use its access token to connect. During this process, the server handling the request changed from a server in the Netherlands to one in Ireland. Azure AD captured details of the connections and sent them to the Office 365 audit log where OCAS picked up the information, analyzed the events, and concluded that a potential impossible travel situation exists. As it happens, I know that this is exactly what transpired, but it’s a great example of how tenant administrators need to apply their knowledge of Office 365 and how Microsoft’s datacenter infrastructure operates to assess and resolve a flagged alert.

Administrator in Office 365

Another thing to consider is that OCAS notes that the user is an administrator in Office 365. This doesn’t mean that the account is a tenant administrator. It means that the account holds an administrative role. In this case, the account holds the SharePoint administrator role. Again, when probing details of an incident, check before assuming the worst.

Resolving Issues

This case did not take much to resolve. Other OCAS alerts require substantially more effort to understand and conclude. The point I make is that OCAS is a tool to highlight issues to administrators which deserve some attention. Just because OCAS flags an alert isn’t evidence that a problem exists. Always use human intelligence to validate computer indications when resolving alerts. You’ll get better results that way.

By now, everyone should be convinced that using basic authentication for connections to Exchange Online is a bad idea. Microsoft has been pushing to remove basic authentication for quite a while, with announcements at the Ignite 2019 conference setting the stage. At that time, Microsoft said they would remove support for:

• Exchange Web Services (EWS – following an earlier announcement in July 2019).
• Exchange ActiveSync (EAS).
• IMAP4.
• POP3.
• Remote PowerShell.

The logic for choosing these protocols is that they are the set most exploited by attackers. After clients replace basic authentication with modern authentication for connections, attackers have a lot less attack surface to target.

A Change in Plan

Microsoft’s original plan was to remove support for basic authentication using these protocols in October 2020. The Covid-19 pandemic interfered with the ability of many organizations to do the necessary preparation for the deprecation and in April 2020, Microsoft was forced to push the date out to mid-2021.

Now, Microsoft is changing its approach. The basic principles are:

• Expanding the set of protocols covered in the program.
• Disabling basic authentication when it’s not used.
• Leaving tenants who use basic authentication alone for the moment and giving 12 months’ notice for deprecation when the basic authentication removal program restarts.

Let’s dive into some detail.

Expanded Target Protocol Set

The set of protocols has increased to include:

• MAPI (Messaging Application Programming API): The API Exchange Server is built on.
• RPC (Remote Procedure Call). MAPI over RPC is known as Outlook Anywhere and uses basic authentication. MAPI over HTTP supports both basic or modern authentication.
• OAB (Offline Address Book).
• SMTP AUTH (see below).

Outlook desktop clients (Windows) already consume EWS to access information like free/busy data and MailTips. This change closes off potential vulnerabilities in Microsoft’s own client to align better with the work already done to support modern authentication IMAP4 and POP3 clients. There is no good reason for Outlook clients to connect to Exchange Online using anything but modern authentication. Microsoft is not including AutoDiscover in the protocol set. The logic here is that AutoDiscover only ever informs clients where to go to access user data; the protocol can never access user data, so it is of little use to attackers. Microsoft says that they will consider disabling basic authentication for AutoDiscover in the future, once the battle to eliminate basic authentication for the other protocols is won.

Use It or Lose It

Instead of a big-bang turn-off on a nominated date, Microsoft will disable basic authentication for protocols when tenants do not use this capability “to prevent potential misuse”. Microsoft notes that many organizations don’t realize what protocols are in active use, so they will measure the use of basic authentication within tenants and use that information to disable basic authentication for unused protocols. Tenants will receive a message center notification in the Microsoft 365 admin center 30 days before a protocol is blocked.

Extended Notice Before Blocks Descend

For an undefined period, basic authentication will not be disabled when it is in active use by tenants. Eventually, the period of tolerance for basic authentication will lapse and Microsoft will move into a more active closedown phase. However, Microsoft says they will provide at least 12 months’ notice to tenants before blocking basic authentication for protocols in active use.

SMTP AUTH

SMTP AUTH is the client submission protocol used by applications or devices to submit outbound email to Exchange for processing. Many PowerShell scripts use the Send-MailMessage cmdlet to send messages via SMTP AUTH. As noted in July 2020, Microsoft has already disabled SMTP AUTH for new tenants (don’t these folks send email via PowerShell?) and is now including SMTP AUTH in the overall program rather than handling it separately.

What Happens Next

If your organization uses the affected protocols, you need to build a plan to reduce and then remove the usage for basic authentication. This might involve client upgrades, software changes, and perhaps firmware upgrades to devices which connect to Exchange Online (notably to use SMTP AUTH). You’ll get a 12 month notice of deprecation when Microsoft restarts its basic authentication removal program.

If your organization doesn’t use the affected protocols, this fact will be picked up by Microsoft’s analysis and you’ll receive message center notifications to say that Microsoft is going to disable basic authentication for one or more protocols. Thirty days later, Microsoft will enforce the block. The potential exists that someone might overlook the notification, and in this case, Microsoft says that they are working on a self-service procedure to reenable protocols in the Microsoft 365 admin center. It’s a good idea to enable the integration between the message center and Planner to make sure you don’t miss important notifications.

In some respects, it’s sad that Microsoft has delayed removing basic authentication for vulnerable connection protocols. I suspect that the reason is rooted in analysis of telemetry from tenants around the world which concluded that implementing the block as planned in mid-2021 would be too disruptive. It’s easy to argue that Microsoft should plough ahead and make the change, but the consequences of blocking connections across many unprepared organizations might generate a severe interruption in service. Tenants would be less vulnerable to attack with the block in place, but stopping people from working is perhaps too big a price to pay for a general-purpose service.

Shifting dates like this is a great reminder of the value of a book with updated content to track developments. The Office 365 for IT Pros eBook covers updates so you don’t have to sweat.

Since 2015, the Office 365 for IT Pros team has pioneered the concept of writing an ever-changing book to track developments in cloud technology. We’re now in our seventh edition, and we’re delighted at the response we have received from our readers.

The cloud is a big space and there’s plenty that we don’t cover, even inside the boundaries of the Microsoft 365 ecosystem. With that in mind, it’s great to see the publication of Microsoft 365 Security for IT Pros.

Connections with Office 365 for IT Pros

When you look at its Gumroad.com listing, you might think that Microsoft 365 Security for IT Pros is a sister book for Office 365 for IT Pros. It’s actually an independent production by a group of MVPs led by Michael Van Horenbeeck. Michael was one of the original authors of Office 365 for Exchange Professionals, the name given to the first two editions of what is now Office 365 for IT Pros. Michael learned from our experience, adopted most of the same selling structure as we use, and included the text of our Chapter 24 (Protecting Office 365 content). You could say that the two books are cousins.

One thing they didn’t do is publish a Kindle version of the book. I’m torn on this point. Some people like the Kindle version of Office 365 for IT Pros. We do not because of the way that Amazon deals with technical books.

Microsoft 365 Security for IT Pros Chapters

The chapters in Microsoft 365 Security for IT Pros are:

1. Introduction. Introducing security in the context of Microsoft 365 and Microsoft work in security.

2. Securing Identities. Using Azure Active Directory to secure the identities of Microsoft 365 accounts.

3. Microsoft Endpoint Manager (Intune). How to secure devices connected to Microsoft 365 with Endpoint Manager.

4. Microsoft Defender ATP. How to use Advanced Threat Protection to protect end-user devices.

5. Cloud App Security. How to adopt and use Microsoft’s cloud protection service to gather intelligence and apply policies to protect your organization.

6. Microsoft Threat Protection. Using Microsoft’s unified defense suite to detect and repel attacks against your organization.

7. Microsoft Information Protection. How to protect confidential and sensitive information stored inside Microsoft 365.

The team writing the Microsoft 365 Security for IT Pros book promise monthly updates and use the same year-long subscriber model as we do. I hope they understand the amount of work that’s needed to keep text updated! After five years it’s natural (but still hard at times) for us. Starting off, the workload can come as a surprise. You can keep updated with developments through their website.

Security Important for All

Security is obviously something that anyone with administrative responsibilities for an Office 365 tenant needs to pay attention to. Having some solid advice from professionals working in the space is a great help.

Time Running Out for Old Email Connection Protocols

I’ve heard some people doubting that Microsoft will remove basic authentication from seven Exchange Online mailbox connection protocols. The argument advanced is that customers won’t allow this to happen because removing Exchange Online basic auth connections will be too disruptive. That is, unless they’ve experienced the unique joy of being the victim of an Exchange password spray attack.

Update: The big switch-off date is now October 1, 2022. On that day, Microsoft will begin the final process of disabling Exchange Online basic auth in Microsoft 365 tenants that still use basic auth for email connections.

Update (September 1): Microsoft is granting tenants the ability to get a three-month extension before retiring basic authentication. See this article for more detail. January 1, 2023 is the new drop-dead date.

Disruption will certainly happen if you’re running obsolete clients like Outlook 2010 which don’t support modern authentication. Or if you use POP3 and IMAP4 to connect to fetch messages and the developers of your email client don’t pick up the new OAuth-compliant versions of these protocols. The biggest issue here is likely to be with devices that use these protocols to connect to Exchange to fetch messages as I have no idea how the device manufacturers will approach the upgrade. Other issues exist with applications built with Exchange Web Services where programmers don’t quite know how to move forward (this blog by MVP Ingo Geganwarth might help). Or if you have an old mobile email client which likes to use basic auth with ActiveSync.

Finally, there’s PowerShell… We’ll have to switch to modules which support modern authentication, like the Exchange Online Management module, and upgrade scripts to make sure that authentication still works, especially for scheduled scripts which run without human intervention.

There’s work to be done. Lots of work, but the final goal of eliminating insecure authentication methods from Microsoft 365 is worthwhile. Those who doubt this statement might consider a recent case study by the Microsoft Detection and Response Team (DART), the people who help companies when malicious actors have penetrated networks to create persistent threat.

A Case Study of a Compromised Office 365 Tenant

The case study explains that attackers obtained the password of the Office 365 administrator via a password spray attack. Multi-factor authentication (MFA) was not enabled on this account. Microsoft says that 99.9% of account compromise attacks are blocked with MFA. Attacks like password sprays, which rely on basic authentication, run into a stone wall when an account uses MFA, which is why MFA should be used by as many Office 365 accounts as possible.

Once the attackers penetrated the administrator account, all of the Microsoft 365 tenant was theirs to exploit. They used content searches to find “interesting” information in mailboxes and extracted and moved the information out of the company in preparation for something like a business email compromise attack. Poor auditing of actions like content searches and non-owner access to mailboxes enabled the attack to succeed. Eventually DART cleaned things up and concluded that

• MFA should have been used to prevent the attack succeeding on the administrator account.
• Conditional Access Policies would have helped prevent unauthorized access.
• Auditing should be part of regular operations.
• The only safe option is disallowing legacy authentication altogether. Blocking basic authentication for email is a great step forward in removing legacy authentication.

Hard Data for Account Compromises

Further insight (if needed), comes from an interesting session given at the RSA Conference 2020 called Breaking Password Dependencies: Challenges in the Final Mile at Microsoft featuring Alex Weinert (Director of Identity Security at Microsoft) and Lee Walker (Principal Architect, Microsoft IT). During this session, Microsoft said that about 1.2 million of their cloud accounts were compromised in January 2020. This is only 0.5% of the total user base, but it still points to the level of attack. In effect, an Office 365 tenant with 10,000 accounts can expect to have 50 compromised accounts every month, unless they use MFA, conditional access policies, and block legacy authentication. Although MFA alone blocks 99.9% of the compromises, but only 11% of enterprise users used MFA in January 2020.

Password Spray and Replay Attacks

Microsoft revealed that 480K of the accounts were compromised by password spray accounts (Figure 1), and 99% of password spray accounts use Exchange Online basic auth with IMAP4 and SMTP.

A similar number of accounts were compromised by password replay attacks. People often use the same password for personal and work accounts, so if a password becomes known to attackers because a service is compromised, they might try to reuse that password to attack other accounts belonging to the user. Again, legacy protocols play a big role here, especially the combination of IMAP4 and SMTP. The protocols due to be disabled for basic auth on October 13, 2020 are highlighted in Figure 2. Microsoft says that a 67% reduction in compromises happens for tenants who disable legacy authentication. You can’t eliminate the possibility of attack, but you can make the task of the attacker much harder.

The Need to Eliminate Legacy Email Client Protocols

Looking at the account compromise rate by protocol, you clearly see the need to remove Exchange Online basic auth for email connection (Figure 3). This graph underlines why Microsoft is driving for the October 13, 2020 date (now October 2022).

The session also includes a lot of interesting and useful information about Microsoft’s experience of blocking legacy authentication within their own infrastructure. If you’re involved in the plan to prepare your tenant for the changes coming in October, it’s worth listening to how Microsoft worked through dealing with applications that depended on basic auth during their rollout.

Time to Get Going

It’s possible that Microsoft will come under customer pressure to extend the cut-off date for Exchange Online basic auth connections. I hope they resist. Hard evidence exists that eliminating basic authentication helps enormously to increase resistance against attack. Why would anyone want to remain vulnerable?

Update April 30: Microsoft has announced support for OAuth connections with IMAP4 and SMTP AUTH. POP3 coming soon.

For more reasoned commentary about all things related to Office 365, subscribe to the Office 365 for IT Pros eBook and learn how to keep your tenant secure.

Stop Unwanted People Using Sharing Links Sent for Documents

Announced at session BRK3100 at the Ignite 2018 conference last September and then included in the OneDrive for Business Roadmap update for June 2019, password-protected sharing links are now available across Office 365.

Only for Anyone Links

Before getting too excited, let’s reflect that this feature only work for Anyone sharing links. These are the links that can be used by anyone who has them. Many Office 365 tenants tune the sharing controls for SharePoint Online and OneDrive for Business to prohibit the use of Anyone links because they consider them a security risk. But if your tenant allows Anyone links, you can now protect them with custom passwords. The password protected sharing link feature is available in the SharePoint Online and OneDrive for Business web clients. Block download is available in the OneDrive mobile client.

Sending Password-Protected Links

To begin, select a document and share it. Select “Anyone with the link” as the share. Click Anyone with the link to change the settings. In Figure 1 you can see that a password has been entered and we’ve also selected the option to block the recipient from downloading the document. This forces Office 365 to call the online app to display the content, so it only works for Office documents.

When you’ve updated the settings, click Apply. You should now see that the icons under the link have changed to include a padlock (password protected) and download barrier (Figure 2).

If a sharing link has already been created with a password, you’ll have the chance to update the link with a new password or use the existing password (Figure 3). It’s not a good idea to replace a password on a sharing link unless you update previous recipients with the new password.

Click Send to tell Office 365 to create and send the message with the sharing information. You’ll find the message in the Sent Items folder of your Exchange Online mailbox. When the recipient opens the message, they’ll see that the link will work for anyone with the password. Before they can open the content, you’ll need to give them the password through email, a voice message, SMS, Teams personal chat, or other method. Once they have the password, they can click the link, input the password (Figure 4) and see the content.

Limited Access to Content

In our case, the link we sent was both password-protected and blocked for download. As noted above, if the document is an Office file, Office 365 calls the relevant online app to open it. As you can see in Figure 5, the user is blocked from downloading and printing the file.

Modify Links

If necessary, you can use SharePoint’s Modify Access feature to update sharing links, including the ability to reset passwords in links. You can’t remove a password from a link once it is present.

Password-protected sharing links are straightforward to use. The sole difficulty might be for organizations to embrace the idea that they can permit Anyone links. After all, even if you decide that it’s OK to allow these links, there’s no way to force users to add passwords to the links every time. Perhaps that might be a future feature.

For more information about managing SharePoint Online and OneDrive for Business, read the chapter in the Office 365 for IT Pros eBook.

Multi-Factor Authentication Should Be Enabled for Privileged Accounts

Update: This article describes a script using Graph APIs to generate a report showing the MFA status for accounts and highlights administrative accounts that aren’t MFA-enabled. Given the deprecation of the MSOL module, you should switch to the Graph version.

If, like me, you were impressed by the case laid out in the July 10 2019 blog entitled Your Pa$$word doesn’t matter by Alex Weinert (Microsoft), you might wonder how to take his advice to “turn on MFA” for accounts. The process can take some time and user education because you can’t really enable MFA for “average users” if you don’t prepare them to deal with the resulting challenges, roll out the Microsoft Authenticator app, and so on. And then there’s the ongoing need to find unprotected Azure AD accounts to coach their owners about the wonders of MFA.

Reporting Accounts with Administrative Roles

One immediate step you can take is to clamp down on accounts holding one or more Azure Active Directory administrative roles that are not MFA-enabled. Microsoft has an Azure Active Directory usage and insights report about authentication methods to inform tenants about the accounts that are/are not enabled for MFA and self-service password reset (Figure 1), but it doesn’t highlight accounts holding administrative roles.

We discussed how to create a report of Azure AD accounts and their MFA status in a previous post and we can build on the techniques explored there to construct a PowerShell script to report accounts holding an administrative role that need to be protected with MFA. You can grab a copy of the script from GitHub.

What the Script Does

The script is imperfect and could do with improvement in terms of optimization and error handling, but it works. Here’s what it does.

Azure Active Directory defines directory roles which can be assigned to accounts to allow those accounts to perform specific tasks. In this case, we’re interested in some of the more highly-permissioned roles like Exchange Admin, so we use the Get-AzureADDirectoryRole cmdlet to grab the GUIDs identifying these roles and put them in variables. We then call the Get-AzureADDirectoryRoleMember cmdlet to populate another set of variables with details of the accounts that hold each role.

Write-Host "Finding Azure Active Directory administrative roles..."
$UserAccountAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘User Account Administrator’} | Select ObjectId
$TenantAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Global Administrator’} | Select ObjectId
$TeamsAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Teams Service Administrator’} | Select ObjectId
$ExchangeAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Exchange Service Administrator’} | Select ObjectId
$SharePointAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Sharepoint Service Administrator’} | Select ObjectId

# Find out the set of accounts that hold these admin roles in the tenant
$UserAccountAdmins = Get-AzureADDirectoryRoleMember -ObjectId $UserAccountAdmin.ObjectID | Select ObjectId, UserPrincipalName
$TenantAdmins = Get-AzureADDirectoryRoleMember -ObjectId $TenantAdmin.ObjectID | Select ObjectId, UserPrincipalName
$TeamsAdmins = Get-AzureADDirectoryRoleMember -ObjectId $TeamsAdmin.ObjectID | Select ObjectId, UserPrincipalName
$ExchangeAdmins = Get-AzureADDirectoryRoleMember -ObjectId $ExchangeAdmin.ObjectID | Select ObjectId, UserPrincipalName
$SharePointAdmins = Get-AzureADDirectoryRoleMember -ObjectId $SharePointAdmin.ObjectID | Select ObjectId, UserPrincipalName

The script then calls the Get-MsolUser cmdlet to create a collection of Azure Active Directory licensed accounts (yes, there’s an odd mix of the Azure AD V1 and V2 cmdlets in the script; that’s because I can’t work out how to get MFA information using the V2 cmdlets). Using the MFA report code described here, each account is checked to see if it is MFA-enabled. We then create an array of accounts which are not MFA-enabled. These accounts are checked to see if they hold one of the administrative roles we’re interested in. If an account holds one or more of those roles, we capture its details.

# Extract users whose accounts don't have MFA
$MFAUsers = $MFAReport | ? {$_.MFAUsed -ne "Enforced"}
If (!($MFAUsers)) { Write-Host "No privileged accounts found without MFA protection" ; break}

Write-Host "Checking MFA status for accounts holding admin roles..."
$i = 0
$Report = [System.Collections.Generic.List[Object]]::new() # Create output file 
# Check Admin Roles if MFA not enabled
ForEach ($User in $MFAUsers) {
  $Roles = $Null
  If ($UserAccountAdmins.ObjectId -Contains $User.ObjectId) {
         Write-Host $User.DisplayName "Account holds the User Account Admin role" -ForegroundColor Red 
         $Roles = "Account Admin" }
  If ($TenantAdmins.ObjectId -Contains $User.ObjectId) {
         Write-Host $User.DisplayName "Account holds the Tenant Admin role" -ForegroundColor Red 
         If ($Roles -eq $Null) { $Roles = "Tenant Admin" } Else { $Roles = $Roles + "; Tenant Admin" } }
  If ($TeamsAdmins.ObjectId -Contains $User.ObjectId) {
         Write-Host $User.DisplayName "Account holds the Teams Admin role" -ForegroundColor Red 
         If ($Roles -eq $Null) { $Roles = "Teams Admin" } Else { $Roles = $Roles + "; Teams Admin" } }
  If ($ExchangeAdmins.ObjectId -Contains $User.ObjectId) {
         Write-Host $User.DisplayName "Account holds the Exchange Admin role" -ForegroundColor Red
         If ($Roles -eq $Null) { $Roles = "Exchange Admin" } Else { $Roles = $Roles + "; Exchange Admin" } }
  If ($SharePointAdmins.ObjectId -Contains $User.ObjectId) {
         Write-Host $User.DisplayName "Account holds the SharePoint Admin role" -ForegroundColor Red 
         If ($Roles -eq $Null) { $Roles = "SharePoint Admin" } Else { $Roles = $Roles + "; SharePoint Admin" } }      
 If ($Roles -ne $Null) {Write-Host "User" $User.DisplayName "is assigned the following roles:" $Roles -ForeGroundColor Yellow;  $i++ 
    $ReportLine = [PSCustomObject]@{
       User      = $User.DisplayName
       UPN       = $User.UserPrincipalName
       Roles     = $Roles
       MFA       = $User.MFAUsed }   
   $Report.Add($ReportLine) } #End if
}

Reporting Unprotected Azure AD Administrative Accounts

As the code runs, it generates information about accounts which are not MFA-enabled but hold administrative roles (Figure 2). Apart from anything else, this is a good way to see what accounts hold administrative roles and ask whether they need to hold those roles.

Finally, a CSV file is generated with details of accounts holding Azure AD administrative roles which are not MFA-enabled and exported to a CSV file. Figure 3 shows details of what the file contains as viewed through the Out-GridView cmdlet. It’s easy to pick out the accounts whose security needs to be improved.

As always, we’re happy to hear about other approaches to the problem. Please post your ideas as a comment to this post.

Need more solutions to common Office 365 Admin problems? The Office 365 for IT Pros eBook is packed full of ideas…

Makes Basic Security Recommendations for Office 365

The U.S. CyberSecurity and Infrastructure Security Agency (CISA) “Microsoft Office 365 Security Observations” report issued on May 13 doesn’t offer any new advice to Office 365 administrators about keeping their tenants secure. In fact, anyone who has ever read the Office 365 for IT Pros eBook will think that the CISA suggestions are simple block-and-tackle steps that any competent administrator will already have taken.

But to be fair to CISA, their advice is directed at organizations “transitioning to O365 and other cloud services.” In other words, people who are just getting used to Office 365 and need basic help to secure their tenant. This salient fact didn’t stop some websites coming up with headlines like “Feds warn of Office 365 security flaws” – a classic click bait headline.

Some Words of Basic Advice

Let’s look at some of the issues highlighted in the analysis.

Multi-factor authentication (MFA) not enabled by default for administrator accounts. This is true. It’s also absolutely positive that all administrator accounts should be protected by MFA. However, it’s hardly a flaw because some up-front work is needed to figure out what the second factor will be in the authentication process. An argument could be made that part of the Office 365 tenant setup routine should be to configure MFA for the first administrator account, but it’s better to put some thought into the topic. For instance, is SMS a dependable mechanism or should we use the Microsoft authenticator app? What accounts need protection? (answer: all administrator accounts and sensitive user accounts). What apps support MFA (Office 365 apps do, but what about third-party apps)? In short, preparing for and deploying MFA is a step that well-prepared tenants will take as they deploy Office 365.

Mailbox auditing is disabled. This used to be the case, but Microsoft changed the default for Office 365 tenants last year. In fact, well-managed tenants had made arrangements to enable mailbox auditing for all accounts using PowerShell for years beforehand.

Unified audit log needs to be enabled. This is a very simple one-time operation. I think Microsoft should enable ingestion for all tenants by default, but I don’t think this is an issue that deserves too much attention. High-profile or sensitive Office 365 tenants are likely to use other methods to gather audit information such as Office 365 Cloud App Security or a third-party reporting product (like Radar Security and Audit) that use other APIs to retrieve audit data from Office 365, if only to avoid the known problems in the ingestion of audit data into the unified log (this is just one example).

Password Sync Enabled. It’s absolutely true that care needs to be taken in the configuration and operation of the AADConnect utility used to synchronize on-premises objects to the cloud in hybrid organizations. And then keep updated with patches issued to fix vulnerabilities. The worry expressed in the report is that some privileged accounts might have been compromised in the past when AADConnect wasn’t as careful as it should have been. Regular audits of administrator accounts and the use of MFA to remove a reliance on simple passwords help.

Modern authentication unsupported by older protocols. I continue to be bemused at how many people continue to use email clients based on the antique POP3 and IMAP4 protocols. These clients can’t use modern authentication. As the report points out, Azure Active Directory conditional policies can block these clients connecting and force people to use more secure clients. Alternatively, you can block protocols for an organization with Exchange Online authentication policies.

CISA Recommendations

The report ends up making five relatively simple recommendations:

• Use multi-factor authentication. This is the best mitigation technique to use to protect against credential theft for Office 365 users.
• Enable unified audit logging in the Security and Compliance Center.
• Enable mailbox auditing for each user. [Now on by default]
• Ensure Azure AD password sync is planned for and configured correctly, prior to migrating users.
• Disable legacy email protocols, if not required, or limit their use to specific users.

Implementing these recommendations should take a competent administrator less than a day in total and that’s including making a decision about MFA and planning and testing AADConnect. The hardest piece in the list is the human dimension of how to explain to people that they can’t use their favorite legacy protocol email client to connect to Exchange Online.

What’s Missing

A large number of relevant steps that should be taken to protect organizations after they move email to the cloud are missing from the report. What’s curious is that anyone who has any experience of using Microsoft Secure Score to analyze an Office 365 tenant will understand why these steps are necessary, which then begs the question why the report’s authors failed to cover these points.

For instance, configuring Exchange Online Protection to protect against malware isn’t considered, nor is the need to check users auto-forwarding to remote domains. The latter point is bad for two reasons: first, it allows potentially sensitive information to go outside the tenant; second, hackers often plant rules to forward email to learn how an organization works before they execute an impersonation attack. There’s no discussion about how to control mobile devices connecting to the tenant either.

To create a more balanced view, a more comprehensive report would have incorporated aspects of Office 365 that don’t exist on-premises. Office 365 Message Encryption (available for all Office 365 E3 and E5 tenants), which enables out-of-the-box message encryption to any recipient, is one example. Office 365 Sensitivity Labels protect sensitive information in both email and documents, even if the information leaves the tenant. Data Loss Prevention is different in Office 365, and its policies can enforce encryption too. And then there’s lots of things that can be done with Office 365 Advanced Threat Protection to ensure that Exchange Online is better protected than its on-premises counterpart.

The lack of coverage (even a brief mention) of the features that can be exploited after an organization moves to Office 365 is a flaw in the report. If you want to make observations about the security of a system, you must consider the entire picture.

Consultants to Blame?

Perhaps the most worrying statement in the entire report says that: “The organizations that used a third party have had a mix of configurations that lowered their overall security posture (e.g., mailbox auditing disabled, unified audit log disabled, multi-factor authentication disabled on admin accounts). In addition, the majority of these organizations did not have a dedicated IT security team to focus on their security in the cloud. These security oversights have led to user and mailbox compromises and vulnerabilities.” In other words, third-party consultants don’t know how to secure Office 365 (especially Exchange Online). It sounds like a failure in due diligence during the selection process when organizations set out to find Office 365 expertise to help them move to the cloud. That’s pretty serious. Hopefully, it only happened in the organizations CISA interviewed for the report.

In summary, there’s some value in the report but it’s very limited when it comes to the complete spectrum of Office 365 apps and services. CISA looks at some aspects of keeping email secure after a migration to Exchange Online but ends up by only scratching the surface of what can be a very complex subject.

Need help addressing the issues raised in the CISA report? Look in the Office 365 for IT Pros eBook and read Chapter 3 (Identities and Authentication), Chapter 21 (Reporting and Auditing), Chapter 4 (Managing Office 365), Chapter 5 (Exchange Online), Chapter 17 (Protecting Email traffic), and topics spread across other chapters

Reduced Confusion as Everyone Waits for Native Support in Office Clients

As is the nature of the Microsoft cloud, the preview version of the Azure Information Protection client (unified labeling edition) has been replaced by the generally available version, now available for download and deployment. Microsoft’s April 16 announcement on the topic was upbeat but I still find considerable confusion in the field about labels, Azure Information Protection, Office, encryption, and rights management. Let’s see if we can clarify the situation.

Rights Management

Rights management is the technology that allows content owners (authors) to protect documents and files by stamping them with a template. The template defines the rights given to recipients to interact with the content such as the ability to edit or print. Rights management is automatically enabled for all Office 365 E3 and E5 tenants.

Azure Information Protection

Azure Information Protection (AIP) is a suite of technology built by Microsoft to control and help secure email, documents, and files. Reflecting their original name of “classification labels,” AIP labels are used to classify material inside or outside Office 365 with different degrees of sensitivity to reflect the confidentiality of the content. Labels are associated with rights management templates but also include other features like content marking. Labels used for the most sensitive information are likely to invoke encryption to protect the information against unauthorized access. AIP labels and templates are managed in the Azure Information Protection blade of the Azure portal. An AIP license is needed to assign AIP labels to files.

Office 365 Sensitivity Labels

Sensitivity Labels are like AIP labels except that they are managed through the Security and Compliance Center. Both sets of labels share a common base in rights management and if a tenant started with AIP labels, they can migrate the set of AIP labels to become sensitivity labels and thereafter continue managing the labels through the Security and Compliance Center.

Sensitivity Labels are designed to protect content like email and documents stored inside Microsoft 365. Office 365 E3 and E5 plans include the licenses to use sensitivity labels, including the ability to encrypt email and documents. Figure 1 shows an Outlook message protected by a sensitivity label. You can also see the protection bar, which shows the current label applied to an item, and the sensitivity button, to expose the set of labels available to the user.

Although Exchange Online, SharePoint Online, and OneDrive for Business support sensitivity labels today, it will take some time before sensitivity label support is picked up in other workloads, like Teams.

AIP Client (s)

Two versions of the AIP clients are available. The standard version reads its policy and label information from the Azure portal. The unified labeling version reads equivalent information from the Security and Compliance Center. Both versions integrate with the Office desktop applications. You should use the AIP unified labeling client with Office 365, making sure to use the latest version whenever possible.

If you see a Protect button in the Office desktop apps, you know you’ve installed the older version of the AIP client. The unified labeling client installs a Sensitivity button (as shown in Figure 1).

Although the unified labeling version of the AIP client is not quite as functional as the older client. Microsoft expects it to reach close to feature parity with its older counterpart by the end of 2019. Microsoft’s blog post also makes the important point that “going forward new features will be included in the Azure Information Protection unified labeling client whereas we’re not planning to add new features to the Azure Information Protection client”. In other words, future development efforts are focused on the unified labeling version, so tenants starting deployment projects today are strongly advised to use this version.

Encryption

One of the big features of rights management templates is the ability to protect content through encryption. The keys used for the encryption can be tenant-provided (BYOK or HYOK) or Microsoft-managed (MMK). In either case, the AIP client is responsible for encrypting content after an AIP or sensitivity label is applied to a message, document, or file. This is why you need to deploy AIP clients to workstations.

Native Support

It’s obviously inconvenient to have to deploy yet another client to user workstations. To make things easier, Microsoft is building native support for sensitivity labels (and encryption) into the Office ProPlus (click-to-run) desktop apps and the Office Online apps. Office mobile apps (Word, PowerPoint, Excel) also support the application of sensitivity labels today. Outlook Mobile can read protected content and will be able to apply sensitivity labels to new messages soon.

When the Office apps include native support for sensitivity labels, you won’t need to deploy the AIP client to get this functionality unless you intend applying labels to content stored outside Office 365, in which case you need an AIP license (available in P1 and P2 plans and as part of the Enterprise Mobility + Security suite or Microsoft 365 Enterprise plans).

Summing Up

Most organizations have a mixture of content that needs to be protected inside and outside Office 365. The unified labeling version of the AIP client delivers this functionality today. In the future, native support in the Office apps will create a more integrated solution for Office content, but you’ll still need to deploy an AIP client to handle content stored in file servers and other non-Office 365 locations.

Still confused abut AIP, labels, encryption, and Office 365? We suggest you read Chapter 24 of the Office 365 for IT Pros eBook where this topic is covered in detail.

New Consoles Turn Up in Office 365 Tenants

Previewed in January 2019, this week the new Microsoft 365 Security Center and Microsoft 365 Compliance Center have turned up in Office 365 tenants. The new consoles integrate different components from across the Microsoft 365 suite and will eventually replace the Office 365 Security and Compliance Center (SCC). Use https://compliance.microsoft.com to access the Microsoft 365 compliance center and https://security.microsoft.com for the Microsoft 365 security center, or click the Security and Compliance links now available in the Office 365 Admin Center.

Fit and Finish Needed

Although deemed generally available by Microsoft, the new consoles need some fit and finish to become fully functional. Many options in the Compliance Center take you back to the SCC. For example, you must use the SCC to create new supervision policies or manage sensitive information types. There’s no trace of the Office 365 audit log or content searches either. However, you can manage retention and sensitivity labels and create and apply policies for these labels in the new center (but not a retention policy that applies a default retention setting to one or more locations).

The new centers share the same design language as the Microsoft 365 Admin Center. Screen layouts are less bulky and clearer than in the SCC, so they’re a little easier on the eye. Some options (like Alerts and Classification) appear in both consoles. Monitoring and Reports is also a common option, but you see different data for compliance than you see for security.

Split Responsibilities

Apart from integrating other Microsoft 365 components alongside Office 365, dividing security and compliance into separate consoles allows Microsoft to have different access roles to control who can use the consoles. If you run a small tenant when the only administrative role used is a global administrator, the division in responsibilities won’t make any difference to you, but in larger tenants, being able to assign precise administrative responsibilities is a good thing. We therefore have roles like the Security Administrator and Compliance Administrator (see this page for details).

Impact on the Office 365 for IT Pros eBook

As noted above, Microsoft needs to do some work to bring the new consoles up to scratch so that they can phase out the Office 365 Security and Compliance Center. We hope that Microsoft fixes the problems that afflicted the SCC during this process, such as the many warning messages that something couldn’t be done because some ill-defined and unknown quota had been exceeded.

For the moment, the Office 365 for IT Pros writing team will continue to focus on the SCC and keep a watching brief on developments in the new consoles. Once everything is ready, we will switch our coverage to the Microsoft 365 consoles and update whatever is needed (screen shots etc.) across a range of chapters.

Being able to respond to changes like this as they’re rolled out by Microsoft is one of the charms of a eBook. The rate of change in Office 365 sure doesn’t make live easy for printed books.

Reducing Account Compromises for Exchange Online

Last October, Microsoft introduced the ability for Office 365 tenants to disable basic authentication for Exchange Online using protocol authentication policies. A recent tweet from Alex Weinart, a Group program manager on the Azure Active Directory team said that disabling basic auth reduces the account compromise rate by 67%. This is more than enough evidence for anyone running an Office 365 tenant to disable basic auth now.

Alex’s tweet also pointed to an interesting post called Discovering and Blocking Basic Auth that gave further evidence for the case against basic auth, especially for tenants who still support really old protocols like IMAP4 and POP3.

Why Do People Still Use Old Email Clients?

I don’t quite know why people still use IMAP4 and POP3 clients. Both protocols originate in the early days of email when the world and the internet were safer places and attackers didn’t seek to piggyback on top of protocols with brute-force and password spray attacks.

The simple fact is that more modern and safer email clients are available. Clients that support modern authentication include OWA for browsers and Outlook mobile for Android and iOS. People using Outlook for Windows should be forced to use modern authentication. Apart from personal choice (“I really like using the old Thunderbird client”), no good reason exists to support the use of old and insecure clients. The bottom line is that if you move people to safer clients, you can disable the IMAP4 and POP3 protocols completely to close a big fat hole in your tenant’s defenses.

Exchange Web Services

Although it can also use basic auth, Exchange Web Services (EWS) is in a different category to IMAP4 and POP3. EWS is used by the Outlook for Mac client and it’s also used by backup and migration products to stream Exchange Online data from mailboxes (backup) or import information into mailboxes (migration). It’s also possible that EWS is used by other third-party products. Overall, it’s unlikely that you can block EWS any time soon.

Understand and Manage Connection Protocols

The post about discovering and blocking basic auth makes two excellent points. First, you should understand what protocols are being used to connect to Exchange Online mailboxes in your tenant. If you don’t know who uses what protocols, you won’t be able to plan to manage the phase-out or control of protocols using basic auth.

Second, although all important user accounts should be protected by MFA, Azure Active Directory conditional access policies are a very flexible and convenient way to restrict basic auth connections to the lowest possible set, providing that is, if you’re willing to pay for Azure AD Premium licenses (which also enable other useful features such as Office 365 group expiry and naming policies). As the post reminds us, “Last year, we added the ability to block legacy authentication in conditional access” and goes on to explain a scenario where IMAP4 connections are restricted to specific IP addresses.

The post also points to another article describing how to use conditional access policies to block basic authentication. Given the world of threat that we live in and the number of attacks that flow in a continuous stream against Office 365 tenants, you should at least ask the question if you should deploy such a policy (perhaps even to a select group of users or client platforms) to eliminate or reduce the risk posed by basic authentication in your tenant. It’s the right thing to do.

For more information about identities and authentication in Office 365, read Chapter 3 of the Office 365 for IT Pros eBook.

Luring the Unwary into Clicking an Attachment

The growing popularity of cloud services makes it common to receive documents for eSignatures from services like DocuSign or Adobe Sign. Attackers note trends like this and try to exploit the tendency of humans to accept things on face value, which is the basis of this phishing attempt.

The attack is relatively crude as the signs that the message is false are pretty obvious. First, no respectable eSigning service would send messages from a public email service like bluewin.ch (run by SwissCom in Switzerland). Second, the email address to the left of the domain is obfuscated. (In this case, the address is microsoftexchange3297e09615bc6ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109e@bluewin.ch).

Seeing an address like this is suspicious because there’s no reason for a legitimate service to disguise their email address in customer communications. For example, DocuSign uses dse@docusign.net for its notifications). Further examination of the message header with the useful Message Header Analyzer (MHA) add-on for Outlook didn’t reveal anything to make me believe that the message was valid.

Examining the Link

The next thing is to look at its payload. The user is asked to click a link to see a PDF document. The reader is conned into believing that the link will take them to OneDrive (using a blurry graphic), but it really leads to digitaloceanspaces.com. There’s no need to go any further to prove that this message is a phishing attempt because no valid communication would signal that it comes from OneDrive and go to a developer site.

Reporting Phishing Messages

If you receive a message like this, you can report it to Microsoft with Outlook or OWA. Microsoft analyzes reported messages to understand the techniques used by attackers to bypass anti-malware checks such as Exchange Online Protection. The intelligence gathered is used to improve the checks.

Given the volume of spam and malware (53.49% of total email volume in September 2018), some phishing messages will always get through. Here are two other examples of recent phishing attempts: “Encrypted file from OneDrive” and “Retrieve pending messages for domain.”

Office 365 includes good out-of-the-box protection, but admins need to understand how to use Exchange Online Protection and users need some help to understand how to detect any bad stuff that arrives in their inboxes.

The array of anti-malware checks and tools available in Exchange Online Protection and Advanced Threat Protection for Office 365 are described in Chapter 17 of the Office 365 for IT Pros eBook. Because I read Chapter 17, I knew what to look for in the bad message.

Encryption for Exchange Online Autosignatures

When I wrote about the effect of encryption on ISV autosignature products, I made the point that the Exchange transport service can apply autosignatures (disclaimer text) to outbound messages with a rule even if the messages are encrypted. This is because Exchange uses rights management super-user permissions to decrypt messages, apply the disclaimer, and then encrypt them again for final delivery.

Questions flowed in to know if it is easy to create a transport rule (aka mail flow rule) to apply an autosignature like those generated by the ISV products. The answer is that you can, but it takes some effort, especially if you want to use nicely formatted HTML text in the autosignature. The UI in the Exchange Admin Center to create and manage transport rules isn’t very accommodating when it comes to inserting complex formatted text. However, with persistence, it’s possible to create nicely formatted autosignatures (see the Exchange documentation for some examples, including how to insert a graphic file like a logo in an autosignature).

Apart from the difficulty of editing the text used in autosignatures applied by transport rules, the most common complaint is that rules stamp all messages, including replies, so you end up with multiple autosignatures in a mail thread. This is true, but it’s easy to build an exception into the rule so that the autosignature is applied once.

Once you’ve built a transport rule to apply an autosignature, you can combine it with other rules to protect messages sent to all or some destinations by applying a rights management template, including the special Encrypt-Only or Do Not Forward templates.

An Example of Encrypted Email

An example is always helpful. The screenshot below shows a protected message received by an Outlook.com user. The message has an autosignature applied by a transport rule. The text of the autosignature is inserted into the message content even though the message is protected. Some Azure Active Directory elements (like the first name, last name, phone number, etc.) are used in the autosignature. The phone number is blank, meaning that it hasn’t been populated for the user (more on this below).

The relevant extracts from the transport rule (using Get-TransportRule) are shown below.

ExceptIfSubjectOrBodyContainsWords            : {This message is the property of Redmond and Associates}
ApplyHtmlDisclaimerLocation                   : Append
ApplyHtmlDisclaimerFallbackAction             : Wrap
ApplyHtmlDisclaimerText                       :

Redmond and Associates

This message is the property of Redmond and Associates If you receive this message in error, please delete it immediately and inform us at +353 1 991 17463 about its delivery.
%%FirstName%% %%LastName%%
Phone: %%PhoneNumber%%
Email: %%Email%%

The exception in ExceptIfSubjectOrBodyContainsWords is important because it stops the autosignature being inserted into replies.

Why Use Third-Party Autosignature Products?

If it’s relatively straightforward to use a transport rule to insert autosignatures, including for protected email, why do people buy and use third-party autosignature products? The biggest reasons are flexibility and ease of use. The third-party products make it much easier to build and deploy attractive autosignatures to targeted sets of users (or the whole company) without having to grapple with the Exchange Admin Centre UI or PowerShell. Much as I like PowerShell, using it to edit HTML is not a rewarding experience.

Organizations that need to change autosignatures frequently (for instance, to advertise events) or deploy a range of different autosignatures to different groups within the company will find it easier to use specialized autosignature products. The downside, as I pointed out in the Petri.com article, is that server-side processing by these products cannot deal with protected messages. A client-side add-in must inject the autosignature into a message before encryption is applied by the client.

Directories

A word on directories… No centrally-managed autosignature will work unless the directory it’s based on holds accurate information. Make sure that your Azure Active Directory is updated with valid information for any of the attributes (like address or phone number) used by autosignatures.

For more information about transport rules, see Chapter 17 of the Office 365 for IT Pros eBook.

Exchange Online Makes It Easier to Identify Problematic Sessions

Anything that helps Office 365 tenant administrators to track attempted or actual hacks is a good thing. Microsoft’s January 4 post telling us that Exchange Online mailbox and admin audit records now include a session identifier is an example of a small but useful change. I don’t need to repeat the description of what the change is as that ground has been well covered by the original post and the many duplicates that invariably appear to repeat the information given by Microsoft. But what hasn’t been explained is how to use the session identifier in a practical sense. Let’s try here.

Office 365 Audit Log

The first thing to know is that Exchange mailbox auditing must be enabled for any records to be captured. Auditing is enabled by default for Exchange Online, but it’s always wise to check. The second thing is that a tenant must also enable the ingestion of records from workloads into the Office 365 audit log. This is a one-time action.

Once enabled, audit data from Exchange flows into the audit log. Records show up roughly 15 minutes after an event happens. The delay is because of the need to gather data and pass the records through the normalization process to transform Exchange data into Office 365 audit data before ingestion into the log.

Audit records remain in the audit log for 90 days (for accounts with Office 365 E3 licenses) or 365 days (for those with Office 365 E5 licenses). Once the retention period elapses, Office 365 removes the audit records from the log. If you want to keep audit data for longer, you need to invest in a third-party product such as Quadrotech’s Radar for Security and Audit.

Looking for Audit Records

You can use the Audit log search functionality in the Microsoft 365 Compliance Center to look for Exchange activity, and then examine details of the records. As shown below, the session identifier is among the properties revealed when you click the More information link when viewing an audit record.

Understanding AuditData

Many of the interesting properties captured in an Office 365 audit record, including the session identifier, are held in a JSON-formatted property called AuditData. It’s difficult to track all the actions that occur within a specific session using the SCC interface and the better approach is to use the Search-UnifiedAuditLog cmdlet to find relevant records and examine what they hold.

However, because the session identifier is tucked away within the AuditData property, we must convert the JSON data before we can look at the session identifier. The Search-UnifiedAuditLog cmdlet includes a SessionId parameter, but it has no relevance here as it does not filter records based on the Exchange session identifier.

Extracting and Reporting Audit Events

The process to start tracing the events belonging to a session are therefore:

1. Find the audit records for the relevant period and filter them to extract the events generated by Exchange.
2. Extract the information held in the AuditData property for each record.
3. Report what we find.

This PowerShell code is based on an example found in the reporting and auditing chapter in the Office 365 for IT Pros eBook. You’ll notice that some of the MailboxLogin records have no session identifiers. This is because these are PowerShell sessions that use basic authentication to connect rather than sessions generated by Exchange clients like OWA or Outlook. Only sessions that use modern authentication have their session identifiers recorded.

[array]$Records = (Search-UnifiedAuditLog -StartDate 4-Jan-2019 -EndDate 5-Jan-2019 -ResultSize 1000 | ? {$_.RecordType -like "*Exchange*"})
If ($Records.Count -eq 0) {
   Write-Host "No Exchange audit records found." }
 Else {
   Write-Host "Processing" $Records.Count "Exchange audit records..."
   $Report = @()
   ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      $ReportLine = [PSCustomObject]@{
           TimeStamp   = $AuditData.CreationTime
           User        = $AuditData.UserId
           Action      = $AuditData.Operation
           Status      = $AuditData.ResultStatus
           SessionId   = $AuditData.SessionId
           Mailbox     = $AuditData.MailboxOwnerUPN }
      $Report += $ReportLine
  }}
$Report | Sort SessionId, TimeStamp | Format-Table Timestamp, User, Action, Status, SessionId -AutoSize

TimeStamp           User                                Action       Status    SessionId
---------           ----                                ------       ------    ---------
2019-01-04T09:18:02 Administrator@office365itpros.com   MailboxLogin Succeeded
2019-01-04T18:12:46 Administrator@office365itpros.com   MailboxLogin Succeeded
2019-01-04T18:39:51 Tony.Redmond@office365itpros.com    MailboxLogin Succeeded 1229a1b9-61fc-46f4-960a-84323c91cfc2
2019-01-04T18:49:48 Kim.Akers@office365itpros.com       MailboxLogin Succeeded 1f6d382a-a2d2-4875-a6d1-264120f4392e
2019-01-04T18:51:35 James.Ryan@office365itpros.com      MailboxLogin Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:51:55 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:34 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:35 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:54:47 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:37 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T19:00:15 James.Ryan@office365itpros.com      SendAs       Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T15:36:51 Tony.Redmond@office365itpros.com    MailboxLogin Succeeded 85808ea9-a43d-4221-9338-584c4717f740

Our code works, but it outputs events from all the Exchange sessions in the chosen period. We can improve things a tad by filtering out anything but the records belonging to the session we need to examine. It’s easy to do this by adding a prompt to allow the user to input a session identifier (if they’re smart, they will cut and paste this from a record displayed by the compliance center).

$Session = (Read-Host "What session id to look for")

And now we adjust the code to process the records so that we only output those for the chosen identifier.

If ($Records.Count -eq 0) {
   Write-Host "No Exchange audit records found." }
 Else {
   Write-Host "Processing" $Records.Count "Exchange audit records..."
   $Report = @()
   ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      If ($AuditData.SessionId -eq $Session) {
         $ReportLine = [PSCustomObject]@{
           TimeStamp   = $AuditData.CreationTime
           User        = $AuditData.UserId
           Action      = $AuditData.Operation
           Status      = $AuditData.ResultStatus
           SessionId   = $AuditData.SessionId
           Mailbox     = $AuditData.MailboxOwnerUPN }
        $Report += $ReportLine}
  }}

The output now includes only the records for the chosen session, sorted in time order:

TimeStamp           User                                Action       Status    SessionId
---------           ----                                ------       ------    ---------
2019-01-04T18:51:35 James.Ryan@office365itpros.com      MailboxLogin Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:51:55 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:34 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:35 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:54:47 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:37 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T19:00:15 James.Ryan@office365itpros.com      SendAs       Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91

It’s pretty clear from the audit log that someone logged into the James Ryan account performed a series of hard deletes (permanent removal of mailbox items) in quick succession followed by a mail send. Now we know what happened, we can look at the individual audit records to discover which items were removed from the mailbox. That takes a little more work, but it’s relatively easy because we have the relevant audit records that contain the information.

For more information about the Office 365 audit log and many practical examples of how to use it to generate reports about different tenant activities, see the reporting and auditing chapter in the Office 365 for IT Pros eBook.

The Scourge of Bad Passwords

Bad passwords for Azure Active Directory accounts are those that are easy to guess, overly simple, or common. “Password123” is a good example of a password that you wouldn’t like to see someone using, especially if they use the same password for multiple sites and so expose themselves to the dangers of being pwned, which is when the bad guys retrieve a username and password combination from a compromised site and use the pair to do some harm (see this article for how to check that Office 365 accounts have not been pwned).

Custom Banned Passwords

Azure Password Protection, a feature of Azure Active Directory, does its bit to eliminate bad passwords by maintaining a global banned password list generated by observing how password are created and compromised across the breadth of Microsoft’s cloud properties. In November, Microsoft added the ability for a tenant to add a set of custom banned passwords to the list, such as the name of the company, trademarks, or brand names. The feature is in preview, but it seems like such a simple and good idea that it should find its way into general availability soon and then become part of the norm for Azure Active Directory.

To configure custom banned passwords, go to the Azure Active Directory portal, select Authentication Methods, and then Password Protection. As shown below, you then enter a list of custom words, choose to enforce the list, and Save.

Immediately, Azure Active Directory includes the custom words in its validation of changes to user passwords. As explained in Microsoft’s article, “the banned password list matches passwords in the list by converting the string to lowercase and comparing to the known banned passwords within an edit distance of 1 with fuzzy matching.“

Testing a Banned Word

As a test, I signed into a user account and went to their Office 365 settings to change the account password. In this case, “England” is a word on the banned list, and I entered “England2018!” as the new password. At first glance, this is a strong password because it has a mixture of uppercase and lowercase letters, some numbers, and a special character. But because the new password matched a banned word, Office 365 rejected it and told the user to choose a password that’s harder for people to guess.

The Need for User Education

At this point, the user is probably a tad bemused because they have done what they think is the right thing to create a good password, so they’ll probably call the help desk. User education and information needs to be part of the introduction of features like this, unless your help desk likes to be swamped with calls.

Licensing

Using the global banned password list is free for cloud-only Office 365 user. Things get a little more interesting (potentially expensive) when you have synchronized on-premises users or want to use custom banned words with cloud-only users. On-premises users need an Azure AD Premium license, while cloud-only users need an Azure AD Basic license to use custom words. Office 365 comes with an Azure AD Free license, but the need to upgrade is probably not an issue for the enterprise customers to which a feature like this is most useful as it’s likely that they have Enterprise Mobility and Security licenses to cover the requirement.

See this blog by hosting guru Oliver Moazzezi for information about how to integrate on-premises Active Directory with Azure Password Protection. Further in-depth coverage is also available in the blog of MVP Brian Reid.

Not a Magic Bullet

Features like this are not a magic bullet against hacker attacks. Instead, they are individual bricks in a wall of preventative measures that an Office 365 tenant can erect to limit the attack surface for hackers. Disabling basic authentication for Exchange Online to reduce the effectiveness of password spraying attacks is another example. Ensuring that high-profile users and all administrator accounts use multi-factor authentication is yet another.

The point is that hackers don’t stop thinking about how they can break into systems. Office 365 tenant administrators need to keep raising their game too as otherwise their tenant will eventually be compromised.

Identities are covered in depth in Chapter 3 of the Office 365 for IT Pros eBook. And then you’ll probably want to read Chapter 4 to brush up on Office 365 management.

S/MIME and the Unified Labeling Client

One of the interesting aspects of the latest release of the Azure Information Protection (AIP) client  (version 1.41.51.0) is its ability to use an existing S/MIME deployment instead of cloud-based rights management to sign and encrypt email.  The integration is only supported for the click-to-run version of Outlook 2016 for Windows.

The idea is that you can create a custom configuration for Outlook to call S/MIME instead of the normal rights management templates to encrypt an outbound message (read the online instructions). The custom configuration associates an S/MIME action (sign, encrypt, or both) with an AIP label. When the user applies the label to a message, the AIP client updates the message properties with the label metadata and applies whatever S/MIME action is defined.

The idea is not to replace rights management with S/MIME. Instead, it’s to help a small group of customers who have invested to deploy an S/MIME infrastructure. The custom AIP configuration does nothing to help customers manage S/MIME; it simply applies the S/MIME protection if it is available and functional.

Not for Most Office 365 Tenants

Although this feature proves the flexibility of the AIP client, I don’t think it is of much interest to the majority of Office 365 tenants. Here’s why:

• The solution only works for Outlook for Windows.
• Cloud-based rights management is built into and enabled for every Office 365 E3 and E5 tenant. You don’t have to do any work to encrypt messages with Outlook and OWA (or read those messages on any email client).
• The advent of Office 365 sensitivity labels, which will work for Office applications (Windows, Mac, and Online) in addition to email, makes rights management even more valuable. It’s not hard to see how Microsoft will extend coverage of sensitivity labels to other Office 365 data (like Teams conversations or channels) in the future.
• Rights management makes it easy to protect messages with transport rules.

So, a nice feature if you use S/MIME and have invested in that technology – but maybe it’s time for you to think about using something more modern and functional to protect more than just email?

To read more about sensitivity labels, rights management, and encryption, go to Chapter 24 of the Office 365 for IT Pros eBook.

Sensitivity Labels are a Game Changer

Today’s Petri.com post discusses the use of Microsoft 365 sensitivity labels through an updated set of Office desktop applications coming soon. A previous post reviewed the migration from Azure Information Protection (AIP) labels. Of course, you can create and deploy sensitivity labels to protect Exchange and SharePoint content without going anywhere near AIP. In the long term, AIP labels are only needed if you want to protect content that isn’t stored inside Office 365.

The important point is that AIP labels and sensitivity labels share a common foundation in the Azure Information Protection service and the set of rights management templates published through that service. Both update the same file metadata and both use the same permissions.

Rights management has been around for a long time. I think the technology got a bad rap because it was deemed complex and unwieldy.  Sensitivity labels change the dynamics because they are easy to create and publish, and easy for users to apply to Office documents stored inside SharePoint and to email sent by Exchange Online. For these reasons, sensitivity labels will make protection through rights management and encryption a daily part of Office 365 life.

Rights and Permissions

Protection means that a user cannot access content unless they have the rights to do so. Furthermore, once a user accesses content, the permissions assigned to them (the rights) dictate what they can do (print, edit, forward, reply, etc.). Protecting documents and email gives authors confidence that they control that content. For instance, adding a new recipient to a reply to protected message is useless from the perspective of that recipient because they don’t get the right to open the content because they’re not in the set assigned to the original message. All in all, protecting Office 365 content is a good thing.

The Downside of Protection

Even good technology can have its downside and protection is no different. Once you protect a document, you lose some functionality. The biggest issue is that Office 365 cannot search the content because it can’t decrypt the content to index it. This means that content searches and eDiscovery must rely on document metadata for its indexes. If users populate the metadata with terms that search can use to find documents, it might not be so much of a problem. But users are humans and humans often don’t do such a good job with metadata.

Of course, if a content search finds some protected content, you then face the further difficulty of what to do with it. Investigators might want to review the content to check whether it’s needed for eDiscovery purposes, but the content is encrypted. The solution is to use super-user privilege to decrypt the content. A technical solution exists, but dealing with encrypted files can be painful.

ISVs and Protection

In addition to the issues thrown up inside Office 365, any ISV who deals with Office 365 content needs to understand if the advent of sensitivity labels and increased use of rights management within Office 365 impacts their product. If a product depends on gaining access to content, it’s going to run into a brick wall when it tries to access protected content.

No Argument Against Protection

You can’t really argue against the goodness of securing access to confidential information. Sensitivity labels give users control over their information, and they should know what’s confidential and needs to be protected. Some user education is needed to ensure that everyone knows how best to use the range of visual markings and protection available through sensitivity labels, but overall, this is a very good feature that’s arriving into Office 365.

To read more about sensitivity labels, rights management, and encryption, go to Chapter 24 of the Office 365 for IT Pros eBook.

Knowing Which Accounts Are MFA-Enabled and Those That Don’t

When an issue like the November 19 2018 Azure outage occurs, the first thing that an administrator needs to know is what users are affected. In this case, the problem was that users whose accounts were enabled for multi-factor authentication (MFA) couldn’t complete the sign-in process and therefore weren’t able to access Exchange, SharePoint, and other Office 365 apps.

You can, of course go to the Microsoft 365 Admin Center and manage the MFA status of accounts there (Go to Active Users, click the More drop-down, and select Multifactor Authentication setup). However, the GUI is awful (Figure 1). It’s not part of Office 365 (it comes from Azure), hasn’t been updated in years, is slow, and is painful to navigate when you have a large tenant with many accounts.

Because the GUI is so terrible and slow, I usually turn to PowerShell to manage MFA for Office 365 accounts. The cmdlets you need are in the MSOnline module.

PowerShell Report

To start, let’s find out what accounts are MFA-enabled. Here’s a script to find and report the MFA status of all user accounts. The output is a CSV file. In a situation where an MFA outage is happening and you can’t access your normal administrative account, you’ll need to sign into Office 365 with a breakglass account.

CLS
Write-Host "Finding Azure Active Directory Accounts..."
$Users = Get-MsolUser -All | ? {$_.IsLicensed -eq $True}
$Report = [System.Collections.Generic.List[Object]]::new() # Create output file
Write-Host "Processing" $Users.Count "accounts..." 
ForEach ($User in $Users) {
   $MFAMethods = $User.StrongAuthenticationMethods.MethodType
   $MFAEnforced = $User.StrongAuthenticationRequirements.State
   $DefaultMFAMethod = ($User.StrongAuthenticationMethods | ? {$_.IsDefault -eq "True"}).MethodType
   If (($MFAEnforced -eq "Enforced") -or ($MFAEnforced -eq "Enabled")) {
      Switch ($DefaultMFAMethod) {
        "OneWaySMS"             { $MethodUsed = "One-way SMS" }
        "TwoWayVoiceMobile"     { $MethodUsed = "Phone call verification" }
        "PhoneAppOTP"           { $MethodUsed = "Hardware token or authenticator app" }
        "PhoneAppNotification"  { $MethodUsed = "Authenticator app" }
      } #End Switch
    }
    Else {
          $MFAEnforced= "Not Enabled"
          $MethodUsed = "MFA Not Used" }
  
   $ReportLine = [PSCustomObject] @{
           User        = $User.UserPrincipalName
           Name        = $User.DisplayName
           MFAUsed     = $MFAEnforced
           MFAMethod   = $MethodUsed }
                 
    $Report.Add($ReportLine) 
} # End For

Write-Host "Report is in c:\temp\MFAUsers.CSV"
$Report | Select Name, MFAUsed, MFAMethod | Out-GridView
$Report | Export-CSV -NoTypeInformation c:\temp\MFAUsers.CSV

Figure 2 shows the contents of the report as viewed through the Out-GridView cmdlet.

Update: The script described in this post uses the Microsoft Services Online module (MSOL). Microsoft will deprecate the module at the end of 2022. You should upgrade scripts to use Graph API queries or cmdlets from the Microsoft Graph PowerShell SDK. See this post for information about how to extract and report details of authentication methods used by Azure AD accounts.

Azure Active Directory Sign-in Log

Because the refresh token of MFA-enabled accounts don’t necessarily expire during an outage, a more nuanced approach is to check the Azure Active Directory sign-in logs for events with error codes 50076, 50074, or 50058, all of which flag problems signing in with an MFA-enabled account. You can review sign-ins interactively or download events to a CSV file. You can then use Excel to look through the failed sign-ins or import the CSV file into Power BI to analyze it there. In either case, you’ll end up with a set of accounts who are experiencing problems signing into Office 365.

Disabling MFA for Accounts

When a cloud outage happens, there’s no guarantee when normal service will resume. As everyone discovered on November 18, the process to figure out the root cause of a problem, come up with a fix, test it, and then deploy into production across a massive multi-tenant infrastructure can take many hours. While this process was in going on, the only workaround administrators had was to disable MFA for user accounts. This is easily done for a specific user:

$MFAOptions = @()
Set-MsolUser -UserPrincipalName Kim.Akers@Office365itpros.com -StrongAuthenticationRequirements $MFAOptions

To disable a batch of users, simply form a collection and call the Set-MsolUser cmdlet for each account. In this case, we disable MFA for all members of the Marketing department. If you extract failed sign-in data from Azure Active Directory, you can create a CSV file holding the set of accounts to process and use it as the input.

$MFAOptions = @()
$Accounts = Get-MsolUser -Department Marketing | ? {$_.StrongAuthenticationMethods -ne $Null}
ForEach ($A in $Accounts) {
Set-MsolUser -UserPrincipalName $A.UserPrincipalName -StrongAuthenticationRequirements $MFAOptions}

Enabling MFA for Accounts

Later on when the outage is over, we need to re-enable MFA for the same set of accounts (we’ll assume that you have saved details of the accounts and populated those names in the $Accounts variable). The PowerShell snippet shown below sets up MFA based on one-way SMS (text) messages containing 6-digit codes.

$MFA = New-Object –TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$MFA.RelyingParty = "*"
$MFA.State = "Enabled"
$MFAOptions = @($MFA)
$MFAMethod = New-Object –TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$MFAMethod.IsDefault = $True
$MFAMethod.MethodType = "OneWaySMS"
$MFAMethods = @($MFAMethod)

ForEach ($A in $Accounts) {
    Set-MsolUser –UserPrincipalName $A.UserPrincipalName –StrongAuthenticationRequirements $MFAOptions –StrongAuthenticationMethods $MFAMethods }

These examples aren’t a complete solution. Instead, they’re intended to give administrators a start to figure out how to manage MFA settings with PowerShell.

For more details about Office 365 MFA, see the online documentation.

We cover multi-factor authentication for Office 365 in Chapter 3 of the Office 365 for IT Pros eBook.

Updated November 22 with Microsoft preliminary root cause analysis and then on November 26 with the final version.

Two Outages in Ten Weeks

The second major outage for Azure multi-factor authentication (MFA) in two months brought some Office 365 to a halt on Monday, November 19. That is, until administrators understood what was happening and and disabled MFA for accounts to allow users to sign in.

The first outage occurred on September 4 when lightening struck Microsoft’s San Antonio datacenter. Post-postmortems published after the event (here’s the VSTS version) revealed how the impact of the outage rippled across multiple Microsoft cloud services, including MFA.

The Problem

The original problem statement was:

“Customers in Europe, Asia-Pacific and the Americas regions may experience difficulties signing into Azure resources, such as Azure Active Directory, when Multi-Factor Authentication is required by policy.”

The official word on the Azure incident history page says:

“A recent update was deployed to improve connections to caching services for the MFA service, this introduced a race condition which prevented users from being able to sign-in, or carry-out self-service password resets, when using MFA services…

Engineers initially rolled back the deployment which eliminated the connection between the Azure MFA service and the backend caching service. Engineers subsequently cycled impacted servers which allowed authentication requests to succeed.“

On November 26, Microsoft updated the root cause analysis to say:

“There were three independent root causes discovered. In addition, gaps in telemetry and monitoring for the MFA services delayed the identification and understanding of these root causes which caused an extended mitigation time. 

The first two root causes were identified as issues on the MFA frontend server, both introduced in a roll-out of a code update that began in some datacenters (DCs) on Tuesday, 13 November 2018 and completed in all DCs by Friday, 16 November 2018. The issues were later determined to be activated once a certain traffic threshold was exceeded which occurred for the first time early Monday (UTC) in the Azure West Europe (EU) DCs. Morning peak traffic characteristics in the West EU DCs were the first to cross the threshold that triggered the bug. The third root cause was not introduced in this rollout and was found as part of the investigation into this event.

1. The first root cause manifested as latency issue in the MFA frontend’s communication to its cache services. This issue began under high load once a certain traffic threshold was reached. Once the MFA services experienced this first issue, they became more likely to trigger second root cause.
2. The second root cause is a race condition in processing responses from the MFA backend server that led to recycles of the MFA frontend server processes which can trigger additional latency and the third root cause (below) on the MFA backend.
3. The third identified root cause, was previously undetected issue in the backend MFA server that was triggered by the second root cause. This issue causes accumulation of processes on the MFA backend leading to resource exhaustion on the backend at which point it was unable to process any further requests from the MFA frontend while otherwise appearing healthy in our monitoring.”

The worrying part of the story is that a code update proved to be unreliable when introduced into production, which is not good for Microsoft’s cloud quality and testing regimes.

Early-morning Incident

The incident started at 04:39 UTC and stopped users completing the MFA secondary challenge and sign-into services like Office 365. For instance, the text message containing the code to prove that the account owner has the device registered for the account never arrives, meaning that the challenge shown below can never be completed.

According to Microsoft, the problem started to ease at around 14:45 UTC after a hotfix was deployed. It takes a long time to deploy code fixes across a massive infrastructure and many tenants were affected by the problem for several hours afterwards. I first managed to authenticate with MFA at 18:23 UTC. Others were not so lucky and the lack of connectivity persisted for several hours afterwards. The incident slowly wound down and, at the time of writing, the situation is being monitored by Microsoft but everything is working.

Overall, Monday wasn’t a great day for users or administrators alike. MFA-enabled accounts couldn’t access Office 365 applications if their refresh token expired and they needed to go through the MFA sign-in process to reauthenticate. Administrators, whose accounts are more likely to be protected by MFA, hit the same issue and lost access to Office 365 and Azure portals.

Communication Blues

During the incident, Microsoft communicated with customers via the Office 365 Admin Center and the Azure status page, but didn’t always give the same story in both places. For instance, around 14:00, on the service health page of the Office 365 portal, we learned:

While we continue to develop the code update, we’re exploring additional workstreams to find a path to mitigation.

While at the same time, the Azure portal told watchers that:

Engineers have explored mitigating a back-end service via deploying a code hotfix, and this is currently being validated in a staging environment to verify before potential roll-out to production. Engineers are also continuing to explore additional workstreams to expedite mitigation. 

Obviously, the text posted on the Azure portal gave more complete information. One wonders why the people responsible for updating the portals couldn’t have used the same story?

On the one hand it’s reasonable that Azure should have its own communications because its services are used by more than Office 365. On the other, Microsoft runs both services and it is strange to have Office 365 give less information than is publicly available elsewhere.

Microsoft Says to Use MFA

Microsoft recommends that Office 365 tenants use MFA. The priority is to protect accounts with privileged access, like tenant administrators, followed by high-profile accounts, like those used by executives. However, for maximum protection against hacker attacks, all Office 365 user accounts should use MFA.

Microsoft reinforces the message by giving tenants that use MFA a big boost in their Secure Score (if that means anything to you). Generally speaking, I agree with Microsoft and think that all accounts should be protected. Until, that is, something bad happened and users can’t sign into Office 365 or any other Microsoft cloud service because of an MFA failure. It’s worth underlining that the problem only surfaces for new connections or when a user’s access token expires and needs to be renewed. While the access token is still valid, users can continue to connect even with a broken MFA service.

Disable MFA to Keep Working

The question then becomes what should a tenant in case of an extended an MFA outage when users need to get into Office 365 or other services and can’t because they cannot complete the MFA process. The obvious answer is to disable MFA for affected user accounts while the outage continues and then re-enable the accounts for MFA immediately the outage is over and normal service resumes. Of course, this assumes that you can still sign into an administrator account to reset MFA for users. But keeping an admin account that isn’t secured with MFA is a bad idea, isn’t it?

Breakglass Accounts

Not if it’s a “breakglass” account. In other words, a privileged account that can be used in case of emergency and other administrator accounts are unavailable for some reason. See this article for a discussion on the topic as well as some advice from Microsoft on how to manage emergency administrative accounts for Azure Active Directory.

The lesson of the outage are clear. If they use MFA (as they should), Office 365 tenants need to be prepared to deal with outages. Knowing what accounts are protected with MFA is a start, being able to disable MFA if needed is a good idea (and revert once the problem eases), and having a breakglass account is also sensible.

The process to enable Office 365 accounts for multi-factor authentication is covered in Chapter 3 of the Office 365 for IT Pros eBook. We’re not so hot on disabling MFA…

Poor Fit and Finish Within Office 365 at Times

Yesterday, we discussed Microsoft’s decision to withdraw their plan to send email to Office 365 end users after receiving strong feedback from customers. Today’s Petri.com article discusses the introduction of Privileged Access Management (PAM) for Office 365. In writing the article, I wondered if some of the effort expended by Microsoft on plans that customers have never asked for might not be better used to refine some of the obvious flaws in important systems like PAM.

It’s at times like this that I wonder just how well the fabled DevOps model really operates when it comes to creating solid software. Almost every day, I seem to run into something inside an Office 365 application that doesn’t work as well or as smoothly as it should. The fit and finish of Office 365 can be pretty bad at times – the infamous tendency of the Office 365 Admin Center to barf because of cookie problems is just one example of what I mean. It seems like the rush to deliver features is all-encompassing and the need deliver quality is of secondary consideration.

Although Microsoft must take the majority of the blame when the standard of their software slips, customers are also at fault because we accept the problems. Or at least we don’t protest as much or as often as we should.

The Future of PAM

Getting back to PAM, I like the idea of controlling elevated access very much and think it’s good that Microsoft is introducing some of the experience gained from their internal Office 365 operations into the product. What’s not so good are some of the flaws that are obvious, most of which I am sure Microsoft will move to eliminate now that they’ve been highlighted. More strategically, I wonder how the current Exchange-centric model can be brought forward to cover the rest of Office 365 when applications don’t have the rich RBAC control system that’s been developed for Exchange for nearly a decade.

I’m sure the developers have plans for progression and it will be interesting to see how PAM expands to deal with SharePoint Online, OneDrive for Business, Teams, Planner, Yammer, and anything else that comes long. We’ll see in time.

Protect but Don’t Block

Office 365 tenants who use Rights Management with Azure Information Protection (and use a cloud key rather than their own key, or HYOK) can now include the special Any Authenticated Users in the permissions configured for protection templates. Previously, you could only define permissions for users within the same tenant or named individuals in other domains *(using their email addresses). Any Authenticated User is a special permission which grants a set of permissions defined in a template to any user who authenticates by signing into:

• An Azure Active Directory account. For example, anyone in another Office 365 tenant.
• A Microsoft Services (MSA) account. For example, anyone who uses Outlook.com.
• A directory service federated with Azure Active Directory (like Google) or where a one-time passcode is used to access protected content. These types of protection are usually involved when sending email to recipients of non-Microsoft email services.

The intention behind the Any Authenticated Users permission is to give tenants a method to encrypt information sent outside the organization so that it is protected in transit and at rest while still supporting granular permissions and access control (such as expiration and offline access). In effect, you’re not worried about who opens the content if they can authenticate, but you still want some control over what they can do with the content.

Like the permissions assigned to individuals or groups, you can grant specific permissions to Any Authenticated User. For instance, you can stop people who use the permission from copying or printing the content. You can also track and revoke access to the content at any time.

Any Authenticated Users and Sensitivity Labels

As you might know, Microsoft is currently in the process of unifying protection labels as defined in the Azure Information Protection portal with Office 365 labels. This doesn’t mean that we will have a single set of labels. Rather, Office 365 will have two sets, both of which are managed through the Classification section of the Security and Compliance Center:

• Sensitivity labels, which apply protection and are shared with Azure Information Protection.
• Retention, which define for how long Office 365 keeps information like documents and email.

The migration of labels from Azure Information Protection to Office 365 is still a work in progress. Here’s what I report in Petri.com on the topic.  You can add the Any Authenticated Users to a template in the Azure portal and it will be synchronized to the Security and Compliance Center. However, you can’t yet add the permission to a label through the Security and Compliance Center.

For more information about rights management, read Chapter 24 of the Office 365 for IT Pros eBook.

Office 365 Audit Records Reveal Interesting Events

Over the last few days, I’ve noticed records being generated in the Office 365 audit log for an account called BOXServiceAccount. You can see an example above. The audit records are matched by alert policies (managed through the Security and Compliance Center) that cause email to be sent to my account when events that might need investigation occur. In this case, a use of Exchange Online administrative permission by an account.

A quick internet search turned up this Microsoft support article, which throws some light on the subject. Although the wording is odd (for example, “BOXServiceAccount is added to a role” is more likely “BOXServiceAccount is used to add an account to a role.”), the intent is clear. BOXServiceAccount is a system account used behind the scenes to carry out tasks within Office 365. A discussion in the Microsoft Technical Community from April 2018 and another in the Microsoft Answers forum from June 2017 provided some extra insight. Clearly, I haven’t been paying attention.

In this case, it seems like BOXServiceAccount comes into play when an administrator assigns another user one of the custom administrative roles through the Office 365 Admin Center. I assume the reason why a system account is used in this manner is that the administrator who assigns someone a role might not have the permission to add that account to the Azure Active Directory role groups which underpin the administrative roles.

Azure Active Directory Role Groups

To see the role groups defined in your tenant, run the Get-AzureADDirectoryRole cmdlet (from the Azure AD PowerShell V2 module).

Get-AzureADDirectoryRole

ObjectId                             DisplayName                      Description
--------                             -----------                      -----------
07308ce7-381b-4fb1-b31e-398b8a66c946 Billing Administrator            Can perform common billing related tasks like updating payme...
0f3a91cd-4fdd-436e-97ed-f2a01b19bfe2 User Account Administrator       Can manage all aspects of users and groups, including resett...
1402c923-f478-4a9c-82b1-0511726c43bd Customer LockBox Access Approver Can approve Microsoft support requests to access customer or...
268030c9-556f-47a6-a167-5970cb734558 Device Administrators            Device Administrators
36333bfe-4ff2-452a-a4a0-d11a668b44c7 Company Administrator            Can manage all aspects of Azure AD and Microsoft services th...
387f95ae-e47f-4156-b5d3-2d9150fdea7e Directory Readers                Can read basic directory information. For granting access to...
432e4ce3-ed50-4406-aeb6-1794283ad211 Lync Service Administrator       Can manage all aspects of the Skype for Business product.
4e0cabe2-fe25-49e1-8538-61a8b8422517 Reports Reader                   Can read sign-in and audit reports.
53add08e-5b0c-4276-a582-9ce02fb6c947 Exchange Service Administrator   Can manage all aspects of the Exchange product.
57122a2b-cd95-4370-a84b-4e90ec8e722a Service Support Administrator    Can read service health information and manage support tickets.
64503181-13d0-4ef6-8ee2-a08a7b690168 Power BI Service Administrator   Can manage all aspects of the Power BI product.
7ae4b349-1f17-429c-8795-dcc56096c0c7 Helpdesk Administrator           Can reset passwords for non-administrators and Helpdesk Admi...
88b6939a-ef4b-4e8e-9aba-00f4f8447e66 Compliance Administrator         Can read and manage compliance configuration and reports in ...
c7ba418f-9d1e-4bd2-b770-dba1cbc2c336 Directory Writers                Can read and write basic directory information. For granting...
f35c2f36-b60d-4b17-b261-0de8af7da552 SharePoint Service Administrator Can manage all aspects of the SharePoint service

The Lync Service Administrator listed is just an old display name. It equates to what you see as the Skype for Business Online Administrator when viewed through the Office 365 Admin Center. To see the current accounts assigned a role, run the Get-AzureADDirectoryRoleMember cmdlet and pass the object identifier of the role you want to examine.

Get-AzureADDirectoryRoleMember -ObjectId "f35c2f36-b60d-4b17-b261-0de8af7da552"

ObjectId                             DisplayName                            UserPrincipalName                  UserType
--------                             -----------                            -----------------                  --------
d44088a5-a5ea-47af-b724-cffb12c6ed3e Paul Smith                             Paul.Smith@office365itpros.com Member
d446f6d7-5728-44f8-9eac-71adb354fc89 James Abrahams                         James.Abrahams@office365itpros.com Member
67105a51-e817-493e-8094-f600babf5f62 Marc Vigneau                           Marc.Vigneau@office365itpros.com   Member

No Mystery – Move Along Please

So, apart from its odd name, there’s no mystery about BOXServiceAccount. It’s just one of the system accounts used by Office 365 to get work done. There’s nothing wrong with using accounts like this because system accounts have been used for years for different purposes, such as updating your Exchange Online configuration to match standards set by Office 365.

But what’s wrong is that Microsoft has never communicated the reason why BOXServiceAccount exists and how it is used. A note in the Message Center in the Office 365 Admin Center wouldn’t have gone amiss, well before administrators began to see the interesting audit events turn up in their Office 365 audit log. Maybe I missed that too.

For more information about custom Administrative roles, see Chapter 4 of the Office 365 for IT Pros eBook. And of course, you can have a great time reviewing the many interesting facts to be found in the Office 365 audit log in Chapter 21. And activity alerts and alert policies are covered in Chapter 21 too, just in case you don’t feel like browsing the audit log daily.

Encrypt Only

In March 2018, Microsoft introduced the ability for Office 365 users to use the Encrypt Only feature to encrypt email sent from Outlook 2016 and OWA. Part of Office 365 Message Encryption and included in the Office 365 E3 and E5 plans (also available as an add-on), the idea behind the Encrypt Only feature is to avoid the need for people to use S/MIME to protect their outbound email. Messages encrypted by Office 365 can be read by recipients in any email service.

Introducing DecryptAttachmentForEncryptOnly

On August 23, Microsoft updated the Information Rights Management (IRM) configuration for tenants with a new setting called DecryptAttachmentForEncryptOnly. The new setting controls if Exchange Online decrypts attachments of messages protected with Encrypt Only when opened by authenticated users.

The default is False, meaning that attachments remain protected when downloaded (Figure 1). In other words, the sender exerts control over the file.

Change the setting to True if you want recipients to be able to do whatever they want after they download attachments. To update, connect to Exchange Online with PowerShell and run the command:

Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $True

Changes made to the IRM configuration are effective tenant-wide immediately.

No Online Edits for OWA

If you opt for unrestricted access, be aware that users cannot perform an online edit of an Office attachment protected by Encrypt Only with OWA. You’d expect that this would be the case, but OWA preserves encryption unless an attachment is downloaded. So if you click Preview for an Office attachment and then click Edit and reply, you’ll see:

The workaround is to download any attachment you want to edit as this forces Exchange Online to decrypt the file.

The DecryptAttachmentFromPortal Setting

The DecryptAttachmentFromPortal setting was introduced some time ago to allow recipients who don’t have an Azure Active Directory account (services such as Gmail, Yahoo!, and Yandex) to access encrypted message attachments. This setting is now deprecated in favor of DecryptAttachmentForEncryptOnly.

No Other IRM Templates Affected

The DecryptAttachmentForEncryptOnly setting only applies to attachments for messages sent using the Encrypt Only feature. They don’t apply to attachments protected with any other rights management template.

One Configuration

The new setting allows tenants to control how recipients interact with attachments protected by the Encrypt Only feature. It’s worth emphasizing that the IRM configuration applies tenant-wide and you cannot change a setting for one message, one sender, or a recipient. Once you change a setting, it applies for all messages.

For more information about protecting email and documents, see Chapter 24 of Office 365 for IT Pros.

Serious ADFS Bug Discovered

First reported on August 14, a security flaw in Active Directory Federation Services (ADFS) that could allow attackers to bypass multi-factor authentication MFA services, has been addressed by Microsoft. ADFS is often used by Office 365 customers to pass authentication requests to on-premises Active Directory.

The flaw was discovered by the Research and Exploitation (REX) team at Okta, the security identity management company, who reported it in a blog post entitled “The Inside Job: When Microsoft MFA Fails.” The problem is summarized in their statement:

“The vulnerability allowed potentially malicious actors to bypass Multi-Factor Authentication (MFA) safeguards, as long as they had full access to another user’s credentials on the same ADFS service. This is similar to taking a room key for a building and turning it into a skeleton key that works on every door in the building.”

Download and Install the ADFS Patch

The patch (CVE-2018-8340) is available online. According to Samuel Devasahyam (aka Mr. ADFS) of Microsoft, customers who use ADFS should “install the patches now.” Obviously, given that any bug affecting authentication is a bad thing, Samuel’s advice is well founded.

For more information about using ADFS with Office 365, see Chapter 3 of Office 365 for IT Pros.

A New Attack

Avanan is an Israeli security company that has a track record of pointing to Office 365 security and saying that it could be improved. In some cases, like their criticism of MTA-based email scanning a la Mimecast, I think they have a point. In others, I’m not so sure.

Take the “PhishPoint” episode, reported by Avanan to affect 10% of the Office 365 customers they work with. Avanan duly scales this number up to estimate that the problem affects the same percentage globally, or 13.5 million of the 135 million active Office 365 users (the last official number – likely higher by about 15 million now). I must be missing something here, because if 13.5 million Office 365 users had been attacked through a malicious SharePoint document, I think Twitter and other social media would be in global meltdown. And they’re not.

The attack involves an embedded URL in an email that leads to a real SharePoint document (presumably in an Office 365 tenant owned by the attacker) that invites the victim to sign into Office 365 to read the content of another document that’s shared in OneDrive for Business. The result is a dummy sign-in screen that looks like the regular Azure Active Directory sign-in, which is where the attacker gathers user credentials, presumably for later use to compromise their account, perhaps in a Business Email Compromise attack.

Will Users Notice the Flaws in the Attack?

I’m sure some people will be deceived by the scheme, but I’ve got to hope that the majority will notice signals like being taken from one document to another (odd when you think about how sharing works inside Office 365), followed by a sign-in screen whose URL has no connection to Office 365 and, in Avanan’s posted example, is flagged as “dangerous.”  Perhaps the Office 365 customers that Avanan deals with are less well-trained, which is why 10% of them have been affected.

Joking apart, the report does highlight that malicious code can be introduced through infected documents. Solid user training to warn people about how attackers work should be given on an ongoing basis. Threats evolve all the time, so training needs to keep pace.

Read, Understand, Decide

Avanan’s business is based on convincing people that they need extra layers of security to keep Office 365 safe. Some of the reasons they advance are good, some are FUD (I thought this example was in 2016). The articles that they write about Office 365 security are worth reading (like “8 Security considerations when moving to Office 365“), if only to cause you to pause for thought and consider whether you need to do more to secure your tenant. But don’t take everything in face value. You understand your tenant better than anyone else, so always put the information presented by a third party into that context and then make decisions.

For more information about SharePoint Online and OneDrive for Business, read Chapter 8 in Office 365 for IT Pros. For more information about Advanced Threat Protection and Exchange Online Protection, see Chapter 17.