In our previous two blogs (Part 1 and Part 2), we discussed how to set up and configure an application in Entra ID and assign permissions to access Entra ID and Office 365 events. You might be thinking at this point, I’m here to work with Google SecOps, why have we spent so much time talking about Entra ID? Well, your patience will be rewarded now, because this is where we take the prep work we did in the previous blogs and apply it to feed management to ingest events.

Let’s start by clicking Add New in our Feeds view. The pop-up that opens prompts us for a Feed Name, Source Type and Log Type. For both Entra ID and Office 365, select the Third Party API source type in the drop-down.

Entra ID has two distinct log types, one for interactive sign-ins and one for audit. The logs that are generated can also be found within the Microsoft Entra admin center under Monitoring & Health.

While Microsoft changed the name of Azure Active Directory to Entra ID, Google SecOps lists the log types using the Azure AD naming convention, so don’t be confused. Interactive sign-in logs will use the Azure AD log type and audit logs will use the Azure Active Directory Director Audit log type. Finally, if we want to ingest user context data from Entra ID, we can use the log type of Azure AD Organizational Context. Office 365 is also available, it’s just further down the list. Once you have selected the log type of interest, click Next.

In the first blog of this mini-series, we discussed the importance of recording the values for our tenant ID, application (client) ID and secret value. In this step, we are going to enter these values into the three fields below in the blue box.

Depending on the functionality you want to monitor in Office 365, we can set up one to five feeds based on the different content types associated with the Office 365 log type including SharePoint Audit, Exchange Audit, General Audit, and more. A separate feed for each content type is required.

Once the input parameters have been entered, we can click Next and review our settings and then click Submit. Ingestion will immediately start to occur though it may take a few minutes to initially complete.

If you see a failed status next to a specific feed, you can hover over it to get some additional information. If you get a HTTP 403 error like this, adequate permissions for the specific feed may not be set properly. In this example, our Entra ID application had Office 365 permissions but not the correct Graph API permissions for the Azure AD log type.

A HTTP 401 error may indicate that one or more of the following values is incorrect; tenant ID, application (client) ID and secret value.

Let’s take a few minutes and discuss the Azure AD Organizational Context log type. As previously mentioned, this feed ingests users and their properties from Entra ID which can then enrich events with user context, much like Okta or Microsoft Active Directory. When configuring this feed there are checkbox options to retrieve devices and/or groups.

Users in Entra ID can be assigned to one or more groups. In our example, Mike Slayton is assigned to a number of groups, one of which is the InfoSec Study Group.

If we ingest the organizational context from Entra ID without clicking the ingest groups checkbox, we get entity data associated with Mike, including his email address, when the user was created and other properties.

Here is the same entity record for Mike, except this time we clicked the ingest groups checkbox and now we have additional information pertaining to the groups he is assigned to. We’ve trimmed the data to just the InfoSec Study Group for readability, but notice that we have fields that start with the term relations.

Let’s look at another example, this time using the user Dan Cooper. Dan’s Entra ID user shows that he is assigned to the workstation wrk-pacman. 

With the retrieve devices checkbox selected, we can ingest Dan’s user information from Entra ID and here we can see relations again, but this time associating the asset and ownership to Dan.

Using the groups and devices retrieval in entity context is optional but if these capabilities are used in Entra ID, this additional context can be very useful in rule writing.

I hope this blog has shed some light on how you can take your Entra ID and Office 365 solutions and integrate them into Google SecOps. Now that you have the data in Google SecOps, what can we do with it? Well you can start by checking out some of the community rules we’ve created and blogged about to gain visibility into activities like anonymous file downloads, applications and secrets being created and more.

In the next few months, I will be making some additional use cases available around Office 365 and Entra ID. BTW, I know there are some additional Microsoft Azure based feeds that Google SecOps makes available, including Azure Activity, Graph API Alerts and Graph Activity logs. While we haven’t walked through the specifics of configuring these feeds, the concepts we covered today apply to these feeds as well, so you can take what we covered today and extend your logging as needed.