Arreglando problemillas

Eliminar directivas que sobreescriben el registro.

Seguramente habréis oido hablar sobre las directivas que tatúan el registro, tienen el efecto que se observa al aplicar una directiva de registro a un equipo o usuario y luego la quitas. Aun cuando has quitado la directiva, los valores del registro se quedan permanentemente con los cambios (si no los quitas manualmente). Esto no es muy útil cuando administramos sistemas o usuarios que cambian de función. Así, cuando MS introduce las directivas de grupo en Win2k, quisieron cambiar este comportamiento, al menos para valores de registro.

En definitiva es un problema significativo con las politicas del sistema que soportaban las versiones anteriores a windows 2000. El tatuar significa que las políticas realizan cambios permanentes en el Registro. El administrador debe, explícitamente, eliminar las políticas, manual o con otra política contraria.

Este comportamiento va a peor cuando actualizamos Windows desde una versión anterior, el proceso de actualización no elimina la configuración de las políticas del sistema y aquéllas persisten. Así que una de las cosas que podemos hacer es eliminar las siguientes llaves/claves del registro de cada equipo y perfil de usuario antes de actualizar Windows:

  • HKLMSOFTWAREPolicies
  • HKLMSOFTWAREMicrosoftWindowsCurrentVersionPolicies
  • HKCUSoftwarePolicies
  • HKCUSoftwareMicrosoftWindowsCurrentVersionPolicies

El ‘como’ eliminarlas durante la actualización es la cuestión. No es un tema para imágenes de disco ya que el problema sólo aparece durante la actualización.

Si nos encontramos frente a los equipos durante la actualización podríamos eliminarlas manualmente… pero… va a ser que no. De otra forma, ejecutar el programa de instalación de Windows desde un archivo de lotes o un script. Así podemos colocar el comando que elimina las llaves antes del que inicia la instalación. Un ejemplo de INF que las elimine puede ser:

[Version]
Signature=$CHICAGO$

[DefaultInstall]
DelReg=Reg.Settings

[Reg.Setiings]
HKLM,SOFTWAREPolicies
HKLM,SOFTWAREMicrosoftWindowsCurrentVersionPolicies

Hay algunas incidencias con el uso de scripts, la primera que el usuario debe ser administrador para eliminar las ramas del Registro. Aunque podemos utilizar la técnica de elevación de procesos. Esto no está exento de errores y hay que hacerlo cuidadosamente o confiar en nuestra infraestructura de administración de software. La segunda es que sólo elimina las políticas por-equipo y no quita las de las secciones del perfil de usuario. No serás capaz de usar un script como éste desde un script de inicio de sesión o, permitir al usuario ejecutarlo ya que no disponen de los privilegios necesarios para eliminar ramas del Registro. Esto es verdad siempre que no hayamos incluido a todos los usuarios en el grupo Local de Aministradores, cosa que espero que no se haya hecho. Otra solución razonable es cargar cada sección del perfil de usuario en el Editor del Registro y entonces eliminar las dos ramas. Podemos, más o menos, automatizar este proceso mediante un script que conecte a un equipo remoto, cargue cada sección del perfil que hay en HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList, elimine las ramas y descargue la sección.

Elevación de privilegios de los procesos.

Los privilegios son una pequeña paradoja desagradable. En una mano, no queremos añadir a los usuarios al grupo local de administradores. Restringir a los usuarios es una práctica adecuada que impide errores humanos, distracciones sin sentido, virus oportunistas y algunas cosas más. En la otra mano, el despliegue de software a usuarios restringidos es complicado. No tienen los privilegios necesarios para la instalación de muchas aplicaciones. Ya estuvimos viendo algunas posibilidades a usar para alcanzar una estabilidad entre acceso sin límites y un escritorio totalmente bloqueado. Pero ahora veremos como ejecutar procesos elevados, con los que se pueden llevar a cabo muchas de las tareas descritas pero en los entornos más bloqueados.

 

Para elevar los privilegios, desde elegantemente hasta arriesgado o poco fiable. Las Directivas, específicamente InstallAlwaysElevated, es una de las formas para permitir a usuarios restringidos la instalación de aplicaciones basadas en windows installer. También podemos utilizar la característica de inicio de sesión secundaria o las tareas programadas. El ‘autologon’ que usa Microsoft Systems Management Server (SMS), y finalmente algún metodo más peligroso.

Directivas

La directiva InstallAlwaysElevated instala aplicaciones basadas en windows installer con privilegios elevados. Esta directiva permite que los usuarios instalen esas aplicaciones, pero no otros tipos de instalación si sus cuentas están restringidas.

Las consecuencias de aplicar esta directiva: Los usuarios podrían tener acceso total a sus equipos, es decir pueden cambiar sus privilegios y evitar tu administración de cuentas y equipos. No sólo eso, esta directiva abre la puerta a virus disfrazados de paquetes de windows installer. No es por tanto una configuración muy recomendable, aunque sería mejor que unir a los usuarios al grupo local de administradores.

Para que esta directiva sea efectiva, debemos habilitarla tanto por-equipo como por-usuario en el mismo instante. Podemos hacerlo cuando se va a desplegar alguna instalación de software y deshabilitarla en cuanto se haya cumplido, al menos limitamos la exposición al peligro.

