A reader asks how to monitor membership changes for some specific high-profile groups. You can buy a commercial product to do the job or use PowerShell to exploit the information held in the Office 365 audit log. A combination of a custom attribute assigned to the sensitive groups and an audit log search does the job.
This article explains how to use PowerShell and the Office 365 audit log to report Azure AD license assignments. The output isn’t pretty, but it works. The code works by finding two different audit events for each license assignment and combining information from both events to create a view of what happened. It’s rough and ready and can be improved, but the principal is proven and that’s what I set out to do.
Microsoft DART (cybersecurity response team) published an interesting article about the essential sources of Microsoft 365 audit data used for forensic investigations. The Office 365 audit log gets a big mention and DART seems pretty impressed by the new audit log search that’s available in preview in the Purview Compliance portal. I’m not impressed by the performance of the new interface and will continue to use PowerShell. As it turns out, so will DART.
Every time someone reacts to a message in a team chat or channel conversation, Teams captures an audit record and sends it to the Office 365 audit log. The Teams reactions audit records are an interesting source of information. In this article, we show how to use PowerShell to interpret the contents of the reactions, and how to use the data to find the underlying messages.
You might never need to use a break glass account, but if the need arises, you’ll be glad that you had the foresight to anticipate that bad things can happen and create a break glass account for your Microsoft 365 tenant. This article describes why you might want one or more of these accounts, their characteristics, some pitfalls to avoid, and how to check that the break glass accounts aren’t being used.
The Microsoft 365 audit log holds all kinds of useful data, including events logged for SharePoint Online and OneDrive for Business file deletions. It’s easy to use PowerShell to search the audit log to find and interpret the events and create a report. Large tenants might need to export the audit data on a regular basis to an external repository to allow for long-term retention and analysis. We explain the principles of the process in this article.
New audit events are available to capture information about Teams meetings and participants, but only if you have Office 365 E5 or above licenses. That’s because Microsoft deems these events to be high-value audit information prized by forensic investigators when they try to unravel what happened in an incident. You’ll have to make your own mind up how valuable the events are, but we’ve written some PowerShell to make the data more accessible.
When SharePoint users share information, Office 365 captures events in its audit log. By analyzing the events, we can build a picture of how people share information. The sad thing is that the audit events logged when someone extends the validity of a sharing link doesn’t contain as much information as you might like. Even so, we can still analyze the sharing events to build a picture of what happens in an Office 365 tenant.
Microsoft 365 retention policies control how the system removes items automatically from Exchange Online, SharePoint Online, Teams, and other locations. Because these policies are so powerful, it’s a good idea to keep an eye on who makes changes to their settings. The audit log is a natural place to go looking for information about policy updates and while we can find information there, some of the data is oddly formatted or obscured for some reason. Persistence and PowerShell delivers answers, but this is a task way harder than it should be.
After writing about auto-label policies for Teams meeting recordings, we were asked about how to track the creation of the recordings. The key to be able to report the data us events in the Office 365 audit log. Once you know where to look, it’s easy to find the audit records and extract data about the creation of Teams meeting recordings.
Auto-label policies are a good way to assign retention labels to important files stored in SharePoint Online and OneDrive for Business. The big problem is tracking the progress of auto-labeling. In this article, we explore how to use events logged in the Office 365 audit log to figure out what files are labeled and how long it takes the auto-label policies to process the files. The example explored here is an auto-label policy for Teams meeting recordings.
The Office 365 audit log is packed full of information about what happens inside workloads. New events show up all the time. The question is how to understand what actions these events relate to. We outline a simple procedure to discover the presence of new audit events and dive into the investigation of an event called Consent to application, which is pretty important in the context of recent high-profile attacks.
The Office 365 audit log is a great source of information about what happens inside a Office 365 tenant. Searching the audit log takes practice, but it turns up lots of insight. This article covers how to use the ObjectIds and FreeText parameters to find information about what happens to an object,
You can easily add people from outside your Office 365 tenant to the membership of Teams, but some oversight of who those people are and what teams they join is probably needed. This PowerShell script shows how to find records in the Office 365 audit log and figure out if they relate to the creation of new guest accounts before sending email asking to justify the addition of the new account.
Office 365 notification MC220283 says that Microsoft has retired support for organizations to audit Sway activities. In other words, no more Sway events in the Office 365 audit log. This might or might not be a problem for your tenant, depending on how much use you make of Sway and if you have the necessary licenses. But the real problem is the lack of communication before Microsoft removed the feature. That’s not good.
The Planner browser UI now displays a notice to users when someone else has changed tasks in a plan. This is useful, but it would be much better if Microsoft enabled support for the Office 365 audit log so that events happening in Planner flowed into the audit log. There’s no sign of that happening, despite requests for three years or more.
Support for sensitivity labels is generally available for SharePoint Online. Users can apply labels to classify and protect documents, but a mismatch can happen between labels applied to documents and the sites where the documents are stored. When this happens, SharePoint Online emails site owners to tell them that a mismatch exists.
The SendAs audit event is logged when someone uses the send as permission to send a message from an Exchange Online mailbox. The events are stored in the Office 365 audit log and can be found there with an audit log search. However, things aren’t as straightforward as they are on-premises because some other types of delegated messages turn up in searches. Fortunately, we have a script to help.
The email addresses for Teams channels are interesting objects. Messages sent to channels start conversations in the target channel and are also captured in SharePoint. Any team member can enable or disable the ability of a channel to receive email by creating or removing email addresses and no admin control exists to stop this happening. Events captured in the Office 365 audit log reveal when email addresses are created or removed, meaning that you can at least know what’s going on.
Office 365 Groups (and their underlying teams and sites) can be removed by user action or automatically through the Groups expiration policy. By examining records in the Office 365 audit log, we can track exactly when groups are soft-deleted followed by permanent removal 30 days later. All done with a few lines of PowerShell and some parsing of the audit data held in the records.
A question asked how to be notified when people delete Teams. The answer lies in the Office 365 audit log, and once we’ve found out when Teams are deleted are who deleted them, we can notifications to administrators via email or by posting to a Teams channel. The administrators can then decide if they should restore the deleted team or let it expire and be permanently deleted after 30 days.
Exchange Online writes audit records into the Office 365 audit log when messages are deleted by delegates and administrative action. We can analyze the audit records to find out who deleted a specific message. Some challenges exist to interpret the audit records for admin-generated deletions (for example, when you run Search-Mailbox), but it’s easy enough to code the necessary checks in PowerShell.
Microsoft launched the MailItemsAccessed audit event (to capture when email is opened) in January, reversed the roll-out in April, and now might restart sometime in Q3. It’s an odd situation that isn’t really explained by a statement from Microsoft. Are they going to charge extra for this audit event? Will they be analyzing the events? Or does Office 365 capture too many mail items accessed events daily?
On May 7, Microsoft eventually fixed a truncation bug that affected group events (creation, add member, etc.) ingested into the Office 365 audit log. The fix took far too long coming and the overall response is certainly not Microsoft’s finest hour. Audit events, after all, are pretty important in compliance scenarios and it’s not good when those events are incomplete.
Announced in January, paused in March – that’s the fate of the MailItemsAccessed audit record generated by Exchange Online for the Office 365 audit log. Microsoft found some problems that they are fixing, which is good (because you want audit data to be reliable). And when the fixes are available, the deployment of the new audit record will restart.
In one of those interesting (but possibly worthless) facts discovered about Office 365, we find that audit records are captured for Teams compliance records written into Exchange Online group mailboxes. The Search-UnifiedAuditLog cmdlet reveals details that we can interpret using some techniques explained in Chapter 21 of the Office 365 for IT Pros eBook.
Exchange Online now captures session identifiers in its mailbox and admin audit records that are ingested in the Office 365 audit log. That’s interesting and useful, but how do you access and interpret this information on a practical level?
Exchange Online will soon capture audit records for any access to a message in a mailbox. Initially, the audit records will not be ingested into the Office 365 audit log, but that will happen in the future.
Following a Dutch report saying that Office 365 might violate GDPR, some thoughts about how to restrict some of the flows of information from an Office 365 tenant to Microsoft.
Exchange administrators are accustomed to looking through mailbox audit logs to find details of events. Those same events are in the Office 365 audit log, so that’s the place to go look for information, like when you want to find out who sent a message from a shared mailbox using the SendAs permission.
Microsoft has updated its retention period for Office audit records from 90 to 365 days, but only for accounts with Office 365 E5 licenses. On another front, the problem with truncated audit records for Azure Active Directory events still persists.
Exchange Online sends its mailbox audit records to the Office 365 audit log. You can search the log to discover who deleted messages from mailboxes, normally only an issue when delegates are involved.
A demo to show how easy it is to use PowerShell to manage Office 365 Groups and Teams was progressing nicely at the UK Evolve conference when a problem happened with code that used to run perfectly. Sounds like a normal programming situation, but in this case, Microsoft had changed the format of Office 365 audit records for Azure Active Directory operations. That’s not so good. What’s worse is that some essential data is now missing from the audit records.
Records featuring an account called BOXServiceAccount appear in the Office 365 audit log. Not much information is available about the account, but it’s all OK because it’s used to assign administrative roles to Office 365 accounts.