In this blog, I will show you why existing GPO policies could potentially break new products like Intune Endpoint Privilege Management (EPM). I will show you how a specific security policy broke Endpoint Privilege Management and gave me the 0x80004003 error.
1. Introduction
Last week, I was reading back some posts on the WinAdmins Discord Channel. Someone posted a question in the Intune channel asking if someone was familiar with the 0x80004003 (-2147467261) Endpoint Privilege Management error.
This error was mentioned when trying to run the app as an administrator, which doesn’t tell you anything about the actual error. I contacted the OP and looked at the EPM error logs he posted.
The OP deployed EPM to his hybrid joined devices and created an elevation policy to ensure some users could elevate PowerShell. After the Declared Configuration document (EPM Elevation Rules) was pushed to the device, he tried to run PowerShell with elevated permissions.
After entering the Business Justification, the error 0x80004003 popped up. Let me tell you what happened and what I noticed
2. Something went wrong
Luckily, EPM has some good debug logging enabled by default, so finding the culprit shouldn’t be difficult.
I started finding the exact timeframe in which the error was shown. After opening the first of the 3 logs (EPMService,EPmConsent, and the EPM log), I searched the error code itself: 0x80004003.
As shown above, the ConsentUI gives us an error with the same Error code at about 11:26:53. Now that I had the exact time frame, I opened the other 2 EPM logs with the CMTrace tool and scrolled down to the same time frame.
As shown below, we now get a new error message. This error message told us that it failed to create the virtual account of the user, with the error code 0x80070569
So, it looks like we are having issues with the virtual account. As in virtual? Yep, The Virtual Account that uses the Virtual Provider to Logon with the power of the Logonuserexex Function is not getting created.
The last EPM log shows us pretty much the same, but this one also mentioned the LogonUserExEx function I talked about.
If you combine the LogonUserExEx with the error code 0x80070569, you could already get a good idea of what could be going wrong, but I decided to open the epmcommon.dll
Within a minute or 2, I got to the part of the code that would give the same error as I showed you above.
If we add Logon32_logon_interactive to the other keywords we already have, things could start making sense.
3. The 0x80070569 Error
With the Interactive Logon added to the list of existing keywords, we can only come up with 1 conclusion:
0x80070569 is a “Logon failure” in which the user has not been granted the requested logon type. This makes things a bit funnier, so I reached out to the OP again and asked if there was a lingering Local Security policy active to restrict the people who are allowed to log on locally
Allow log on locally – security policy setting – Windows Security | Microsoft Learn
Unfortunately, the OP lives in a different time zone, so I didn’t get an answer directly. So, I decided to create a similar kind of policy. As shown below, I created a new settings catalog policy to define the users who are allowed to log on locally.
I added Fritsie and myself to the list above and rebooted and synced the device. Guess what error I got after trying to elevate a process.
I got the same error as the OP. The logon-local policy was indeed the culprit. It’s good to know that besides the EPM log, the security event log will also show you the issue.
As shown above, while trying to run the process with the virtual EPM account, the user (MEM\MMSMOA_RUDY_$) has not been granted the requested logon type (2). This requested logon type 2 corresponds to the Interactive logon.
4. Trying to fix it?
Well, now we know which account name we need to configure, let’s add the virtual account to the allowed local log-on, user list.
I could elevate the process again after adding the account and syncing the device! Just after fixing the issue in my environment, the OP reached out. After digging through the default domain policy, he found out that the logon locally policy was indeed limited to two sets of users. The administrators and the domain users
But now comes the trouble… how are we going to add all of the unique Virtual Domain Accounts to it? The virtual account is not a member of a group. I tried to do a funny thing (aka not working!!! )
If we take a closer look at the detailed event log message, it also mentions the targetusersid S-1-0-0
This well-known SID corresponds to the group that has no members.
But as expected, that didn’t work (which was expected)
So I decided to create a new LOCAL group manually, called “EPM” with a separate PowerShell script (to make sure the Allow Logon Local Policy could add the group)
Please note : as mentioned above, This solution below isn’t going to work in the real world, but I am just trying to show you what I did to solve it
try {
$groupName = "EPM"
$existingGroup = Get-LocalGroup -Name $groupName -ErrorAction Stop
Write-Host "Group '$groupName' already exists."
} catch {
New-LocalGroup -Name $groupName
Write-Host "Group '$groupName' created successfully."
}After the group is created I am going to find the Virtual Account and add it to the EPM group I just created. (this account is different on each device and you should have elevated)
$path = 'Registry::HKey_Local_Machine\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\*'
$items = Get-ItemProperty -path $path
$items = $items | Where-Object { $_.PSChildName -like '*s-1-5-110*' }
Foreach ($item in $items) {
$objUser = New-Object System.Security.Principal.SecurityIdentifier($item.PSChildName)
$objName = $objUser.Translate([System.Security.Principal.NTAccount])
$item.PSChildName = $objName.value}
$profilePath = $item.ProfileImagePath
$upn = $profilePath -replace 'c:\\Users\\', ''
try { Add-LocalGroupMember -Group "epm" -Member $item.PSChildName
Write-Host "User $($item.PSChildName) added to 'epm' group successfully."
} catch {
Write-Host "Failed to add user $($item.PSChildName) to 'epm' group. $_"
}
}
If that PowerShell script is successfully executed, the virtual account will be added to the Local EPM group
From there on I could add the EPM group to the “Allow Local Log On” policy, it will work as expected! You can now use EPM to elevate your processes again
The only big issue here is that the Allow Logon policy blocks the Virtual Account login, and… the account needs to log on once (Using EPM Elevation). Otherwise, the profile is NOT getting created. If the profile is not created, the SID can’t be retrieved, and without SID, the user can’t be added to the group.
5. Let’s MEM it
There are two ideas, but they didn’t correctly solve the issue. If you have read my blog, which Specterops also highlighted during their token buy journey, it contains something interesting.
The Virtual Hidden Account will become a member of the MEM\MEM fake (maybe not that fake) domain group. Guess what we can add to the logon locally policy? Yeah, a group!
With this information, the first idea would be to add MEM\MEM, right? But does mem\mem sound like a proper group? Well, not exactly. If we remove the \mem from it, it smells like a proper group.
I changed the Allow Local Logon policy I configured in Intune and added the MEM group to the policy. After making sure the device was synced, I opened the group policy and noticed this behavior.
We all know that azuread\rudy@wvdcloud.nl will be translated to the “real name,” but I wasn’t expecting the MEM domain group to be translated to the fake MEM\MEM group. It’s funny, but at the same time… “it” seems to know how that group needs to be translated.
With this MEM group added to the logon locally policy… it seems like that idea has done its job! Elevating Procomon with EPM with this policy configured seems to work.
Conclusion
When you want to use EPM and you are using the policy to restrict who is allowed to log on interactively you need to make a choice.
- Start using EPM and kick out that GPO
- Start using EPM and configure all of the unique virtual accounts as I did
- Or just go with the flow and add the MEM group to the policy!!!!