I have been getting a lot of questions from customers about the configuration of the Azure AD Connector in Microsoft Sentinel. OK, I have not been asked, but just in case I am, I want to be sure I can explain the various logs ingested by Microsoft Sentinel.
The Azure AD Connector is an out-of-the-box connector developed by Microsoft. Making the experience of using this connector is smooth. Most of the breakdown I will discuss comes directly from the documentation (Connect Azure Active Directory data to Microsoft Sentinel | Microsoft Docs). I will try to add some more examples and explanations for clarity.
At the time of this writing, only two logs are not in the preview, Sign-in Logs and Audit Logs.
To ensure that the Azure AD Connector can see these logs, they need to be sent to the Log Analytics workspace that Microsoft Sentinel is using. Selecting these logs is done through the Diagnostic Settings in Azure AD.
"Contain information about interactive user sign-ins where a user provides an authentication factor." Accessing the logs is the same view of data you can access from Azure Active Directory > Monitoring > Sign-in logs. The sign-in logs are where you see all those users' interactive logons, success, failure, locations, and device information. I use this log to examine Conditional Access, especially when testing policies.
"Contain information about system activity relating to user and group management, managed applications, and directory activities." Audit logs can also be accessed via Azure Active Directory > Monitoring > Audit logs. These logs are the meat and potatoes of what is going on with Azure identity needs. You will see the management of policies, groups, and applications within these logs. I want to know when an application is created or updated within Azure. Application creation or modification can give insight to something rouge that main be going on.
Also, at the time of this writing, there are seven more logs in preview.
Non-Interactive User Sign-In Logs
"Contain information about sign-ins performed by a client on behalf of a user without any interaction or authentication factor from the user." Think of these sign-ins as something that occurs in the background. For example, you have an OAuth 2.0 token. You use this token to perform Single Sign-on (SSO).
Service Principal Sign-In Logs
"Contain information about sign-ins by apps and service principals that do not involve any user. In these sign-ins, the app or service provides a credential on its behalf to authenticate or access resources." An application may use a Service Principal to log into Azure AD. Authentication will usually be in the form of a certificate or client secret.
When you register an application, a Service Principal is created. Application registration would be a good thing to monitor to determine if rogue applications are registered.
Managed Identity Sign-In Logs
"Contain information about sign-ins by Azure resources that have secrets managed by Azure." These are similar to Service Principals in that they are used to authenticate an application. Where they differ is that the credentials are managed in Azure AD. You don't even have access to them.
"Contain system activity information about users, groups, and roles provisioned by the Azure AD provisioning service." I know that explanation is pretty vague. The provisioning log audits activities dealing with Enterprise Applications. For example, provisioning of an Azure AD user into Salesforce or ServiceNow.
ADFS Sign-In Logs
Using the Azure AD Connect Health, you can enable the collection of Active Directory Federation Service (ADFS) Sign-in logs. Of course, this would only be applicable if you are using ADFS to federate your logon to Azure AD, which is significant with organizations that use Smart Cards.
When this log collection is enabled, you will see the same information as the Sign-In Logs. If you are using Azure AD to view the Sign-In Logs, these logs are correlated into the same view.
If you perform Incident Response or Hunting activities, having this data can give insight into lateral movement from on-premises to Azure authentication.
User Risk Events
This log and the next log, Risky Users, come from Azure AD Identity Protection. User Risk Events are similar to the Azure AD Identity Protection Risk Detections. These would be events like anonymous IP addresses, atypical travel, and leaked credentials.
This log would be similar to the Risky Users report in Azure AD Identity Protection. Risky Users log is a list of users that may be at risk. Risky Users would be great information to correlate against other logs collected in Microsoft Sentinel.