Azure AD Sign-in logs for service principals and other recent improvements

The Azure AD sign-in logs are an indispensable tool for troubleshooting and investigating security-related incidents. For years they had a major flaw though – no records were being generated for any login made by using the client credentials grant flow. Well, Microsoft has finally delivered on this front, so rejoice!

To access the service principal login entries, you can use the Sign-ins tab in the Azure AD blade, then hit the Service principal sign-ins tab. Note the banner on top, it indicates that I’m using the new Preview experience, which you must switch to in order to get the SPN sign-in logs.

Azure AD sign-in logs

By default entries from past 24h will be displayed, but you can adjust the window to up to 30 days by using the Date selection dropdown. Other settings include the option to toggle between local and UTC timestamps, control how entries are being aggregated (you can choose between 1 hour, 6 hours, 1 day) and add optional filters, such as the Service principal ID or name, IP address, Resource, and more.

The entries themselves are represented in aggregated view, and you have to expand a given group in order to get additional details on a particular sign-in. Under the Details pane, you will see info as to the date the activity was performed, status, application, resource and service principal details, IP address and resolved geo-location. Comparing the details with a “regular” sign-in, you will note a lot of missing data, most notably the Conditional access details. Unfortunately, Conditional Access policies still do not apply to logins performed via the client credentials flow, making it that more important to be able to report on any and all activities performed via a given application.

If needed, you can Download the data in CSV or JSON format. For the former, the file name will resemble something like “ApplicationSignIns_2020-09-26_2020-10-03”. You can also Export the data to a Log analytics workspace, which is Microsoft’s preferred method of working with the sign-in logs. At this time, the service principal sign-in logs do not flow into the Unified Audit Log within Office 365, aren’t consumed by MCAS and cannot be accessed via the Graph API, making the Azure AD blade and Log analytics your only choices. Support for Graph API should be coming fairly soon, as evident from the method used inside the portal, namely querying an Azure AD Graph endpoint like the below one:

https://graph.windows.net/xxxxxxxxx-352a-4eda-bece-09d0684d0cfb/activities/getSummarizedNonInteractiveSignIns(aggregationWindow=’1d’)?$filter=(createdDateTime ge 2020-09-29T10:45:04.987Z and createdDateTime lt 2020-09-30T10:45:04.987Z)&$top=50&$orderby=createdDateTime desc&source=kd

It’s also interesting to note that no “first-party” service principal sign-ins are being exposed, which is probably for the best, given the number of entries this will result in. Most organizations will likely only care about any entries corresponding to applications they own, and third-party integrations.

Some other interesting news below, you can skip the rest of the article if you only care about the SPN Sign-in logs.

First, an updated consent dialog can be seen below:

100320 0827 AzureADSign2

Next, we have updated branding controls, including the option to specify dark-theme images. More importantly, we can now use basic markdown-style formatting for the text control, including bold, italics, underline and hyperlink formatting:

  • Hyperlink: (link)
  • Bold: **text** or __text__
  • Italics: *text* or _text_
  • Underline: ++text++

The hyperlink controls in particular might bring some unease, as for years we have been training users not to click anything on login pages, but on the other hand can be useful for redirecting people to your helpdesk page and such. Below is an example of how the response looks like in code and on the page:

100320 0827 AzureADSign3

{“Username”:”pesho@michev.info”,”Display”:”pesho@michev.info”,”IfExistsResult”:0,”ThrottleStatus”:0,”Credentials”:{“PrefCredential”:1,”HasPassword”:true,”RemoteNgcParams”:null,”FidoParams”:null,”SasParams”:null,”CertAuthParams”:null,”GoogleParams”:null},”EstsProperties”:{“UserTenantBranding”:[{“Locale”:0,”BannerLogo”:”https://aadcdn.msauthimages.net/c1c6b6c8-oshmh-bip8duot7itxwugzdtsj7d5vdw9gkh2ys0bno/logintenantbranding/0/bannerlogo?ts=636836777778040687″,”BoilerPlateText”:”<p>Bla bla bla bla\n<a href=\”http://maliciousURL.com\” rel=\”noopener noreferrer\” target=\”_blank\”>http://google.com</a></p>\n”,”KeepMeSignedInDisabled”:false,”UseTransparentLightBox”:false}],”DomainType”:3}…}

In addition, we should soon be getting mobile-specific customizations.

On PIM’s side of things, new Alerting experience has been made available, as well as a preview of Discovery & Insights. This includes a new wizard-driven interface to help you reduce the number of permanent role assignments, including support for service principal assignments. Make sure to check this Ignite session for additional details on this: https://techcommunity.microsoft.com/t5/video-hub/get-to-least-privilege-in-azure-active-directory-and-microsoft/m-p/1698823

5 thoughts on “Azure AD Sign-in logs for service principals and other recent improvements

  1. axyrium says:

    I’m troubleshooting an issue where several people in the org are randomly getting logged out of the locally installed Office apps (including OneDrive) on their AAD joined devices. We can usually get them signed back in, but eventually and randomly (sometimes hours later) they get signed back out of one or more of the apps. (Sometimes one Office app works, but they’ll get signed out of another).

    in searching for answers I stumbled on this page and see that when looking at the sign-in logs for service principals there are multiple login failures from the Office applications and Windows search for all users. Any ideas on why this might be happening where to look for more info?

    Thanks!

    Reply
  2. Mike says:

    It’s 2023 and, sadly, it seems I still cannot access the Service Principal or Managed Identity sign-in logs via Graph 🙁

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.