Harness: -Credential finds a Microsoft Entra account's session

[fadwen]

Summary

Fixes -Credential on the five Invoke-Intune*Test commands for Microsoft Entra accounts. The launcher could not find such an account's session unless the credential happened to name it the way Windows does, and failed or fell back to the stored-password task otherwise.

This closes the item #4 left open under "Not changed" as the query user long-name case, carried forward in #5. Measured on a device, the name length was never the problem: the parser reads the output correctly. The name being looked for was the wrong one.

ModuleVersion is not bumped; the change is under Unreleased in the changelog.

What was measured

On the Entra joined lab device (VM 125, 2026-10-05), with a tenant user created for the purpose and signed in at the console:

Signs in as	isl-verylongusername-test01@4nlnm3.onmicrosoft.com (27 characters before the @)
Display name	Isl Verylongdisplayname Testaccount
Windows calls it	AzureAD\IslVerylongdisplayna

• The Windows name is the display name without its spaces, cut at 20 characters. It is neither the sign-in name nor a part of it. Round 1 had the same shape: signed in as betar@..., running as AzureAD\JeffStuhr.
• query user prints that name in lower case. The user name column is 22 characters wide and the name stopped at 20, so the parser's split held. No name longer than 20 characters was seen.
• NTAccount.Translate resolves AzureAD\<sign-in name> and AzureAD\<Windows name> to the account's SID. The bare sign-in name, the bare Windows name and AzureAD\<part before the @> do not resolve.
• A scheduled task accepts only the Windows name for an interactive principal. The sign-in name and the SID string were both refused at registration ("No mapping between account names and security IDs was done").

Cause

Invoke-IslProcess took the credential's user name apart as text (the part after a backslash, or before an @) and looked for that in query user. That works for a local account, whose Windows name is that text, and cannot work for an Entra account.

Changes

• Private/Resolve-IslAccount.ps1 (new). Asks Windows for the SID behind the credential's user name, trying AzureAD\ in front of a sign-in name that does not resolve as given, and for the name Windows gives that SID. Returns nothing when the name does not resolve; the caller then works with the name as before.
• Invoke-IslProcess. Matches the session on the resolved Windows name and registers the interactive task for it. The result's UserName and RunAs still carry the credential's name as given. The stored-password path is unchanged.
• Grant-IslFolderAccess. Grants the run folder by SID when the account resolves, since a sign-in name is not a name icacls looks up.
• Grant-IslFolderAccess, error message. Under -ErrorAction Stop on Windows PowerShell 5.1 a refused grant ended with icacls' bare line instead of the message naming the account and the folder, because 5.1 turns a native command's redirected stderr into error records. The 5.1 gate caught this through the new test on the first push; the function now reads the output under Continue.
• Documentation. Validation/Findings.md ("The harness as another account") replaces the "not measured" note with the table above. The README and the -Credential help of the five harness commands say how an Entra account can be named. MAML rebuilt.

Before and after on the device

The module run as SYSTEM through the guest agent, the same probe script and the same signed-in user, -Credential naming the account three ways:

Credential names the account as	Before	After
user@domain	Refused: "No mapping between account names and security IDs was done"	Ran in the user's session
AzureAD\user@domain	No session found, stored-password task: "The user name or password is incorrect"	Ran in the user's session
AzureAD\IslVerylongdisplayna	Ran in the user's session	Ran in the user's session

Every successful run reported who=AzureAD\IslVerylongdisplayna session=2 interactive=True with RunAs ending in (Interactive), and left no scheduled task and no run folder behind.

Verification

• Unit and integration suites: 927 pass on PowerShell 7.6.6 (8 skipped: elevation, lab credential). On Windows PowerShell 5.1 the unit suites and two integration files: 877 pass (33 skipped).
• New tests: the resolver against the machine's own accounts and against the device's answers played back; the launcher finding an Entra session by its Windows name, and not taking another account's session for a sign-in name that only looks like it; the folder grant landing on the SID; the 20-character query user line as the device printed it.
• PSScriptAnalyzer (Error and Warning) is clean, no line is over 115 characters, the help Markdown validates and Build/Publish-Module.ps1 -WhatIf stages and verifies the package with the new private file in it.

Not changed

• The stored-password path still registers the task with the credential's name as given. It was not exercised for an Entra account.
• Two accounts with the same Windows name in different domains, both signed in, would still be indistinguishable in query user. That was true before and is not addressed here.
• The tenant user stays in the dev tenant with the other lab objects, and its profile stays on the lab device.