Mac OS X 10.4 Tiger greatly enhances integration for smart cards, as described in this advanced article. The configuration required is much simpler than in previous Mac OS X versions.
Important: The format of the configuration file and the scripts used to configure smart card login have changed from Mac OS X 10.3.x. Do not copy or use these files directly from a previous version of Mac OS X, or it may make the system unusable. It is no longer necessary to manually run pcscd, as this daemon is started automatically by Mac OS X when it detects a smart card reader.
It is safe to install a successfully modified /etc/authorization to enable smart card login on any client system, even those without smart card readers. If no reader or card is present, the user will continue to see the default login window, and there will be no performance impact.
To support login with a smart card on Mac OS X 10.4, the card must support signing with a public key. In addition, the card itself must have a plugin, known as a tokend, that can communicate with securityd and the card itself.
There are three tokends installed as part of the base Mac OS X installation.
| Tokend | Smart card specification |
| "CAC" | US Federal Government: CAC: Common Access Card GSC-IS: Government Smart Card Interoperability Specification v2.1 |
| "BELPIC" | Belgian Personal Identity Card |
| "JPKI" | Japanese Public Key Infrastructure card |
Enabling smart card login is controlled through entries in the /etc/authorization file. Perform the following steps in Terminal to modify the authorization file.
This final step will replace the system's active authorization file with your edited version. These changes take place immediately so you do not need to restart.
Part of the login process is to do a lookup for the expected user in a directory service such as Open Directory, LDAP, or Active Directory. The first and recommended method to link a smart card user with a record in a directory service is to add the hash of the public key to the user's directory record. This is the most convenient and most secure way of identifying a smart card user. The second method is to lookup the user based on values drawn from the email signing certificate as required for the US Federal Government smart card use.
A script is preinstalled to assist you in binding a smart card to a user's local directory domain record. This is /usr/sbin/sc_auth:
myhostname# /usr/sbin/sc_auth -h
Usage: sc_auth accept [-v] [-u user] [-k keyname] # by key on inserted card(s)
sc_auth accept [-v] [-u user] -h hash # by known pubkey hash
sc_auth remove [-v] [-u user] # remove all public keys for this user
sc_auth hash [-k keyname] # print hashes for keys on inserted card(s)
An example of the output from this for a US Department of Defense Common Access Card is:
myhostname% sc_auth hash
01C2F20D8964BE7701B57B63B0A1795B8F2604C1 Identity Private Key
443F30C356E676F447CD4DA89F46CC0CCED19737 Email Signing Private Key
4845564C1F8C6B378C19B8F262CE422933CF1FD1 Email Encryption Private Key
To add a user to the local directory
myhostname% sudo sc_auth accept -u myuser -h 01C2F20D8964BE7701B57B63B0A1795B8F2604C1
...where "01C2F20D8964BE7701B57B63B0A1795B8F2604C1" is the hash for the key associated with the Identity Private Key. Refer to the script for further usage instructions. You will need to run this as a user authorized to modify the directory. In this example, any of the hash entries listed could have been used for associating the card to the account. If desired, more than one smart card can be associated with a single user account by running the script again with the hash from the additional card(s).
The script adds a field to the user's authentication_authority property. For example, after executing the command above, the authentication_authority property for the user looks like:
myhostname% dscl . -read /Users/myuser
...
"authentication_authority" = ( ";ShadowHash;", ";pubkeyhash; 01C2F20D8964BE7701B57B63B0A1795B8F2604C1" );
...
One can immediately log in to a new session using the smart card.
Smart card login uses Open Directory for all of its user lookups, so any supported directory structure will function properly.
Other Directory schema
The method used by sc_auth described above is the recommended way to link a user to their directory entry. However, some sites use an alternative lookup method or are unable to modify their schema for various reasons. To address this, there is a way to configure the smart card authorization plugin to use an attribute mapping method which maps various attributes from a certificate on the smart card to a different field in the directory. This is primarily provided to support the Common Access Card, although it does work with similarly designed smart cards.
The configuration file is an array of dictionaries. Each dictionary in this array represents the data needed to determine one search key in an Open Directory search. If no configuration file is present, the built in method of using the public key hash will be used. The file is at /etc/cacloginconfig.plist .
Example:
<dict>
<key>fields</key>
<array>
<string>NT Principal Name</string>
</array>
<key>formatString</key>
<string>$1</string>
<key>dsAttributeString</key>
<string>dsAttrTypeNative:ntprincipalname</string>
</dict>
This might produce a search string key (dsAttributeString) of "0123456789@mil". Note that the token after "dsAttrTypeNative:" would be the actual name of the attribute to use in your directory schema.
<dict>
<key>fields</key>
<array>
<string>RFC 822 Name</string>
<string>NT Principal Name</string>
<string>Country</string>
</array>
<key>formatString</key>
<string>$1#$2/$3</string>
<key>dsAttributeString</key>
<string>dsAttrTypeNative:uniqueid</string>
</dict>
This might produce a search string of "smith@navy.mil#0123456789@mil/US":
There was a similar, but more complicated way of doing this in Mac OS X 10.3. To support the improved integration of smart cards, some unused functionality was removed, providing a much simpler configuration.
The only fields that may appear in the "fields" section of the file are
Key String Example
Country US
Organization U.S. Government
Organizational Unit:1 DoD
Organizational Unit:2 PKI
Organizational Unit:3 USN
Common Name SURNAME.GIVEN.MI.1160048910
RFC 822 Name gsurname@navy.mil
NT Principal Name 1160048910@mil
These will be extracted from the e-mail signing certificate. Spaces and capitalization are significant. "Organizational Unit:1" refers to the top level OU and will typically be "DoD". "Organizational Unit:3" refers to the bottom level OU and may be for example "USN".
Example of /var/log/secure.log:
May 26 22:55:11 envy SecurityAgent[3900]: Showing Login Window
May 26 22:55:25 envy com.apple.SecurityServer: Token reader SchlumbergerSema eGate 0 0 inserted into system
May 26 22:55:25 envy com.apple.SecurityServer: token inserted into reader SchlumbergerSema eGate 0 0
May 26 22:55:32 envy com.apple.SecurityServer: reader SchlumbergerSema eGate 0 0 inserted token "[User Key] " ([User Key] ) subservice 37 using driver com.apple.tokend.coolkey
(This is where the PIN prompt login window appears.)
May 26 22:55:32 envy SecurityAgent[3900]: Showing Login Window
May 26 22:55:36 envy SecurityAgent[3900]: User Authenticated: continue login process
May 26 22:55:44 envy com.apple.SecurityServer: Succeeded authorizing right system.login.console by process /System/Library/CoreServices/loginwindow.app for authorization created by /System/Library/CoreServices/loginwindow.app.
May 26 22:55:44 envy com.apple.SecurityServer: Succeeded authorizing right system.login.done by process /System/Library/CoreServices/loginwindow.app for authorization created by /System/Library/CoreServices/loginwindow.app.
A good method for validating that the Smart Card is being recognized by the system is that the smart card appears in the Keychains list. When selecting the keychain in the list all certificates and keys appear within the Keychain Access window.