none
Forest Trust e inicios de sesión RDS en redes separadas por firewall RRS feed

  • Pregunta

  • Buenos días.

    Hemos creado una relación de confianza entre dos bosques separados por internet, sin VPN. Se han creado las correspondientes reglas del firewall según este artículo, solamente entre los controladores de dominio de ambos bosques (Ambos bosques con un solo dominio):

    https://support.microsoft.com/en-us/kb/179442

    La relación de confianza es de una sola dirección, y con autenticación selectiva. La relación de confianza se establece correctamente, y desde el dominio en que se confía se puede acceder a los recursos compartidos del dominio que confía.

    Sin embargo, a la hora de iniciar sesión por escritorio remoto en los equipos del dominio que confía, no autentica correctamente y dice que no se puede encontrar el dominio especificado. Si abrimos en el firewall los puertos del artículo anterior para todos los equipos de ambos dominios, sí que podemos iniciar sesión por RDS.

    Tenía entendido que no era necesaria lo conectividad del artículo anterior en todos los equipos, sino solo en los controladores de dominio, y estos hacen de cabeza de puente, tal y como está haciendo correctamente la compartición de recursos de red.

    ¿Existe la posibilidad de no tener que tener los puertos abiertos desde todos los equipos del dominio para inicios de RDS?

    Gracias de antemano.

    saludos.




    • Editado jokland_cat miércoles, 9 de noviembre de 2016 9:24
    • Editado Moderador M miércoles, 9 de noviembre de 2016 16:15 typo
    miércoles, 9 de noviembre de 2016 9:23

Respuestas

  • Los usuarios que se conecten por escritorio remoto deben estar incluídos en el grupo local "Remote Desktop User"

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    • Propuesto como respuesta Moderador M lunes, 14 de noviembre de 2016 18:16
    • Marcado como respuesta Moderador M viernes, 18 de noviembre de 2016 15:52
    viernes, 11 de noviembre de 2016 19:12
    Moderador

