Mi compi Chema Alonso me envió por correo la noticia del proyecto Mojave, en donde se pone a prueba a un conjunto de personas el desconocimiento de Windows Vista y en donde nos damos cuenta de cómo el ser humano se deja llevar por las apariencias y comentarios que escucha, en vez de averiguar las cosas por uno mismo. En el proyecto se pregunta a los participantes si les gusta Windows Vista y porqué. Todos indican aspectos negativos del Sistema operativo y hasta le dan calificaciones de 0. Posteriormente se les muestra la supuesta nueva versión de Windows, llamada "Mojave" y se les enseña las novedades como busqueda indexada, control parental, Media Center, etc. y se les vuelve a preguntar si les ha gustado. Al darse cuenta que en realidad en un Windows Vista, algunos no saben donde meterse.

Os lo recomiento:

http://mojaveexperiment.com

Ahora yo me pregunto. Si esto sucede con Windows Vista, que sucedería si hacemos lo mismo con política, religión, ética, etc. Los seres humanos nos dejamos llevar por los rumores y las apariencias y muy pocos ponen empeño en investigar si lo que se dice es cierto o no.

Antes de comenzar la parte más práctica de este artículo, me gustaría explicar que se entiende por preferencia y las diferencias que existen con respecto a las directivas de seguridad.
Normalmente, las empresas y organizaciones requieren la aplicación de dos tipos de configuraciones, configuraciones administradas y configuraciones no administradas. Las configuraciones administradas son aquellas que se fuerzan en su aplicación y no se permite su modificación por parte de los usuarios, por ejemplo, bloquear el acceso al panel de control. Las configuraciones no administradas son preferencias que se configuran para mejorar la experiencia del usuario y que el sistema se ajuste mejor a su perfil, pero se permite que el usuario modifique la preferencia en cualquier momento. Por lo tanto no tienen un carácter de seguridad, sino de personalización del entorno.

Normalmente, esta personalización del entorno se ha venido realizando hasta ahora mediante la ejecución de scripts durante el inicio o cierre de sesión, o generando imágenes de sistema operativo con las preferencias ya preconfiguradas.

Cuando hablo de preferencias, me refiero por ejemplo a la creación de una carpeta de usuario, creación de entradas de registro específicas, accesos directos en el escritorio u otras ubicaciones, configuración de la impresora predeterminada, etc.

Pues bien, ahora Microsoft y Windows Server 2008 nos ponen las cosas un poco más sencillas a los profesionales de TI, gracias al nuevo conjunto de elementos configurables en las GPOs, llamado preferencias del sistema.

Antes de poder configurar nada vamos a necesitar varios  componentes:

• Un controlador de dominio basado en Windows Server 2008
• Consola de administración de políticas de grupo para Windows Server 2008 o Windows Vista SP1 (en este caso hay que descargarse RSAT)
• Group Policy Preference Client Side Extension (descargable desde aquí)

Solo se pueden administrar las preferencias desde la consola de administración de políticas de grupo que incluye Windows Server 2008 o el conjunto de herramientas de administración para Windows Vista SP1 (RSAT). Sin embargo, vamos a poder aplicar la configuración de preferencias a equipos con Windows XP SP2, Windows Vista, Windows Vista SP1 y Windows Server 2008.
Una de las ventajas que aporta la configuración de preferencias es que no es necesario disponer de aplicaciones que hayan sido diseñadas para “entender” las políticas de grupo, independientemente si  agregamos una entrada de registro o configuramos un archivo .ini.

Antes de que un equipo pueda recibir las configuraciones de preferencias debemos descargar e instalar Group Policy Preference Client Side Extension 

• GPPCSE para Windows XP SP2 - http://www.microsoft.com/downloads/details.aspx?FamilyId=E60B5C8F-D7DC-4B27-A261-247CE3F6C4F8&displaylang=en
• GPPCSE para Windows Vista - http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=AB60DC87-884C-46D5-82CD-F3C299DAC7CC&displaylang=es

Las configuraciones de preferencias se crean de forma muy similar a cualquier otra GPO. Desde la consola de administración de políticas de grupo creamos y vinculamos una nueva GPO en la OU en la que estén los equipos o usuarios que queramos configurar, por ejemplo, vamos a crear una GPO para configurar un acceso directo a una carpeta compartida.

En la consola de edición de la GPO que acabamos de crear, podemos observar que existe una carpeta llamada Preferencias, tanto a nivel de usuario como a nivel de equipo. Dentro de esta carpeta están todos los elementos configurables, agrupados en Configuración de Windows y Configuración del panel de control.

Este tipo de configuración nos va a permitir desde crear, modificar o eliminar carpetas, archivos .ini, o entradas de registro, hasta configurar los perfiles de energía, impresoras u opciones regionales.

Por fin tenemos un entorno totalmente configurable desde el Directorio Activo, sin necesidad de crear complicados scripts de inicio de sesión.
En este ejemplo, vamos a crear un acceso directo a nivel de usuario por lo tanto seleccionamos Shortcuts con el botón derecho y hacemos clic en New > Shortcut.
Se abre la siguiente pantalla, en donde configuraremos las opciones del acceso directo.

