Direct Access vs VPN

Hola.

Para empezar tendremos que definir que es cada cosa ya que Direct Access y VPN no son la misma cosa. Comencemos por VPN, Virtual Private Network, son muy conocidas y altamente empleadas por todos los fabricantes de electronica de comunicaciones. Microsoft por su parte también la implementa mediante RRAS, Route and Remote Access Server, que es el RAS de toda la vida paro los que llevamos algún tiempo en esto.

 

El problema: No se ve clara la diferencia.

Direct Access - VPN

 

VPN: Es un Túnel que se crea a través de internet para que las comunicaciones entre los dos puntos sean como si estuviésemos en la misma red. Es un sistema abierto y compartido por todos los fabricantes.

Direct Access: Es un Super-tunel que ha creado Microsoft para mejorar las VPN tradicionales. Lo implementan solo las ultimas versiones de Windows Server y Windows 7, 8 en adelante.

 

Las Ventajas de Direct Access son su talón de Aquiles.

 

DirectAccess

VPN

Los equipos se conectan automáticamente sin intervención.

           X

Funciona a través de todos los firewalls

           X

Se puede seleccionar el servidor de acceso y el tipo de autenticación durante la conexión.

           X

Soporta autenticación y encriptación de punto a punto

           X

Soporta administración de los equipos remotos

           X

Compatible todas las versiones de clientes Windows

           X

Compatible con equipos de otros Sistemas Operativos

           X

Compatible con equipos fuera de dominio

           X

No necesita Windows Server 2008 R2 en el punto remoto

           X

Visto así, todo son ventajas, pero para implementar Direct Access no es tan sencillo como lo pintan. si lo viesemos de esta otra forma…

Se necesita:

  • Servidores con Direct Access, mínimo Windows Server 2008 R2
  • Dos adaptadores de red: Uno a la Lan y otro a internet con 2 IPs consecutivas Públicas.
  • Los clientes de DirectAccess con Windows 7 o superior.
  • Un controlador de dominio y DNS con Server 2008 R2 o superior.
  • Una infraestructura PKI, Public Key Infrastructure para generar certificados.
  • IPsec para la protección del tráfico.
  • IPv6 en el servidor DirectAccess: ISATAP, Teredo o 6to4.
  • Ademas para dar acceso a clientes con IPv4 necesitaremos la ayuda de terceros.

 

La implementación

La implementación tanto de direct access como de VPN se puede realizar mediante el asistente que ofrece el servidor tras instalar el rol de Acceso remoto.

Direct Access

 

Problemas en la implementación

La implementación parece sencilla hasta que nos ponemos a hacerla ya que en uno de los pasos mas importantes, nos encontramos con el principal problema: ¿Como poner el servidor? en la red perimetral, en la interna, con uno o con dos adaptadores de red… y lo mas importante ¿como le ponemos 2 IPs públicas a la nic del Servidor?

Era típico el error: “no se encuentra un adaptador interno con una dirección IP válida

image0001

 

Soluciones en la implementación

Vemos que desde Server 2008 ha sido siempre una implementación rígida y difícil de realizar. Hemos tenido que esperar a 2012 R2 para simplificar las cosas .

Captura de pantalla 2015-04-06 a las 23.48.04

Desde que instalamos el Rol, ya nos aparecen mas opciones, El proxy para aplicaciones Web. Y a la hora de implementar también nos dejara poner los adaptadores dentro de la red interna y hacer NAT hacia ellos, incluso con un solo adaptador.

image0002

 

Para la gran mayoria

Hoy por hoy las VPN aunque menos seguras son las mas flexible y fáciles de configurar. En Windows server prácticamente no han cambiado a excepciona de que ahora están en el mismo rol que el que dota al servidor de la capacidad de enrrutar y unir delegaciones entre si; RRAS.

conf_

Cambio de SID al Windows server 2012

Cambio de SID a un Windows Server 2012

-esta entrada esta plagiada de mi propia entrada para 2008

Procedimiento

  • Hay que ejecutar SYSPREP y seleccionar “generaliza” con la opción por defecto “iniciar configuración rápida (OOBE) del sistema”.
  • SysPrep no hace falta descargarlo, se encuentra en la siguiente ruta del 2012:

\windows\system32\SysPrep\sysprep.exe

Captura de pantalla 2013-03-03 a la(s) 23.46.55
Le cuesta un ratillo en reiniciar…
Captura de pantalla 2013-03-03 a la(s) 23.47.26
Y luego nos pide terminar la instalación como cuando lo instalamos por primera vez:
 Captura de pantalla 2013-03-03 a la(s) 23.52.51

