This blog covers one of the most requested features ever: finally being able to automatically translate Entra group SIDs into readable names on the device itself.
Introduction
If you added an Entra group to a local group, it appeared as an unknown SID (not translated to its real name). The same went for the Intune roles Device Administrators and Company Administrators (S-1-12-1…), which are automatically added to the local Administrators group during Entra join and were just as unreadable.
All you saw were weird SIDs, and if you wanted to know what they meant, you had to rely on third-party tools like Oliver Kieselbach’s PowerShell helpers just to convert them into something readable.
That’s been one of the most common requests for years: “Why can’t Windows show the name of my Entra groups the same way it does for users?” Starting with Windows Insider build 27881, that’s finally changing. Let’s dive in.
The Missing Entra SID to Name Piece
The SID-to-name logic itself isn’t new.
Windows has long been able to resolve Entra users correctly. When you added an Entra user to a local group, the UPN appeared immediately.
That flow already used a device-signed lookup through Entra and cached the result locally inside the Sid2Name registry key.
But Entra groups and Intune roles were never part of that SID-to-Name process.
If a group SID wasn’t already cached, Windows had no way to ask Entra what it represented. That’s why entries like Device Administrators or Company Administrators always appeared as raw S-1-12-1 identifiers.
With build 27881, Microsoft quietly filled in the missing half of that story.
A new internal feature called AADSidToNameV2Support extends the same lookup logic from users to include groups and roles.
PS: Please check out this YouTube video if you want to learn to spot those features yourself:
The Hidden Entra SID to Name Translation Layer
For some time, Windows resolved User SIDs through LSA and SAM, but Entra Group SIDs or Intune Roles were invisible to that world. The new version of AAD/ Entra Sid To Name Support changes that.
When Windows encounters a user, group, or role it doesn’t recognize, it now checks the local identity cache first. If it’s not found there, Windows reaches out to Entra, asks who the SID belongs to, and stores the response for next time. Once cached, translations become instant… even offline!!
Cache location: HKLM\SOFTWARE\Microsoft\IdentityStore\Cache\<SID>\IdentityCache
When Windows Does Not Know Who You Are
The process starts in SpLookUpSIDFromIdentityName (cloudap.dll), the same path used by the Local Security Authority when resolving SIDs.
If the SID isn’t recognized, the request flows into DoLookupIdentityFromSID. This function checks whether the device is Entra-joined, and confirms the SID Security Principal type (user/group/role)
From there on, it decides whether to resolve it through Entra. If it is, control passes to ConvertSidToName where the actual cloud lookup happens.
Talking to Entra: the Entra Sid To Name Endpoint
Inside ConvertSidToName, Windows builds a secure request to prove its identity.
It uses SidToNameRequest::BuildDeviceAuthAssertion to create a JSON Web Token signed with the device’s Entra certificate. Inside the request, we can spot the encoded group name that needs translation.
That request is sent to Entra at the endpoint: https://login.microsoftonline.com/<tenant>/sidtoname
Windows then parses the response using SidToNameResponse::Parse, confirms the security principal type through ValidateSecurityPrincipalType, and updates its cache.
Caching the Entra Group / Role SID
After Entra confirms who the SID belongs to, Windows saves the Entra SID to name translation locally for all future lookups.
Each Identity Store Cache entry includes details like:
- IdentityName apv2_users
- SecurityPrincipalType Group
- Sid S-1-12-1-xxxx…
- DisplayName apv2_users
From that point on, Windows instantly recognizes Entra users, groups, and roles, even without contacting Entra again.
Creating the Classic NT4-Style Name
Some Windows components still expect the old DOMAIN\User format.
That’s handled by GenAndPersistNT4StyleName, which creates a compatible alias such as AzureAD\apv2_users and stores it next to the SID.
If the alias already exists, Windows validates or updates it automatically.
It’s a quiet background process that keeps modern Entra identities compatible with older APIs.
Key Additions Behind the Scenes
- Feature flag
Controlled by Feature_AADSidToNameV2Support.- Disabled (24H2 / 25H2): only user lookups work.
- Enabled (Insider 27881+): groups, roles, and service principals are supported.
- Type validation
New function ValidateSecurityPrincipalType ensures the returned value is one ofuser,group, orrole. - Broader coverage
The lookup now supports Entra users, groups, Intune roles, and service principals. - Updated mapping
InitializeCommonSidToNameFields outputs additional attributes like display name, UPN, and object type.
Why This Matters
What used to be unreadable S-1-12-1 SID entries are now proper Entra nam es.
Windows understands them, Intune policies can apply them correctly, and administrators finally see which Entra group or role a SID represents.
For now, this capability is exclusive to Insider Preview builds; it’s not yet present in Windows 11 24H2 or 25H2. But it’s clear where things are heading. Windows is finally learning to speak Entra fluently.
And if you remember how the security baseline once broke because “Administrators” didn’t match localized names, this might just be the first real step toward fixing that once and for all.
While Windows handles identities, Patch My PC handles your apps: deploying and automatically patching them through Intune without any extra work. Come book a demo and see it for yourself.
