DataProtectionProvider fails to unprotect when hosted on IIS with keys persisted to the default location

[kikaragyozov]

When running ASP.NET Core on Kestrel/IIS Express, everything works as expected.

The following method gets called before the app is built:

        public static IDataProtectionProvider Create(string discriminator)
        {
            // build the service collection
            var serviceCollection = new ServiceCollection();
            var builder = serviceCollection.AddDataProtection()
                .SetApplicationName(discriminator)
                   .ProtectKeysWithDpapi(true);

            return serviceCollection.BuildServiceProvider().GetRequiredService<IDataProtectionProvider>();
        }

This works in IIS Express, Kestrel. I haven't tested this in docker, but I'm guessing because it uses Kestrel under the hood, it'll work as well.

The moment we move to using IIS though, all hell breaks lose. My Unprotect call fails with the error

System.Security.Cryptography.CryptographicException: The key {XXXXXX-XXXX-XXXX-XXXXX} was not found in the key ring. For more information go to https://aka.ms/aspnet/dataprotectionwarning

What's going on here? The IIS configured is running on my local machine, the same machine from which both the other methods worked.
Furthermore, I've manually added permissions to the default location of where the keys are being stored, verified that indeed the GUID mentioned EXISTS in the folder, i.e the file is there.

I've also tried specifying manually a folder, via PersistKeysToFileSystem which fixes the issue, but why doesn't it work via the default location (%LOCALAPPDATA%\ASP.NET\DataProtection-Keys)

Is there something specific that needs to be done on IIS for it to work out of the box?

Load User Profile is set to true in the Application pool.

Tested on .NET 9/.NET 8

[adityamandaleeka]

Can you please take a look here: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/default-settings?view=aspnetcore-9.0#key-management

I wonder if the environment isn't flowing properly (see the part about setProfileEnvironment in that doc).

[kikaragyozov]

        <applicationPools>
            <add name="DefaultAppPool" />
            <add name="rdf" autoStart="true" managedRuntimeVersion="" />
            <applicationPoolDefaults managedRuntimeVersion="v4.0">
                <processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
            </applicationPoolDefaults>
        </applicationPools>

setProfileEnvironment was set to false. I changed it and restarted the IIS server from the IIS application window by clicking "Stop" and then "Start". The issue still occurs.