Hi, Here is the array: <string>builtin:prelogin</string> <string>builtin:policy-banner</string> <string>loginwindow:login</string> <string>builtin:login-begin</string> <string>builtin:reset-password,privileged</string> <string>loginwindow:FDESupport,privileged</string> <string>builtin:forward-login,privileged</string> <string>builtin:auto-login,privileged</string> <string>myplugin:auth,privileged</string> <string>builtin:authenticate,privileged</string> <string>PKINITMechanism:auth,privileged</string> <string>builtin:login-success</string> <string>loginwindow:success</string> <string>HomeDirMechanism:login,privileged</string> <string>HomeDirMechanism:status</string> <string>MCXMechanism:login</string> <string>myplugin:config,privileged</string> <string>CryptoTokenKit:login</string> <string>loginwindow:done</string>

Hi, macOS - Sequoia 15.3.1 Apple silicon Real hardware 2 plugins - custom login view plugin, and auth plugin. Everything works fine in a "regular" login scenario. Things turn south when using FDEAutoLogin, and our plugin set result to .deny. Then the user gets the native login screen. instead of the custom one.

thanks!

Hi, I am using NSXPCConnection with setCodeSigningRequirement. I tried different requirements. Simplest = "anchor apple generic". This one works. Requirement1 = "anchor apple generic and IssuerIsDeveloperID and LeafIsDeveloperIDApp". In this case my app can not connect with my daemon. Requirement2 = "anchor apple generic and certificate leaf[subject.OU] = ". In this case too, my app can not connect with my daemon. My app and daemon are signed with the same developer id cert and same team id. What am I missing here? Thanks, Sivan

Thanks for your answer. I have posted a question regarding setCodeSigningRequirement, in the post that you have mentioned above.

Thanks for your reply! So what is Apple's path for providing end point security by third party companies? What is the path to increase security and participate in the login, unlock and sudo operations? cheers

Many Enterprises are forcing file vault in their computers. Why wouldn't Apple enable the authorization plugins to run also under the vault login process? This also prevents the integration of password less login solutions for macOS. A reasonable workaround to this problem may be using a virtual smart card. But a virtual smart card is not working on macOS, but it can be hacked. So why wouldn't Apple make it easy to go forward with password less login solutions? cheers, sivan

Thanks for your reply. Well, it seems that I have found a work around for this problem. Using a Daemon running with sandbox capability. This way I am able to add BLE entitlement to the Daemon, and the user can grant a Bluetooth privilege. Now the authorization plug-in is sending requests by XPC to the Daemon, and the Daemon is doing the BLE stuff. cheers sivan