Why an Office 365 Connector Generates Multiple SendAs Audit Events
Office 365 Connectors allow data drawn from multiple internet sources like Twitter to be imported into Office 365. Why imported tweets result in multiple SendAs events logged in the Office 365 Audit log came as a surprise. There is some logic into why this happened, but it’s kind of warped.
Office 365 Connectors are a neat way to capture information from over 50 different internet sources and import them into Office 365 groups in the form of “cards,” each of which represents an item fetched from the source. For instance, if you connect to your company’s official blog, the card represents a snapshot of a blog post rather than the complete text. The idea is that the cards inform people that new information is available and provide sufficient context for them to decide whether or not they want to follow the link in the card to see the full content. The Office 365 Group also provides a suitable place for discussions about the content in the network source.
When discussing how best to include the topic of Connectors in our “Explore the ultimate field guide to Microsoft Office 365 Groups” session at Microsoft Ignite (yes, all Ignite sessions start with a verb), Benjamin Niaulin, one of my co-presenters, complained that everyone uses Twitter as the example for how to use a connector. He’s off now to find a great example to use for the session and I await what he decides to show at Ignite with great interest.
In the interim, I use the Twitter connector to monitor the tweets sent by a number of MVPs, all of which are then collected into an Office 365 Group (Figure 1). One good thing about the Twitter connector is that the cards it produces are usually able to capture the complete text of tweets, so I have a complete record of interesting tweets from interesting people.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
All was well until I decided to create an activity alert that monitored for SendAs operations in user mailboxes. I didn’t have any great reason to create such an alert except as part of my personal testing effort to understand the new activity alerts feature. (To access activity alerts, go to the Security and Compliance Center console, select Alerts, and then Manage Alerts.)
The idea behind activity alerts is that you can establish some criteria to monitor audit entries as they are loaded into the Office 365 Unified Audit log. If the criteria are satisfied, the alert fires and an email notification is sent to nominated individuals. I have other alerts set up for events such as file check-in operations for SharePoint document libraries and wanted to see how well an Exchange event worked.
However, before Exchange mailbox events can flow through to the Office 365 Unified Audit log, you have to enable auditing for the mailboxes you want to monitor, as otherwise audit events are not recorded for those mailboxes. For example, here’s how to use the Set-Mailbox cmdlet to enable auditing for a single mailbox:
[PS] C:\> Set-Mailbox -Identity TRedmond -AuditEnabled $True
Or, to make sure that mailbox auditing is enabled for all mailboxes:
[PS] C:\> Get-Mailbox -RecipientTypeDetails UserMailbox | Set-Mailbox -AuditEnabled $True
You also have to remember that Exchange events can appear in the audit log much later than events originating from other sources. For instance, SharePoint Online events usually show up within 15 minutes whereas the advertised delay for Exchange Online is “up to 12 hours”. However, the delay between something happening inside a mailbox and an audit event being loaded into the log varies enormously. Sometimes it’s just a few minutes and sometimes it can take hours. This is important because alert notifications are sent when the source audit events are extracted from the underlying workloads and ingested into the audit log. Figure 2 shows an example of the email notification for a SendAs event.
I assume the reason why Exchange Online events are slower to appear is that the nature of an email system is that a larger volume of events occur than when dealing with the somewhat slower pace of document creation and updates. Sometimes events turn up quickly but sometimes it takes a lot longer. Being informed that something happened 12 hours ago is interesting, but it would be a lot more useful if the alert was flagged much closer to the actual incident.
The Office 365 Audit Log Report option in the Reports section of the Security and Compliance Center allows you to search the Office 365 Unified Audit log for the SendAs event that caused the alert to trigger. In my case, I found more SendAs events than expected, none of which could be associated with known user activity. Upon investigation, all of the events were associated with the mailbox owned by an Office 365 Group created to store tweets captured through a connector, and all were tagged with my name as the person who apparently used the SendAs permission to send a message for that mailbox.
Figure 3 shows an extract of the information reported in the audit event. The solution to the conundrum of why these events were recorded is contained in this detail. First, the Client Info String tells us that the client used to create the messages is the ConnectorWorkProvider, or the Office 365 connector. Second, the Item detail shows that the card created by the connector contains the text of a tweet. We know that the connector created the card in the MVPtweets mailbox because that’s shown in the MailboxOwnerUPN field. It also appeared that an audit event was recorded every time the connector found new tweets to capture.
Putting these pieces of the information together, one possibility is that the Office 365 Connector uses the account that created the connector to Twitter to create cards in the target mailbox in a way that makes them appear to be SendAs events. There’s probably a good reason why this might happen. For instance, it might be that the developers chose to impersonate the account used to create the connector when creating new cards. It might also be the case that the name of the account that created the connector was captured at that time and is stamped on activity thereafter without any impersonation taking place.
I also considered the possibly that a group owner’s account is used to create the cards, but disproved this theory by changing the group owner to another account and observing that the original account continued to be reported as responsible for the events.
For whatever reason, more SendAs events than anticipated accumulated in the audit log. I wouldn’t have known this unless I used the new activity alerts feature and then noticed the weird side effect of the Office 365 Connector. This kind of interaction between different features is unlikely to be tested by developers as the Office 365 Groups team is probably unaware of Exchange Online mailbox auditing and activity alerts. All of which proves the difficulty of tracking all of the connections that occur within a complex ecosystem like Office 365!
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.