Por supuesto, en caso de tener Directorio Activo y usar directivas de grupo ni pensar en utilizar esta directiva. La única razón que nos lleva a la posibilidad de utilizarla es en lugar de una infraestructura de gestión de software. En el caso de AD y GPO tenemos a nuestra disposición una solución elegante para pequeñas y medianas empresas, la Instalación y Mantenimiento de Software, ésta característica nos permite desplegar el soft a través de las GPO, ya que nos permite el despliegue del soft basado en windows installer a usuarios restringidos y escritorios bloqueados porque se hace con privilegios elevados. (INFO)

Inicio secundario

O conocido como Run As (Ejecutar como), permite a los usuarios ejecutar programas en el contexto de otras cuentas distintas de la suya. Por ejemplo: he iniciado la sesión como Pepe que pertenece al grupo de usuarios pero quiero ejecutar un programa como un administrador, clic derecho en el acceso directo al programa y ejecutar como. El programa se ejecutará bajo la cuenta que hayamos introducido. Aunque esta opción no es muy práctica para la instalación de soft ya que requeriría que los usuarios conociesen las credenciales de administrador. Pero sí nos sirve a nosotros cuando estamos frente al escritorio de un usuario y queremos hacer cualquier cosa con nuestras credenciales sin salir de su sesión.

También podemos utilizar esta característica desde la línea de comandos.

RUNAS [ [/noprofile | /profile] [/env] [/netonly] ] /user: Usuario Programa
RUNAS [ [/noprofile | /profile] [/env] [/netonly] ] /smartcard [/user: Usuario] Programa

/noprofile Especifica que RunAs no debe cargar el perfil de usuario, carga más rápido el programa pero suele dar errores.

/profile Especifica que RunAs debe cargar el perfil de usuario.

/env Usa el entorno actual en vez del entorno del usuario.

/netonly Especifica que las credenciales son únicamente para acceso remoto.

/savecred Usa las credencialesw previamente guardadas por el usuario.

/smartcard Especifica que las credenciales se proporcionan mediante una tarjeta.

/user Usuario : Especifica el nombre de la cuenta a usar. Tipo usuario@dominio o DOMINIOusuario.

Programa Lo que hay que ejecutar.

Tareas programadas

Una de las cosas interesantes de las tareas programadas es que podemos acceder remotamente a la carpeta de tareas programadas de cada equipo. También, que podemos incluir un nombre de cuenta y su contraseña en cada tarea. No necesitamos proporcionar a los usuarios de credenciales necesarias para ejecutar una tarea, como la instalación de soft. Por eso Tareas Programadas gana al Inicio Secundario. Se accede remotamente al equipo deseado, abrimos la carpeta de tareas programadas, clic derecho dentro de la carpeta, Nuevo, Tarea programada y renombramos la tarea, luego la configuramos según nuestros deseos:

imageimage

image

image

  • En Ejecutar, escribimos el comando que queremos que se ejecute, con la ruta relativa apuntando al equipo donde se ejecuta, \equipocarpetasetup.exe
  • En Ejecutar como, escribimos la cuenta con la que queremos que se ejecute la tarea, luego pulsamos en establecer la contraseña y rellenamos los campos, DOMINIOcuenta
  • En la pestaña de Programa, configuramos la programación de la tarea.
  • En la pestaña Configuración configuramos Windows para eliminar la tarea de la carpeta después de ejecutarse.

Hay que ser precavidos y pensar en aquellas tareas que puedan necesitar la intervención del usuario, para no programarlas, ya que no verán la tarea en ejecución a menos que miren en el administrador de tareas. Normalmente si necesitan de la intervención del usuario no se realizarán correctamente.

AutoLogon

Este metodo puede servirnos donde no hay una infraestructura de administración de software para su despliegue. Es como configurar un archivo de respuestas pero que se puede usar después. La configuración de autologon necesaria es:

Rama: HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinLogon

Configuración

Clave

Tipo

Valor

Habilitar autologon AutoAdminLogon REG_SZ 0 , 1
Usuario DefaultUserName REG_SZ nombre usuario
Dominio DefaultDomainName REG_SZ nombre dominio
Contraseña DefaultPassword REG_SZ contraseña
Cantidad de inicios AutoLogonCount REG_DWORD n veces

Rama:HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunOnce

Soft a ejecutar Name REG_SZ Comando

Voy a proceder a la instalación de una aplicación en un equipo donde los usuarios están restringidos y no pueden instalarla. Configuramos los valores descritos en las tablas, para cuando el usuario cierra sesión o cuando se reinicia el equipo, el sistema automáticamente iniciará sesión como administrador del equipo. El autologoncount se configura según las veces que sabemos que se reiniciará el equipo durante esa instalación. Por ejemplo:

Instalacion.inf

[Version]
Signature=$CHICAGO$

[DefaultInstall]
AddReg=Reg.Settings

[Reg.Settings]
HKLM,SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon,AutoAdminLogon,0,"1"
HKLM,SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon,DefaultUserName,0,"Administrador"
HKLM,SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon,DefaultDomainName,0,"DOMINIO"
HKLM,SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon,DefaultPassword,0,"contraseña"
HKLM,SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon,AutologonCount,0x10001,0x02
HKLM,SOFTWAREMicrosoftWindowsCurrentVersionRunOnce,Setup,0,"\servidorrecursosetup.exe"

Después hemos de ejecutar el comando Shutdown para reiniciar el sistema, con un archivo de lotes, el comando start y la opción /wait se procede a la instalación y luego shutdown –r para reiniciar el equipo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *