What do the OS X authorization mechanisms actually do?

Question

Background 

I'm trying to glean a better understanding of the OS X login process, in order to decide the best way for achieving VPN Single Sign On.

Please do correct me if I'm wrong, but I believe that—

1. launchd(8) calls gettyent(3) and thus determines from ttys(5) to execute loginwindow.app for /dev/console.

2. loginwindow.app attempts to acquire the system.login.console authorization right, for which the authorization database specifies the following mechanisms (listed together with my understanding of their function); those that are privileged run within the authd process (as root), whilst those that are not privileged run within the SecurityAgent process (as _securityagent):

   • 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 (resets the user’s preferences to include global system defaults; configures the mouse, keyboard, and system sound using the user’s preferences; sets the user’s group permissions; retrieves the user record from Directory Services and applies that information to the session; loads the user’s computing environment—including preferences, environment variables, device and file permissions, keychain access, and so on; launches the Dock, Finder, and SystemUIServer; launches the login items for the user).

Questions

I would very much like to confirm my understanding of each mechanism's function:

1. Is their source code available openly? I know that the non-builtin mechanisms are defined by plugins that can be found under /System/Library/CoreServices/SecurityAgentPlugins, but I cannot find the source from which they were built. Nor can I find where the builtin mechanisms are defined.

2. If the source is not available, are the mechanisms documented anywhere?

Observations

1. How can loginwindow:login prompt for credentials if it is invoked before builtin:forward-login and builtin:auto-login, either of which cause the GUI to be bypassed? Does it inspect the context for such credentials and skip itself if they are present? Seems strange.

2. Furthermore, as described in Apple's 802.1X Authentication technical white paper:

   When Login Window Mode is configured and a user types in an user name and password at the login window, two things will happen. First, the login window will authenticate the computer via 802.1X to the network using the user name and password the user entered. After the 802.1X authentication is successful, login window will authenticate the same user name and password to the external directory.

   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.

   From a casual inspection of the loginwindow plugin binary, it seems that it handles such 802.1X authentication—but the only mechanism invoked within that plugin prior to builtin:authenticate is loginwindow:login. Am I correct in thinking that this mechanism not only displays the login prompt, but then also attempts 802.1X authentication? (If so, that not only seems a little sloppy IMHO but also suggests that credentials from EFI/auto-login cannot be used for 802.1X login window authentication.)

Answer 1

1. From what I recall loginwindow:login is actually used in spawning the GUI login window, similar to builtin:policy-banner. So it is logical to be spawned before the rest of the actions. So the GUI window is the one that is actually irrelevant/bypassable, not the credentials themselves.

2. What exactly would you like to modify and towards what purpose ? For example, if you require the authorization plugin to be invoked in other situations, you can do that by editing auth.db.

Also, builtin:authenticate sub-systems should handle differencing between 802.1X and local auth.

Answer 2

builtin:forward-login,privileged

Forwards the successful FileVault login to the OS X Login Window and bypasses the need to login there. It's kind of like single sign-on. I disable this in my environment since it wasn't using the 802.1X profile I had setup. I would try doing that.

OS X: How to disable automatic login when FileVault is enabled

sudo defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES