loginwindow Mechanisms

Jamf Connect Login adds multiple mechanisms to the loginwindow application. Most standard macOS mechanisms are also used.

Note: Mechanisms defined as "privileged" prompt the loginwindow to run the mechanism as the root user and do not have a user interface.

Default Jamf Connect Mechanisms

The following mechanisms are added to the loginwindow application by Jamf Connect Login by default:




This mechanism checks the OIDCProvider key to determine if Microsoft Azure AD is being used as an identity provider (IdP).

If Azure is used as your IdP, CheckAzure will begin the authentication process and display a Microsoft web view to users.

If Azure is not used as your IdP, the CheckOIDC mechanism continues the loginwindow process.





This mechanism works directly against your Okta or OIDC endpoint to complete authentication with your IdP. Customers using OpenID Connect (OIDC) must use CheckOIDC, and Okta customers must use CheckOkta.

Note: CheckOkta uses Okta's Authentication API. No changes need to be made to Okta to enable this functionality.

For CheckOkta or CheckOIDC to work, you need to configure your IdP in the Jamf Connect Login preferences.

This mechanism can support simple authentication, multi-factor authentication (MFA), and password resets from an IdP. It does not directly authenticate the user to the system but completes the following background process:

  1. The mechanism gathers a username and password from the user, and then verifies the user locally.

  2. The mechanism does one of the following:

    • If the username matches a local user, the mechanism puts the username and password into the Security Agent, and then passes the authentication to the next mechanism.

    • If the username does not exist locally or a configuration has been set to always authenticate with your IdP, then the user and password are authenticated with Okta or OIDC


PowerControl allows the shutdown and reset buttons to function at the Jamf Connect login window. This mechanism has no configurable options and needs to run privileged to function.


CreateUser can create a local account based on a username and password provided in the CheckOIDC or CheckOkta mechanism.

This mechanism will do the following depending on the existence of a local user:

  • If the short name of the currently authenticated user matches a local user, CreateUser does not run. The rest of the mechanisms will run.

  • If a local user does not exist for the currently authenticated username, CreateUser creates a local account.

CreateUser can also do the following if a new user is created:

  • Assign the first available UID starting from the UID of 501.

  • Create the new user as a non-admin account on the system, by default. This can be changed via a preference key or by using the OIDC settings in the CheckOIDC mechanism.

  • Create a default home folder for the new user using the createhomedir command. The home folder is localized according to the local settings of the computer.

  • Write /var/db/.NoMADCreateUser with the name of the user in that file.

If you are using Okta, the CreateUser mechanism will migrate a user based on the process started in the CheckOkta mechanism.


DeMobilize can change Active Directory mobile accounts to exclusively local accounts.

When enabled, this mechanism removes any non-local attributes from a user’s record before allowing the system to authenticate the user. When finished, the user’s password, UID, and home directory remain the same as before. A restart is not required.

Note: This mechanism does not remove any Active Directory binding that may be in place, it just removes the user from being associated with an AD user record.


You can enable FileVault encryption for the first user on computers with macOS 10.13 or later using an AFPS formatted volume. This mechanism is best suited for initial user setups to ensure FileVault is enabled before the user logs in. Without this mechanism, you must manually enable FileVault or sign out to trigger the encryption process.

Note: If you are using an MDM service to manage your macOS computers, you can continue to set a FileVault recovery key profile and escrow the personal recovery key.

This mechanism only enables FileVault if all of the following conditions are met:

  • The computer is running macOS 10.13 or later

  • The volume is APFS formatted

  • FileVault is not already enabled

  • The EnableFDE preference is set in Jamf Connect Login

If all conditions are met, the user will be enabled for FileVault and receive a SecureToken. If the account is a local admin, it can enable other users for FileVault on the computer.

Note: This mechanism can enable FileVault for a non-admin user.


This mechanism improves the initial login process time on computers with macOS 10.12.

Note: On macOS 10.13 or later, this mechanism does not run.

Additional Jamf Connect Mechanisms

The following mechanisms can be added to the loginwindow application with the authchanger tool:




This mechanism allows for an end user license agreement to be configured during the log in process.

For information on how to add this mechanism to Jamf Connect, see Adding the EULA Mechanism.


This mechanism allows for a Notify script to be run, which displays a computer's setup process for users.

For information on how to add this mechanism to Jamf Connect, see Adding the Notify Mechanism.


This mechanism allows administrators to specify a script to be run during the loginwindow process.

For information on how to add this mechanism to Jamf Connect, see Adding the RunScript Mechanism.

MacOS Mechanisms

The following mechanisms are included in the standard macOS loginwindow application and are still used by default installations of Jamf Connect Login:




This mechanism displays a rich text format directory (RTFD) file containing an acceptable use policy. The user must acknowledge the message by clicking Accept before proceeding to the login window.


This mechanism communicates to the system that the loginwindow process has started.


This mechanism can perform a password reset by using an Apple ID.


This mechanism forwards login credentials from EFI on startup.


This mechanism applies automatic login credentials on startup.


This mechanism determines if a user is allowed to log in.


This mechanism initializes Kerberos by obtaining the ticket granting server (TGS).


This mechanism does the following:

  • 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


This mechanism begins the process of setting up the environment for Finder.


This mechanism mounts the user's home directory.


This mechanism displays the progress of the home directory mounting process.


This mechanism applies configuration profiles to the computer.


This mechanism can work with smart cards and other token based authentication methods.


This mechanism completes many of the final set up items for the user. The following is completed:

  • 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 computer preferences, file permissions, keychain access, and other user settings

  • Launches the Dock, Finder, and SystemUIServer

  • Launches the specified log in items for the user

Related Information

  • Additonal Mechanisms
    Learn how to add non-default mechanisms to Jamf Connect Login.

  • authchanger
    Learn how to use the authchanger tool to modify the authentication database and add non-default mechanisms to Jamf Connect Login.

  • About the loginwindow Application
    Learn about the how the loginwindow application works on macOS.

Copyright     Privacy Policy     Terms of Use     Security
© copyright 2002-2019 Jamf. All rights reserved.