Cambios tras el reinicio

Al reiniciar he visto varios cambios:
  • El logo, se ha cambiado
  • Ha perdido la configuración de Equipo
  • perdido la configuración del Dominio
  • perdido la configuración de la red
Pero el SID esta cambiado, que es de lo que se trataba. Pues eso, las aplicaciones, Roles, datos, etc, están todas, pero hay que volver a meterlo en dominio y darle un Nombre de equipo.

 

 

Meter un equipo en dominio con 2012 server.

Mi problemilla de hoy

Meter un equipo en dominio en 2012, una tarea habitual y casi no encuentro como hacerlo en 2012. Pero aún encontrándolo, me parecía un poco cutre la forma de meter un equipo en dominio a través de “mi PC” ya que Windows 2012 carece de este icono y hay que ir a explorar una carpeta para encontrarlo. 

 

Pero no es así, afortunadamente hay otra forma mas profesional y que tambien esta en versiones anteriores de Windows, solo que siempre lo hacia desde el otro sitio.

La solución

En Panel de control -> Seguridad -> Sistema -> configuración avanzada del sistema.

Y desde esta ventana ya sabemos como cambiarlo.

 

 No he descubierto nada, pero me quedo mas tranquilo y ya no pienso que Microsoft es cutre […] 🙂

 

>Migrar DHCP de un servidor a otro.

>

Me he encontrado con el problema de migrar un DHCP de un servidor a otro. Cosa que no tiene mayor inconveniente….a no ser que se quieran mantener las mismas IPs que tienen los equipos con el viejo DHCP.
¿Cómo resolverlo?…¿a mano?
NO, tal como soy, las hubiera puesto todas mal 😉. Lo he hecho por línea de comando (antiguamente existía un comando addreservedip… pero en 2008 no existe) usando el tan versátil netsh.
>netsh dhcp server cw2k8dhcp.Dominio.dom scope 10.50.69.0 add reservedipIP a reservar” “MAC” “nombre equipo
Un poco cutre, pero efectivo. Haremos lo siguiente:
Exportamos a un *.txt las concesiones actuales de nuestro DHCP


Modificamos el .txt añadiendo el comando NET, pero para hacerlo mas rápido, lo abrimos ese *.txt con Excel para generar la “parrafada” y no tener que picarla a mano.
En mi caso genero una nueva columna con:
=”netsh dhcp server \\cw2k8dhcp.cartv.int scope 10.50.69.0 add reservedip “&A3&” “&E3&” “&B3&” “
y arrastrando “pa´bajo” obtenemos todos los comandos.
Seleccionamos la “parrafada” generada y la grabamos en un NotePad como *.bat
Ejecutamos el *.bat desde el el servidor con el nuevo DHCP.
Comprobamos que ha funcionado correctamente:

Listo 😉

Recordando los 5 Maestros, FSMO, los 5 Roles

Recientemente me han preguntado como transferir algún rol por linea de comando….. me han pillado, ya que es algo que como no se hace, se olvida. Pues me dije vamos a aprovechar el blog para tener siempre a mano los maestros que siempre se nos olvidan. Repasemos:
 

1 empecemos

Hay cinco funciones Flexible Single Master Operations (FSMO) en un bosque de Windows 2003. Hay dos maneras de transferir una función FSMO en Windows 2003. En este artículo se describe cómo transferir las cinco funciones FSMO utilizando complementos de Microsoft Management Console (MMC). Las cinco funciones FSMO son:

1.1.              Maestros

  • Maestro de esquema
  • Maestro de nombres de dominio
  • Maestro de infraestructura
  • Maestro RID
  • Emulador de PDC

1.2.              Comando para listar los roles

Desde una consola en cualquier DC:
#:\netdom query fsmo

2.   Descripción

2.1.              Maestro de esquema:

uno por bosque.
El titular de la función FSMO de maestro de esquema es el controlador de dominio responsable de realizar las actualizaciones al esquema del directorio.

2.2.              Maestro de nombres de dominio:

uno por bosque.
El titular de la función FSMO de maestro de nombres de dominio es el DC responsable de realizar los cambios al espacio de nombres de dominio para todo el bosque del directorio.

2.3.              Maestro de infraestructura:

uno por dominio.
El titular de la función FSMO de maestro de infraestructura es el DC responsable de actualizar el SID y el nombre completo de un objeto en una referencia entre objetos de diferentes dominios.

2.4.              Maestro RID:

uno por dominio.
El titular de la función FSMO de maestro RID es el único DC responsable de procesar las peticiones de grupos RID de todos los DC de un dominio dado.

