Permitir ejecuciones remotas con cualquier usuario al intentar acceder al recurso compartido C$ (LocalAccountTokenFilterPolicy)

En Windows existen ciertos recursos compartidos establecidos por defecto con intenciones administrativas. Entre ellos está el conocido C$ (C dolar, el símbolo "$" indica que se trata de un recurso que el sistema mantiene "oculto"), que seguramente muchos usaríamos para poder conectarnos al equipo remoto de una red de forma subyacente al usuario de ese equipo, básicamente tener acceso a su disco del sistema C: (letra de unidad asignada por defecto en sistemas Windows).

Podemos ver en la consola de Microsoft (fsmgmt.msc) de "Carpetas comparitdas", los recursos que por defecto son compartidos, donde veremos el conocido c$ (C dolar) entre otros.

Figura 1: Consola Miscroft fsmgmt.msc "Carpetas compartidas".

Para que esta conexión sea posible, a parte de tener las debidas configuraciones de red bien configuradas como veremos más adelante. Hablando en este caso de una "red privada o doméstica" es necesario una de las dos siguientes posibilidades:

Conocer el usuario y contraseña con privilegios administrativos de la máquina remota.
Crear un usuario y contraseña igual que el usuario con el que intentamos conectarnos al equipo remoto.

En este caso nos quedaremos con la opción más cómoda que sería la de añadir el usuario al equipo remoto.

En el caso de formar parte de una red de dominio, esto se debería administrar con grupos en el propio controlador de dominio (DC). En este caso podríamos crear un grupo en el que incluiríamos a los usuarios administrativos y ese grupo incluirlo en grupo de administradores de forma manual o por algún script mediante GPOs en los equipos de la red de Dominio.

Escenario de ejemplo:

Equipo: PLUTON | Usuario activo: maria
Equipo: JUPITER | Usuario activo: juan

En el siguiente ejemplo, de una red privada, el usuario activo en el equipo local es "juan" (equipo: Jupiter), pero el usuario remoto con el que queremos acceder desde el cliente es "maria" (del equipo: Pluton, pero que se creará también el equipo Jupiter). Por lo que en el equipo remoto crearíamos una cuenta de usuario con la misma contraseña que la del equipo donde queremos acceder y lo agregamos al grupo de Administradores, de modo que haya una coherencia entre este usuario en ambas máquinas.

Figura 2: Usuarios administradores del equipo remoto.

Hasta este punto todo correcto. Pero cuando intentamos acceder con el usuario y contraseña del mismo que el del equipo remoto aunque exista dicha coherencia de credenciales igualmente, por seguridad, nos solicita usuario y contraseña a través del UAC. Por lo que queremos es evitar o eludir el UAC en este caso.

Escribiendo en una ventana de ejecución el nombre o dirección IP del equipo remoto seguido del recurso compartido C$: \\equipo_remoto\c$.

Figura 3: Ejecutando el recurso compartido C$ hacía un equipo remoto de la misma red.

En sistemas Windows XP dentro de una red era común si teníamos los suficientes privilegios en un usuario frente a un equipo remoto el poder acceder a su disco C: (letra de unidad asignada por defecto a un sistema Windows) ya que este por defecto se compartía.

Esto a partir de Windows Vista en adelante con la incorporación del sistema UAC (User Account Control) nos solicita, por seguridad, que nos autentiquemos con un el usuario privilegiado de la máquina remota y por lo tanto confirmemos las credenciales del usuario con el que intentamos acceder a la máquina remota. En siguiente caso el usuario maria del equipo Pluton quiere conectarse al equipo Jupiter.

Figura 4: Autenticación de login con UAC para el acceso al recurso compartido C$.

Para poder eludir el UAC, solamente en este caso, podremos hacerlo fácilmente añadiendo un valor con un dato específico en una clave concreta del registro de Windows. Pero antes comentaré algunas configuraciones previas a tener en cuenta para todos los equipos de red o en los que queramos tener este tipo de acceso.

Antes de establecer la clave de registro oportuna, revisamos la configuración de la red privada para comprobar si está todo bien establecido, por defecto cuando nos unimos a un grupo de trabajo de una red privada o de hogar esto se autoconfigura correctamente.

