Configure Smart Card Logon for MacOS
As federal IT networks and systems expand, especially in light of recent Bring-Your-Own-Device (BYOD) models gaining popularity, it has become necessary to extend mandatory security controls to previously unsupported devices. This guide provides implementation resources to enable smart card authentication on Mac operating system (macOS) workstations and laptops for macOS-local and windows-domain accounts.
macOS Version Support
Smart card logon is natively supported on macOS Sierra 10.12 or later and Windows Server Directory logon since High Sierra 10.13. All instructions contained within this guide assume the implementer is leveraging High Sierra or a more recent macOS.
Enablement of mandatory smart card login for all Mac workstations and laptops within your environment will help align to the NIST SP 800-53 Identification and Authentication family of controls to support FISMA compliance.
Choose an Authentication Option
Agencies have two options to enforce smart card authentication in macOS.
- Local Account Pairing - For a non-domain joined macOS account, an agency may enable local account pairing. This method pairs a smart card to the local macOS user account and requires its use for desktop authentication. No domain or Kerberos architecture is needed.
- Windows Domain User Account - For a windows domain-joined device, an agency can map smart card attributes to an Active Directory account. This method involves creating a plist configuration file and disabling local pairing on the macOS device.
Agencies may additionally choose a machine or user-based enforcement which disables all password-based authentication.
- Machine-Based Enforcement (MBE): This implementation removes the option for password-based authentication in favor of smart card-only authentication for any account accessible by the macOS device (local or network).
- User-Based Enforcement (UBE): This implementation creates an exception to smart card-only authentication for specific users or groups of users (e.g., network admins, device admins, and individuals waived from smart card requirements).
Local Account Pairing
Local Account Pairing is a user-prompted process.
- Insert the PIV card into a card reader connected to the macOS device.
- A series of prompts direct the user to pair the PIV card to the local account. The user will need administrative access to complete the process.
- Provide the PIV PIN and then log out.
- Insert the PIV and provide the PIN to log back in.
See this Apple Platform Deployment guide for more information on local account pairing.
Windows Domain Account Pairing
Most departments and agencies already maintain processes to map PIV attributes to Active Directory domain accounts. This playbook also provides guidance on the different models that can be used to link domain accounts to PIV certificate attributes.
Ensure the following prerequisites are complete or ready:
- The person completing this process has administrative privileges on the macOS device.
- The macOS device is joined to the Windows domain.
- Federal PKI and domain controller certificates are distributed and installed on the macOS device key store.
Domain Controller Certificate Trust
Many organizations run internal device PKIs that issue their domain controller certificates. Ensure all certificates needed to conduct a smart card domain authentication are distributed to the macOS devices.
Step 1. Disable Local Account Pairing
The local pairing interface must be disabled. To disable the local pairing dialog:
- Open the Terminal app.
- Type the following:
sudo defaults write /Library/Preferences/com.apple.security.smartcard UserPairing -bool NO
- When prompted, enter the administrator password.
Step 2. Write the Property List
A property list, or plist, maps smart card attributes to a Windows domain account. The most common configuration is to map the NT Principal Name in the PIV Authentication certificate Subject Alternative Name to the userPrincipalName attribute in Active Directory. The following image provides the contents of a configuration file that extracts the NT Principal Name from a PIV to match against a directory AltSecID in support of an authentication event.
Agencies may want to apply additional smart card configuration settings. Additional options may include:
- allowSmartCard - Must be set to TRUE to allow the device to leverage smart cards for multiple functions (authentication, digital signing).
- enforceSmartCard - Can be set to TRUE to ensure that smart card authentication is made mandatory at initial logon, authorization, and unlocking from screensaver mode.
- tokenRemovalAction - If set to “1,” enables the screensaver when a smart card is physically removed from the device.
- UserPairing - Can be set to FALSE to prevent the pairing dialogue from appearing on smart card insertion.
- oneCardPerUser - Can be set to FALSE for users who may have multiple acceptable smart cards (e.g., PIV and alternative tokens).
- checkCertificateTrust - Can be an integer between 0 and 3:
- 0 - turns off certificate trust checking
- 1 - turns on trust checking, but does not conduct revocation checking
- 2 - turns on trust checking, and a ‘soft’ revocation check is conducted where ‘valid’ and ‘unknown’ are treated the same
- 3 - turns on trust checking, and a ‘hard’ revocation check is conducted where the response must contain a ‘valid’ status to allow the authentication to proceed
Step 3. Choose a Deployment Method
An agency may deploy a plist through various remote mechanisms.
- Employ third-party Mobile Device Management (MDM) tools
- Leveraging an Apple specific configuration tool via the App Store
- Direct configuration profile delivery via an email, webpage, or over-the-air profile delivery
If a remote deployment is not available, the administrator may also perform the configuration locally following Step 1 and 2.