WindowServer

DirectAccess es una implementación muy útil aunque habitualmente difícil de implementar, tanto por los requerimientos de infraestructura como por los conocimientos necesarios para su implementación

Sin entrar en detalles, DirectAccess permite que los clientes remotos estén conectados automáticamente a la red empresarial automáticamente en cuanto disponen de Internet; sin necesidad de crear y conectar VPNs. El que quiera más información sólo tiene que hacer una búsqueda en Internet, hay infinidad de documentos que explican los detalles

En Windows Server 2008 R2, los requerimientos son realmente complejos para una pequeña empresa (Conectividad IPv6, Autoridad Certificadora, dos direcciones contiguas IPv4 en Interner, etc. etc.) pero a partir de Windows Server 2012, además de la configuración para la “gran empresa” podemos hacer una implementación realmente sencilla y fácil, sin tantos requerimientos: una dirección IPv4 fija de Internet, no haber deshabilitado IPv6 en nuestra red, y realmente poco más

Esta demostración paso a paso, realmente me ha llevado bastante tiempo y trabajo prepararla en mi ambiente de laboratorio, y no por la cantidad de máquinas necesarias, sino porque para la simulación, el servidor de DirectAccess requiere una dirección pública de Internet, y por supuesto yo lo tengo en una red interna con direccionamiento privado, así que me tuve que valer de una configuración adicional que luego mostraré. Además cuando el cliente se conecta “desde afuera” debe tener acceso a Internet, aunque no la utilice, pero tiene que deterctarlo

La infraestructura necesaria es realmente poca:

• Un Controlador de Dominio (DC1)
• Un servidor miembro que oficiará de NLS (SRV1)
  Tiene una carpeta compartida (Shared) para probar el acceso del cliente desde Internet
• Un servidor miembro que conectará a “Internet” (VPN)
• Un cliente que se conectará adentro y desde afuera

Pero para simulación deberemos contar además con:

• Un servidor que simule un DNS de Internet (ISP)
• Una estructura auxiliar para poder salir a Internet (NAT y ROUTER)
  En mi caso ROUTER, es el real que me conecta a Internet, y NAT es una instalación de un servidor que simplemente ofrece eso, NAT
  Atención a esta instalación de NAT, pues la interfaz “interna” tiene dirección públlica (mi Internet simulada), y la interfaz “externa” (mi red interna) tiene dirección privada 🙂

El siguiente diagrama explica la configuración inicial mejor que mil palabras, por supuesto todos los servidores son Windows Server 2012, y el cliente es Windows 8

En esta demo, dada la extensión de pasos y además que supongo que el que le interese esto conoce de memoria el funcionamiento básico, no mostraré algunas capturas de pantalla, por ejemplo entiendo que todos sabemos instalar una funcionalidad o complemento. De otra forma esto se haría muy pesado

Comienzo en DC1, creando un grupo donde incluiré las máquinas que pueden conectarse por DirectAccess. El grupo creado lo llamaré “DirectAccess Computers” e incluiré en el mismo al cliente CL1

Luego, ahora en el servidor VPN intalaré el rol “Remote Access”, con todas las opciones por omisión hasta “Install”

Luego que finaliza la instalación veremos la siguiente pantalla, donde elegiremos “Open the Getting Started Wizard”

Elegimos “Deploy DirectAccess Only”

Esta pantalla tiene dos configuraciones importantes. Por un lado, tiene que detectar la configuración como “Edge” (tiene una IPv4 pública), y por otro lado debemos ingresar el nombre con el que seá accedido desde Internet. En mi caso usé “vpn.guillermod.com.ar” (sin “root”).

Para que esto sea así, en el servidor ISP, en este mismo momento, creo una zona “guillermod.com.ar” y agrego un registro A donde el nombre “vpn.guillermod.com.ar” se resuelve a la dirección 131.107.0.1 (externa de VPN)

Y proseguimos con el asistente en VPN hasta que llegamos acá. Por omisión el sistema permitirá que se conecten por DirectAccess todas las “Domain Computers” que detecte como portables.

Este no es nuestro caso, sólo queremos que se conecten las que pertenecen al grupo “DirectAccess Computers” y además no queremos que sean sólo las portables (a las virtuales no las detecta como portables )

Así que en la siguiente figura, entramos por “here”

Entramos por “Change” al lado de “Remote Clients”

Quitamos “Domain Computers”, agregamos “DirectAccess Computers” y desmarcamos la opción “Enable DirectAccess for mobile computers only”

Seguimos con “Next” y “Finish”, luego “Ok”, y nuevamente “Finish”

Nota: Como no disponemos de una infraestructura de clave pública en esta demostración, se crearán en forma automática certificados para IP-HTTPS y el Network Location Server (SRV1), además habilitará automáticamente Kerberos Proxy. El asistente también habilitará NAT64 y DNS64 para la interoperabilidad con nuestro ambiente con sólo IPv4

Todo finalizado correctamente

Habiendo finalizado, nos mostrará el “Dashboard”

Seleccionemos “OPERATION STATUS” y debemos dejar pasar un par de minutos hasta que todo muestre “Ok”. Hacer cada tanto un “Refresh”

Ahora vamos a CL1, debemos asegurarnos que esté incluido en el grupo “DirectAccess Computers” y que le esté aplicando las GPOs creadas. Lo podemos ver con “GPRESULT /R”.
Si no estuviera hacer “GPUPDATE /FORCE” y reinicio

Para probar que para el acceso con DirectAccess no se necesita nada especial, iniciaré sesión con un “usuario normal” que yo llamé “User Uno (u1)”, simplemente para que quede localmente la copia del perfil y pueda iniciar sesión sin estar conectado a la red del Dominio

IMPORTANTE: hay un “bug” que aún ahora con la versión final de los productos persiste y que debemos solucionar manualmente. El servidor DirectAcces espera IP-HTTPS, pero el cliente prueba con 6to4 y Teredo, por lo tanto debemos deshabilitar estas interfases
Para esto, como administrador, debemos ejecutar:

• NETSH INTERFACE IPV6 6TO4 SET STATE DISABLED
• NETSH INTERFACE TEREDO SET STATE DISABLED

El paso siguiente es mover este cliente (CL1) a la “Internet simulada”, así que la cambiaré y le pondré la configuración IPv4 que lo simula (ver diagrama al principio de la nota. Lo reinciaremos e inciamos sesión con el usuario “User Uno (u1)”

Abramos PowerShell y veamos si estamos conectados por DirectAccess, para eso abramos PowerShell y escribamos:

• Get-DAConnectionStatus

Si nos muestra “ConnectedRemotely” es que ya estamos conectados 🙂

Probemos ingresar a un recurso de la red interna

Observen un PING a DC1

De todas formas, lo que nos importa es poder acceder a los recusos de la red interna 🙂

Y además tenemos “internet directo”

Resumiendo, DirectAccess es algo muy útil, tengamos en cuenta que así como el usuario tiene conectividad a la red interna, desde la red interna podemos administrar al cliente tal cual como si estuviera conectado a la red interna; no necesita ninguna configuración especial en el cliente (salvo la aplicación de la GPO), no necesita privilegios en la cuenta del usuario, ni éste debe hacer alguna tarea para que se conecte

Con sistemas anteriores, teníamos la dificultad de la infraestructura y requerimientos específicos, pero a partir de Windows Server 2012, tenemos también una implementación sencilla