Skip to content

2025

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:

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.