pam_krb5 with PKINIT from Heimdal and MIT

Douglas E. Engert deengert at
Thu Oct 12 18:23:49 EDT 2006

Attached are mods to Russ's pam_krb5-2.4 to use the Heimdal PKINIT
as found in the snapshots this week. These include error codes
to indicate if PKCS11 found a reader and smart card.

There is one non-pkinit mod and that is to return PAM_USER_UNKNOWN
rather the PAM_SERVICE_ERR if the user is to be ignored.

Also attached are /etc/pam.d/gdm and /etc/pam.d/gnome-screensaver
to use pam_krb5 with the try_pkinit before trying a password.

Note the try_pkinit and use_pkinit, to try and use pkinit
if a card is inserted, or to force the use of a smart card on this
workstation. This is independent of what the KDC may say.

Note that the way gnome-screensaver works, the broken_conv parameter
was introduced. Without this the gnome-screensaver-dialog will call
pam if the mouse is moved and will get into the pkinit code before
the user has a chance to insert the smart card.

In the krb5.conf file the following are the pkinit related lines:

    TEST.REALM = {
	kdc =
         win2k_pkinit = yes
         pkinit_require_eku = no
#       win2k_pkinit_require_binding = no
#       pkinit_require_krbtgt_otherName = no
#       pkinit_require_hostname_match = no
         pkinit-anchors = DIR:/opt/smartcard/trusted.certdir

     pkinit-pool = DIR:/opt/smartcard/pool.certdir
     pkinit-user = PKCS11:/usr/lib/

This is run on Ubuntu Edgy, with OpenSC is 0.11.1 which has support
for the HSPD-12 PIV smart cards that I am using.  The Heimdal
and pam_krb5 are compiled from snapshots. The KDC is W2k3, and
the cert on the cards are Windows Enterprise CA issued certs.

There is still an issue with the way the Heimdal lib cleans up
and calls the PKCS11 C_Finalize to release the card.

P.S. the can refressh the AFS token when called from

Nalin Dahyabhai wrote:

> On Fri, Oct 06, 2006 at 11:44:15AM -0500, Douglas E. Engert wrote:
>>So while waiting for the pam_krb5-2.4 source to show up on
>>, I am attaching the Heimdal pkinit mods for
>>pam-krb5-2.3 as a point of discussion. I would hope the MIT
>>and CITI people would comment on their pkinit API.
> The pkinit support is hooked in through a preauthentication abstraction
> interface.  The only thing libkrb5 is aware of on its side is that
> there's a module which can supply data for, and process data provided
> by, a KDC for preauthentication type 16 (or 17, or 15).
> The same interface could be used to implement other preauthentication
> types (that's the intention anyway), but at the moment I think attention
> is focused on making sure that it's sufficient to interface with pkinit
> modules.

The real use of pkinit is with smartcards, and so you need a way
to test if the user has inserted the card. The Heimdal snapshots have
a way to do this when it cals PKCS11.

>> o The thinking is if the user puts in a smart card, try and use it.
>>   If no card is present use passwords as before. If they put in a card
>>   and it fails, don't fall back to password, make them take the card
>>   out first.
> The libkrb5 side of things goes through the list of preauth types
> suggested by the KDC, and the first preauth type for which it's able to
> obtain data is deemed good enough to fire off a request to the KDC.
> If a pkinit module is called first, and it supplies data, then the
> client uses that, skipping the password prompt.  If the KDC rejects the
> pkinit request, the client will give up unless the KDC's error response
> includes e-data which might be used to try adjust the request.

Consider how the user reacts to this as you may need a PIN
for pkinit, or a password if not. So you may want to consider these
as seperate attempts and not try and do it all at once in the library.
Most users will use only a smartcard or a password but not both.

> If the KDC's error included e-data, the modules get a crack at it, and
> if one of them provides different data, the library will re-send the
> request with the new padata.
> The end-result is what you describe above.

Another point to keep in mind, is that smart card readers are being
introduced, that have a builtin keypad. It is used to enter the PIN
in such a way that the PIN is never sent to the workstation thus
avoiding keyboard sniffers. This means that pam can not treat the
"password" prompt as a prompt for the pin, and the pin can not be
cached. Heimdal and PKCS11, OpenSC and PCSC can handle such a reader
although  I don't have one of these readers to test.)

> HTH,
> Nalin
> _______________________________________________
> krbdev mailing list             krbdev at


  Douglas E. Engert  <DEEngert at>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pam_krb5-2.4-diff.20061012.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gdm
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnome-screensaver

More information about the krbdev mailing list