samba - Jul 2023 - Samba 4 AD SmartCard Authentication Problem

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.
>

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.
>>
>