Crear red de sitio a sitio S2S en Azure utilizando RRAS

En Microsoft Azure tenemos la posibilidad de crear dos tipos diferentes de conexiones VPN, de punto a sitio P2S, donde básicamente realizamos una conexión desde un solo punto o equipo a una red en Azure. Si desea saber cómo configurar este tipo de conexión los invito a leer el siguiente post: Crear red punto a sitio en Azure. En este caso vamos  a ver cómo realizar una conexión VPN de sitio a sitio S2S, donde lo que hacemos conectar toda una red LAN completa con una red en Azure.

Para este tipo de conexión VPN necesitamos de una dirección IP pública en nuestra LAN, y un dispositivo de enrutamiento  para conectar a la red virtual de Azure a través de un túnel VPN IPSec/IKE (IKEv1 ó IKEv2), el dispositivo a utilizar debe ser compatible con Azure en este enlace puede encontrar más información sobre los dispositivos soportados.

Ahora veamos los pasos para crear la conexión VPN

1. Crear red virtual

Ingresamos al portal de Azure https://portal.azure.com nos dirigimos al Market Place y en la parte de Redes elegimos Red Virtual

Ahora vamos a poner los datos de la red virtual, debemos utilizar un segmento de direcciones IP que no vaya a entrar en conflicto con el segmento de nuestra red local, todas las máquinas que creemos en adelante y las asociemos con esta red, se les asignará una dirección IP del segmento creado, para este caso tenemos un espacio de direcciones 192.168.0.0/16, y de este espacio de direcciones crearemos una subred en un segmento más pequeño 192.168.1.0/24

Nombre: Ponemos el nombre que deseemos para nuestra red, aquí la llamaremos VNet

Espacio de direcciones: El espacio de direcciones que usaremos para asignar a esta red virtual, una red virtual puede contener varias subredes, por esta razón estoy creando un espacio de direcciones generoso (máscara de 16 bits), para luego crear subredes a partir de este espacio de direcciones, hemos elegido como espacio de direcciones 192.168.0.0/16 

Suscripción: Elegimos la suscripción a utilizar.

Grupo de recursos: Podemos elegir un grupo de recursos existente o bien podemos crear uno nuevo, generalmente y como una buena práctica debemos crear primero el grupo de recursos antes de crear cualquier otro recurso, en mi caso siempre o hago así, y en este caso utilizaré un grupo de recursos que previamente creé llamado RRAS

Ubicación: Elegimos la región en la cual deseamos crear la red, en este caso Este de EE.UU.

Bajo el apartado subnet 

Name: ponemos el nombre que llevará nuestra subred, en este caso la llamaré Backend

Address range: El segmento de direcciones para la subred, vamos a utilizar 192.168.1.0/24

Como mencioné anteriormente, tenemos la posibilidad de crear varias subredes dentro de una red virtual, en este caso vamos a necesitar de una subred de puerta de enlace, para ello sobre la red recién creada en Configuración seleccionamos subredes

Allí podemos ver nuestra subred recién creada Backend y en la parte superior tenemos la opción de agregar una subred de puerta de enlace como se muestra a continuación.

Nos solicitará el segmento a utilizar para esta nueva subred, el nombre no lo podemos elegir, siempre se llamará GatewaySubnet lo único que debemos poner es el segmento de direcciones a utilizar, voy a tomar otro de mi espacio global de direcciones para la red virtual 192.168.2.0/24, se puede elegir un segmento más pequeño, pero de hecho Microsoft recomienda no dejarlo tan limitado por si se requieren configuraciones en el futuro.

 Al final las subredes quedaron de la siguiente forma:

2. Crear puerta de enlace de red virtual

Básicamente esta puerta de enlace nos servirá como puente para enviar y recibir información entre la puerta de enlace de Azure y el servidor RRAS local.

Vamos al Market Place y en la sección de redes buscamos Puerta de enlace de red virtual

Y empezamos a diligenciar los campos:

Nombre: El nombre que deseamos para la puerta de enlace de red virtual, en este caso Gateway (bastante creativo XD).

Tipo de puerta de enlace: Elegimos VPN  ya que es el tipo de conexión que estamos creando.

