ADFS maintains private keys in two protection contexts. In Location 1 (User DPAPI), encrypted key blobs may exist on disk, but the DPAPI protection is tied to the service account’s SID and associated DPAPI masterkey material. In the assessed environment, the domain DPAPI backup key approach successfully decrypted masterkey material for interactive user profiles, but returned no decryptable material associated with the ADFS service account profile. All subsequent offline decryption attempts similarly failed, consistent with the masterkey not being recoverable through the evaluated on-disk recovery approach in this environment—though this observation is bounded to the assessed environment and does not represent a universal architectural property of all ADFS deployments.
Location 2 (Machine RSA) does not rely on a user-specific logon session. Instead, the key material is protected using Machine DPAPI, leveraging the DPAPI_SYSTEM LSA secret together with machine masterkeys available to sufficiently privileged SYSTEM-level contexts.
Why the WID Path Misses This Key
In ADFS environments experiencing configuration drift—commonly arising during manual certificate rotations where AutoCertificateRollover is disabled—the ADFS service host can successfully bind to a newly provisioned signing certificate at the operating-system level, ensuring continued service operation. However, the WID configuration database may not reflect the current signing certificate, resulting in stale certificate metadata.
This divergence between configuration and runtime state is the condition that ADFS Event ID 385 is designed to flag. As a consequence, extraction techniques that rely solely on the WID database and DKM material may return certificates that are no longer used for active signing, leading to rejected assertions in downstream federation scenarios.
Understanding How the Machine DPAPI Store Becomes Populated
Understanding how the Machine DPAPI store becomes populated requires examining how ADFS persists its token-signing key material. During initial deployment, automatic certificate rollover, or manual certificate rotation, ADFS persists its RSA private key material in the machine-scoped CAPI key store at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\, protected using machine DPAPI context rather than a user-bound DPAPI context. SharpDPAPI /machine enumeration in the assessed environment confirmed that the active machine key material resided under this path, while the CNG Crypto\Keys store was not observed in use in the assessed environment.
The protection chain relies on the DPAPI_SYSTEM LSA secret together with machine masterkeys associated with the S-1-5-18 security context, stored in C:\Windows\System32\Microsoft\Protect\S-1-5-18\ as DPAPI-protected key material—both components ultimately resolvable only within highly privileged SYSTEM-level contexts on the host. The corresponding certificate is enrolled into the LocalMachine\My certificate store, from which ADFS retrieves the associated private key during token-signing operations.
The architectural rationale for machine-scoped key storage is operational resilience. A machine-scoped key remains usable across service account password changes, gMSA rotations, system reboots, and service restarts without requiring key reprovisioning or dependency on a specific interactive logon session. This design ensures that the ADFS service can consistently access the signing key regardless of changes to the underlying service account credentials.
However, this same design choice has important security implications. Because the private key is protected using Machine DPAPI rather than a user-bound DPAPI context, a sufficiently privileged local process capable of accessing the machine key store and associated DPAPI artifacts may be able to recover the key material independently of the original service logon session. As a result, under certain conditions, recovery of the active ADFS token-signing private key may be achievable without direct interaction with LSASS memory or the live ADFS service process itself, potentially reducing visibility to defenses primarily focused on credential dumping or process-memory access behaviors.
