Requiring Smart Cards for logon - what happens when CRL publication fails
Let's say your organization wants to make smartcards mandatory for all users as part of a security push, i.e. implement 'two-factor authentication' ("something you have and something you know").
The concern however is that if revocation checks for either the Domain Controller certificate (from the client side) or the Smartcard certificate (from the Domain Controller side) fails, no logons will be possible.
Example: The issuing CA is down and cannot publish any new CRL, this would eventually cause the existing CRL to expire and no new CRL to be available until the CA has been recovered. Using the default settings smartcard logons will start failing as soon as any CRL in the certificate chain becomes stale (expires).
Ticking the ‘Smart Card is required for interactive logon’ checkbox for a user resets the password for that user to a random complex password that is unknown to anyone and the UserAccountControl attribute of the user gets the flag SMARTCARD_REQUIRED added to it.
In addition to this, the DONT_EXPIRE_PASSWORD flag on the account is set so that the user's password never expires. The GINA or LogonUI components on the client check for the presence of the SMARTCARD_REQUIRED flag during an interactive logon (console or RDP) and reject the logon if it isn’t made with a smartcard when it is set for the user.
When a smartcard logon takes place, revocation checking is performed on both the client and the server side:
- The client (XP/Vista or W2k3/w2k8) does a revocation check on all the certificates in the Domain Controller certificate chain, this is to make sure that it’s actually talking to a DC that has a valid Domain Controller certificate.
- The authenticating DC (W2k/W2k3/W2k8) does a revocation check on all the certificates in the Smart Card certificate chain, this is to make sure that the smartcard certificate or any of parents in the chain hasn’t been revoked.
If either of these revocation checks fails, by default the smartcard logon also fails.
The changes to the revocation checking that were implemented in KB article 887578 are as follows:
Client-side:
- If the registry setting UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors is present on the client and is set to a non-zero value, the revocation checking of the Domain Controller certificate always succeeds (unless the CRL is reachable and the certificate has in fact been revoked).
Note that this value is only read during Smartcard logons.
Server-side:
1) Call code that takes care of downloading and caching the CRL (for all certificates in the chain)
a. If any of the CRL’s has expired or is not present in the local CRL cache; try to download a new one from the CDP which will either fail or succeed
b. If any of the CRL we download is also expired or we can’t download a CRL, set the returned error code to CRYPT_E_REVOCATION_OFFLINE
2) If the error returned is CRYPT_E_REVOCATION_OFFLINE *and* the CRL has not expired by an amount of hours greater than the CRLValidityExtensionPeriod, change the return code to 0 (ERROR_SUCCESS)
3) …proceed with the rest of the chain verification.
The KDC does a revocation checking of the smartcard certificates. CRLValidityExtensionPeriod is the server setting; setting it on the client has no effect. There is no CRLValidityExtensionPeriod setting for the client…that part only applies to the authenticating DC, which means there is no grace period for the client when it verifies the DC certificate .
Note:
Post-W2k3 - the registry entry UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors is used in three different components and each has a separate function that is only relevant to that component - setting it in one place doesn't affect the other two components.
The three different locations are:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaCredssp
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetserviceskdc (only valid for Domain Controllers)
HKEY_LOCAL_MACHINESYSTEMCCSControlLSAKerberosParameters
It’s still ultimately only the authenticating Domain Controller that decides if the user will be allowed to authenticate and not the client; the client is only doing a revocation checking of the domain controller certificates during smartcard logons as a secondary caution to make sure it’s talking to a DC that has a valid domain controller certificate.
See also Steve Patrick's excellent blog entry about requiring smartcards for logon at http://blogs.msdn.com/spatdsg/archive/2006/09/05/739565.aspx
References:
You receive a "Logon failure" message when you use a smart card on a Windows Server 2003-based computer
http://support.microsoft.com/?id=887578
How to use the UserAccountControl flags to manipulate user account properties
http://support.microsoft.com/kb/305144
Manually publishing a new CRL during CA disaster recovery
http://blogs.technet.com/b/instan/archive/2011/05/23/adcs-ca-server-disaster-recovery-steps-when-smartcard-logon-is-required-but-no-valid-crl-can-be-published.aspx