• Action: Create
• Name: Carpeta compartida (o cualquier otro nombre)
• Target type: File System Object
• Location: Desktop
• Target Path: \\nombre_servidor\NOMBRE_CARPETA

El parámetro Location es dónde queremos que aparezca el acceso directo, mientras que el Target Path es la ruta hacia la carpeta compartida. También podemos crear accesos a aplicaciones, por ejemplo, la calculadora. En ese caso podríamos lo siguiente:

• Action: Create
• Name: Calculadora
• Target type: File System Object
• Location: Desktop
• Target Path: C:\Windows\System32\calc.exe

Si le queremos pasar argumentos a la aplicación, los escribimos en el campo Arguments de la pantalla.

Una vez creada la configuración de preferencia, cerramos la pantalla de edición de la GPO y esperamos unos minutos a que el Controlador de Dominio se sincronice y a continuación ejecutamos gpupdate /force en el cliente Windows Vista para forzar la descarga de la nueva directiva. Observaremos que en el escritorio aparece el acceso directo que acabos de crear. Si no aparece automáticamente podemos presionar F5 para actualizar el escritorio y cerrar y volver a iniciar la sesión.

En el próximo post hablaré de las opciones de configuración avanzada que nos permiten las directivas de preferencias.

En muchas ocasiones nos encontramos con esta situación: Un usuario limitado que necesita ejecutar una aplicación en su equipo con privilegios administrativos, pero no queremos que conozca las credenciales de otro usuario administrador.

En Windows Vista, con UAC habilitado podemos hacer que por defecto el sistema ejecute una aplicación como administrador (Propiedades del acceso directo > Avanzado > Ejecutar como administrador), o si no, simplemente con el botón derecho seleccionamos el menu Ejecutar como Administrador...

En ambos casos, el sistema solicitará la contraseña del administrador. Pero si no queremos indicarle al usuario cuales son estas credenciales, entonces que opciones tenemos.

La primera opción es otorgarle permisos administrativos directamente al usuario, sin embargo ésto no es recomendable ya que estaríamos dándole más privilegios de los que realmente necesita y podíra ejecutar acciones que no queremos, por ejemplo, instalar programas o modificar la configuración del equipo. Otra opción es modificar manualmente los permisos necesarios tanto a nivel de archivos como de registro para que la aplicación se pueda ejecutar correctamente. Esto puede ser viable siempre y cuando el producto se mantenga mas o menos estable, es decir, que con una actualización no se altere la estructura de permisos necesarios. Además tendríamos que averiguar qué carpetas, archivos y claves de registro requiere acceso la aplicación, por lo tanto el trabajo necesario puede llegar a ser bastante laborioso. Las herramientas Filemon, Regmon y ProcessExplorer de Microsoft Sysinternals, nos pueden ayudar en estas tareas.

Pero nos queda una última opción gracias a la combinación del programa runas.exe y el uso de accesos directos.

Por ejemplo, si queremos hacer que un usuario limitado ejecute Internet Explorer como un administrador, pero sin tener que introducir las credenciales cada vez que inicia el programa, haríamos lo siguiente:

1. Crear un nuevo acceso directo a Internet Explorer en el escritorio (u otra ubicación)
2. En la linea de ejecución del asistente escribimos: runas.exe /user:Administrator /savecred "C:\Program Files\Internet Explorer\iexplore.exe"
3. Escribimos el nombre del acceso directo, por ejemplo "Internet Explorer Admin" y lo guardamos.

Cuando ejecutemos el acceso directo por primera vez, el sistema nos solicitará las credenciales del usuario Administrador, pero gracias al parámetro /savecred, la contraseña se almacena localmente y no se volverá a solicitar, permitiendo así que un usuario limitado ejecute una aplicación como un administrador, sin tener que conocer previamente las credenciales administrativas.

Si, vamos un poco más alla, podemos hacer que un usuario limitado pueda cambiar las propiedades del Firewall de Windows Vista, o abrir una consola administrativa. El procedimiento es similar al anterior y la única diferencia es la línea de ejecución que tendrá el acceso directo:

• runas.exe /user:Administrator /savecred "mmc.exe C:\AdminCon.msc" (Si la consola administrativa AdminCon.msc está ubicada en el disco C:)
• runas.exe /user:Administrator /savecred "control.exe /name Microsoft.WindowsFirewall"

Si el usuario administrativo no es local, sino un usuario de dominio, entonces cambiamos /user:Administrator por /user:DOMINIO\USUARIO_ADMINISTRADOR

A continuación os dejo la lista de subelementos del panel de control que podemos ejecutar directamente desde la línea de comandos o desde un acceso directo:

A pesar de esto, hay que tener en cuenta que este procedimiento no impide que un usuario limitado modifique el acceso directo y ejecute otros componentes o aplicaciones que no queremos que ejecute, por lo tanto, es recomendable utilizar esta alternativa sólo si se puede garantizar que el usuario no tenga acceso a otros componentes o a ejecutar otras aplicaciones, por ejemplo, limitando su acceso mediante políticas de grupo o modificando las ACE en el acceso directo.