Bug 9612 - Samba DC allowed user to logon using revoked certificate on smart card
Samba DC allowed user to logon using revoked certificate on smart card
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
unspecified
x64 Linux
: P5 major
: 4.3
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-29 12:55 UTC by raphaelsk
Modified: 2016-04-01 08:57 UTC (History)
3 users (show)

See Also:


Attachments
Debug level 10 log covering successful smart card logon using a revoked certificate (3.53 MB, text/plain)
2013-01-29 12:55 UTC, raphaelsk
no flags Details
Level 10 debug log of Samba server, with 'pkinit_revoke' set, permitting login using revoked certificate (4.31 MB, text/plain)
2013-01-30 07:20 UTC, raphaelsk
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description raphaelsk 2013-01-29 12:55:09 UTC
Created attachment 8515 [details]
Debug level 10 log covering successful smart card logon using a revoked certificate

After revoking a certificate used to successfully logon to the Samba 4 domain I built for the Samba4/Smart Card logon HOWTO and installing the new CRL to the distribution point and the Samba server, the Samba 4 domain controller continued to permit a user who presented that certificate as their logon credential to successfully logon to the domain. 

The server setup is described in the Samba/Smart Card HOWTO on the Samba Wiki. I later created a new Windows client named Ontario, and created a new user, 'oldschool@greatlakes.example.com'. I issued the user a certificate, and successfully logged into the domain via Ontario using that certificate (stored on a smart card). 

I then revoked that certificate, generated a new CRL, and then gradually introduced the new CRL progressively further into the domain infrastructure. After each step in this process, I was still able to log in to the domain using the now-revoked certificate:

First, I placed the new CRL at the configured CRL distribution point. 
Second, I rebooted the Windows client. 
Third, I installed the new CRL into the 'tls' subdirectory of the Samba provision, replacing the older CRL which was there and which was referenced in the Samba configuration file. 
Fourth, I restarted the Samba 4 server. 
Fifth, I again rebooted the Windows client.

I later re-tried to logon with the revoked certificate after setting the debug level on the Samba DC to 10. The logon again completed successfully, and the log from that run is attached. 

The Windows client never recognized that the certificate was revoked either, however, I never directly installed any CRL on the machine.

I used the openssl verify command on the Samba server to confirm that the CRL did identify the revoked certificate as revoked. (It found an unrevoked certificate to be ok.)

According to an MS AD blog post from December 2008 (http://blogs.technet.com/b/instan/archive/2008/12/08/requiring-smart-cards-for-logon-avoiding-the-outage-caused-by-expired-crl-s.aspx), the domain controller is responsible for verifying that the logon certificate it is presented with during a smart card logon attempt is valid. At the same time, the Windows client must verify that the domain controller's certificate is still valid.
Comment 1 raphaelsk 2013-01-30 07:12:57 UTC
Looking at the almost duplicative crypto item configurations in the Samba configuration file and the KDC configuration file, I figured that, since the Samba config allows me to specify a CRL, there might be an analogous parameter for the KDC configuration. Looking at the Heimdal source code in the Samba source tree, I found the config file parameter pkinit_revoke, the values of which get read in via the function krb5_config_get_strings and get stored as an array of char*.

Adding "pkinit_revoke = FILE:[location of CRL]" to the KDC section of the KDC configuration file resulted in the error "Kerberos: PKINIT: : Failed load revoke list: ASN.1 unexpected field number" (and the resulting disabling of PKINIT). I then made a DER-formatted version of the CRL (which was in PEM format) and pointed "pkinit_revoke" at that version. That resulted in a clean Samba startup.

Unfortunately, even with this setting in place, I was still able to logon to the domain using the revoked certificate. I have attached a debug-level 10 log of the Samba server during that event (same machine names and users as earlier).

It's very possible I'm not using the pkinit_revoke parameter correctly, or that it doesn't do what I think it does; unfortunately, I didn't see any documentation about what kind of input this parameter is expecting. I believe it can be added multiple times; for all I know, it's expecting a thumbprint of a revoked certificate.
Comment 2 raphaelsk 2013-01-30 07:20:59 UTC
Created attachment 8520 [details]
Level 10 debug log of Samba server, with 'pkinit_revoke' set, permitting login using revoked certificate

During the lifetime of this log, the Samba server on Niagra started up, the Windows client Ontario started up, the user oldschool@greatlakes.example.com logged in using the revoked certificate on a smart card, Ontario shut down, and then the Samba server was stopped.
Comment 3 Karolin Seeger 2014-11-27 10:52:37 UTC
Is this a showstopper for 4.2.0?
Comment 4 Stefan Metzmacher 2014-11-29 10:16:13 UTC
This is no 4.2.0 blocker.
Comment 5 Andrew Bartlett 2015-06-10 08:03:04 UTC
This needs to be resolved in upstream Heimdal.  The only part Samba probably needs to do is force in the right CRL if we have 'tls crlfile' set, because having two config items for the same kind of thing is really silly.
Comment 6 Łukasz Matyja 2016-04-01 08:57:38 UTC
Hi ,

I really wanted to address this topic because I want to implement in my login via SmartCard and I was able to improve to partially revoked certificates were rejected . I have yet to test the solution on the weekend and possibly improve but it works. I tested yesterday and quickly rejects the Windows certificates revoked .
Interested , of course, I share the source files for the substitution .

Regards,
Łukasz Matyja