This blog dives into an issue we encountered after enabling Personal Data Encryption (PDE). While it worked perfectly at first, trying to run an executable from a protected path brought up error 0x80070043. It wasn’t a network issue, but something else. Let’s explore what’s going on and how to work around it.
Introduction
When using both Personal Data Encryption (PDE) and Local Administrator Protection, certain workflows, like running an executable from your Desktop, can unexpectedly fail. You might see a Windows Security prompt, but after logging in, the process doesn’t complete successfully and throws errors such as 0x80070043. This isn’t a network problem but a conflict between how these two security features operate.
Let’s break down why this happens and what you can do about it.
Recap: What is Personal Data Encryption?
Personal Data Encryption (PDE) protects your known folders and files by tying access to your user Windows Hello credentials. It keeps your sensitive data safe by encrypting folders like Desktop and Documents, ensuring that only you can open them.
If another account or process tries to access these files, it won’t succeed without the appropriate keys, and access will be denied!
Let’s move on and do a small recap of the Local Administrator Protection feature before diving into the issue itself.
Enter Local Administrator Protection
Windows 11’s Local Administrator Protection is all about securing the admin account itself. Instead of free-floating admin rights, it isolates the admin token. When something needs admin permissions, it creates a temporary “shadow admin,” separating those elevated rights from the rest of the system. This is great for security, but it is less great for compatibility.
The Perfect Storm: PDE + Local Administrator Protection
Here’s where things go sideways. Let’s examine what is happening.
The Protected Path Problem
PDE encrypts folders like your Desktop, so only your user account can access them. That’s fine until you try to run something like an installer, which often requires a bit of elevation before you are allowed to run it.
Elevation Changes the Game
When you hit that “Run as Administrator” button, Local Administrator Protection steps in. It raises the Windows Security prompt and temporarily switches to a hidden admin token to elevate the process.
The 0x80070043 error message
After you log in through the prompt, the executable tries to run, but it can’t access its own location because it’s locked away by PDE. Windows throws an error,0x80070043, or “The network name cannot be found.”
The funny thing is that there are no network issues; the file is just blocked. Here’s the catch: that hidden shadow admin doesn’t have access to your encryption keys. PDE sees this new admin as a stranger and says, “Nope, you’re not getting in.” With it, the shadow admin will be denied access to the file, and you will get the 0x80070043 error code.
We can also spot the same behavior from an elevated cmd. This elevated cmd runs as the shadow admin user: admin_rudy.
The result? A file stuck in no-man’s-land, and you stuck troubleshooting.
Why This Matters
This issue isn’t limited to the text crawler installer! It affects any scenario where an executable in a PDE-protected path requires elevation. PDE assumes the same user context will handle everything (using the session key to decrypt the file), while Local Administrator Protection works in a completely isolated space.
As shown above, when using the cipher tool from an elevated CMD (which is run in an isolated space as admin_rudy) we can spot the fact, that it is not able to decrypt the file. Without having the option to decrypt the file, we can’t open it.
Workarounds for 0x80070043
Here’s what you can do if you hit this issue when trying to open an executable that has been protected with Personal Data Encryption, and you are using Local administrator protection.
1. Moving the file to a Non-Protected Paths?
We could try moving the executable to a folder that isn’t protected by PDE, such as C:\Temp, before running it. But guess what happens? The file and its protection will be moved.
2. Disable Local Administrator Protection?
If PDE-protected paths frequently cause issues, consider disabling Local Administrator Protection in affected environments. This reduces security but avoids these conflicts. (Not advised!!)
3. Modify Workflows
Adapt workflows to avoid storing or running elevated processes directly from PDE-protected paths.(as moving isn’t going to work)
4. Decrypting the file
We could ask (or do it ourselves) the user to use the cipher command to decrypt the file, as shown below.
If we had a GUI, this could be a good option but without it…. nope…. so for now, the only real solution is to ensure you are saving the file to a location which is not protected by PDE.
Impact Beyond Local Administrator Protection
This isn’t just about PDE or Local Administrator Protection. Other Intune Suite tools like Endpoint Privilege Management (EPM) could also experience the same issue when they are trying to access the file if it’s placed inside a folder protected by personal data encryption.
As shown above, when trying to elevate an executable from the desktop with EPM, we will experience the same error! Access Denied (error code 0x80070005 (-2147024891)
Conclusion
Personal Data Encryption and Local Administrator Protection (and epm) are both solid features but together? They could give you some challenges. If you’ve ever found yourself staring at error codes and wondering why your files feel locked away even from you, now you know. Hopefully, Microsoft will smooth out these rough edges, but until then, at least we’ve got some workarounds.