Hello --
I am developing an Authentication Plug-in for the purpose of invoking login with no user interaction (headless).
There seems to be sufficient documentation and sample code on how to implement a plug-in and mechanism, and debug the same, which is great. What I am trying to understand is exactly how to modify the login right (system.login.console) in order to accomplish my goal.
Question 1:
I had the idea of installing my mechanism as the first mechanism of the login right, and when invoked to set the username and password into the engine’s context, in the belief that this would negate the system from needing to display the login screen. I didn’t modify or remove any other mechanisms. This did not work, in the sense that the login screen was still shown. Should this work in theory?
Question 2:
I then tried modifying the login right to remove anything that interacted with the user, leaving only the following:
<array>
<string>builtin:prelogin</string>
<string>builtin:login-begin</string>
<string>builtin:forward-login,privileged</string>
<string>builtin:auto-login,privileged</string> <string>MyAuthPlugin:customauth,privileged</string>
<string>PKINITMechanism:auth,privileged</string>
<string>builtin:login-success</string>
<string>HomeDirMechanism:login,privileged</string>
<string>HomeDirMechanism:status</string>
<string>MCXMechanism:login</string>
<string>CryptoTokenKit:login</string>
</array>
The mechanisms I removed were:
<string>builtin:policy-banner</string>
<string>loginwindow:login</string>
<string>builtin:reset-password,privileged</string>
<string>loginwindow:FDESupport,privileged</string>
<string>builtin:authenticate,privileged</string>
<string>loginwindow:success</string>
<string>loginwindow:done</string>
In place of builtin:authenticate I supplied my own mechanism to verify the user’s password using OD and then set the username and password in the context. This attempt appears to have failed quite badly, as authd reported an error almost immediately (I believe it was related to the AuthEngine failing to init).
There’s very little information to go on as to what each of these mechanisms do, and which are required, etc.
Am I on the wrong track in attempting this? What would be the correct approach?
There’s very little information to go on as to what each of these mechanisms do
Indeed. This has been an issue since Authorization Services was introduced, way back in the day. I’ve filed bugs request such docs in the past, to no avail. And I don’t think that’s going to change now, because Authorization Services is clearly not part of our long-term direction.
One trick I use to investigate this stuff is to insert a dummy mechanism at each step of the process. It can either log state, or pause, or display a UI and pause, allowing me to determine which mechanism does what.
Regarding question 1, I’m actually surprised that failed. I’ve done this in the past and I vaguely recall it working.
I do have a quick suggestion though. Rather than adding your mechanism right at the front, add it just before loginwindow:login
.
Regarding question 2, you have definitely removed too much. You really want to leave builtin:authenticate
enabled. It’s the final credential check and does a bunch of other important stuff.
If my question 1 suggestion doesn’t pan out, try replacing just loginwindow:login
with your mechanim.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"