Tipo de VPN: Elegimos VPN basada en rutas

SKU: Existen varios SKU según las necesidades, en este caso dejamos VpnGw1 este SKU permite máximo 30 túneles S2S, máximo 128 conexiones P2S. Puede ver las diferencias y detalles adicionales sobre los SKU en este enlace

Red virtual: Seleccionamos la red virtual VNet

Dirección IP pública: Aquí podemos elegir una IP existente o crear una nueva, en este caso hemos creado un nuevo objeto de dirección IP pública llamado Gateway-RRAS-IP

Después de tener todo listo hacemos clic en Crear y solo resta tener paciencia, este proceso puede tardar hasta 45 minutos (y tal vez un poco más).

3. Crear puerta de enlace de red local

Esta puerta de enlace es la que va a contener los datos de nuestra red local, incluyendo la dirección IP pública y el segmento de red usado en el entorno local.

Nota: Recuerde que los segmentos de red local no deben existir en Azure

En el Market Place en Redes seleccionamos Puerta de enlace de red local

Ahora proporcionamos los datos necesarios para la creación de la puerta de enlace.

Nombre: Ponemos un nombre descriptivo para la puerta de enlace,en este caso: GW-LAN-RRAS

Dirección IP: Aquí ponemos la dirección IP pública (No puede estar detrás de un NAT), del dispositivo VPN que para este caso será el servidor RRAS

Espacio de direcciones: Aquí debemos poner el segmento o segmentos dela red local, estos segmentos son usados por Azure para enrutar el tráfico de esos segmentos por la VPN, debe tener cuidado de estos segmentos no existan en Azure. La imagen anterior la generé antes de poner el segmento local (lo siento!), pero mi segmento es 172.16.1.0/24. Como pueden ver utilicé uno bastante diferente para no generar confusiones.

El resto de opciones ya las conocemos y las he explicado anteriormente así que voy a omitirlas.

4. Crear conexión VPN

En la recién creada puerta de enlace de red local en Configuración seleccionamos Conexiones

Hacemos clic en el símbolo + Agregar

Y completamos los siguientes datos solicitados:

Nombre: Elegimos un nombre para la conexión, en este ejemplo: S2S-LAN

Tipo de conexión: Seleccionamos De sitio a sitio (IPSec)

Puerta de enlace de red virtual: Seleccionamos la creada en el paso 2 Gateway

Puerta de enlace de red local: Seleccionamos la creada en el paso 3 GW-LAN-RRAS

Clave compartida (PSK): Ponemos una clave cualquiera, la necesitaremos más adelante para configurar el servidor RRAS por lo tanto hay que tenerla presente, en la imagen a continuación utilizo una clave sencilla para fines de esta demostración, pero lo ideal es usar una clave más compleja.

5. Configurar rol RRAS en Windows Server 2012 R2

El último paso es la configuración de el rol RRAS en Windows Server que actuará como nuestro dispositivo VPN. Abrimos Server Manager e instalamos el rol Remote Access

Una vez instalado el rol abrimos la consola RRAS y sobre el nombre del servidor hacemos clic derecho y seleccionamos Configure and Enable Routing and Remote Access

En la primer ventana del wizard seleccionamos Secure connection between two private networks

A continuación seleccionamos Yes

En IP Address Assignment seleccionamos Automatically

Por último, hacemos clic en Finish

Sobre Network Interfaces hacemos clic derecho y seleccionamos New Demand-dial Interface

Hacemos clic en Next para iniciar

Ponemos un nombre ala interface

En Connection Type elegimos  Connect using virtualprivate network (VPN)

Ahora en VPN Type seleccionamos IKEv2

En la siguiente ventana debemos especificar la dirección IP pública asignada por Azure, si no la conocemos basta con ir al portal de Azure y en la información general de la puerta de enlace de red virtual podemos consultarla, tal como se muestra a continuación:

Después de tener la IP pública la ponemos en el wizard y hacemos clic en Next

En Protocols and Security seleccionamos Route IP packets on this interface

En la siguiente ventana hacemos clic en Add para agregar una ruta estática 

