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.
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.
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.
Is this a showstopper for 4.2.0?
This is no 4.2.0 blocker.
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.
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
Good day! Does anyone have a solution to the problem of authorization on the revocation certificate in the samba domain? I deployed a test environment in which the samba dc server, web server apache and Windows client are installed. Authorization for revoked certificates on the web server does not occur, indicating that the certificate has been revoked. But authorization in Windows on the revoked certificate is still going on. I deleted the cached сrl on Windows, but still authorization occurs. Just waiting for the end of life crl. After Windows updated crl, authorization still worked.
I have fixed this bug. Very soon AstraLinux company will publish the patch in samba technical mailing list.
(In reply to Sergey Korchak from comment #8) Did the patch ever get anywhere? Can you update this bug with some references if it did?
Sorry, missed the URL link. The patches need to go to upstream Heimdal and then we can backport them.
This looks like it might be fixed thanks to our Heimdal upgrade in Samba 4.16. Certainly there is a call of hx509_revoke_add_crl() in the setup, so I hope this is working now. It would be useful if someone could add a test for this for us.
(In reply to Andrew Bartlett from comment #11) I've tested smart card revocation with the latest 4.16 build and I can confirm the latest Heimdal upgrade did not resolve the issue. "hx509_revoke_add_crl" is indeed referenced in the Heimdal source but not in the pkinit.c file for the kdc (kdc/pkinit.c). I've tested out the AstraLinux patch and while it works it segfaults when no pkinit_revoke is configured, minior issue probably as it most likely is missing some check if the revocation check should be activated. The AstraLinux patch haven't landed in upstream Heimdal, I don't know if Sergey Korchak gave up on the idea or if it was rejected upstream. While I'm would be willing to spend some time on this, I'm pretty sure it would require some kind of test submitted along with the patch and Heimdal has a steep learning curve.
Thanks Kacper for testing that. I'm sorry to hear this isn't fixed in the meantime. I do see all the Heimdal MRs so I'm pretty sure it wasn't sent to Heimdal. I would encourage submitting a patch, with tests, upstream, as that really is the only way to get this fixed.
(In reply to Andrew Bartlett from comment #13) Submitted https://github.com/heimdal/heimdal/pull/992. Hopefully we can close this bug once it gets accepted upstream.
I cannot vouch for the coding itself, but the patch does work as expected on Samba 4.16. It is a must have in Samba-AD with smartcard deployment.
This bug was referenced in samba master: ce9786748b7b594ca0864158ba49ca4def1b593c 01196cc741ddf611794ba6eb1b5f3a0bcff2f0da b73a01eefd2a526936f11e08a5a32dd2f1106359 2ab15cf11721eaec95950b634b4782d7cae0d311 90b240be08629ab6cad7651c59df1d9f533797c0 81058c60136fba9af2dd7de8f15baef5e7e97bde
This bug was referenced in samba master: 0ee8c263f615baa3b839eeb94236b3f54862233b
This bug was referenced in samba v4-19-test: ce9786748b7b594ca0864158ba49ca4def1b593c 01196cc741ddf611794ba6eb1b5f3a0bcff2f0da b73a01eefd2a526936f11e08a5a32dd2f1106359 2ab15cf11721eaec95950b634b4782d7cae0d311 90b240be08629ab6cad7651c59df1d9f533797c0 81058c60136fba9af2dd7de8f15baef5e7e97bde 0ee8c263f615baa3b839eeb94236b3f54862233b
This bug was referenced in samba v4-19-stable (Release samba-4.19.0rc1): ce9786748b7b594ca0864158ba49ca4def1b593c 01196cc741ddf611794ba6eb1b5f3a0bcff2f0da b73a01eefd2a526936f11e08a5a32dd2f1106359 2ab15cf11721eaec95950b634b4782d7cae0d311 90b240be08629ab6cad7651c59df1d9f533797c0 81058c60136fba9af2dd7de8f15baef5e7e97bde 0ee8c263f615baa3b839eeb94236b3f54862233b