2.5.              Emulador de PDC:

uno por dominio.
El titular de la función FSMO de emulador de PDC es un DC de Windows 2003 que se anuncia a sí mismo como el controlador principal de dominio (PDC) a las estaciones de trabajo, los servidores miembro y los controladores de dominio de versiones anteriores. También es el examinador principal de dominio y se ocupa de las discrepancias en las contraseñas.
Microsoft Knowledge Base = http://support.microsoft.com/kb/197132/

3.   Transferir funciones de FSMO con herramientas de MMC

Puede transferir las cinco funciones de FSMO mediante la herramienta MMC en Windows 2003. Para que una transferencia se pueda realizar, ambos equipos deben estar disponibles en conexión y se realizara con la consola adecuada desde el Servidor que queremos que asuma el Rol.
Si un equipo ya no existe, su función debe transferirse a otro equipo diferente. Para asumir una función, debe emplear una utilidad denominada Ntdsutil.
(http://support.microsoft.com/kb/255504/) Utilizar Ntdsutil.exe para asumir o transferir las funciones de FSMO a un controlador de dominio

3.1. Transferir funciones específicas del dominio: RID, PDC y maestro de infraestructura

o      Haga clic en Inicio, seleccione Programas, Herramientas administrativas y, a continuación, haga clic en Usuarios y equipos de Active Directory.
o      Haga clic con el botón secundario del mouse en el icono Usuarios y equipos de Active Directory y, a continuación, haga clic en Maestros de operaciones.
o      En el cuadro de diálogo Cambiar el maestro de operaciones, haga clic en la ficha adecuada (RID, PDC o Infraestructura) para la función que desea transferir.
o      Haga clic en Cambiar en el cuadro de diálogo Cambiar el maestro de operaciones .
o      Haga clic en Aceptar para confirmar que desea transferir la función.

3.2. Transferir la función de maestro de nombres de dominio

o      Haga clic en Inicio, seleccione Programas, Herramientas administrativas y, a continuación, haga clic en Dominios y confianzas de Active Directory.
o      Haga clic con el botón secundario del mouse en el icono Dominios y confianzas de Active Directory y, a continuación, haga clic en Maestros de operaciones.
o      En el cuadro de diálogo Cambiar el maestro de operaciones, haga clic en Cambiar.
o      Haga clic en Aceptar para confirmar que desea transferir la función.



5. Migrar los roles por linea de comando

Captura de pantalla 2013-02-03 a la(s) 23.31.27
Si en vez de hacerlo siguiendo todos los pasos largos de lo anterior, podemos hacerlo todo por comandos, para ello, desde el servidor destino (el nuevo, el que tendrá los roles), abrimos una ventana de MSDOS y ejecutamos “ntdsutil”, damos a enter; el siguiente comando a escribir es “roles”, damos a Enter. Después escribimos “connections” y damos de nuevo al Enter. Después, nos conectamos al servidor que queremos que tenga los roles, ponemos “connect to server NOMBRE_SERVIDOR”, damos a Enter; salimos poniendo “q” y damos de nuevo a Enter. Ahora escribimos el rol que nos interese mover a este servidor, siempre precedido de la palabra “transfer”, y los cinco roles serían: “domain naming master”, “infraestructure master”, “PDC”, “RID master” y “schema master”. Habría que ejecutar el comando con todos los roles (o sea, cinco veces) y a la pregunta que nos haga si estamos seguros o no, decimos que “Sí”.

      5.  Forzar migración de roles en caso de errores en lo anterior:


Si tenemos algún problema con el Directorio Activo o por lo que sea el servidor origen de alguna función ya no existe o no nos las quiere transferir… siempre podemos forzarlo de la siguiente manera. Desde el servidor destino (el nuevo, el que tendrá los roles), abrimos una ventana de MSDOS y ejecutamos “ntdsutil”, damos a enter; el siguiente comando a escribir es “roles”, damos a Enter. Después escribimos “connections” y damos de nuevo al Enter. Después, nos conectamos al servidor que queremos que tenga los roles, ponemos “connect to server NOMBRE_SERVIDOR”, damos a Enter; salimos poniendo “q” y damos de nuevo a Enter. Ahora escribimos el rol que nos interese mover a este servidor, siempre precedido de la palabra “seize”, y los cinco roles serían: “domain naming master”, “infraestructure master”, “PDC”, “RID master” y “schema master”. Si queremos estar seguros y no sabemos cual hacer, ejecutamos el comando con todos los roles y a la pregunta que nos haga si estamos seguros o no, decimos que “Sí”.

Cuando necesitemos la chuleta…aqui la tendremos a mano.