26 agosto, 2015

Eliminar la caché de datos de equipos almacenada en conexiones RDP

Si hemos realizado conexiones por Terminal Services (escritorio remoto) veremos que estas guardan o quedan cacheadas en el panel de conexión por escritorio remoto.
La caché es guarda temporalmente los datos recientemente procesados de modo que la siguiente vez que nos queramos conectar a otro equipo lo tengamos más cómodo a la hora de introdurcir los datos necesarios.


Figura 1: Nombres de equipo en los que se tuvo alguna vez conexión RDP.

Si la conexión al equipo remoto se llega a establecer, el dato de nombre de equipo, dirección IP o DDNS que hubiésemos usado, quedará guardado para esa sesión de usuario en concreto.

Si queremos eliminar esta caché de datos, la podremos encontrar registrada en la siguiente ruta de registro:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
En formato de claves de registro están generados todos los nombres de equipo, IP o DDNS a los que nos hubiésemos conectado.
Simplemente tendríamos que eliminar todas las claves o la que queramos borrar el registro de conexión almacenada. Estas a parte del nombre del equipo de conexión también almacenan el nombreDeEquipo\UsuarioDeConexión en un valor de cadena llamado "UsernameHint".

Figura 2: Path del registro donde se almacen los datos de conexiones RDP.

También tendríamos que eliminar el valor de cadena correspondiente en la path de registro:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default
Situado en la misma ruta pero en una clave más arriba, veremos la clave "Default".
Esta clave nos indica el orden de prioridad en el que se nos mostrorá la lista de conexiones al desplegar la barra de la ventana de "Conexión a Escritorio remoto".

Figura 3: Valores de cadena de orden de prioridad para conexiones Terminal Services.

Este orden son expresados por valores de cadena (REG_SZ) los cuales llevan nombres del tipo: MRU0, MRU1, MRU2, MRU3, etc. acompañados con el valor de datos del nombre de equipo, IP o DDNS a conectarse.
Si lo que queremos no es borrar el valor MRUX y lo que queremos es variar orden, bastará con renombrar los nombres MRUX, donde "X" incica el número de orden de prioridad de mayor a menor.

Saludos!

24 agosto, 2015

Iniciar una aplicación antes de la carga de perfiles de usuario

Si queremos iniciar una determinada aplicación en background antes de la carga de cualquier perfil de usuario, de modo que ya esté disponible cuando encendamos el equipo y nos apararezca la pantalla de bienvenida de Windows sin necesidad de iniciar sesión en la máquina local.

Simplemente tendremos que agregar en indicar la ruta del fichero bianario .exe que lanza aplicación en la siguiente path del registro.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Una vez estemos en la clave Winlogon, a continuación buscamos el valor de cadena "Userinit" el cual tendremos que añadir el valor de ruta del fichero a ejecutar, por ejemplo: "C:\Program Files (x86)\CARPETA_APLICACIÓN\FICHERO.EXE".
Si queremos agregar más aplicaciones tendremos que separar las rutas por comas (,).

Figura 1: Winlogon, añadiendo aplicación en userinit.

El valor de cadena Userinit nos permite añadir aplicaciones u otros ficheros antes de la carga de perfiles de usuario de Windows.

Info. oficial de Microsoft: https://technet.microsoft.com/en-us/library/cc939862.aspx

Saludos!

14 agosto, 2015

¿Cómo se procesan las GPO’s?

Competencia entre contenedores.

Una GPO, como ya hemos visto anteriormente, puede ser contenida por equipos locales, sitios, dominios y unidades organizativas (en adelante OU). Como un usuario, por ejemplo, estará en un equipo local que a su vez se ubicará en un sitio, pertenecerá a un dominio y será miembro de una OU se ve claramente que se puede dar el caso de que en el equipo local se aplique una GPO, en el sitio otra, otra para el dominio y otra para la OU (e incluso para la OU hija, de tercer nivel, etc.). Se podría dar el caso, por tanto, de que las GPO’s contuvieran políticas que se contradijeran entre sí. Cuando se dan casos de estos, el sistema de GPO’s está implementado para asegurar que siempre se aplicarán las políticas, y para ello establece una forma de prioridad entre éstas por la cual, según dónde estén asignadas, unas prevalecen sobre otras atendiendo a una serie de reglas que a continuación, con la ayuda de dos figuras, describiremos.



En la figura 1 vemos, de forma resumida, cuál es la prioridad de las GPO’s. Las GPO’s de una OU prevalecen sobre las del dominio, que a su vez prevalecen sobre las de sitio, las cuales a su vez prevalecen sobre las del equipo local. Por prevalecer no se entiende que unas anulen a otras; las políticas se suman, sólo se anulan en caso de ser contradictorias entre ellas. Por ejemplo, si a nivel de dominio habilitamos la política de deshabilitación del panel de control y en la OU deshabilitamos esta política, y suponemos que ninguna otra de las políticas a nivel de dominio entra en contradicción con ninguna otra de las de la OU, el resultado que se aplicará a un objeto contenido dentro de la OU será la suma de ambas GPO’s, salvo que la política que se aplica respecto a la deshabilitación del panel de control será la de la OU, no la del dominio, y por tanto el panel de control será visible.

En la figura 2 vemos un diagrama de flujo que nos explica cómo son aplicadas las GPO’s; se puede apreciar el orden en que son leídas y como se actúa en caso de que se contradigan o no. Como se puede suponer, si hubiera una OU de tercer nivel, ésta prevalecería sobre la hija y obviamente una de cuarto nivel sobre la de tercer nivel y así sucesivamente:



Más info en: http://freyes.svetlian.com/GPOS/GPOS.htm
Entradas Relacionadas