In macOS Catalina and earlier, I could invoke Touch ID (calling evaluatePolicy) from a launch agent while being on the lock screen. It worked a little bit different though, not like for a standard app, without showing the native Touch ID prompt, just like in the LoginWindow app. Unfortunately, this scenario absolutely doesn't work in Bir Sur giving the error: coreauthd MechanismUI[39] has finished with Error Domain=com.apple.LocalAuthentication Code=-1004 "Can't show UI while not in a console session" UserInfo={NSLocalizedDescription=Can't show UI while not in a console session} My questions are: What is the "console session" in the evaluatePolicy context? Can I emulate the previous behaviour somehow? Are there any workarounds? I noticed that the native macOS apps like LoginWindow and so on work with Touch ID as usual even from the lock screen. The only difference I noticed is that these apps use the private version of the method evaluatePolicy with a specified uiDelegate.

When an authorization plug-in (like NameAndPassword or so on) is enabled for the system authorization right "authenticate", FileVault cannot be enabled from UI. Clicking on the button "Turn on FileVault..." has no effect. In the system logs I see the error that SecureToken was not found. Without an authorization plug-in, the button "Turn on FileVault..." works as expected, and I see no complaints in the logs regarding the SecureToken. If to do the following: Disable a custom authorization plug-in. Unlock the "FileVault" tab in "Security&Privacy", by clicking on the "lock" icon, using the native authenticaion UI. Enable a custom authorization plug-in again. Hit the button "Turn on FileVault..." In this case the button works as expected. Thisobservation makes me think that the native UI client passes the SecureToken and maybe something else as a part of the authorization process, but a custom authorization plug-in does nothing like that. The question is how to pass the SecureToken or maybe something else what's needed from a custom authorization plug-in? Maybe there is a special undocumented authorization hint for that? Or the observed behavior is a bug?

With the native Login Window client (UI) it was possible to authenticate to a Wi-Fi Enterprise network from the login window screen. If a profile with Login Window Mode ( 802.1X authentication) is applied via MDM or manually, there is shown a special pop-up menu right above the user name field. But how can I implement similar functionality in a custom authorization plugin? I tried to add my own Wi-Fi selector calling the associateToEnterpriseNetwork method of the CoreWLAN framework, but from the login window context it always returns the error: code -3903 . I called associateToEnterpriseNetwork without specifing the indentity like this: [interface associateToEnterpriseNetwork:network identity:nil username:myUsername password:myPassword error:&error]; Are there any other ways to add Wi-Fi enterprise support to authorization plugins? Maybe there're some standard ways to implement. Thanks in advance!

I'm trying to find a working scenario how to implement 802.1X authentication for Wi-Fi enterprise with a custom authorization plug-in. The problem is I don't fully understand what mechanism, in the scope of the system.login.console authorization right, is responsible for 802.1X authentication. The system.login.console authorization right has the following mechanism: builtin:policy-banner (displays Login Window banner, if set). loginwindow:login (prompts for credentials). builtin:login-begin builtin:reset-password,privileged (performs password reset using Apple ID). builtin:forward-login,privileged (forwards credentials from EFI on boot). builtin:auto-login,privileged (applies auto-login credentials on boot). builtin:authenticate,privileged (invokes`` pam_authenticate(3) for authorization service; sets "uid" context value). PKINITMechanism:auth,privileged (initialises Kerberos by obtaining a TGT). builtin:login-success loginwindow:success (secures the login session from unauthorized remote access; records the login in the system’s utmp and utmpx databases; sets the owner and permissions for the console terminal). HomeDirMechanism:login,privileged (mounts the user's home directory). HomeDirMechanism:status (displays progress of home directory mounting). MCXMechanism:login (applies configuration profiles). loginwindow:done  Since the second stage of that authentication is handled by the pam_opendirectory.so module and is dependent on the network being present, the first stage (authenticating via 802.1X to the network) must necessarily occur prior to that. That is, it must occur before the builtin:authenticate mechanism. Am I correct in thinking that the loginwindow:login mechanism not only displays the login prompt, but then also attempts 802.1X authentication? If so, it makes impossible to implement the same functionality in a custom plug-in. I tried to use the CoreWLAN framework, but that didn't work. I even filed a bug, but got a reply from Apple saying that CoreWLAN only works from application context. As the result, I cannot switch a WI-Fi network using CoreWLAN, while staying in Login Window, even from a daemon. As soon as I leave the Login Window screen, CoreWLAN methods (Wi-Fi enterprise related) start working. Or does 802.1X authentication occur in a different mechanism (lower in the call chain)? And it's possible somehow to pass credentials and selected wifi network parameters as a hint or a context value from the custom plugin mechanism to the system built-in mechanism that is responded to 802.1X authentication?