Here are the feedbacks that I've reported: FB8642358 (stuck on Login Window), FB8690483 (stuck while switching the user from the FUS menu)

I've just tested Beta 8. Unfortunately, the issues are still not fixed: Here are the feedbacks that I've reported: FB8642358 (stuck on Login Window), FB8690483 (stuck while switching the user from the FUS menu)

We only support Touch ID from a standard app context. Folks ran into this on 10.15 (I think) where using Touch ID from a Network Extension provider stopped work. I’ve also researched this in the specific context of a pre-login context (a authorisation plug-in) and confirmed that this is not expected to work. Understood, thanks. Can you suggest a better way to make a feature request for our customers then? In Feedback Assistant there is no division into bugs and features. Another question, all features are always for the public, and it's not possible to request a "private" feature from Apple especially for another company. I mean there is no partnership programs between Apple and another company? Please correct me if I'm wrong.

Some update... I was wrong about the bug reason. By clicking "Turn on FileVault..." with a custom authrorization plug-in, I see the following error: default 01:05:58.196222+0300 opendirectoryd While verifying password: user <private> (<private>) is a SecureToken user default 01:05:58.196247+0300 opendirectoryd While verifying password: user <private> (<private>) is a ShadowHash user default 01:05:58.196268+0300 opendirectoryd While verifying password: using both SecureToken and ShadowHash error 01:05:58.272387+0300 opendirectoryd Failed SecureToken authentication for AC6D2888-891E-4720-82F0-503A5D598030 other domain: invalid credentials What is interesting, by unlocking the Preferences I see the the command above successful default 01:13:13.362741+0300 opendirectoryd While verifying password: user <private> (<private>) is a SecureToken user default 01:13:13.362768+0300 opendirectoryd While verifying password: user <private> (<private>) is a ShadowHash user default 01:13:13.362792+0300 opendirectoryd While verifying password: using both SecureToken and ShadowHash default 01:13:13.439127+0300 opendirectoryd Successful SecureToken authentication for AC6D2888-891E-4720-82F0-503A5D598030 other domain default 01:13:13.545419+0300 opendirectoryd Verified password for <private> (AC6D2888-891E-4720-82F0-503A5D598030): SecureToken (ODNoError), Shadowhash (ODNoError) default 01:13:13.545470+0300 opendirectoryd Verified password for <private> (AC6D2888-891E-4720-82F0-503A5D598030): SecureToken and Shadowhash results match default 01:13:13.546567+0300 opendirectoryd AuthenticationAllowed: Evaluation result for record "<private>", record type "<private>": Success default 01:13:13.546711+0300 opendirectoryd Authentication succeeded for <private>: ODNoError default 01:13:13.546777+0300 opendirectoryd <private> (815A3688-FFFF-1D01-8C07-000001000000) is eligible for login hashes: SecureTokenOnly feature flag is not enabled default 01:13:13.624443+0300 opendirectoryd Successful SecureToken authentication for AC6D2888-891E-4720-82F0-503A5D598030 other domain default 01:13:13.624550+0300 opendirectoryd While setting credential for <private>: SecureToken is also set on the credential

I dug into the problem a bit deeper. I created a custom authorization plug-in with an empty mechanism that does absolutely nothing. and inject the mechanism directly after "builtin:authenticate" for the right "authenticate". In the case after locking the tab FileVault, buttons "Turn off FileVault..." and "Enable Users" work normally. But if to SetContextValue for the key kAuthorizationEnvironmentUsername, buttons "Turn off FileVault..." and "Enable Users" stop reacting at all. The buttons don't react even if to get the value of the key kAuthorizationEnvironmentUsername from context and put it again with no changes. In the system logs, I see the following: com.apple.preference.security.remoteservice  Unlock user (<admin user>) is not found. What is interesting ... changing kAuthorizationEnvironmentPassword only doesn't break the FileVault buttons. Is that a known bug? Any workarounds?

I’ve no idea why you’re getting this but it’s not a huge surprise: Authorisation plug-ins run in a very weird context. It doesn't work even from the application context. I ran 9 times a simple test containing only the following two line (I used PEAP as a authentication method): [interface disassociate]; BOOL res = [interface associateToEnterpriseNetwork:network identity:nil username:myUsername password:myPassword error:&error]; 2 times out of 9 I managed to connect to Wi-FI enterprise network without any prompts. 1 time out of 9 the method showed success, but I wasn't connected to Wi-Fi Enterprise network (It's strange, because in RADIUS server logs I see that "full access was granted") 6 times out of 9 the system kept asking for Wi-Fi credentials, which is weird because the correct credentials were specified as the parameters. Moreover, the associateToEnterpriseNetwork call was not blocking and terminated in a couple of seconds with the error code 1. But the credential prompt kept hanging, so I could enter the credentials and get connected to my enterprise network. This behaviour looks unpredictable, it's quite glitchy . As for the login window context, I tried to wrap the associateToEnterpriseNetwork method into a launched daemon and pull it from my authorisation plug-in. While I'm pulling the daemon being on the login window screen, I get the error -3903, the one i mentioned before. As soon as I leave the login window, my daemon stops showing the error -3903 and either works as expected or shows the error 1. It looks like it's a bug.