Remote Desktop – Escritorio Remoto: Instalación Básica en Grupo de Trabajo (“Workgroup”)

Muchas veces he visto la consulta sobre la utilización de Remote Dekstop – Escritorio Remoto en ambiente de Grupo de Trabajo. No es que no se pueda, sino que el procedimiento de instalación es diferente, y la funcionalidad reducida con respectoa a la implementación en ambiente de Dominio Active Directory

No se pueden utilizar los procedimientos “normales” de instalación y configuración denominados “Quick Start” y “Standard Deployment” que he documentado en notas anteriores, hay que hacerlo de forma diferente

Además veremos cómo podemos solucionar el mensaje de advertencia sobre el certificado no confiable del servidor que da por omisión

La infrastructura que utilizaré para esta nota son solamente dos máquinas virtuales, ambas en Grupo de Trabajo (“Workgroup”)

• RD-Srv1: Windows Server 2012 R2
• “Nombre Aleatorio”: Windows 10 Professional

Comenzaré agregando la funcionalidad en RD-Srv1, de la forma habitual, pero sin las opciones sugeridas para el caso, como muestran las siguentes capturas de pantalla

Observen que no selecciono la opción sugerida de “Remote Desktop Services Installation”

Seleccionamos en esta pantalla la funcionalidad requerida

Seleccionaré dos componentes “Remote Destop Licensing” y “Remote Desktop Session Host” agregando las funcionalidades requeridas como muestran las siguientes pantallas

Y como solicita, reiniciamos la máquina

Noten que como es habitual en los servidores de Escritorio Remoto, no muestra el nombre del último usuario que inició sesión, hay que escribirlo

Podemos observar que no podemos administrarlo de la forma en que lo haríamos en un ambiente de Dominio Active Directory

Como estamos en ambiente de Grupo de Trabajo, el modo más común de permitir el acceso desde un equipo a otro es “espejando” una cuenta de usuario, que sea el mismo nombre y contraseña tanto en el origen como en el destino

Por lo tanto crearé un usuario local en RD-Srv para demostración

Es importante que el usario no tenga que cambiar la contraseña en el primer inicio, pues no lo permitirá

Y para que pueda ingresar por Escritorio Remoto debemos incluir la cuenta en el grupo “Remote Desktop Users”

En la máquina cliente con Windows 10, con una sesión de administrador local, creo un nuevo usuario “espejado”, mismo nombre y contraseña. Esto no es un requerimiento para la implementación que estamos haciendo, lo hago sólo porque es lo habitual en ambiente de Grupo de Trabajo para permitir el acceso a recursos compartidos sin pedir usuario y contraseña

Siempre en el cliente, cierro la sesión del administrador, e inicio sesión con el usuario de prueba

Con el cual iniciamos el comando para Escritorio Remoto

Indicamos el servidor al cual se conectará

Aunque el usuario ha sido “espejado” debemos ingresar las credenciales de conexión. Esto puede ser útil, ya que estando trabajando localmente con una cuenta se puede iniciar un Escritorio Remoto con otra cuenta  de diferente usuario

Como en las conexiones de Escritorio Remoto se hace una autenticación del servidor al cual nos conectamos, acá aparece la advertencia, ya que no puede verificar la autenticidad del certificado de servidor exhibido

Lo anterior se produce porque es un certificado auto-firmado. Es decir la autenticidad de RD-Srv, la garantiza el propio RD-Srv, como si fuera un certificado de una Autoridad Certificadora de tipo Raíz. Pensé que se podía solucionar fácilmente simplemente instalando el certificado, pero veremos que no es así

Para instalar certificado por máquina hay que ser administrador local, así que lo dejé por usuario

¿Automático es lo mejor, no es cierto? ;)

Intento iniciar sesión nuevamente con el usuario ya teniendo el certificado del servidor instalado, pero sigue mostrando la advertencia

De todas formas y para probar el funcionamiento, si aceptamos la advertencia vemos que podemos iniciar la sesión de Escritorio Remoto sin problemas

Pero nos queda solucionar el problema de quitar la advertencia de seguridad. Investiguemos un poco el tema a ver si encontramos la solución

Si recordamos o si queremos observar nuevamente el certificado que muestra la advertencia, vemos que el problema se trata porque no está instalado en “Trusted Root Certification Authorities”

Creemos una consola (MMC.EXE) y miremos un poco el tema

Evidentemente, no está donde debería estar

Pese a que es un certificado auto-firmado, lo ha dejado en el lugar de las autoridades certificadoras intermedias

Para llevar el certificado del servidor al contenedor “Trusted Root Certification Authorities”, debemos hacer pasos intermedios

Aunque no he capturado las pantallas, si lo hacemos desde el propio usuario, sigue tomándolo como no confiable. Así que lo que haré será exportarlo, y luego inciando sesión con una cuenta de administrador local colocarlo en el contenedor necesario: “Trusted Root Certification Authorities” pero de la parte de máquina

Entonces comenzamos exportándolo

Cerramos la sesión del usuario, e iniciamos con una cuenta de administrador local, y creamos una consola para administrar los certificados

A diferencia del caso del usuario, con una cuenta de administrador local podemos seleccionar el contenedor de máquina

Y procederé a importar el certificado, que había exportado como usuario, pero ahora en “Trusted Root Certification Authorities” de la parte de máquina

No he capturado las pantallas porque son casi repetidas, pero si ahora inician sesión con el usuario de prueba, y comienzan una sesión de Escritorio Remoto verán que ya no sale la advertencia

 

Ha quedado pendiente la configuración del licenciamiento necesario de Escritorio Remoto, la idea era hacerla en forma conjunta con esta, pero ya está demasiado larga, así que la veremos en la próxima :)

 

Anuncio publicitario