• in Entra ID
  • 4 min read

Entra Useless Insights Report

Overview

Yes. The name is snarky on purpose.

With the drive to using phishing-resistant MFA something on the mind of many organizations, I’ve been taking a look at the Usage & Insights Report features in Entra, specifically the Authentication methods activity report.

Enumerating the type of authentication methods registered on a user, on a per-user basis, can be time consuming, and would become untenable in extremely large organizations.

Authentication methods activity reporting to the rescue – right? Not so much.

In digging into the report, whether it’s through the Entra admin center or through Microsoft Graph PowerShell SDK, the data reported through this is just astoundingly awful if you want to try and build some basic measurements around who is actually registered for passkeys (FIDO2); I haven’t looked to see if it’s as awful with other methods.

Luckily in the tenant I’m examining, there are only a few hundred user objects, so it’s also feasible to enumerate each user the long way, which I’ll cover below as the workaround. I’ve posed a complaint to Microsoft in some channels and have yet to hear anything back, other than similar experiences from a few others.

An Interesting M365 Billing Scam

Update

I called the 888 number this morning and it does indeed go to a scam call center. I played along with the person on the other end, who ultimately wanted my first and last name, email address, the order number, and most importantly, my credit card number, so they “could reverse the charge” 🤣

The Scam

This is a case where I’d actually love to see how this plays out – when you see the way that scammers try to string things together. I’ve been receiving a rash of unpaid toll bill texts, which give themselves away pretty easily based on the source number. But I’m not here to talk about that scam.

Instead, I’m here to dig into this email I received last week:

  • in Entra ID
  • 6 min read

Spying On Your ISVs Credential Choices

Overview

Microsoft, and the general identity industry, has recommended that applications use certificates over secrets when it comes to credentials for things like applications. This recommendation has existed for about as long modern authentication and authorization systems have existed – over a decade now. Yet the reality is that there continues to be mystery shrouded around certificates, and sysadmins and developers still lean into using secrets.

Secrets are problematic because they are nothing more than a password. Secrets are so much just a password that while Microsoft might refer to secrets as secrets in the UI for Entra, the underlying attribute name is passwordCredentials! While you can use systems like Azure Key Vault for secure management of who has access to the secrets, the reality is that secrets tend to be managed insecurely, both in transport and at rest. Identity Protection exists for workload identities, but it is not real time, and there are scenarios where it will not help you if the abuse is coming from inside the same trusted network.

It’s easy for organizations to determine what they are using with single-tenant applications, or if they are a developer of a multi-tenant app. A quick Microsoft Graph API call to applications/objectid of the application (app registration), and you can examine whether the application has certificates, secrets, or both assigned as credentials. You can also store credentials on the service principal, which I cover here, Entra App Registrations and Enterprise Applications: The Definitive Guide – Eric on Identity.

  • in Entra ID
  • 12 min read

The Intersection of Graph and Entra ID: Application Permissions and Roles

When you work someplace that develops software that interacts with Entra ID, the question of Graph permissions eventually comes up. With the recent Midnight Blizzard attack against Microsoft, where a threat actor appears to have used service principals and Graph permissions to access resources in Microsoft’s own Entra tenant, the scrutiny on permissions grows even more intense. You can read more about this with a great write-up from Andy Robbins here, Microsoft Breach — What Happened? What Should Azure Admins Do? | by Andy Robbins | Feb, 2024 | Posts By SpecterOps Team Members.

Primer on the Microsoft Graph API

Before jumping into the permission weeds, let’s review a few things to set the stage. If you already understand the Graph API basics, feel free to scroll past.

What is Graph API

The Microsoft Graph API is the unified API endpoint into most Microsoft 365 services, which includes Entra ID. For purposes of this article, the terms Graph and Graph API refer to the Microsoft Graph API.

Figure 1

Microsoft Graph API diagram / Courtesy Microsoft Learn

You can read more of an overview about the Graph API here, Microsoft Graph overview – Microsoft Graph | Microsoft Learn.

  • in Entra ID
  • 10 min read

Dude, Where's My Audit Logs?

Audit logs can provide all sorts of wonderful points of data. In the interest of identity security, we have historically seen that we can glean rich sets of information around what’s happening in a directory service with some properly functioning audit logging. For many identity practitioners, there is the expectation that while we may not always look at the audit logs or their details, if or when we need them, they’ll be there to help us understand whatever it is we are investigating. Same goes for compliance and auditing as well.

Considering that customers have no ability to impact what or how auditing happens in Entra ID, in the shared responsibility model, it’s on Microsoft to ensure all events are audited.

Figure 1

Shared responsibility model, courtesy Microsoft, with identity and directory infrastructure highlighted.

Microsoft documents what is audited in Entra ID, which you can find here, Azure Active Directory (Azure AD) audit activity reference – Microsoft Entra | Microsoft Learn.