Why an Office 365 Connector Generates Multiple SendAs Audit Events

Posted on August 30, 2016 by Tony Redmond in Office 365 with

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.

Using the Twitter connector to import cards into an Office 365 Group

Figure 1: MVP tweets (Image Credit: Tony Redmond)

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:

Or, to make sure that mailbox auditing is enabled for all mailboxes:

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.

An email notification for a SendAs event

Figure 2: An emailed notification for a SendAs event (Image Credit: Tony Redmond)

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.

An extract of the information reported in the audit event shows why the events were recorded in detail

Figure 3: Details of the SendAs audit event (Image Credit: Tony Redmond)

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.

Tagged with , , , , , ,

Register for this Webinar

How Replication Supports Your Company’s RTOs & RPOs
Join us for this free webinar

Can you have your workloads running within the agreed RTOs? Join this webinar with expert speakers from Veeam to exceed business objectives with an RPTO<15 min for ALL of your application and data.

Thursday, December 14, 2017 at 11 a.m EST