[Samba] Samba 4 AD SmartCard Authentication Problem

[Hans Schulze]

I found an old bugzilla report for this behavior:

https://bugzilla.samba.org/show_bug.cgi?id=9612

According to the statements in it, there was a patch already in version 
4.16 and in heimdal 8 last year? Which option must be in the krb5.conf?

I have tried kdc_pkinit_revoke and pkinit_revoke. Both have no effect.


Am 19.07.2023 um 14:27 schrieb Hans Schulze via samba:
> Unfortunately this does not work.
>
> Example: Yes, when i give it a few Days, the client will retrieve the 
> actual crl faster. But the auth still works.
>
> I have tried it. I revoked an cert. Installed a new win10 client and 
> joined the domain. After login with the revoked p12 cert on a yubikey, 
> i can see he queries the CDP and still allows the login.
>
> With certutil and a cert in DER format, i tried this:
>
> certutil -f -urlfetch -verify testus-cert.cer
>
> The output says that the cert is revoked. But login was granted. That 
> is completly strange.
>
> Someone an Idea?
>
> Am 19.07.2023 um 14:08 schrieb Andrey Repin via samba:
>> Hello Hans Schulze,
>>
>> Wednesday, July 19, 2023, 1:03:25 PM, you wrote:
>>
>>> Thanky you, for the Info.
>>> After some research, here is some further information:
>>> The current stable kerberos implementation make no crl verify. At 
>>> this time
>>> only the domain member like win10 clients make these. After joining the
>>> domain and first login with smartcard, they try to resolve the CRL
>>> Distribution Points for all certs of the chain. Only one url that 
>>> cannot be
>>> reached and the authentication fails.
>>> The funny thing is, they are retrieved
>>> and cached only once, as long as the validity of the crl is given. 
>>> Should a
>>> new crl be issued, the clients would still have the old crl cached. 
>>> Thats a problem.
>> You should not issue CRL with very long validity period.
>> Give it a few days over your routine CRL update cycle and it should 
>> work.
>>
>>> This mechanics was implemented to reduce the traffic to the 
>>> distribution point.
>>> You can check the cache with certutil on windows client, like:
>>> certutil –urlcache CRL
>>> These are my thoughts on this and I hope someone else can use them to
>>> better understand similar problems. I think this mechanic is a little
>>> security issue. But we hope that the new version will be released 
>>> soon and will fix this problem.
>>
>