Unpacking Authentication Between Entra ID Joined Workstations

In enterprise environments, increasingly built on Microsoft Entra ID (formerly Azure Active Directory), assumptions from traditional domain-joined networks no longer hold in many cases. During a recent engagement, I encountered an unexpected twist: Entra ID joined machines on the same LAN were able to authenticate with each other — but not using NTLM or Kerberos in any familiar form.

Worse, my usual tools (like CrackMapExec, NXC, and Responder) broke down entirely when targeting these machines, and all authentications had to be performed natively from a Windows machine. This blog post aims to dissect why this happened.

⚠️ Note: Microsoft Entra ID used to be known as Azure AD. It can be confusing because authentication still refers to users as AzureAD\user, and much of the Microsoft documentation around this topic still calls it Azure AD. Just know that anywhere you see Microsoft Entra ID, you can think Azure AD, and vice versa.

Answering Key Questions About Entra ID Authentication

This post walks through the authentication quirks I observed between two Entra ID joined Windows 10 machines. Specifically, this article answers:

What auth protocol is actually in use?
Why do traditional tools fail?
Can you relay or capture hashes?
Do PINs behave differently than passwords?
Can you dump creds remotely?
Can you use Nessus for a remote, authenticated scan?

TL;DR: A Summary of Entra ID Authentication for the Impatient

Entra ID Users are not stored in the software asset management (SAM). Therefore, Net-NTLMv2 authentication breaks.
NTLM and Kerberos do not function as expected — even NTLM relay does not work.
Authentication over Server Message Block (SMB) prefers PKU2U certificates after going through the process of SPNEGO → NEGOEX → PKU2U. NTLM authentication is not possible for accounts that are only joined via Entra ID.
Linux tools like smbclient or impacket tools fail because they cannot participate in this flow (they do not have a PKU2U certificate option).
Passwords entered by Entra ID users during poisoning attacks may still trigger Net-NTLMv2 handshakes, but not if the user signs in via PIN (Windows Hello), because then it is attempting authentication via PKU2U. So they are useful to crack but not to relay.
Relaying Entra ID creds does not work across Entra ID joined machines even if you get a NetNLTMv2 handshake because of the aforementioned NTLM failing.

Test Environment Setup

To reproduce the behavior:

Domain: Custom Entra ID tenant.
Devices: Two Windows 10 machines, both Entra ID joined using the same Entra ID account and tenant.
Networking (SMB sharing is enabled on both):
- Windows 10 (Commando): 192.168.2.3
- Windows 10 (Clean, vanilla): 192.168.2.1
- Kali Linux: 192.168.2.4

⚠️ Note: PIN login was enforced by default via Windows Hello for Business (WHfB).

The Weirdness Begins: SMB Authentication

I expected NTLM or Kerberos over SMB, but authentication failed when using the Entra ID account from anything but another Windows box.

The three tests that were conducted to force Net-NTLMv2 handshakes are below.

Test 1: Via File Explorer

When attempting to capture a Net-NTLMv2 handshake from the user logged into the clean Windows 10 machine by using Responder on Kali, a PIN authentication was prompted. The setup for this was:

Kali listening with Responder (responder.py -I eth0 -P) on 192.168.2.4.
Using clean Windows 10 from 192.168.2.1 to attempt to authenticate to Responder over SMB via the file explorer.
A PIN was requested of the user on the clean Windows 10 machine. It did not send any credential material to Responder, and file explorer on the clean Windows 10 machine indicated an issue.

Figure 1. Clean Windows 10 cannot authenticate to Kali's Responder instance after entering user's PIN.

Result: The prompt asked for a PIN, not a password, and the authentication failed. Responder could not trigger the expected NTLMv2 hash leak here.

Test 2: Via a Browser Without the Proxy Auth Option Enabled

When a PIN wasn't used — or if I forced a password entry — it got interesting.

Using Responder without the proxy auth, I captured a standard Net-NTLMv2 hash.

I cracked it to confirm: it’s the real password. This hash was sent before the Windows prompt even asked the user for credentials.

Figure 2. Net-NTLMv2 handshake captured after authenticating without proxy auth.

Result: Responder captured a crackable handshake when authenticating via a basic auth prompt in the browser.

Test 3: Via File Explorer Without the Proxy Option

The test setup is the same as the previous two, but without using the proxy option in Responder. This Net-NTLMv2 handshake came in prior to entering creds, which is the standard way Responder works — transparently to the user.

Figure 3. Responder working as normal capturing a handshake transparently to the user.

The handshake that was captured cracked successfully to the correct password. There is a subtle difference in this test vs in Test 2. This one shows the Entra ID account in the same way that it appears in Windows. The format is AzureAD\user@FDQN.com. In Test 2, I entered a credential for user@FQDN.com. Figure 4 shows what the credentials being passed look like when they are obtained from a Windows 10 machine transparently to the user.

Figure 4. Cracking the Net-NTLMv2 handshake.

Result: This is probably the most important result that we can see. The authentication to Responder happened transparently to the user when the user attempted to connect to the Responder instance. It tells us that it is possible for SPNEGO to authenticate via Net-NTLMv2 if it is requested by the server. However, during our testing of authenticating to a Windows device with Net-NTLMv2, the authentication did not work, because SID mapping was wrong Error! Reference source not found. (addressed in more detail later).

This example is possibly an edge case that was not intended to ever happen in a Windows environment, but because Responder can handle the entire authentication flow, we were able to retrieve a Net-NTLMv2 handshake containing the credential material for the Entra ID account.

Attempting Relays and Failing

So what about relaying? I tested NTLM relaying using ntlmrelayx between Entra ID joined machines.

Test setup:

