Azure Microsoft Graph Audit Logs integration via API

First of all, we log in to Azure with a user with administrator authorization.

Then we need to click on the Microsoft Entra ID tab and make App Registration from there.

I indicated where it is in the image.

You will only need to provide an application name related to the registration process.

After registering, you can see Client ID and Tenant ID information under overview. You need to save these. You will need them during the resource addition phase.

Then we need to click Certificates & secrets and create a Secret Value.

After clicking on the new client secret tab, let's write a name in the section on the right and specify the time you want it to be valid.

We need to make a note of the secret value we created. This information is visible once, you need to save it when you create it.

We need to enter the API Permission field, click Microsoft Graph and click Application Permission in the window that appears. Then just type audit in the search box, you can select everything under the auditlog tab in the field that appears.

You can open everything under the Audit tab that you want to get logs from this area.

The minimum permission the integration actually needs is AuditLog.Read.All (application permission). If you also plan to collect sign-in logs and you want to see which Conditional Access policy was evaluated, add Policy.Read.ConditionalAccess (or Policy.Read.All) as well. Without one of those policy permissions Microsoft Graph omits the applied Conditional Access policy list from the response, so the sign-in record still arrives but the policy name and the enforced control stay empty.

When finished, you need to click Grant admin consent and complete the authorization.

Then we can go to the source addition area and select API > Azure Microsoft Graph Audit and enter the information we have previously saved in this field and pull the logs to Logsign USO.

Then you need to enter the following fields on the source addition screen.

We have collected the information required to get audit logs while configuring, we can write this data in the fields above. Scope and Base URL information is given below. If this information is written incorrectly, audit logs will not be received.

Client Secret > Obtained during configuration.

Client ID > Obtained during configuration.

Tenant ID > Obtained during configuration.

Scope > https://graph.microsoft.com/.default

Base URL > https://graph.microsoft.com

Log Types > Optional. Leave it empty to collect directory audit logs only, or select the routes you want to collect. See the section below.

Log Start Date > How far back the first collection reaches. It can only be set while the source is being created. If it is left unset, the poller starts 12 hours back.

Then when you check connection, it should return success.

The connection check only requests an access token from Microsoft. It does not read the audit endpoints, so a missing permission or a missing license still returns success here and shows up later in the poller logs.

Log Types

The source can collect two Microsoft Graph routes. The Log Types field is a multiple selection and it is optional.

An empty selection means directory audits only, which is also what sources created before this field existed keep doing after an upgrade. Sign-in collection is opt-in: nothing changes on an existing source until you select Sign-ins and save it.

The two routes keep separate collection positions, so enabling sign-ins does not reset or interrupt the directory audit collection of the same source.

How the logs are collected

Each poll asks for one time window per selected route, at most 60 minutes wide, and follows the paging links until the window is finished (up to 50 pages, with a 2 second pause between pages). The request timeout is 180 seconds.

Microsoft Entra writes audit and sign-in records with a delay of a few minutes, so every window is re-read 30 minutes back and repeated records are removed by their record id. You should not see duplicates in Logsign because of this overlap.

Because of the 60 minute window and the 30 minute overlap, a source that is far behind moves forward around 30 minutes of log time per poll. Selecting a long Log Start Date value means the back-fill needs many poll cycles before the source reaches the current time.

Normalized fields

The fields below are filled for sign-in records. Directory audit records keep the same data under nested keys (for example initiatedBy_user_userPrincipalName), so for that route only the record id and the category are normalized and the rest stays under AzureGraphAudit.*.

A sign-in usually lists every Conditional Access policy of the tenant, including the ones that were not applied. Logsign keeps only the decisive ones: if a policy blocked the sign-in, that policy is written to Policy.Name, Policy.ID and Event.Action, otherwise the policies that were applied successfully are written. Policies with the result notApplied, notEnabled or report-only are dropped.

Fields that are not in the table above are still searchable under the raw AzureGraphAudit.* namespace, for example AzureGraphAudit.conditionalAccessStatus, AzureGraphAudit.caPolicyResult and AzureGraphAudit.location_city. Source country and city are filled from the GeoIP lookup of Source.IP.

Sign-in records are classified as Identity / User / Login when the status error code is 0, and as Identity / User / Deny for every other error code, including a Conditional Access block (error code 53003). Directory audit records keep the default Security / Alert / Info classification.

Troubleshooting