How to add the inviter to a guest user object in Azure AD using a Logic App, Graph API, and Log Analytics Rest API

We recently brainstormed about Azure AD Guest Management. If an organization is not (yet) able to use Access packages and reviews for their Access Management and Guest Handling they might want to establish other processes to revalidate Guest Accounts.

One Method could include asking a responsible person if the guest’s account and his access are still valid. In our case, the responsible person was the user which invited the user to the Azure AD. To be able to identify the responsible person we thought about assigning the inviting person as a manager to the guest account. This could be used afterward to trigger some automation to expand the identity of the guest.

In this blog article, I will show you a way how to use Azure Log Analytics and Azure Logic Apps to fulfill the governance requirement described above.

Short Description of the Process

A scheduled Logic App will crawl the Audit Events from a Log Analytics Workspace in intervals. If the Log Analytics query finds new guests invites the UserID and InvitingUserID from the AuditLog will be used to identify and update the guest user accordingly by using the Graph API.

Log Analytics

Every admin action and more is stored in the AAD Admin Audit Logs. If you’re interested in this topic it’s likely that you already use Log Analytics to retain and handle your audit logs. If not, you can follow this instruction to enable it: Stream Azure Active Directory logs to Azure Monitor logs – Microsoft Entra | Microsoft Docs. This screenshot shows the minimum required Azure Active Directory Diagnostic Setting for the following tasks:

With that setting, you can query your AAD Audit Logs for any Event. You can do this with KQL. As you hear from every site – especially the #secinfo bubble – KQL is a great tool to explore your data. Unfortunately, I’m not experienced with it yet. But my co-worker Andre build a small query that fits our needs. You can start trying it out and query your Logs in Log Analytics for Guest Invites eg by using this KQL Query:

The query should list all invites and the relevant user data created in the last 24h.

App Registration / Authentication

We’re using the HTTP connector of the Logic App to assign the Manager via Microsoft Graph. To be able to authenticate against the Graph we’ve created an Azure AD App Registration. The App Registration is using App Permissions and has the permission ‚User.ReadWrite.All‘ assigned. To generate the token we’ve created an App Secret and stored it in an Azure Key Vault.

You can also use the Azure AD connector to get this job done. When I wrote this article you could only use a regular user authentication with this connector which we wanted to avoid. If you do so you can skip this step and use user-based authentication with all its caveat.

Logic App – Preparation

The processing of this task is done by a Logic App. The Logic App needs to connect and authenticate to the Log Analytics Workspace and to Microsoft Graph. While we’re using the App Registration described above to authenticate against AAD/Microsoft Graph, we can use a managed Identity to authenticate for Log Analytics. To be able to do this we need to enable a system-assigned managed identity for our new Logic App:

Next, we need to assign the ‚Log Analytics Reader‘ Role for the Log Analytics Workspace to the newly created Managed Identity. With that setting, our Logic App is able to authenticate and query for the events we need from the Log Analytics Workspace.

If you’re using an Azure Key Vault to store the App Secret (which you should do) you can also assign the ‚Key Vault Secret User‘ Role for the secret to the managed Identity.

Logic App – the steps

The Logic App is using the recurrence trigger. It should be enough that new guest users were processed once a day. Afterward, we initialize and fill the Variables for the Tenant ID, the App ID (of the App Registration we’ve created before), the Log Analytics Workspace ID, and the query we’re using to extract the audit events.

The query is the same as in the example above but only returns the essential id’s.

The timefilter we use in the query should match the interval of the recurrence trigger to avoid that guests being handled more than once. In this example the Logic App is triggered once a day.

Now we can go on and query Log Analytics. I’m using the Log Analytics Rest API and an HTTP Request instead of the build-in Log Analytics connector because it allows the authentication as a managed identity instead of user-based or SPN Authentication.

To be able to parse the output of the query I’ve started the LA once and used the result of the HTTP Action as sample payload.

We have now all information we need to update our guest accounts. Unfortunately, the output of the query is not so easy to process as I’m used to it from regular Graph API Queries. So we’ve used some loops and positional arrays to be able to select the right values. A loop to process each table, another for each row where I’ve then selected the first value as GuestUserID and the second one as the InvitingUserID.

To avoid update errors for Guests which were renewed because of Layer 8 problems etc, we check the existence of the user before with the request above. If the HTTP request results in a Status=200 the Logic App proceeds using an update request against the Graph:

That’s it! Now the Logic App will run daily and set the manager field to the value of the user who invited him.

The complete flow looks like this in our lab:

You can prove it by using e.g. a Log Analytics Query to find the specific update Events:

The result in the screenshot says that the AppReg ‚GuestGovernance‘ was used to set a new manager to a Guest Identity.

Thoughts?!

What would you do with this information to improve Guest Identity Governance? Do you have other ideas how to improve guest governance efforts?

I’m happy about every feedback. You can reach me via Twitter

Other news