Kali Linux: 192.168.2.4 was running ntlmrelayx.
Clean Windows 10: 192.168.2.1
Commando Windows 10: 192.168.2.3

It failed even when hashes were captured. From the attacker’s viewpoint, several connections appeared to be initiated, but all of them failed. What is likely happening is that the authentication protocol between Entra ID joined machines prefers PKU2U certificates. SPNEGO leads to NEGOEX negotiation, and eventually to a cert exchange that ntlmrelayx does not have the ability to participate in, so the connection appears blank with no credential material.

When credentials were entered intentionally into a browser on Commando Windows 10, the credentials were captured; but when that connection was sent to the victim clean Windows 10 machine, the authentication failed because NTLM authentication does not work correctly to an Entra ID joined machine.

Figure 5. Clean Windows 10 cannot authenticate to Kali's Responder instance after entering user's PIN.

Result: The prompt asked for a PIN, not a password, and the authentication failed. Responder could not trigger the expected NTLMv2 hash leak here.

Dumping Creds

There are two scenarios to consider when we talk about dumping credentials:

Dumping credentials from a workstation with an Entra ID account
Dumping credentials from a workstation to acquire Entra ID account credentials.

In the first scenario, you will need to use a tool that is able to authenticate with a PKU2U certificate. So realistically, you are limited to something that you can get a session on the machine with, like Mimikatz or a beacon running in the context of a user. For the same reason that none of the other Linux tools work, secretsdump and similar tools will not work.

In the second scenario, as obvious as it may sound, you will need to use a tool that is looking in the right place. Secretsdump, lsassy and things that rely on those tools under the hood are not going to pull any credential material for you because the accounts that are being used by Azure are not stored in the SAM like a cached credential. And, they are not stored in LSASS like other interactive logon credential material. Mimikatz can dump a Primary Refresh Token (PRT) locally.

So Why Do Windows-to-Windows Logins Still Work?

Because they speak the same auth dialect. When a Windows box logs in using an Entra ID account, and you try dir \\otherhost\admin$, it works (assuming your account has admin access to that machine, and 445 is open) — but under the hood, it is not NTLM or Kerberos.

It is likely:

SPNEGO starts the negotiation.
NEGOEX is selected.
PKU2U (certificate-based) is used for actual auth.

But here is the problem: tools like Responder, impacket and any other NTLM or Kerberos based tooling do not understand how to continue this flow. Windows can complete it. Linux cannot.

Why Does NTLM Not Work Between Two Entra ID Joined Machines?

There are a few reasons.

1. Entra ID joined machines do not enable NTLM for Entra ID accounts by default.
When a machine is Entra ID joined (and not hybrid or domain-joined), Entra ID accounts are not mapped to local NTLM SIDs the way traditional domain accounts are. NTLM needs a mapping from a username to a password hash in the local SAM or via domain trust. Entra ID does not do that — instead, it issues a PRT and uses WHfB or cert-based auth (PKU2U/NEGOEX). Even if the account appears as a local admin in net localgroup administrators, it is just a token representation tied to the device trust, not a credential that is usable via NTLM.

2. NTLM does not know who you are.
Net-NTLMv2 needs to have a local or domain NT hash to validate against in order for it to work. Net-NTLMv2 requires certain things:

A challenge from the server
A valid NT hash to compute a response
The receiving host to understand the domain or user context

3. GPO or registry settings may prevent NTLM entirely.
Entra ID joined machines may ship with the following reg/GPO hardening by default or via Intune:

Restrict NTLM. Deny incoming NTLM traffic.
Allow PKU2U auth only for online identities.
Local Security Policy → Network Security: Restrict NTLM. Deny all accounts.

When you attempt Net-NTLMv2 authentication with an Entra ID account against an Entra ID joined workstation, it will fail. Even if the creds were technically correct, the SID is not locally resolvable. This leads to specific event logs using a correct “AzureAD\” username/password combo.

You will see: “Unknown user or bad password,” indicating that the workstation cannot successfully validate the credential material you gave it against known credential material. This is what the event of the failed logon looks like in the Windows Event Viewer (Event ID 4625 is a failed logon).

Notice in Error! Reference source not found. how the TargetUserSid field is a default “S-1-0-0.” Normally, during NTLM authentication, the credentials being presented will get mapped to a user SID on the server (receiving) side. During Entra ID workstation authentication, the SID is required to be sent over with the authentication process. This is one of the things that is very likely breaking the standard NTLM authentication process.

Figure 6. Failed login attempting an Entra ID account with NTLM.

When comparing that to a successful logon (EventID 4624) with the exact same user, the only difference is that the “TargetUserSid” is identified, and the user has a successful login (Error! Reference source not found.).

Figure 7. Successful login with an Entra ID account to another Entra ID joined workstation.

5 Key Takeaways

Entra ID fundamentally changes some assumptions red teamers and blue teamers have relied on for decades. The presence of WHfB, PKU2U and NEGOEX makes lateral movement and credential relaying trickier — and breaks a lot of tools. But when approached differently, this can also offer unique attack vectors to pivot to cloud environments.

PINs stop credential material from getting transmitted to Responder. You must coerce password-based auth to get NetNTLMv2 handshakes.
Relaying Entra ID accounts is extremely limited in scope, if it works at all.
Credential dumping of Azure credentials needs to be approached differently but can offer substantial pivoting capability.
Credential dumping with Entra ID account credentials must be done in the context of that user, likely from their workstation or in the context of the user.
Relying on Kali Linux or remote Linux tools in an environment like this is going to hamstring you.

References

Learn more about CDW’s Threat and Vulnerability services, including Pen Testing, Social Engineering, and Vulnerability Management, to strengthen your defenses.

Learn More