Implementação de Smart Cards. O que acontece quando a publicação das CRL’s falha.

Neste post vamos abordar o tema "Implementação de Smart Cards. O que acontece quando a publicação das CRL’s (Certificate Revocation List) falha".

 

Vamos supor que a sua organização quer implementar a utilização de Smart Cards como parte de uma nova política de Segurança, por exemplo a implementação de “Autenticação two-factor”. Normalmente quando falamos deste assunto levantam-se uma série de preocupações:

O que é que acontece quando falha a verificação da revogação do certificado do Servidor do Domínio (a partir do cliente) ou falha do lado do certificado Smart Card ( a partir do Controlador de Domínio)? Se isto suceder nenhum logon será possível causando uma indisponibilidade total.

 Se tomarmos como exemplo a utilização das configurações Default, podemos depararmo-nos com as seguintes situações:

A entidade certificadora “Issuing CA” está indisponível e não consegue publicar um nova CRL válida;

A CRL do “Offline Root CA” não foi renovada e publicada para as localizações CDP (Certificate Ditribution Point);

Eventualmente os certificados irão expirar e como uma nova CRL não se encontra disponível os logon’s com os Smart Cards falharão de imediato.

 

Então vamos lá perceber o que acontece quando utilizamos Smat Card:

• Quando seleccionamos a opção “Smart Card is required for interactive logon” ou “Para inicio de sessão interactivo é necessário um cartão Smart”  a password do utilizador é alterada para uma password complexa aleatória que é desconhecida por todos, e o atributo de UserAccountControl é alterado para incluir o flag de SMARTCARD_REQUIRED.

Artigo relacionado:

How to use the UserAccountControl flags to manipulate user account properties
https://support.microsoft.com/kb/305144

 

• Durante o Logon a GINA ou os componentes de LogonUI fazem uma verificação da presença da Flag durante o processo de logon interactivo (Consola ou Remote Desktop Protocol) e rejeita o logon se não for efectuado com o Smart Card se a flag estiver activa;

 

• Quando um logon é efectuado utilizando Smart Cards é efectuada a verificação da validade do certificado Revocation checking (verificação de revogações) quer do lado do Controlador de Domínio quer do lado do cliente.

No cliente, é efectuada uma verificação de revogação de todos os certificados na hierarquiado certificado do Controlador de Domínio, isto para certificar que o cliente está a comunicar com um Controlador de Domínio válido.

No Controlador de Dominio, é efectuada uma verificação de revogação de todos os certificados na hierarquiado certificado que se encontra no Smart Card, isto para garantir que o certificado do Smart Card ou qualquer certificado nacadeianão foi revogado.

Se qualquer das verificações acima mencionadas falhar, com as configurações Default, o logon não vai ser possível; 

 

• A falta de presença dum certificado válido no Ntauth store na Active Directory poderá também levar a problemas de autenticação.

How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store
https://support.microsoft.com/kb/295663

 

Para resolver algumas destas situações foram implementadas alterações ao método de verificação de revogações, como o kb887578 abaixo mencionado refere:

No Cliente:

Se a chave de registo UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors estiver presente e se tiver uma configuração que não seja zero “0”, a verificação de revogação do certificado do Controlador de Domínio pode ser sempre bem sucedido. Nota: Este valor apenas é lido durante o logon com certificados.

Smart Card Authentication Changes
https://technet.microsoft.com/en-us/library/cc721959(WS.10).aspx

Registry key values to disable CRL checking

Key	Value
HKLM\SYSTEM\CCS\Services\Kdc\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors	Type=DWORD Value=1
HKLM\SYSTEM\CCS\Control\LSA\Kerberos\Parameters\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors	Type=DWORD Value=1

No Controlador de Domínio:

1) É chamado código que trata do download edo caching das CRL para todos os certificados na hierarquia do certificado.

a)     Se algum dos certificados da CRL expirou ou não estiver presente no cache local CRL; tenta fazer download de uma nova CRL a partir do CDP, que vai falhar ou terá sucesso;

b)     Se algum das CRL dos quais efectuamos download também tiver expirado ou se não podermos aceder a uma das CRL’s, o código de erro é definido como CRYPT_E_REVOCATION_OFFLINE

 

2) Se o erro retornado é CRYPT_E_REVOCATION_OFFLINE, e casoa CRL não tenha expirado por uma quantidade de horas maior do que o CRLValidityExtensionPeriod, o código de retorno passa para 0 (ERROR_SUCCESS)

3) O resto da verificação da cadeia.

O KDC faz uma verificação de revogação dos certificados de smart card. CRLValidityExtensionPeriod é uma configuração de servidor, que não tem nenhum efeito sobre o cliente, o que significa que não há período de carência para o cliente quando ele verifica o certificado do Controlador de Domínio.

UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors é uma definição de cliente, quando definido no cliente, o mesmo conseguirá sempre fazer uma verificação de revogação do certificado do Controlador de Domínio com sucesso, desde que tenha um CRL em cache. Não vai tentar fazer download de uma nova CRL, uma vez que é considerado logon em modo offline. Esta só se aplica para logon’s com Smart Cards.

Nota: É ainda, em última análise a autenticação do Controlador de Domínio que decide se o utilizador terá permissão para autenticar, e não o cliente. O cliente só está  a fazer uma verificação de revogação dos certificados do Controlador de Domínio durante o logon com Smart Cards, como um cuidado secundário para se certificar que este está a falar com um Controlador de Domínio que possui um certificado de Controlador de Domínio e válido.

 

E quais as ferramentas que podemos utilizar:

Podemos validar se as CRL’s no Domínio estão válidas e acessíveis através da ferramenta pkiview.msc (incorporado no sistema operativo Vista / Windows 7 / 2008 / 2008 R2 ou disponível via download para 2003 / 2003 R2 através do 2003 Resource Kit)

           

 

Nota: A ferramenta PKIview.msc corre no contexto do utilizador, assim sendo utiliza o contexto de segurança do utilizador para LDAP e para HTTP além das configurações do proxy definido para tentar aceder aos caminhos definidos http. Não se esqueçam que quando estamos a falar de certificados de Computador, o sistema terá de ter acesso aos caminhos especificados tendo em alguns casos a máquina de ter configurações de Winhttp definidos.

Artigo relacionado:
Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)
https://technet.microsoft.com/en-us/library/cc731131(WS.10).aspx

 

Para poder listar os certificados disponíveis num Smart Card utilize o comando: Certutil -scinfo
Introduzir PIN não é necessário para esta operação. Basta premir Esc em cada caixa de diálogo para fazer a leitura dos certificados públicos no cartão.

 

Referências:
==========

O Steve Patrick's  tem um excelente blog sobre logons com smart cards que recomendo:

So, you want to use smart cards? - Spat's WebLog (Steve Patrick) - Site Home - MSDN Blogs
https://blogs.msdn.com/b/spatdsg/archive/2006/09/05/739565.aspx

How To: Determine if a user has logged on via smart card - Spat's WebLog (Steve Patrick) - Site Home - MSDN Blogs
https://blogs.msdn.com/b/spatdsg/archive/2006/09/06/739854.aspx

AD Troubleshooting - Site Home - TechNet Blogs

https://blogs.technet.com/b/instan/

 A equipa de Suporte,

Jean-Pierre Ramalho