There are a few convenient scapegoats here but ultimately in this case it is not biometric unlock that enabled this but rather characteristic of the Active Directory's design (I'm not sure I will call it a weakness).
For Android and iOS if you forget your PIN code I believe you are screwed, as in no one can decrypt your device for you.
Actually it is not just an issue with AD design, but the AD design only makes it slightly worse. The underlying issue is that biometrics are not required to retrieve the biometric key from DPAPI and instead of authenticating with Windows Hello, any program could just simply ask DPAPI for the key.
My understanding from a quick reading is that Bitwarden essentially used Windows Hello to ask "is the user there" and if so, asked DAPI to give Bitwarden the secret vault credentials which it happily did because that's its job.
The problem with this was that the vault credentials in DAPI was not safe from other programs running as the user, nor from domain admins which could use the recovery key stored on the AD server (which they did in their attack after gaining admin access).
The solution was to use Windows Hello the way it was meant. That is, to store an asymmetric key pair, where the private key is hidden and protected by the biometrics or hardware security key, and use that to encrypt the secret vault credentials before storing them in DAPI.
Have you looked into how (whether?) Windows Hello actually checks which app is asking it to perform a private key operation?
On Android, this is tied to the app UID, and on iOS/macOS it's tied (I believe) to the developer team identifier. Hopefully there's a similar mechanism on Windows...?
It doesn't, or at least it doesn't for traditional applications. UWP (store apps) might, but I've never seen it.
To be fair, identifying an app when not delivered through some locked down store mechanism is actually problematic. DPAPI is tied to the user/machine account along with additional entropy provided by the application itself. It would be nice if MS added an option for DPAPI to use a hash of the name blessed by a CA in a valid code signing cert. However, that wouldn't matter in this case, since they had domain admin and could easily manipulate the cert store.
Self-signed code signing certificates would seem to be a good compromise (like e.g. Android does it).
Even a hash over the executable (+loaded DLLs) would work in a pinch. Breaks app binary updates, but for a “stay logged in and unlock via biometrics“ feature (as opposed to “store this credential forever”), that might be acceptable.
Probably not, given that Android's security model sandboxes apps and accordingly can identify which one is trying to access a given keychain credential.
