We had a need to ingest Azure AD Sign-Ins to our Splunk environment to identify compromised accounts logging in from geographically improbable locations. We use Office365 for Outlook, OneDrive, SharePoint Online, Teams, etc. All of those resources make that Sign-In information very valuable to collect. We could see the information we wanted under Azure Active Directory Sign-Ins, we just needed to get it into Splunk:
Let me start off by saying that there are a lot of ways to do this and I feel like we tried almost all of them. We also did not have to pay for an Azure Monetary Commitment, Subscription, pay-as-you-go thing, GraphAPI license, etc. Once we configured the App Registration in Azure AD, we were golden. This phase is what took 6 or more months — we tried a variety of methods and kept getting stuck thinking we needed to write the logs to some bucket or blob and then ingest them into Splunk. With the Splunk Add-On for Microsoft Office 365, we pull them in directly without storing them anywhere in between in Azure AD.
App Registration
Start off by creating an App Registration in Azure AD — this is what Splunk will use to query the Sign-In logs.
- Sign in to the Azure portal using either a work or school account or a personal Microsoft account.
- If your account gives you access to more than one tenant, select your account in the upper right corner. Set your portal session to the Azure AD tenant that you want.
- Search for and select Azure Active Directory. Under Manage, select App registrations.
- Select New registration.
- In Register an application, enter a meaningful application name to display to users; this doesn’t have to match Splunk.
- Specify who can use the application; we just gave a few of us in IT Security permission to use the App Registration to generate new secret keys that we’ll use below.
Write down the Application (client) ID and Directory (tenant) ID and ensure the App Registration has the following API Permissions:
- ServiceHealth.Read
- ActivityFeed.Read
- ActivityFeed.ReadDlp
- ActivityReports.Read
Finally, create a new Client Secret. Write it down, because I couldn’t find where to display it later. This will be used by Splunk as the “password” to connect to Azure AD and ingest the Sign-Ins.
Microsoft 365 App for Splunk
The Microsoft 365 App for Splunk has a lot of dashboards and relies upon the Splunk Add-On for Microsoft Office 365 (below). This App doesn’t require much if any configuration — that comes from the Splunk Add-On for Microsoft Office 365 next.
The Microsoft 365 App for Splunk has a few dependencies for the dashboards to display correctly; these are optional if you’re only wanting the Add-On and not the App (with dashboards):
Splunk Add-On for Microsoft Office 365
Download and install the Splunk Add-On for Microsoft Office 365 to configure your Azure AD connection into Splunk.
Once in that Add-On, go to the Tenant tab and input the following:
- Name – this can be whatever you want to use within Splunk
- Endpoint – either “Worldwide” or “USGovGCCHigh”, we chose “Worldwide”
- Tenant ID – paste this in from earlier (Directory (tenant) ID)
- Client ID – paste this in from earlier (Application (client) ID)
- Client Secret – paste this in from earlier
Next, create Inputs for the types of data you’d like to ingest. Here is how I configured ours:
We placed our Azure AD logs into a dedicated “azure” Index in Splunk, but you might want to place them in a different Index for how you have Splunk architected.
Verification
Finally, verify that data is successfully arriving by running one of the following searches on your search head depending on which input type you have defined:
- sourcetype=o365:management:activity
- sourcetype=o365:service:status
- sourcetype=o365:service:message
- sourcetype=splunk:ta:o365:log
Conclusion
Thank you to our Splunk sales engineer for pointing us to this Splunk blog post detailing exactly what we needed to do. We wasted so much time trying different Apps and methods to bring the logs in, but once we found that blog post then we were up and running the same day.
I love the dashboards on the Microsoft 365 App for Splunk in identifying geographically improbable logins. My team has used that to identify compromised accounts and disable them before they’re used to try and send spam or login to our systems. I’m also working on feeding the logins to Splunk Enterprise Security under Identity so that we can use Splunk ES’s intelligence regarding authentications. Hopefully I’ll be able to write something up on that once complete.
Thanks for reading!
