Hoy, todas las organizaciones se plantean dejar de usar en algún momento las passwords para pasar a lo que denominan una autenticación fuerte . Y la salida del DNIe no ha hecho más que incrementar este tipo de necesidad.
Lo que sucede, no es que Windows no pueda implementar un logon con smartcards. Esta funcionalidad está presente desde que apareció Windows 2000 hace ya 6 años sino lo que dificulta su uso son los requisitos, que provienen de la aplicación de la especificación PKINIT basada en Kerberos. Estos requisitos se detallan en el articulo de soporte de Microsoft del caso Q281245 y puede consultarse en: http://support.microsoft.com/kb/281245/es
Con respecto a los requisitos, algunos son de configuración y son más o menos faciles de cumplir, mientras otros son relativos a la estructura y contenido del certificado o certificados x509v3 contenidos en la tarjeta intelegente (smartcard).
Windows requier requiera que el certificado contenga:
- La ubicación del Punto de distribución de CRL (CDP), donde CRL es la Lista de revocación de certificados, debe estar llena, en conexión y disponible. Por ejemplo:[1]Punto de distribución CRLNombre del punto de distribución:Nombre completo:URL=http://server1.name.com/CertEnroll/caname.crl
- Uso de claves = firma digital
- Restricciones básicas [Tipo de asunto=Entidad final, Restricción de longitud de ruta=Ninguna] (Opcional)
- Uso mejorado de claves = Autenticación del cliente (1.3.6.1.5.5.7.3.2)(El OID de autenticación del cliente sólo es necesario si se utiliza un certificado para la autenticación SSL.)
- Inicio de sesión de tarjeta inteligente (1.3.6.1.4.1.311.20.2.2)
- Nombre alternativo del sujeto = Otro nombre: Nombre principal= (UPN). Por ejemplo:UPN = usuario1@nombre.com, El OID OtherName UPN es: "1.3.6.1.4.1.311.20.2.3" y el valor OtherName UPN: debe ser una cadena UTF8 codificada en ASN1
- Asunto = Nombre completo del usuario. Este campo es una extensión obligatoria, pero es opcional rellenarlo.
El mayor obstaculo, en mi opinión, son los atributos que he marcado en rojo y en especial el segundo que obliga a establecer la relación entre el certificado y el usuario en el mismo momento de la emisión del certificado.
Esto tiene algunas implicaciones, tanto técnicas como operativas, y es que si se trata de un certificado personal se esta vinculando datos laborales de la persona (usuario del Directorio Activo que corresponde a la persona de la empresa en la que trabaja cuando se emite el certificado), si por cualquier razón esa persona cambia de trabajo necesitaría revocar dicho certificado y solicitar uno nuevo.
Si nos planteamos utilizar en nuestra empresa alguno de los certificados personales que se emiten por la administración como los certificados CERES o el propio DNI electrónico, veremos que ninguno cumple estos requisitos y no pueden solicitarse como requiere Windows.
Y es que Windows no puede configurarse en este aspecto y tiene configurado que la relación entre el certificado y el usuario debe ser siempre a través del contenido del atributo "Nombre alternativo del asunto" (Subject Alternative Name) y que el certificado debe tener el proposito de "Inicio de sesión de tarjeta inteligente" (Smartcard logon) y una dirección (URL) válida para la comprobacion de revocación.j
Adicionalmente es obligatorio en el logon comprobar siempre la revocación de certificados no pudiendo desactivarse por el administrador este comportamiento al igual que se hace en otras aplicaciones. Esto lo hace más seguro, pero en ciertos casos añade más segundos de demora al proceso de inicio de sesión.
Si falla cualquiera de estas requisitos, Windows determina que el certificado no es válido para el logon y no progresa la petición, con el consiguiente mensaje al usuario.
La realidad es, que desde hace ya algunos años, y en especial desde el lanzamiento del DNI Electrónico (DNIe) la mayoría de los organismos públicos y empresas estan planteandose evolucionar desde el inicio basado en usuario y contraseña a una autenticación más segura basada en varios factores (algo que tiene el usuario o algo que és, además de lo que sabe).
Lamentablemente, Microsoft no ha publicado planes para cambiar este comportamiento en Windows y las implementaciones que resuelven esta problemática por parte de empresas de software, optan por el método tradicional de reescribir el proceso que gobierna el logon de Windows (comúnmente denominado GINA de Graphical Identification aNd Authentication library)
Todo esto nos ha llevado en Smart Access a desarrollar una familia de productos (denominada SmartID) que facilita y promueve el uso de smartcards, certificados y opcionalmente reconocimiento biométrico para un incio de sesión más seguro en Windows. Estos productos ya se comercializan desde Abril de 2006 y proporcionan la flexibilidad a las organizaciones de utilizar cualquier certificado propio o emitido por terceros para el inicio de sesión en Windows utlizando smartcards de forma segura.
Rames.
No hay comentarios:
Publicar un comentario