Examine the Sign-in logs

Jonas Bøgvad
Jonas Bøgvad

Table of Contents

Whenever a Sign-in occurs to Azure AD, it will be logged under Sign-in logs; this is our source for troubleshooting or determining whether Azure AD authentication was successful or unsuccessful. If you want to troubleshoot an unsuccessful sign-in or determine when and why challenges were required or not, the sign-in logs will provide additional information.

Before troubleshooting sign-in logs, it is highly recommended that you try to understand Primary Refresh Token. This will give you a head start in determining the authentication details for a specific scenario.

For starters, what is a Primary Refresh Token?
Some would argue that authentication relies solely on user identity, but you are incorrect 🤥

Digging in

Accessing Azure AD and selecting Sign-in logs will reveal all authentications that have occurred to Azure AD with a given identity. You will be able to examine which applications a user has been granted or denied access to by identifying the user in question.

Learned the hard way to stop trying gather logs with the same account you test with😏

Let's check the Azure AD sign-in logs to see if there are any recent entries.

Take a look at the screenshot; you will see the date, the user, and the application. I have removed the columns so that the view is straightforward. I visited portal.office.com and logged in with my user to complete my sign-in.

If we add the column resource, we will be able to see which application I communicated with, which is OfficeHome and Office365 Shell WCSS-Client. These are the "front end" applications that we see on our screen and with which our sign-in communicates to gain access to the resources.

  • OfficeHome is the application we use when we access portal.office.com
  • Office 365 Shell WCSS-Client is the browser code that runs whenever a user navigates to (most) Office365 browser-based applications. The shell, also known as the suite header, is shared code that loads as part of the majority of Office365 workloads, such as SharePoint, OneDrive, Outlook, Yammer, and many others.

Now let's add the resource column.

Each application to which we are granted access provides us with access to the requested resources.

  • Microsoft Graph (Microsoft is taking advantage of graph to show us data within a resource)
  • Office 365 Shell WCSS-Server (is the resource that holds our data in Office 365)
  • OfficeHome (is the resource Microsoft uses to show portal.office.com)

Single Sign-On

I've added the columns "Incoming token type" and "Authentication requirements" to verify that I'm using SSO to access applications and resources after the first MFA prompt (challenge to get my claim), you will see that i am using my PRT token for the rest of my session.

If we click on the first entry, we will discover that I was tasked with MFA.

MFA challenged is validated by "MFA completed in Azure AD".

Now, let's verify that we've used SSO without further challenge to another application or resource.

As you can see it says "MFA requirement satisfied by claim in the token".

What do we end up with?

Now we have the following:

  • When - Date
  • Who - User (The identity (User) doing the sign-in)
  • How - Application (The client (Application) used for the access)
  • What - Ressource (The target (Resource) accessed by the identity)

In addition, we validated Single Sign-On by examining the logs.

More information

Basic info in the Azure AD sign-in logs - Microsoft Entra
Learn what the basic info in the sign-in logs is about.