Smart-card logon for OS X (part IV)

[continued from part III]

Smart-card elevation

In addition to the login screen and screen-saver, elevation prompts for sensitive operations will also work with smart-cards:

Elevation prompt asking for PINAs before, the dialog can adjust for credential type in real-time. On detecting presence of a smart-card (more precisely, a card for which an appropriate tokend module exists and contains valid credentials) the dialog will change in two subtle ways:

  • Username field is hard-coded to the account mapped from the certificate on the card, and this entry is grayed out to prevent edits
  • Password field is replaced by PIN

If the card is removed before PIN entry is completed, UI reverts back to the original username/password collection model.

One might expect that elevation in command line with “sudo” would similarly pick up the presence of smart-card but that is not the case. su and sudo still require a password. One heavy-weight solution involves installing the PKCS#11 PAM (pluggable authentication module) since OS X does support the PAM extensibility mechanism. A simpler work-around is to substitute an osascript wrapper for sudo. This wrapper can invoke the GUI credential collection which is already smart-card aware:

sudo replacement with PIN collection(Downside is that the elevation request is attributed to osascript, instead of the specific binary to be executed with root privileges. But presumably the user who typed out the command knows the intended target.)


Before discussing the trust-model and comparing it to Windows implementation, here is a quick overview of steps to enable smart-card logon with OS X:

  • Install tokend modules for the specific type of card you plan to use. For the US government PIV standard, OpenSC project installer contains one out of the box.
  • Enable smart-card login using the security command to modify authorization database.
    $ sudo security authorizationdb smartcard enable
    YES (0)
    $ sudo security authorizationdb smartcard status
    Current smartcard login state: enabled (system.login.console enabled, authentication rule enabled)
    YES (0)

    (Side-note: prior to Mavericks the authorization “database” was a plain text-file at /etc/authorization and it could be edited manually with a text editor— this is why some early OSX smart-card tutorials suggest tinkering with the file directly. In Mavericks it is a true SQLite database and best manipulated with the security utility.)

  • Associate one or more certificate mappings to the local account, using sc_auth command.

Primitive trust-model

Because certificate hashes are tied to a public-key, this mapping does not survive the reissuance of the certificate under a different key. That defeats the point of using PKI in the first place. OSX is effectively using X509 as a glorified public-key container, no different from SSH in the trusting specific keys rather than the generalized concept of an identity (“subject”) whose key at any given time is vouched for by a third-party. Contrast that with how Active Directory does certificate mapping, adding a level of indirection by using fields in the certificate. If the certificate expires or the user loses their token, they can be issued a new certificate from the same CA. Because the replacement has the same subject and/or same UPN, it provides continuity of identity: different certificate, same user. There is no need to let every endpoint know that a new certificate has been issued for that user.

A series of future posts will look at how the same problem is solved on Linux using a PAM tailored for digital certificates. Concrete implementations such as PAM PKCS#11 have same two-stage design: verify ownership of private key corresponding to a certificate, followed by mapping the certificate to local account. Its main differentiating factor is the choice of sophisticated mapping schemes.  These can accommodate everything from the primitive single-certificate approach in OSX to the Windows design that relies on UPN/email, and other alternatives that build on existing Linux trust structures such as ssh authorized keys.


6 thoughts on “Smart-card logon for OS X (part IV)

  1. shirkrin says:

    Just it doesn’t get lost:
    I managed to restore my screen unlock to the graphical version by uninstalling the smartcard services and finally (the missing pice):

    sudo sc_auth remove -u MyUser

    With the sc_auth remove I would still only get the non-graphical unlock screen.
    And I honestly didn’t notice I still had a card certificate in there..

    • Hi shirkrin,
      I can’t uninstall all the stupid smartcard services. I always get the ugly login prompt. Is there a workaround to get the nice loginscreen back? I even deleted a smartcard service in the system library. No success. Which smartcard services have you uninstalled? Heeeelp! This screen makes me mad. ^^ Sorry for the double post but I was too stupid to press on the reply button.

    • Yeaaaah! I fixed it! If you have the non graphical login screen just delete the file /etc/cacloginconfig.plist after deleting that you’re normal login screen will appear (no restart required). I hope this helps.

  2. Hi shirkrin,
    I can’t uninstall all the stupid smartcard services. I always get the ugly login prompt. Is there a workaround to get the nice loginscreen back? I even deleted a smartcard service in the system library. No success. Which smartcard services have you uninstalled? Heeeelp! This screen makes me mad. ^^

  3. Hi there,

    Thanks for your guide it help us a lot. But we still facing an issue :
    If we could open AD’s session on a mac using a smartcard (PKCS#11), we can’t obtain a TGT.

    Logs dosen’t talk too much, we juste have a :

    Oct 18 11:15:03 computername NetAuthSysAgent[15242]: NAHSelectionAcquireCredential Error Code=-1765328360 “acquire_kerberos failed USER@REALM: -1765328360 – Preauthentication failed” UserInfo={NSDescription=acquire_kerberos failed USER@REALM: -1765328360 – Preauthentication failed}

    Do you have any idea ?

  4. Hello Gildas.
    It looks like in this case you are doing a domain logon to Active Directory, instead of local login to the current machine. This series of posts is only the local login scenario where OSX is validating the certificate. In your use case, it is the enterprise AD that gets to check the certificate and also perform additional steps for Kerberos. Different model.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s