En el caso de usar una red privada, formar parte de un grupo de trabajo o grupo del hogar, nos centraremos en la configuración de uso compartido avanzado de este. En el apartado privado (que sería el que correspondería en este caso) comprobaremos que esté activado la "detección de redes, compartir archivos e impresoras, y que Windows administre las conexiones del grupo del hogar".

Por defecto, cuando configuramos un equipo para que este se una a un grupo del hogar esta configuración debería estar ya preestablecida del siguiente modo.

Figura 5: Configuración del uso compartido de redes (entorno privado).

En un segundo bloque vemos la configuración de "Todas las redes" las cuales son otro tipo de características en la que digamos que el uso compartido no afecta para "perfiles públicos o invitados".

Deberemos tener activa las tres opciones disponibles, o simplemente las dos últimas opciones "Usar un cifrado de 128 bits y activar el uso compartido por contraseña", el cual en este caso no tendrá relevancia si lo tenemos activado o desactivado, ya que no se trataría de recursos compartidos de forma intencionada sino de los recursos compartidos por defecto del sistema, esta característica no está disponible en equipos que se encuentren en un dominio.

En la primera opción "Activar el uso compartido para todos los usuarios a carpetas públicas" se refiere aquellas carpetas del perfil de usuario que por defecto Windows comparte, pero que no tienen una gran importancia si no guardamos nada en ellas.

Figura 6: Configuración del uso compartido de redes (todas las redes).

Al activar las características anteriores, sobre todo la que respeta al uso compartido de archivos e impresoras, esta por defecto añade unas determinas reglas de entrada en el WFAS (Windows Firewall Advanced Security) referentes al protocolo SMB (Service Mensage Block), las cuales se deberían aplicar en este caso solo al perfil privado.

Figura 7: Reglas de entrada del Firewall avanzado para SMB "Compartir archivos e impresoras".

Por último comprobaremos un par de servicios. El servicio "Examinador de equipos" (Browser) realiza repetidas comprobaciones de actualización para conocer a los equipos vecinos de una misma red, de modo que así nuestro equipo estará actualizando la lista de equipos latentes dentro de la red.

Figura 8: Servicio "Examinador de equipos de red" (Browser).

El servicio "Servidor" (LanmanServer) nos proporcionará compatibilidad para todos aquellos equipos que quieran acceder a este, ofreciendo así el servicio necesario para acceder a sus recursos compartidos.

Figura 9: Servicio "Servidor" (LanmanServer)

Finalmente y el motivo por lo que escribo este artículo, sería añadir el valor necesario el registro de Windows para poder bypassear la autenticación UAC. La autenticación se hace pero se hace forma subyacente, esto simplemente nos evita autenticarnos con usuario y contraseña de forma manual.

En el registro de Windows del equipo remoto que queremos conectarnos (Jupiter), buscamos la clave:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Añadimos un nuevo valor REG_DWORD de 32 bits (aunque el sistema sea de x64 el valor tendría que ser igualmente de 32 bits). El nombre de este valor será: LocalAccountTokenFilterPolicy y la información de dato la establecemos a "1".

Figura 10: "LocalAccountTokenFilterPolicy" para evitar la autenticación manual en acceso a C$.

Ahora simplemente cerramos el registro y probamos, si aún así no se actualizasen los cambios, cerraríamos sesión o si fuese necesario (que en las pruebas que he realizado no ha sido necesario) reiniciaríamos el equipo.

Veremos que ahora al intentar acceder al recurso compartido C$ del equipo remoto al que hemos añadido este valor no nos pedirá de forma visible la autenticación de un usuario con privilegios para acceder a el y a ese recurso.

Se puede ver en una fsmgmt.msc la existencia de una sesión remota activa del usuario maria procediente del equipo remoto Pluton, la cual solo usó el usuario usuario local creado en el grupo administradores del equipo Jupiter (equipo al que remoto al que se conectó maria) para autenticarse, aunque como se ve en la captura de pantalla la sesión es con referencia al equipo remoto que accedió. (usuario maria del equipo Pluton accedió al equipo > Jupiter) . Visualizando las sesiones activas en la consola fsmgmt.msc.