El Polizón Tanzano

Publicada la RC1 de FIM 2010

noreply@blogger.com (Unai Castro) — Thu, 01 Oct 2009 06:51:00 +0000

Microsoft ha publicado hoy la Release Candidate 1 de Forefront Identity Manager 2010. Está disponible para su descarga en el siguiente enlace.

Actualización gradual a MOSS 2007

noreply@blogger.com (Unai Castro) — Sun, 17 May 2009 08:59:00 +0000

Existen varias formas de actualizar una infraestructura a MOSS 2007, en función del tamaño y complejidad de la infraestructura, se puede realizar una actualización inmediata, gradual (con o sin servicios compartidos) o una migración del contenido de las bases de datos a una nueva granja de servidores.

La actualización inmediata sólo se recomienda para sitios con un único servidor o una granja de servidores pequeña. Tiene la ventaja de que se realiza de una forma automática, mediante el asistente, y de que se conservan las URL’s originales. Los inconvenientes que presenta es que los sitios dejarán de estar disponibles durante el proceso de actualización. Este tipo de actualizaciones no se puede revertir.

Las actualizaciones graduales se deben utilizar para granjas medianas o grandes, con muchos sitios. Tiene la ventaja de que los sitios se van migrando poco a poco y que, durante este proceso, se puede seguir utilizando la infraestructura. Por otra parte este tipo de actualización permite revertir los cambios en caso de que algún portal o sitio presente problemas debido a personalizaciones o código en la nueva versión. El inconveniente es que este procedimiento es más complejo y se utilizan más recursos.

La migración de bases de datos se utiliza básicamente cuando se va a actualizar el hardware o la arquitectura de la granja de servidores. Este es el método más complejo de los anteriores.

Para conocer todos los detalles de los tipos de actualizaciones se puede consultar el siguiente artículo de la Technet Library: http://technet.microsoft.com/es-es/library/cc263447.aspx

Además de los tipos de actualizaciones es necesario conocer qué rutas y topologías están admitidas para su migración. Por ejemplo, no se puede actualizar directamente Windows Sharepoint Services 2.0 a Office Sharepoint 2007. Otra restricción es que no se puede realizar una actualización gradual de Sharepoint 2003 cuando éste utiliza una base datos MSDE, lo cual sucede cuando se instala Sharepoint 2003 con motor de base de datos.

Y todo esto viene a colación porque intentando realizar una migración gradual de Sharepoint 2003 a la versión 2007 me he encontrado con que el asistente de instalación tenía deshabilitada la opción de actualización gradual tal y como se ve en la siguiente imagen.

Mi infraestructura de Sharepoint utiliza un servidor SQL 2005 para las bases de datos, con lo que, a priori, no debería existir ningún problema. En mi caso las bases de datos de los sitios están en una instancia llamada “Sharepoint”, como se puede ver en la siguiente imagen.

Después de darle bastantes vueltas he descubierto que si la instancia de SQL se denomina “Sharepoint” el asistente de instalación determina que el motor de base de datos que se está utilizando es MSDE y deshabilita la opción de actualización gradual. Aunque existen otros métodos mejor que el nombre de la instancia para determinar la versión del motor de base de datos parece que en Microsoft se basan únicamente en el nombre.

La única solución que he encontrado a este problema ha sido crear otra instancia con un nombre distinto, mover las bases de datos y restaurar el Sharepoint desde la nueva instancia. Una vez hecho esto ya tengo disponible la opción de actualización gradual.

Forefront Identity Manager 2010

noreply@blogger.com (Unai Castro) — Sat, 09 May 2009 16:57:00 +0000

Microsoft ha publicado recientemente el nuevo nombre para ILM “2”, se denominará Forefront Identity Manager 2010. De este nuevo apelativo se desprenden dos corolarios.

1. Microsoft ha decidido incluir ILM en la familia de productos de seguridad Forefront.

2. Se retrasa el lanzamiento al menos hasta el año 2010, en lugar del cuarto trimestre de 2009 en el que estaba programado.

La nueva imagen se puede visitar en la web del producto: http://www.microsoft.com/Forefront/en/us/identity-manager.aspx

Cambiar la contraseña de los usuarios de CLM

noreply@blogger.com (Unai Castro) — Sat, 09 May 2009 16:23:00 +0000

Cambiar la contraseña de los usuarios que utiliza CLM no es un procedimiento trivial. Es necesario tener en cuenta diversos aspectos para que la infraestructura continúe funcionando correctamente. Igualmente hay que garantizar la administración de las tarjetas y certificados emitidos hasta el momento mediante esta herramienta.

CLM utiliza las contraseñas de los usuarios con los que se configuró la infraestructura para poder realizar las tareas de administración con los certificados y tarjetas. Durante la configuración de CLM, el asistente, solicita las cuentas de usuario y las contraseñas de los seis usuarios necesarios para estos menesteres. Estas contraseñas se almacenan cifradas en una clave del registro HKLM\SOFTWARE\Microsoft\Clm\v1.0\Server\WebUser, la podemos ver en el archivo web.config de CLM. La clave se cifra mediante Data Protection API. En el momento que modifiquemos las claves de los usuarios de CLM en el Directorio Activo los valores de estas claves de registro no se corresponderán con la contraseña de los usuarios y CLM dejará de funcionar correctamente.

La forma de actualizar las contraseñas en el registro es ejecutando de nuevo el asistente de configuración de CLM. Durante el asistente se solicitarán los usuarios que utilizará CLM. Se debe indicar que utilice los usuarios ya creados indicando para cada uno de ellos las nuevas contraseñas. En otro paso de este procedimiento se solicitará el servidor SQL y la base de datos para CLM. Es importante indicar al asistente que se utilizará la misma base de datos para mantener la información de los certificados y tarjetas emitidos hasta el momento.