Y ponemos el segmento de la red virtual en Azure

Quedará de la siguiente forma, hacemos clic en Next

Nos solicitará crear credenciales, como utilizaremos clave compartida no es necesario, así que solo pondré el nombre de usuario.

Hacemos clic en Fisnish para terminar la configuración de la interface Demand-dial

Seleccionamos la interface recién creada Azure S2S y hacemos clic derecho y luego Propiedades

Vamos a la pestaña Security y ponemos la clave PSK

Ahora, solo nos resta hacer clic derecho sobre la interface y seleccionar Connect

Y como podemos apreciar en la siguiente imagen tenemos en estado Connected

Y eso es todo, si queremos verificar el estado de la conexión desde el portal de Azure, vamos a la puerta de enlace de red virtual, y en Configuración seleccionamos Conexiones

Podremos apreciar tanto el estado de la conexión como los datos de entrada y salida.

Bien, y hasta aquí hemos llegado, sé que está un poco largo, pero tocaba hacerlo. Espero les sea de utilidad.

Error al agregar grupos de otros dominios a colección en RDS

A continuación vamos a ver cómo resolver un problema que se puede presentar al intentar agregar un grupo de un dominio diferente al que tiene la implementación de RDS, puede tratarse de un dominio externo con le cual se tenga una relación de confianza, o incluso un sub-dominio dentro del mismo bosque, el error dice que nos aseguremos de que exista una relación de confianza bidireccional entre los dominios, pero el error sale así exista dicha relación y esté funcionando bien, de hecho el mensaje sale también si se trata de un subdominio, que de manera predeterminada tendrá una relación de confianza transitiva y bidireccional. El mensaje de error que se presenta es el siguiente:

The security identifier could not be resolved. Ensure that a two-way trust exists for the domain of the selected users
Exception: The network path was not found

Solución 

Podemos resolver esto de dos formas, la primera es agregar el sufijo DNS del dominio en el cual se encuentra el grupo que deseamos autorizar en la colección. Para ello vamos a las propiedades de la tarjeta de red, y en la pestaña DNS ponemos el sufijo del otro dominio y hacemos clic en OK

Ahora, desde el símbolo del sistema ejecutamos: ipconfig /flushdns

Ahora verificamos, en mi caso el grupo del otro dominio es Domain Users, aquí ustedes eligen el grupo sobre el cual desean otorgar permisos en la colección, después de agregar el sufijo DNS del otro dominio permite agregar el grupo sin ningún problema.

Ahora veamos la segunda opción, esta vez vamos a utilizar PowerShell. y ejecutamos lo siguiente

 Set-RDSessionCollectionConfiguration -CollectionName "Desktop" -UserGroup "DominioB\Domain Users"

El la anterior instrucción podemos ver que mi colección se llama Desktop y que el grupo de usuarios que tendrá acceso a la misma será DominioB\Domain Users

Después de esto si volvemos a la colección efectivamente aparecerá el grupo.

Bien, eso es todo, espero que esta información sea de utilidad. Un saludo!

ITPros-DC Tech Talks Live

Se me había hecho tarde para compartir en mi blog esta invitación! se trata de una serie de webcast sobre diversas tecnologías y completamente gratis! las sesiones se llevarán a cabo todos los martes de 8:00 a 9:00 PM hora Colombia, iniciamos el pasado 13 de junio y finalizarán el 29 de agosto, la última sesión tendrá una particularidad y es que será presencial con transmisión en vivo. En esta última sesión se hablará sobre seguridad. específicamente sobre WannaCry el ransomware que recientemente afectó a múltiples organizaciones alrededor del mundo, la sesión estará a cargo de Rodolfo Parrado Gutierrez, experto en estos temas y quien lleva varios años trabajando en la industria de TI. Las sesiones son sobre diversas tecnologías tales como: Microsoft. Citrix, IBM, VMWare y Oracle. En mi caso no solamente soy el organizador del evento, también estaré hablando sobre Windows Server 2016, así que los invito a revisar la agenda y a conocer a cada uno de los speakers. Toda la información está disponible en: http://www.itpros-dc.com/techtalks/

