NTAccount/Sid Translation fails with RPC Endpoint Mapper Authentication policy enabled and IIS installed

Start by reproducing the failure with the Dockerfile commands, the gMSA container, and the PowerShell NTAccount-to-SID translation shown in the issue. Compare behavior with and without IIS installed while EnableAuthEpResolution is enabled; done means the Name-to-SID translation succeeds under the reported configuration.

Describe the bug
I am using a gMSA to authenticate a container to an Active Directory domain. When I hit this bug, the only thing that appears to fail is translating between Account Names and SIDs. Other authentication scenarios to domain resources appear to function. The error I receive is "The trust relationship between this workstation and the primary domain failed."

To Reproduce
Add these two lines to a Dockerfile. The issue only occurs when both the policy is set and IIS is installed. The issue does not occur if the policy is set but IIS is not installed.

RUN Install-WindowsFeature Web-Default-Doc,Web-Http-Errors,Web-Static-Content,Web-Http-Redirect,Web-Http-Logging,Web-Stat-Compression,Web-Filtering,Web-IP-Security,Web-Asp-Net45,Web-Windows-Auth
RUN New-Item 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Rpc' -Force; Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Rpc' -Name 'EnableAuthEpResolution' -Type DWORD -Value 1 -Force

Run Windows container with gMSA. Then try to run a command like this within the container using powershell to lookup up the SID of a domain user/group.

$userString = "DOMAIN\Username"
$user = new-object System.Security.Principal.NTAccount($userString)
$sid = $user.Translate([System.Security.Principal.SecurityIdentifier])
$sid.Value

Expected behavior
The Name->Sid translation succeeds.

Configuration:

• Edition: Windows 11
• Base Image being used: mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2022
• Container engine: docker
• Container Engine version: 20.10.16

Additional context
We apply a script to our base container images that we also use with our Windows VMs that applies a large number of policies to follow CIS/STIG security baselines. After I ran into this issue, I was able to narrow down the policy that triggers the failure to this one: https://www.stigviewer.com/stig/windows_server_2012_member_server/2014-01-07/finding/V-14254

It is very strange though that the failure only happens when the policy is set and IIS is installed.