El asistente además de almacenar las nuevas contraseñas solicitará nuevos certificados a la entidad certificadora para los usuarios clmUser, clmAgent y clmKRAgent. Actualizará el archivo web.config con la nueva configuración. Dentro de este fichero introducirá las huellas de los nuevos certificados de los usuarios de CLM. De esta forma será capaz de determinar qué certificados deberá utilizar. Sólo las huellas de los usuarios clmAgent y clmUser, agente de inscripción y el usuario para el firmado de solicitudes respectivamente, se almacenan en el fichero web.config.

Si la renovación de certificados se realizase de forma manual habría que sustituir los valores de las huellas digitales manualmente en el fichero web.config. La clave está en sustituir los valores en las líneas que contengan “hash” y añadir las claves, eliminado los espacio y separados por punto y coma, en las líneas que contengan “hashes”. En concreto las estas líneas son las siguientes:

Para clmUser:

add key="Clm.SigningCertificate.Hash" value="0A09A7470ABAD05488EED141FA4FA469B7AA71AF"

add key="Clm.SmartCard.ExchangeCertificate.Hash" value="0A09A7470ABAD05488EED141FA4FA469B7AA71AF"

add key="Clm.ValidSigningCertificates.Hashes" value="307B1A81504E334D8466836684ED3258DBCADAB5;04ABEF24AD4D0ACEA0D2B6293BED6D76945CBF13;0A09A7470ABAD05488EED141FA4FA469B7AA71AF"

Para el Agente de inscripción clmAgent:

add key="Clm.EnrollAgent.Certificate.Hash" value="A3E583F664587DF996FA0CDBD151C5B7D88B306E"

Por último hay que asegurarse de que el certificado emitido al usuario clmKRAgent está incluido dentro de los agentes de recuperación de la CA.

Cifrado EFS mediante Smartcard

noreply@blogger.com (Unai Castro) — Sun, 29 Mar 2009 17:28:00 +0000

A la hora de cifrar carpetas o documentos en Windows Vista si no disponemos de un certificado de EFS (Encrypting File System), emitido por una Entidad Certificadora en el almacén personal de certificados, el Sistema nos proporcionará uno autofirmado para este fin. Curiosamente cuando tenemos un certificado EFS dentro de una tarjeta Smartcard al cifrar documentos, Vista crea un certificado autofirmado en lugar de utilizar el certificado de la tarjeta. Aunque este comportamiento se puede cambiar.

Modificar las propiedades del usuario

La primera opción es modificar las propiedades de cifrado EFS del usuario para indicar que el certificado que se ha de utilizar sea el de la tarjeta Smartcard. Para realizar este procedimiento será necesario acceder al Panel de Control y después a la cuenta de usuario. Desde este punto tendremos un enlace para la administración de los certificados de encriptación de ficheros.

Si seguimos el asistente nos proporcionará la opción se seleccionar el certificado que queremos utilizar para la encriptación. Será necesario tener la tarjeta introducida en el lector.

Una vez seleccionado el certificado necesitaremos disponer de la tarjeta para encriptar y desencriptar la información. Para realizar estas operaciones será necesario introducir el PIN de la tarjeta con el fin de acceder al objeto privado, en este caso la clave privada, de la tarjeta.

Uso de los Objetos de Directiva de Grupo

En Windows Vista existe la posibilidad de administrar la gestión de certificados EFS mediante GPOs. La política que se debe configurar se encuentra dentro de la Configuración del Equipo, en Windows Settings, Public Key Policies, Encrypting File System. Si abrimos las propiedades con el botón secundario del ratón tendremos acceso a las características para la gestión de este tipo de certificados.

Entre estas opciones se puede optar por requerir tarjetas Smartcard para EFS. De esta forma cuando el usuario vaya a encriptar algún documento o fichero se le requerirá una tarjeta para llevar a cabo el proceso.

Bloqueo de extensiones en Outlook

noreply@blogger.com (Unai Castro) — Sun, 15 Mar 2009 10:54:00 +0000

Outlook, por defecto, bloquea los ficheros con extensiones peligrosas como exe, com o vbs, e incluso, como se puede ver en la imagen, archivos de certificados con extensiones .cer.

Para permitir el acceso a estos archivos bloqueados sólo hay que añadir un valor en la siguiente clave de registro:

HKCU\Software\Microsoft\Office\12.0\Outlook\Security

Crear un valor de tipo String con el nombre "Level1Remove" y en él introducir las extensiones ha desbloquear separadas por punto y coma, por ejemplo: ".exe;.com;.cer".

Reiniciar el Outlook y listo.

Cómo saltarse la directiva de formato de archivos en Office

noreply@blogger.com (Unai Castro) — Sat, 14 Mar 2009 18:14:00 +0000

Espero que este artículo no lo lean los administradores de mi dominio. En mi defensa diré que es muy triste venderle a los clientes las virtudes de Office 2007 y no poder guardar los documentos en el nuevo formato xml de esta suite.

Como consultor paso la mayor parte del tiempo en clientes y rara vez conecto el portátil en la red corporativa de mi empresa. Recientemente estuve una semana en la oficina, curiosamente después de un proyecto sobre Office 2007 en un cliente, y sucedió lo que tenía que pasar; se me aplicaron las GPOs que los administradores definieron en el dominio. Entre ellas una sobre los formatos de archivos con los que podía guardar los documentos de Office 2007. Me puse a trabajar con Word y estuve escribiendo un documento, cuando fui a guardarlo Word me devolvió el siguiente aviso:

No podía guardar mi documento en el nuevo formato xml de Word 2007 (docx), aunque se me permitía guardarlo en formato Word 97-2003 (doc). Intrigado seguí el enlace (http://support.microsoft.com/kb/922850) de la Knowledge Base de Microsoft para averiguar el problema. En él se explica que este mensaje aparece cuando están restringidos los tipos de documentos de Office que se pueden abrir o guardar. Esta restricción se puede llevar a cabo de tres formas distintas: Desde la configuración del Centro de Confianza de los programas de Office, modificando una clave de registro de Office o desde una directiva de grupo. Comprobé el Centro de Confianza de Word y la clave de registro, y no habían sido alteradas. El “problema” estaba en la GPO de dominio que se había aplicado al equipo.

Las plantillas administrativas de Office 2007

Como soy administrador del equipo intenté comprobar la teoría de que alguna directiva de grupo estaba impidiéndome guardar mis documentos en formato xml. Me descargué las plantillas administrativas de Office 2007 desde el centro de descargas de Microsoft (http://go.microsoft.com/fwlink/?LinkId=78161) y las apliqué en la consola de edición de directivas de grupo local. Efectivamente pude comprobar que la directiva sobre los tipos de documentos que se podían guardar estaba configurada para bloquear los documentos en formato xml, tal y como se puede apreciar en la siguiente imagen:

Lo primero que se me ocurrió fue modificar la directiva de grupo de local para deshabilitar esta directiva pero no funcionó. Luego recordé que la directiva de grupo del dominio tiene prioridad sobre la local. Al contrastarlo en Internet di con un post en el blog de mi amigo Asier Marqués http://asiermarques.com/2007/05/31/orden-de-aplicacion-y-lectura-de-las-directivaspoliticas-de-grupo-gpo-en-dominios-microsoft/) donde corroboré lo que sospechaba.

Solucionando el problema o como saltarse la directiva de los administradores

Evidentemente si no somos administradores del equipo no tenemos nada que hacer dado que el funcionamiento del mismo quedará irremediablemente ligado a lo que determinen los administradores del domino. Pero ya se sabe que hacerse administrador del equipo es muy sencillo, aunque esto no lo voy a contar aquí. Una vez que hemos logrado ser administradores locales del equipo, por supuesto, solicitándolo reglamentariamente a nuestros administradores de red, podemos solucionar el problema.

Lo primero que he pensado es que como es una directiva de usuario podía abrir el programa con la cuenta de administrador local del equipo mediante el comando runas. Esta solución ha funcionado pero no me ha parecido muy elegante.

Al final he encontrado otra solución que me ha gustado mucho más.

Las plantillas administrativas de Word 2007 a nivel de usuario se guardan en la siguiente clave de registro: HKCU\Software\Policies\Microsoft\Office\12\Word. En concreto la directiva para el bloqueo a la hora de guardar documentos de en formato xml se almacena en HKLU\Software\Policies\Microsoft\Office\12.0\Word\Security\FileSaveBlock en el valor OpenXmlFiles. Si este valor está a 1 no se permitirá guardar los documentos en este formato. Sólo es necesario modificarla y ponerla a 0, tal y como se muestra en la siguiente imagen:

Evidentemente cuando volvamos a iniciar sesión en el dominio la clave se modificará por lo que haya definido el administrador, en mi caso se volverá bloquear. Lo que podemos hacer es exportar la clave del registro a un fichero .reg y aplicarla una vez iniciada la sesión, lo más cómodo sería crear un script e introducirlo en la carpeta inicio del menú de inicio de Windows de forma que una vez iniciada la sesión se aplique el valor que nos interesa en el registro.

Periodo de validez de las CRLs

noreply@blogger.com (Unai Castro) — Wed, 11 Mar 2009 16:40:00 +0000

Las CRLs (Certificate Revocation List) son las listas que publica una PKI con los certificados que, por el motivo que sea, han sido revocados. Cuando una aplicación tiene que comprobar la validez de un certificado verifica, además de otras cosas, que el certificado no se halle en esta lista. Si no es así se determinará que ese certificado está revocado y por lo tanto no se confiará en él. Existen otros sistemas como OCSP (Online Certificate Status Protocol) para la verificación de la validez de los certificados que incluyen ventajas sobre las CRLs pero aún no están tan implantadas como estas últimas. En otro artículo hablaré de OCSP.

Como se puede ver en la imagen los certificados incluyen un campo con uno o varios CDPs (CRL Distibution Point) Punto de Distribución de la CRL. Estas direcciones permiten a las aplicaciones determinar dónde deben realizar la consulta para determinar el estado del certificado.

Es muy importante que las CRLs estén disponibles para su consulta en el ámbito de uso de los certificados. Si realizamos un uso de nuestros certificados fuera de nuestra organización tendremos que publicar en internet, mediante un sitio web o FTP, nuestras CRLs. Si el uso que vamos a hacer de nuestros certificados es interno, podremos utilizar un sitio dentro de un servidor interno, publicar la lista en algún recurso compartido o, incluso, en el Directorio Activo mediante LDAP.

Otro factor importante es la disponibilidad de esta información para las aplicaciones. Se debe garantizar que la CRL esté replicada en varios sitios para, en caso de caída de algún servicio, poder seguir consultándola.

La determinación del periodo de publicación de la CRL depende de muchos factores como la criticidad de los certificados, la cantidad de certificados emitidos y revocados o la cantidad de CDPs en los que se distribuya. En función de estos factores se determinará un periodo de publicación que a su vez será el periodo de validez de las CRLs. En cualquier caso este periodo puede variar desde unas horas hasta años. Como se puede ver en la siguiente imagen el periodo de validez de la siguiente CRLs es de una semana.

La caché de las listas

Entonces es necesario que las aplicaciones que deseen consultar la validez de un certificado deban consultar, en realidad se descarga, la CRL que se encuentra en el CDP del certificado. Imaginemos por un momento una PKI Pública como puede ser Verisign que tiene emitidos miles de certificados para sus clientes: Bancos, organismos oficiales, empresas, … los cuales pueden recibir millones de visitas diarias. En cada una de ellas el navegador deberá descargar y consultar la CRL alojada en Verisign para comprobar la validez del certificado de la página web. Esto supone que la cantidad de accesos al CDP pueda resultar enorme. Para mitigar un poco esta situación las CRLs se cachean, es decir, se almacenan en el cliente cuando se realiza una consulta. De tal forma que si accedemos a la web de nuestro banco se descargará la CRL del CDP de la Entidad Certificadora que utiliza nuestro banco y se consulta. Sin embargo, la siguiente vez que nos conectamos no será necesario descargar la CRL dado que la tenemos cacheada y se consulta en local.

Obviamente el tiempo de vida de la CRL que tenemos en la caché es limitado. El límite está impuesto por el periodo de validez de la CRL que se define en el periodo de validez de las mismas. Es muy importante que este periodo permita la seguridad suficiente, en función de cada caso, pero sin llegar a sobrecargar los servidores donde esté publicada. Si el periodo es excesivamente grande, pongamos 1 año, veremos que los clientes se descargarán la CRL una vez y no volverán a hacerlo hasta un año después. Como resultado nuestros CDPs trabajarán sin agobio ninguno. El problema será cuando queramos revocar un certificado, todos los clientes que tengan cacheada la CRL no se descargarán una nueva hasta que la que tienen en caché expire. Es decir, seguirán confiando en un certificado que, por el motivo que sea, hemos decidido revocar. También puede suceder lo contrario; que pongamos un periodo de validez muy pequeño, por ejemplo 1 hora. El efecto será igualmente preocupante, sobre todo si tenemos un gran número de certificados emitidos, porque los clientes se deberán descargar una nueva CRL prácticamente en cada una de las validaciones de los certificados. Eso sí, en cuanto revoquemos un certificado lo sabrán todos los clientes como máximo en una hora.

Habría que pensar muy bien que periodo de validez se debe otorgar a las CRLs, no es lo mismo un certificado de firma de un documento o correo que otro servicio más crítico como puede ser el acceso a una VPN o al Dominio mediante tarjetas inteligentes.

La CRL Delta

A medida que la CRL crece, cosa que inevitablemente sucederá más tarde o más temprano, los clientes tienen que descargarse una cantidad mayor de información. Esto combinado con un periodo de validez relativamente corto puede saturar tanto a los clientes como a los servidores de la PKI. Para mitigar esta situación existen las CRL Delta, que contienen únicamente las modificaciones de la CRL. De esta forma la aplicación cliente solamente se descargará la CRL Delta si dispone de una CRL cacheada que sea válida. Cuando se publica una nueva CRL, bien porque el periodo de validez haya expirado o porque el administrador de la PKI la haya publicado de nuevo, la información de la CRL Delta se volcará a la CRL nueva.

El problema de los controladores de dominio

Como he explicado anteriormente, existen determinados servicios en los que el tiempo desde que se revoca un certificado hasta que las aplicaciones clientes lo detecten es crítico. El ejemplo más claro son los Controladores de Dominio (DC) en los que se permite el inicio de sesión mediante Smartcards. En este tipo de entornos lo que sucede es que los usuarios disponen de un certificado, con un propósito especial, que se asocia a su usuario del dominio. Cuando un usuario quiere iniciar sesión en cualquier cliente del dominio introducirá su tarjeta en lector e introducirá el PIN. El Controlador de Dominio comprobará que la identidad contenida en la tarjeta coincide con el objeto de usuario del Directorio Activo, que el certificado sea válido y, por supuesto, que no se haya revocado. Para esta última comprobación consultará la CRL del Punto de Distribución y la cacheará. En sucesivos intentos de inicio de sesión en ese DC se consultará la caché del servidor en lugar de descargar de nuevo la CRL.

¿Qué sucede si revocamos el certificado del usuario? El usuario podrá seguir accediendo mientras la CRL de la caché del servidor sea válida. Para resolver este problema, además de utilizar OCSP (del que hablaré en próximos artículos), podemos borrar la CRL de la caché del Controlador de Domino.

La caché se almacena en la siguiente ruta: C:\windows\system32\config\systemprofile\application data\microsoft\cryptonturlcache

Bastará con borrar el contenido de esta carpeta para eliminar cualquier CRL que esté cacheada. Aunque se reinicie el servidor la caché no se borrará hasta que lo hagamos manualmente o expire el periodo de validez.

Obviamente la recomendación, cuando deseemos que un usuario no inicie sesión en el Dominio, es deshabilitar o borrar la cuenta de ese usuario, independientemente de que se revoquen sus certificados.

Instalando MIIS de ILM2RC0

noreply@blogger.com (Unai Castro) — Tue, 10 Mar 2009 12:15:00 +0000

Por fin he conseguido instalar la parte de gestión de identidades de ILM “2” y no ha sido fácil. Os dejo en este artículo alguno de los problemas con los que me he encontrado, así como algunos enlaces relativos la instalación que os pueden ayudar en esta tarea.

El Nombre

En esta nueva versión ha desparecido definitivamente el término MIIS (Microsoft Identity Integration Server) que se utilizaba en la versión anterior para denominar a la parte de gestión de identidades, ahora simplemente se llama ILM. El servidor ILM se compone de cuatro partes que se pueden centralizar en un mismo servidor o distribuirlos por diferentes equipos con roles separados. Los componentes son: Servicio de sincronización de ILM, Servicio de ILM, Portal de ILM y Portal de contraseñas de ILM. Una de las cosas que me ha gustado es la interfaz del Portal de ILM que corre sobre Sharepoint. Desde ella se pueden gestionar los usuarios, los grupos de distribución, los grupos de seguridad y solicitudes de la Metaverse. También se gestionan las reglas de sincronización, flujos de trabajo y políticas de administración, entre otras características.

Los Prerequisitos

ILM “2” tiene un maremágnum de prerrequisitos de los que no voy a detallar todos, al final del artículo dejo unos enlaces con esta información, pero sí los más destacables. El servidor ILM sólo está disponible para arquitecturas de 64 bits y requiere al menos 2 GB de memoria. Entre los productos de software que hay que tener instalado destacan: Windows Server 2008, SQL 2008, Exchange 2007, Internet Information Server 7.0 y Windows Sharepoint Server 3.0. También son necesarios otros roles y características de Windows 2008 como un Controlador de Dominio, .NET Framework y Powershell. Finalmente si se desea desarrollar extensiones de reglas para el servicio de sincronización de ILM será necesario disponer de Visual Studio 2008.

El instalador del servidor sólo está disponible en inglés con lo que todos los productos descritos anteriormente deberán necesariamente estar en el mismo idioma. Esto que parece una tontería os puede dar bastantes quebraderos de cabeza como explicaré en el apartado siguiente de problemas durante la instalación. Existe un paquete de lenguaje aunque de momento sólo para alemán y japonés.

El laboratorio se puede instalar en una única máquina, de hecho durante la Beta 3 de ILM “2” Microsoft publicó una Demo en discos virtuales de Hyper-V en la que todo estaba instalado en el mismo equipo. He intentado encontrar el enlace para la descarga de este laboratorio pero parece que ya no está disponible en la web de Microsoft. Por mi parte he utilizado la misma infraestructura donde instale la parte de CLM. El laboratorio se compone de dos equipos Windows Server 2008 Enterprise Edition. En uno de ellos está el Controlador de Dominio y CLM y en el otro tengo SQL 2008, Exchange 2007 e ILM “2”.

La Instalación

La instalación no es muy complicada aunque lleva mucho tiempo por el número de prerequisitos. El mayor problema, al instalar el Servidor y los Portales de ILM, es que si hay errores durante misma es muy probable que no nos devuelva ningún mensaje de error y que la información del Visor de Sucesos no nos despeje ninguna duda. Os recomiendo que al lanzar el paquete de instalación especifiquéis la opción para la creación de un log del instalador, para ello ejecutadlo de la siguiente manera:

msiexec.exe –i \ILM-Server-64bit-msi /log \ILM-Server.log

En la ubicación os generará un fichero con todos los pasos de la instalación y los resultados de cada uno de ellos.

Otra cosa a tener en cuenta si tenemos habilitado el UAC es que la instalación hay que hacerla con elevación de privilegios: Con el botón secundario del ratón seleccionar ejecutar como administrador.

Ya lo he comentado antes pero es importante hacer hincapié en que todos los prerrequisitos deben estar instalados en inglés. En uno de los primeros intentos instalé el SQL en castellano y falló la instalación por este motivo.

El problema con Sharepoint

Un caso particular es el de Sharepoint, dado que aunque instalemos el producto en inglés puede no funcionar la instalación. Efectivamente, he estado varios días intentando instalar el Servidor de ILM con resultados desastrosos y sin ningún error descriptivo del problema. Algo como esto:

Me he recorrido todas las páginas y blogs sobre el producto que he encontrado (todas anglosajonas, por cierto) intentando determinar la causa del error pero sin resultado. ¿Porqué yo tenía un error que nadie más había sufrido? La respuesta es sencilla, aunque cuesta llegar a ella. Dándole vueltas al problema me he dado cuenta de que en mi laboratorio, a pesar de tener el software instalado en inglés, la configuración regional del equipo estaba en español. Se me ha ocurrido la feliz idea de que modificando la configuración se resolvería el problema. Pues no ha sido así. He tenido que reinstalar el Sharepoint después de modificar la configuración regional y después el servidor ILM, hasta que no he seguido este orden no ha finalizado la instalación correctamente. Y una vez funcionando no se debe modificar la configuración regional porque el portal dejará de funcionar.

Los Recursos

La página de producto de ILM “2”
http://www.microsoft.com/windowsserver/ilm2/default.mspx

Guía de Instalación de ILM “2”
http://technet.microsoft.com/en-us/library/cc561135.aspx

PKI Pública vs PKI Privada

noreply@blogger.com (Unai Castro) — Tue, 03 Mar 2009 19:45:00 +0000

Para empezar vamos a definir que entendemos por PKI Pública y PKI Privada. La PKI Privada es aquella compuestas por Entidades Certificadoras internas a nuestra organización en la que la Autoridad Certificadora Raíz pertenece también a nuestra organización. Este tipo de PKI genera certificados para los usuarios dentro de la organización, los equipos cliente, confían en ella gracias a la integración de la PKI dentro del Directorio Activo.

Una PKI Pública es una infraestructura en la que la Autoridad Certificadora Raíz pertenece a una Organización, con reconocimiento público, que emite sus certificados comercialmente para sus clientes. Los certificados de las Autoridades Certificadoras de las PKI Públicas se distribuyen junto con el sistema operativo, de tal forma que todos los usuarios que utilizan el Sistema Operativo confían en los certificados emitidos por estas Autoridades Certificadoras. Estas Autoridades se pueden consultar en el almacén de certificados del equipo dentro del contenedor de Autoridades Certificadoras Raíz de Confianza. En entornos Windows esta lista se actualiza mediante el sitio web Microsoft Update, junto con el resto de actualizaciones que publica el fabricante. Algunos ejemplos de Autoridades Certificadoras Públicas son: Verisign (www.verisign.com), Thawte (www.thawte.com) o Entrust (www.entrust.net).

Características

De las definiciones ya se adivinan varias características de cada una de ellas. En primer lugar a nivel económico, en una PKI pública tenemos que abonar cada uno de los certificados que necesitemos, por el contrario en una PKI Privada podemos emitir tantos certificados como deseemos de forma gratuita. Es cierto que la PKI pública tiene un coste en licencias, pero sólo del Sistema Operativo, con Windows Server se incluye esta característica. De tal forma que con una licencia de Windows Server 2008 Enterprise (unos 2000€ aprox.) podemos generar hasta 35 millones de certificados, en función claro está de las capacidades del equipo. Si compramos, por ejemplo, un certificado de SSL a una PKI Pública puede costarnos entre 100$ y 250$ según las tarifas de Verisign. Es cierto que al tener una PKI interna tendremos un gasto de administración y mantenimiento de la infraestructura pero en cualquier caso parece evidente que para un elevado número de certificados es mucho más rentable la PKI Privada.

Otros aspectos en el que las PKI Privadas salen mejor paradas es en la administración e integración de las mismas con el Directorio Activo y otras aplicaciones corporativas. Las PKI internas se integran perfectamente con el Directorio Activo de Windows así como con otros servidores de Microsoft.

La versatilidad que obtenemos con las PKI Privadas es otro factor a su favor. Al disponer de Entidades Certificadoras propias podemos modificar las plantillas de los certificados que vamos a emitir conforme a los usos que les vayamos a dar. Se pueden incluso combinar varios propósitos dentro de la misma plantilla de certificado para utilizarlos para más de una tarea. Se pueden incluso personalizar algunos campos para que se incluya información adicional en el certificado que nos permita, por ejemplo, utilizarlos en desarrollos propios.

El mayor obstáculo que tienen las PKI Privadas es que para confiar en ellas es necesario hacerlo ex profeso fuera de nuestra Organización. Si queremos publicar nuestro servidor web con un certificado SSL emitido por una Autoridad Certificadora interna tendríamos que distribuir a todos nuestros visitantes el certificado de la Autoridad Certificadora para que lo incluyan en el almacén de certificados como Autoridad Certificadora Raíz de Confianza. En caso contrario obtendrá una alerta indicando que no se puede determinar la confianza en ella.

¿Puedo tener una PKI Privada en la que confíen todos los usuarios de Windows?

La respuesta es sí. Como hemos visto el mayor problema que tienen las PKI privadas es que, a priori, fuera de nuestra organización nadie confía en ellas. Este hándicap se puede solucionar de dos formas. Aunque no es sencillo ni barato.

La primera de ellas es tener una PKI en la que la Autoridad Certificadora Raíz sea de una PKI pública. Esta emitirá certificados para nuestras Entidades Certificadoras intermedias y subordinadas, de tal forma que nosotros administraremos nuestra PKI (excepto la raíz) y podremos emitir los certificados como queramos a nuestros usuarios y clientes. Este procedimiento obviamente requerirá un coste que será necesario consultar con las PKI Públicas del mercado.

La segunda opción es lograr que nuestra Autoridad Certificadora Raíz sea publicada dentro de las actualizaciones de Microsoft. Existe un programa de Certificados de Microsoft Raíz (http://technet.microsoft.com/en-us/library/cc751157.aspx) a través del cual podemos conseguir que Microsoft incluya nuestra entidad entre las de confianza dentro del Sistema Operativo. El problema es que esta opción no está disponible para empresas finales que requieran un únicamente un uso interno. La lista de miembros de este programa se puede consultar en la siguiente web http://support.microsoft.com/kb/931125.

Conclusión

En mi opinión lo ideal sería disponer de una PKI Privada para todos usos que necesitemos dentro de Organización: correo seguro, cifrado, firmado de código, smartcard logon, VPNs, OWA, firmado de documentos … por ser la solución más económica y adaptable a nuestras necesidades. Obviamente tendremos que recurrir a las PKI Públicas cuando queramos certificados, que como SSL, permitan a nuestros clientes y/o proveedores acceder de forma segura a nuestros servidores. Combinando ambas técnicas, dependiendo del uso, tendremos las ventajas de cada una de ellas, reduciendo el coste al mínimo.

Macedonia de extensiones de certificados

noreply@blogger.com (Unai Castro) — Thu, 26 Feb 2009 15:58:00 +0000

Cuando se empieza a trabajar con certificados digitales una de las primeras cosas que sorprende, al menos a mí me sorprendió, es la cantidad de extensiones de ficheros diferentes con las que se pueden guardar los certificados. El objetivo de este artículo es describir los distintos tipos así como la funcionalidad que tiene cada uno de ellos, dado que dependiendo de cual elijamos para guardar el certificado se le podrá dar un uso u otro.

Normalmente los certificados siguen el estándar X.509, actualmente la versión 3, de ITU-T (Union-Telecommunication Standardization Sector, www.itu.int). Sin embargo los certificados se pueden almacenar en otros formatos en función de las necesidades. Los formatos PKCS#7 y PKCS#12 (Public Key Cryptography Standards) son estándares definidos por RSA Security Inc (www.rsa.com).

Los archivos de los certificados, independientemente del formato, se pueden almacenar en archivos binarios (formato DER, Distinguish Encoding Rules) o en archivos de texto (formato PEM, Privacy Enhanced Mail). Los ficheros PEM están codificados en base 64.
A continuación os describo los distintos formatos y las extensiones más comunes que se utilizan para ellos:

Certificados X509 en formato DER

Se utilizan normalmente para el almacenamiento del certificado. Como he comentado anteriormente es un formato de archivos binario que almacena la información en el estándar x.509.

Este tipo de certificados suelen tener las extensiones CER, CRT y DER.

Certificados X509 en formato PEM

La codificación PEM se desarrolló para la securización del correo electrónico. Está codificado en Base 64, sistema conocido y estándar para los clientes MIME.

Las extensiones utilizadas para estos archivos suele ser PEM, aunque en Windows se utiliza CER, al igual que los codificados en DER.

Certificados X509 dentro de PCKS#7

El formato PCKS#7 permite almacenar el certificado junto con los certificados de la ruta de certificación. La ruta de certificación es el conjunto de certificados que jerárquicamente firman un certificado. Es decir, si un certificado de una Autoridad Certificadora (CA) ha sido firmado por una CA intermedia que a su vez ha sido firmado por una CA raíz, la ruta de certificación abarcará la CA intermedia y la CA raíz.

Las extensiones más comunes de los ficheros con este formato son: P7B, P7C, P7S, P7M. Estos archivos pueden estar codificados en formatos DER y PEM.

Estos ficheros se utilizan por ejemplo cuando hay que distribuir el certificado de una entidad certificadora a los almacenes de certificados de los equipos de un dominio. Esto suele ser necesario cuando se implanta una entidad certificadora y se desea que los equipos del dominio confíen en ella.

Los P7S se suelen enviar como anexo-MIME, codificado en Base 64, fuera del texto del mensaje en los mensajes de correo electrónico firmados. Si se utiliza un cliente de correo electrónico que no es S/MIME y se recibe un correo firmado se recibirá un anexo smime.p7s, si se abre se puede comprobar que están incluidos todos los certificados de la ruta de certificación.

Certificados X509 dentro de PCKS#12

Este formato permite la transferencia de los certificados junto con sus claves privadas correspondientes. En Windows este es único formato que admitido para la exportación de un certificado y su clave privada asociada. Dado que la clave privada debe confidencial y por lo tanto protegida el acceso a estos ficheros se realiza mediante una clave que se especifica al generarlos. El PCKS#12 sólo admite codificación DER.

PCKS#12, al igual que PCKS#7, permite incluir todos los certificados de la ruta de certificación cuando es posible.

Las extensiones más utilizadas para estos archivos suelen ser: PFX o PL2

Normalmente este formato se utiliza cuando se realizan backups de los certificados o cuando se necesita mover un certificado de un equipo a otro, por ejemplo de un Autoridad Certificadora.

No se si ha quedado algo claro o lo he liado más.

Instalando CLM de ILM “2” RC0

noreply@blogger.com (Unai Castro) — Tue, 24 Feb 2009 18:29:00 +0000

Por fin he tenido tiempo de instalar y probar la nueva versión de CLM que viene con ILM ”2” RC0 (se puede descargar aquí: http://technet.microsoft.com/es-es/evalcenter/cc872861(en-us).aspx . Esta nueva versión, que introduce numerosos cambios en la parte de gestión de identidades, no trae demasiadas novedades en la parte de gestión de certificados que ahora se llama Certificate Management Service (CMS). Una de ellas es que ahora es compatible con Autoridades Certificadoras de Windows Server 2008 tanto en 32 como en 64 bits. Y esta novedad es muy importante por todos los cambios que traen Certificate Services en Windows Server 2008 aunque eso ya lo contaré en otro artículo.Como iba diciendo, CLM en esta nueva versión no trae nuevas funcionalidades ni características aparentes, de hecho la interfaz es la misma salvo por el splash de presentación en el que han cambiado, obviamente, el nombre del producto.

El laboratorio donde lo he instalado se compone de un Controlador de Dominio, Windows Server 2008 x64, con los Servicios de Certificados y una Autoridad Certificadora Raiz y otra máquina también con Windows Server 2008 x64 con SQL Server 2008 Standard Edition.
Los prerrequisitos, según la documentación de Microsoft, son los mismos que para la versión 2007 aunque como veréis a continuación he tenido que pegarme un poco con la instalación y he descubierto que hace falta alguna cosilla más. Paso a comentar los problemas que he tenido y las soluciones a los mismos por si os sirven ayuda.

Primer problema: Error durante la instalación.

Cuando ya tenía preparado todo el entorno me he dispuesto a instalar CLM desde el msi para la versión de 64 bits. Casi al finalizar la instalación me ha salido el siguiente error:

El error ha aparecido justo antes de saltar .NET Framework así que con esta pista he descubierto que para esta versión además de .NET 2.0, tenía instalado el 3.0, es necesario instalar la versión 3.5 de .NET Framework. Tras instalarlo y reiniciar el equipo la instalación de ILM ha finalizado sin problemas.

Segundo problema: Sin conexión a SQL

Por defecto Windows Server 2008 tiene el Firewall activado con lo que al intentar configurar la instalación de CLM no tenía conexión al servidor de SQL. No olvidéis de abrir el puerto 1433 o el que corresponda a vuestra instalación de SQL.

Tercer problema: Solicitud de certificados para usuarios de CLM

Al llegar al punto de la configuración donde CLM solicita las plantillas de certificados para los usuarios de CLM: clmAgent, clmEnrollAgent y CLMKRAgent, no existía ninguna plantilla disponible. Han sucedido dos cosas. Al contrario que en las CAs de Windows Server 2003 en 2008 nadie, ni siquiera el administrador del dominio, tiene, por defecto, permisos para solicitar certificados. Por otra parte no existe ninguna plantilla publicada por defecto. He dado permisos de solicitud de certificados a nivel de la CA al usuario con el que hacía la configuración y he publicado las tres plantillas necesarias.
Tras solucionar este tercer problema la configuración ha finalizado con éxito.

Cuarto problema: Error de autenticación en IIS 7.0

Al conectarme a la web de CLM he obtenido un error de autenticación (esto sí que está en la documentación). Resulta que en IIS 7.0 la autenticación de Windows funciona en modo kernel por defecto. Es necesario deshabilitarla para que CLM funcione. Para hacerlo sólo hay que abrir el Administrador de IIS y en el sitio de CLM hacer doble clic en el icono Authentication. Después pulsar con el botón derecho sobre Windows Authentication y seleccionar Advanced Settings.

Lo único que hay que hacer es deshabilitar la casilla de verificación de Kernel-mode authentication. Tras lo que podremos entrar en el sitio web de CLM.

Quinto problema: Certificate Services no arranca.

Este ha sido sin duda el ganador de la tarde y, otra vez, por culpa de Kerberos. Después de configurar CLM, cuando añade los módulos de políticas y de salida, el servicio Certificate Services se ha parado y se ha negado a arrancar, escupiendo el siguiente bonito y descriptivo mensaje: “The process terminated unexpectedly. 0x24b (WIN32: 1067)”

En la rama de aplicación del visor de eventos esto se traducía en el siguiente evento:

Después de darle muchas vueltas y tras recordar cierta aventura en una instalación de CLM con un cluster de SQL donde un error Kerberos casi acaba con nosotros (yo contaré en otro momento esta historia) se me ha ocurrido investigar si de nuevo el problema podría venir con el SPN y Kerberos. En la rama de Sistema del visor de sucesos tenía lo siguiente: “Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN” y “Extended Error: 0xc0000035 KLIN(0)”

Esta prueba ha confirmado mis sospechas. Ni corto ni perezoso me he dispuesto a eliminar la entrada de SPN duplicada, así que he listado los nombres de servicios registrados para la cuenta del servidor de SQL y, mira por donde, no ha aparecido ninguno duplicado. Por si acaso he borrado las entradas correspondientes al servicio de SQL, pero no ha servido para nada. Después de restaurar lo borrado e investigar un rato por la red he encontrado el siguiente artículo de Brad Rutkowski http://blogs.technet.com/brad_rutkowski/archive/2008/08/01/domain-doesn-t-know-about-my-computer-account-i-vouch-for-my-computer-you-can-trust-me.aspx (en inglés) donde comenta un problema similar en el que una entrada del SPN estaba duplicada para un servicio. En el artículo indica que mediante un script, publicado por Microsoft en, http://www.microsoft.com/technet/scriptcenter/solutions/spnquery.mspx (también en inglés), se puede consultar un nombre de SPN para comprobar a que cuentas estaba asignado.

Con este script he descubierto que, supongo que la configuración de CLM, ha agregado el SPN de servicio a la cuenta del administrador del dominio, y ya existía para la cuenta de equipo del servidor de SQL. Sólo he tenido que borrarla e iniciar el servicio de Certificate Services.

Pues ya está, tengo operativo mi laboratorio de ILM “2” al menos de su componente CLM. El siguiente objetivo será la instalación de la parte de gestión de identidades.

Os seguiré contando.

En busca del driver perdido

noreply@blogger.com (Unai Castro) — Mon, 23 Feb 2009 18:50:00 +0000

¿Cuántas veces habéis instalado un nuevo equipo y tras instalar todos los drivers que vienen con él aparecen en el administrador de dispositivos los incómodos "Otros dispositivos" con el símbolo de advertencia? ¿Y cuántas de esas veces no podéis determinar de qué dispositivos se trata? Muchas veces determinar qué tipo de dispositivo es el que aparece bajo el epígrafe “Otros dispositivos” se vuelve una tarea casi imposible.

A continuación os dejo un pequeño procedimiento para identificar estos dispositivos.

Desde el administrador de dispositivos hay que seleccionar el que nos esté dando problemas y abrir sus propiedades. Para ello bastará con hacer doble clic sobre el mismo o con el botón secundario del ratón seleccionar propiedades del menú contextual. Una vez en las propiedades deberemos seleccionar la pestaña Detalles y en ella Id. De Hardware de la lista desplegable. Nos encontraremos con algo parecido a esto:

La cadena PCI\VEN_8086&DEV_29B4&SUBSYS_2818103C&REV_02, hace referencia al tipo de dispositivo y al fabricante del mismo. La parte VEN_8086 será el código del fabricante, en este caso VEN_8086 corresponde con Intel Corporation. La parte DEV_29B4 corresponde con el tipo de dispositivo, en este caso Intel Managament Engine Interface (HECI).
Estos datos se pueden consultar en Internet, por ejemplo, en http://www.pcidatabase.com y con ella se puede buscar el driver apropiado en la web del fabricante.

Gracias a Fran ha sido posible este artículo.

Habilitar el audio en Windows 2008

noreply@blogger.com (Unai Castro) — Mon, 23 Feb 2009 11:32:00 +0000

Recientemente me he tenido que pelear con mi nueva y flamante partición con Windows Server 2008 porque no funcionaba el audio. Aparecía el icono del altavoz con el aspa roja . Por supuesto lo primero que me vino a la cabeza fue un problema con los drivers; no serán compatibles, habré instalado los que no son, no estarán firmados… Es una versión Enterprise de 64 bits y como todos sabéis los drivers para Windows 2008 deben estar firmados para poder utilizarlos.

Tras cierto tiempo buscando nuevos drivers por Windows Update y por la web del fabricante del equipo he llegado a la conclusión de que tenía que haber otro problema y así es. Tal y como pasa con otras características del sistema operativo en Windows Server 2008 el audio viene deshabilitado por defecto. Aunque se instale el driver correcto, no funcionará. Es más si no se instala el driver después de haber habilitado el audio tampoco funcionará.

Para habilitar el servicio de Audio existen dos formas:

Abrir la MMC Services y configurar el servicio Windows Audio como automático e iniciar el servicio. Esto iniciará también el servicio Windows Audio Endpoint Builder.

Otra opción es hacer doble clic sobre el icono Sound del panel de control.
Aparecerá el siguiente mensaje indicando que está deshabilitado dándonos la opción de habilitarlo.

El efecto será el mismo que hacerlo desde la consola de administración Services.

Una vez arrancado el servicio de Audio se debe instalar el driver correspondiente. Reiniciar si es necesario, e vualá; el icono ya está bien.

Y después de hacer esto ¿Por qué no oigo mi música?

Por último veréis que ya funciona el audio, podemos cambiar el volumen y los sonidos de audio. ¿Pero qué pasa cuando vamos a escuchar los mp3 que tenemos en el equipo? Al final el objetivo de todo esto era poder ponernos los auriculares y escuchar lo último de …. Nos encontramos con que no hay Windows Media Player y que no se reconocen nuestros archivos de audio. Efectivamente los diseñadores de Windows Server 2008 pensaron que no era una buena idea escuchar los últimos éxitos del Pop internacional en los servidores y por defecto tampoco está instalado. Menos mal que se apiadaron de nosotros y comprendieron que existen muchos administradores que tienen este sistema operativo en sus equipos cliente para poder utilizar por ejemplo Hyper-V y nos dejaron la opción de instalarnos el Windows Media Player.
Para instalar esta aplicación, es necesario instalar la característica Windows Desktop Experience desde la consola de administración del servidor.

Junto con el Media Player se instalarán otras funcionalidades de Windows más propias de Windows Vista que de 2008, por ejemplo, Aero, Sideshow, Defender, Sound Recorder, Video for Windows,… Así que si es un servidor de producción os recomiendo encarecidamente que no habilitéis esta característica. Para la música en este caso es mejor un dispositivo mp4 con unos auriculares.

¡Empezamos!

noreply@blogger.com (Unai Castro) — Mon, 23 Feb 2009 11:22:00 +0000

Este es primer post de mi Blog. Pretendo que este sea un espacio donde publicar soluciones y recursos técnicos que puedan ayudar a otros. Mi especialidad como Consultor Tecnológico es la Seguridad, en concreto PKI e ILM, y sobre ello serán la mayoría de los artículos.

Como estamos empezando al principio habrá bastantes cambios de diseño hasta que encuentre uno que me convenza. También es cierto que al principio no habrá mucha gente que siga el blog, de todas formas a los pocos que lo leáis os pido disculpas por ello.

Pues manos a la obra, ya tengo el primer artículo, espero que os resulte útil.