Desactivar y mover cuentas de equipo a una OU determinada

En ocasiones, puede resultar de utilidad desactivar varias cuentas de máquina y moverlas a una OU determinada. Por lo cual a continuación vamos a ver cómo hacer esto con la ayuda de PowerShell.

Nota: Ya se debe contar con un archivo .txt que contenga el listado de las cuentas de máquina

Lo primero que debemos hacer es crear una OU a la cual moveremos las cuentas de equipo, la cual he llamado OldComputers. Después de tener creada la OU y tener listo el archivo txt con los nombres de las máquinas debemos ejecutar el siguiente código de PowerShell

Nota: Si requiere encontrar máquinas en las cuales no se haya iniciado sesión desde hace determinado tiempo, puede consultar este post, tal vez le sea de utilidad para generar el archivo txt de entrada

Después de ejecutar el código las máquinas listadas en el archvo serán desactivadas y posteriormente movidas a la OU que especificamos.

Cuentas de equipo que no han iniciado sesión después de una fecha determinada

Una de las tareas más frecuentes cuando se está administrando Active Directory bien sea por temas de mantenimiento, auditoria, entre otros...es la identificación de cuentas de equipo antiguas, de máquinas inexistentes, algunas de ellas pueden ser fáciles de identificar porque la máquina se retiró del dominio y se encuentra des-habilitada, pero muchas otras se encuentran activas y no sabemos si están siendo utilizadas o no, es en ese momento cuando nos surge la pregunta ¿Cómo encuentro las cuentas de máquina en las cuales no se ha iniciado sesión hace determinado tiempo?. Bien pues vamos a ver cómo utilizar PowerShell para encontrarlas, en el ejemplo a continuación se generará un archivo CSV que contiene las cuentas de máquina donde no se ha iniciado sesión desde hace más de un año (365 días).

Si verificamos el valor de la variable $fecha podemos ver la fecha que se evaluará, y cualquier fecha que sea menor a la fecha indicada será lo que se exporte al archivo CSV

Con lo cual el resultado será un archivo CSV que contiene todas las cuentas de equipo cuyo atributo lastLogonTimestamp sea menor al dato de la variable fecha, que para esta caso es: miércoles, 22 de junio de 2016 9:28:33 a. m.

El resultado: un archivo CSV que contiene el nombre del host y la fecha del último logon

Gracias por la atención y como siempre, espero les sea de utilidad.

Error al intentar establecer servidor de licencias RDS Windows Server 2012 R2

Si tiene una implementación de RDS (Remote Desktop Services) en Windows Server 2012 R2, tal vez se haya encontrado con un inconveniente a la hora de establecer el servidor de licencias de escritorio remoto, al intentar hacerlo puede recibir un mensaje de error como el que les muestro a continuación:

Primero, en Server Manager vamos a Remote Desktop Services y editamos nuestro despliegue.

Luego, si vamos a la opción RD Licensing se puede apreciar que no está seleccionada ninguna de las dos opciones (Per Device / Per User) y si intentamos establecer alguna de las dos obtenemos el siguiente mensaje de error, aún si sabemos que el servidos de licencias está configurado adecuadamente:

Could not save the settings for RD Licensing. Error: Unable to set the license settings

Para solucionarlo, vamos al servidor de licencias, abrimos una consola de PowerShell elevada y ponemos lo siguiente:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting

Seguidamente:

$obj.GetSpecifiedLicenseServerList()

En la salida podemos observar que en el campo SpecifiedLSList  se encuentra vacío.

Lo que vamos a realizar a continuación es rellenar ese campo con el nombre del servidor de licencias, para ello usamos la siguiente instrucción:

$obj.SetSpecifiedLicenseServerList("servidorlicencias.dominio.com")

Ahora, si volvemos a ejecutar la instrucción $obj.GetSpecifiedLicenseServerList() el nombre del servidor de licencias que especificamos aparecerá en el campo SpecifiedLSList como se muestra a continuación:

Después de hacer este cambio y volver a revisar el estado en RD Licensing ya se encuentra establecido.

Como siempre, espero esta información les sea de utilidad. Hasta la próxima.