Publicada la RC1 de FIM 2010

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

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

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

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

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

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

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.