Todas las respuestas

  • [Guilermo] Respondo entre líneas

    Buenos días.<o:p></o:p>

    Hemos creado una relación de confianza entre dos bosques separados por internet, sin VPN. Se han creado las correspondientes reglas del firewall según este artículo, solamente entre los controladores de dominio de ambos bosques (Ambos bosques con un solo dominio):<o:p></o:p>

    https://support.microsoft.com/en-us/kb/179442<o:p></o:p>
    [Guillermo] Haber configurado reglas de cortafuego en una conexión externa como indica ese artículo, es absolutamente peligroso, se podría entre redes internas, pero de ninguna manera en conexione a Internet. Sólo mira la cantidad de puertos abiertos, y como si fuera poco entre Controladores de Dominio, que son las máquinas que más deberías proteger en tu red
    Otra cosa importante, hay un error cuando dices "ambos Bosques con un solo Dominio". Si hay un único Dominio entonces no hay dos Bosques, y si hay dos Bosques no puede haber un único Dominio. Y si la relación de confianza se hizo entre Bosques, entonces todos los Dominios de un Bosque, confían en todos los Dominios del otro

    La relación de confianza es de una sola dirección, y con autenticación selectiva. La relación de confianza se establece correctamente, y desde el dominio en que se confía se puede acceder a los recursos compartidos del dominio que confía.<o:p></o:p>

    Sin embargo, a la hora de iniciar sesión por escritorio remoto en los equipos del dominio que confía, no autentica correctamente y dice que no se puede encontrar el dominio especificado. Si abrimos en el firewall los puertos del artículo anterior para todos los equipos de ambos dominios, sí que podemos iniciar sesión por RDS.<o:p></o:p>
    [Guillermo] Si no han cambiado los valores por omisión, y están usando directamente RDP entonces los que hay que abrir es TCP-3389 entre cliente y servidor Escritorio Remoto, pero esto también es peligroso

    Tenía entendido que no era necesaria lo conectividad del artículo anterior en todos los equipos, sino solo en los controladores de dominio, y estos hacen de cabeza de puente, tal y como está haciendo correctamente la compartición de recursos de red.<o:p></o:p>
    [Guillermo] ¿Están compartiendo recursos a través de Internet??? Eso sí que es peligrosísimo

    ¿Existe la posibilidad de no tener que tener los puertos abiertos desde todos los equipos del dominio para inicios de RDS? <o:p></o:p>
    [Guillermo] Lee más abajo

    Gracias de antemano.<o:p></o:p>

    saludos.<o:p></o:p>



    De ninguna forma se debe hacer la configuración, que por lo que dices tienes, es equivalente a exponer toda tu red a Internet sin ninguna protección

    Para lo que quieres, lo que se suele hacer es crear entre Routers, o servidores dedicados un conezión VPN entre los sitios, y luego todo el tráfico entre ellos se hace a través de la VPN

    Te dejo dos enlaces que pueden ayudarte

    Windows Server 2012: Conectando Sitios por VPN (Site to Site VPN) | WindowServer:
    https://windowserver.wordpress.com/2013/02/02/windows-server-2012-conectando-sitios-por-vpn-site-to-site-vpn/ 

    Windows Server 2012 R2 – Conectando Sitios por VPN (Site To Site VPN) con L2TP-IPSec [Parte 1 de 5] | WindowServer:
    https://windowserver.wordpress.com/2015/04/07/windows-server-2012-r2-conectando-sitios-por-vpn-site-to-site-vpn-con-l2tp-ipsec-parte-1-de-5/ 

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 9 de noviembre de 2016 10:20
    Moderador
  • Buenos días Guillermo. Gracias por tus comentarios. Hago unas aclaraciones al respecto: En realidad, los dos bosques están conectados mediante una VPN Ipsec. No están los puertos abiertos al Internet entero, ni los de autenticación del artículo que adjunto, ni los de Terminal server. Aun estando conectadas por VPN, lo que no quiero es que desde el dominio que confía en el otro, se puedan acceder a recursos del dominio al que se confía, y por esto lo tengo los puertos filtrados en el mismo canal VPN.<o:p></o:p>

     

    Respecto al tema de los bosques. En cada uno de los 2 bosques que hay relacionados, hay un dominio en cada uno. Por tanto, 2 dominios en total.<o:p></o:p>

     

    saludos.<o:p></o:p>


    miércoles, 9 de noviembre de 2016 10:43
  • Buenos días Guillermo. Gracias por tus comentarios. Hago unas aclaraciones al respecto: En realidad, los dos bosques están conectados mediante una VPN Ipsec. No están los puertos abiertos al Internet entero, ni los de autenticación del artículo que adjunto, ni los de Terminal server. Aun estando conectadas por VPN, lo que no quiero es que desde el dominio que confía en el otro, se puedan acceder a recursos del dominio al que se confía, y por esto lo tengo los puertos filtrados en el mismo canal VPN.<o:p></o:p>

     

    Respecto al tema de los bosques. En cada uno de los 2 bosques que hay relacionados, hay un dominio en cada uno. Por tanto, 2 dominios en total.<o:p></o:p>

     

    saludos.<o:p></o:p>


    Ahora sí :)

    Si hay autenticación selectiva, entonces en la cuenta de máquina del servidor, normalmente hay que asignarle permiso "allow to authtenticate", y asegurarse que los usuarios tengan permiso

    En el cortafuegos debes permitir la conexión por RDP (TCP-3389) a los servidores de Escritorio Remoto y clientes, o si usaran WebAccess entonces también HTTPS

    Si en el cliente dice que no puede encontrar el Dominio, entonces además hay que revisar la resolución de nombres por DNS. Puedes haberlo configurado de tres formas diferentes: Zonas Secundarias, Reenviadores Condicionales o "Stub Zones". De ambos Dominios se tienen que poder resolver todos los nombres del otro

    Para limitar el acceso a recursos, normalmente no se usa cortafuegos, simplemente es algo que se maneja a nivel permisos. No tiene sentido por cortafuegos porque te falta mucha flexibilidad y es muy complicado por los diferenets protocolos que se puedan usar

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 9 de noviembre de 2016 12:16
    Moderador
  •  

    Hola Guillermo. Gracias por tus comentarios.

    Lo que enumeras, ya está hecho y comprobado. 

    La cuestión es que cuando permito acceso total en el firewall y funciona correctamente el inicio de sesión de Terminal server, al capturar tráfico con el wireshark veo que las peticiones de autenticación que hace el servidor de RDS las hace contra los servidores del otro dominio directamente a su IP, en vez de delegar la autenticación al servidor de su dominio, tal y como si lo hace cuando autentica accesos a recursos compartidos de red.

    Al final creo que lo dejaré así, aunque me hubiera gustado dejarlo más cerrado, ya que este bosque al que queremos conectar puede llegar a ser algo "hostil" en algunas circunstancias.

    Saludos.


    miércoles, 9 de noviembre de 2016 14:28
  • Una cliente o máquina sólo puede pedir ticket de Kerberos a Controladors de Dominio de su propio Dominio

    Cuando el cliente de DomA se conecta a un servidor de DomB, sucede lo siguiente

    Cliente en DomA pide ticket a su propio DC para acceder a servidor en DomB

    Su propio DC no puede darle un ticket para un recurso que no es parte de su Dominio, entonces le devuelve un ticket que le permite contactar a un DC de DomB

    El cliente del DomA, contacta al DC de DomB, enseñándole el ticket que ya tiene, pero ahora le pide uno para el servidor en el DomB

    Este último DC del DomB debe darle el ticket correspondiente

    Es así como funciona Kerberos con relaciones de confianza

    Pero, por lo errores que comentas, o no está bien la resolución de nombres, o falta permitir puertos, o permisos

    Prueba, sacando la opción de autenticación en el servidor de Escritorio Remoto sobre el tema de Network Level Autentication

    Por otro lado, y por las dudas ¿está hecha correctamente la dirección de la relación? o sea, que el Dominio de recursos, confíe en el Dominio de Usuarios

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    • Propuesto como respuesta Moderador M miércoles, 9 de noviembre de 2016 16:17
    • Votado como útil Moderador M lunes, 14 de noviembre de 2016 18:16
    • Propuesto como respuesta Moderador M jueves, 17 de noviembre de 2016 16:21
    • Votado como útil Moderador M viernes, 18 de noviembre de 2016 15:53
    miércoles, 9 de noviembre de 2016 14:58
    Moderador
  • Buenas tardes Guillermo. La dirección de la confianza es correcta, y ya probé desactivar el network level authentication. Mismos resultados.

     

    Creo que  el problema no está en la autenticación, sino en la manera en que RDS comprueba si el usuario que se está intentando conectar tiene permisos para hacerlo o no.

     

    He probado varias combinaciones: Crear un Grupo de dominio local en el dominio donde están los servidores de TS y añadir en este grupo de dominio local los usuarios del otro dominio, añadir los usuarios del dominio en que se confía directamente en los permisos de acceso de los servidores de TS, e incluso, en modo prueba, añadir alguno de los usuarios del dominio en el que se confía en el grupo Administradores del dominio donde están los servidores de TS.

     

    Crees que puede venir por aquí el tema?

     

    Gracias por tu apoyo.

     

    Saludos.


    viernes, 11 de noviembre de 2016 18:11
  • Los usuarios que se conecten por escritorio remoto deben estar incluídos en el grupo local "Remote Desktop User"

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    • Propuesto como respuesta Moderador M lunes, 14 de noviembre de 2016 18:16
    • Marcado como respuesta Moderador M viernes, 18 de noviembre de 2016 15:52
    viernes, 11 de noviembre de 2016 19:12
    Moderador