Crear red punto a sitio P2S en Azure

En el año 2013 creé un artículo donde expliqué cómo crear una red virtual de punto a sitio utilizando Windows Azure (en ese entonces). El artículo completo puede consultarse aquí

Ya han pasado más de 3 años desde ese momento, y las cosas han evolucionado bastante en Azure, por lo cual el mencionado artículo ya se encuentra bastante obsoleto. Recientemente he estado dictando un curso de fundamentos de Microsoft Azure para la comunidad ITPros-DC y explicando el tema de redes virtuales me animé a realizar la actualización de esta información en mi blog. Así que empezaré mostrando cómo crear una red de punto a sitio en Azure, en otro artículo explicaré cómo crear la conexión de sitio a sitio S2S.

 Diagrama de la solución:

(Clic para ampliar)

Crear red virtual

Lo primero que debemos hacer es crear una red virtual a través del marketplace en el portal de Azure

Marketplace - Redes - Red virtual

En modelo de implementación dejamos Resource Manager y hacemos clic en Crear

Se abrirá una página solicitando la información para la creación de la red, todos los campos marcados con asterisco son obligatorios.

Nombre: Aquí va el nombre que queremos poner a nuestra red virtual, en mi caso y tal como está en el diagrama la llamé VNet1

Espacio de direcciones: Ponemos el espacio de direcciones a utilizar, posteriormente puede agregar más espacios de direcciones, para mi caso agregué el segmento 192.168.0.0/16 elegí de una vez un segmento grande con máscara de 16 bits para luego poder agregar más subredes en este segmento.

Nombre de subred: El nombre que deseamos para nuestra primer subred, en mi caso la llamé Subred1

Intervalo de direcciones de subred: Ponemos un segmento de red que esté contenido en el espacio de direcciones que definimos anteriormente, en mi caso el segmento 192.168.1.0/24 con una máscara de 24 bits para ubicar las máquinas a las cuales tendremos acceso más adelante.

Suscripción: Si tienen más de una suscripción aquí pueden seleccionar cuál usar.

Grupo de recursos: Se puede crear un grupo nuevo o utilizar uno existente, en mi caso seleccioné un grupo existente llamado Azure-Fundamentals. Si desea saber más sobre grupos de recursos los invito a ver un vídeo donde lo explico con más detalle AQUÍ

Ubicación: El centro de datos donde se implementarán los recursos, en mi caso Este de EE. UU.

Al finaliza la creación de la red virtual, podremos ver el mensaje en el área de notificaciones.

En la parte de Configuración de la recién creada red virtual, podemos ver el espacio de direcciones, donde tendremos la posibilidad de agregar más intervalos, de igual modo con las subredes.

Agregar subred de puerta de enlace:

Antes de poder conectar la red virtual a una puerta de enlace (gateway), es necesario  crear una subred para la puerta de enlace, veamos cómo hacerlo.

Ingresamos a nuestra red virtual VNet1 vamos a Configuración y luego Subredes donde veremos la opción Subred de puerta de enlace como se muestra a continuación:

Se abrirá la página Agregar subred donde especificamos el segmento a utilizar, para este caso elegí el segmento 192.168.100.0/24

Al final debe quedar algo similar a lo siguiente:

Crear puerta de enlace de red virtual

En el marketplace en Redes buscamos Puerta de enlace de red virtual

Se abrirá la página Crear puerta de enlace de red virtual 

Nombre: Elegimos un nombre para nuestra puerta de enlace, para este caso VnetGW

Tipo de puerta de enlace: Seleccionar VPN

Tipo de VPN: Seleccionamos basado en rutas, el más común en la mayoría de implementaciones.

SKU: Seleccionamos Estándar

Red Virtual: Seleccionamos la red virtual VNet1, si no aparece la red virtual probablemente la ubicación esté en otro centro de datos.

Dirección IP pública: Tenemos la posibilidad de elegir una IP creada previamente o crear una nueva.

Suscripción: Si tienen más de una suscripción aquí pueden seleccionar cuál usar.

Grupo de recursos: Se puede crear un grupo nuevo o utilizar uno existente, en mi caso seleccioné un grupo existente llamado Azure-Fundamentals. 

Ubicación: El centro de datos donde se implementarán los recursos, en mi caso Este de EE. UU.

Por último hacemos clic en Crear para empezar

Nota: El proceso de creación de la puerta de enlace de red virtual puede tardar hasta 45 minutos. Pueden tomarse un café mientras tanto.

Después de creada la puerta de enlace de red virtual, podemos ver los siguientes elementos en nuestro grupo de recursos: Una red virtual, la puerta de enlace de red virtual y la dirección IP pública para la misma.

Generar certificados

Para poder utilizar la conexión P2S es necesario utilizar un certificado digital, si se tiene una entidad certificadora es posible utilizar esta entidad para emitir los certificados para utilizar con la VPN, en esta caso utilizaremos certificados autofirmados, anteriormente lo hacia con la utilidad de línea de comando makecert en esta ocasión lo haré utilizando Powershell de Windows 10.

Para crear el certificado raíz debemos abrir una consola elevada de Powershell en Windows 10 y ejecutar el siguiente código:

 $cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `
 -Subject "CN=P2SRootCert" -KeyExportPolicy Exportable `
 -HashAlgorithm sha256 -KeyLength 2048 `
 -CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign

El código anterior generará un certificado llamado P2SRootCert

Nota: Por ahora no cierre esta sesión de Powershell, nos será de utilidad más adelante para generar el certificado de cliente, de lo contrario hay que realizar algunos pasos adicionales.

Podemos abrir la consola de certificados usando certmgr.msc

Ahora debemos exportar la clave pública (.cer) para llevarla a Microsoft Azure.

En la consola de certificados (certmgr.msc) seleccionamos el certificado recién creado, hacemos clic derecho Todas las tareas - Exportar

Se abrirá el asistente para exportar certificados, clic en Siguiente para continuar.

En la siguiente ventana seleccionamos No exportar la clave privada

En formato de archivo de exportación seleccionamos X.509 codificado base 64 (.CER)

En la siguiente ventana seleccionamos la ruta y el nombre del archivo para el certificado.

Al finalizar saldrá un mensaje indicando que la exportación se realizó con éxito.

Generar certificado de cliente

Ahora vamos a generar un certificado de cliente a partir del certificado raíz que acabamos de crear en los pasos anteriores, para ello la misma consola elevada de Powershell que utilizamos para crear el certificado raíz pegamos el siguiente código:

New-SelfSignedCertificate -Type Custom -KeySpec Signature `
-Subject "CN=P2SChildCert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")

Como se puede apreciar en la imagen anterior, se ha generado un certificado llamado P2SChildCert

Si desea instalar el certificado en otro equipo debe exportarlo con la clave privada.

Podemos ver en la consola certmgr.msc los dos certificados, tanto el de raíz como el cliente.

Crear grupo de direcciones para clientes VPN

Ahora debemos abrir la configuración en la puerta de enlace de red virtual, allí vamos a Configuración de punto a sitio

Aquí es donde debemos agregar el grupo de direcciones que recibirán los clientes al conectarse a la VPN, si volvemos a nuestro diagrama veremos que el segmento que definimos para tal fin es: 172.16.1.0/24

Cargar certificado raíz (.cer) en Azure

En la misma configuración de punto a sitio donde agregamos el grupo de direcciones podremos ver más abajo la opón para agregar el certificado con la llave pública, el mismo que ya exportamos y tenemos guardado en una ubicación local.

Debemos ubicar el certificado y editarlo con un bloc de notas, y copiamos su contenido (solamente la parte resaltada con amarillo)

Ahora, volvemos al portal de Azure y pegamos esta información y asignamos un nombre, y por último hacemos clic en Guardar

Descargar e instalar cliente de conexión VPN

Para poder conectarse a la VPN aparte del certificado de cliente se necesita instalar un paquete de cliente VPN que crea la conexión que utilizaremos, la descarga la hacemos directamente desde el portal. Al finalizar la carga del certificado en Azure, en la parte superior se habilitará la opciòn Descargar cliente VPN

Nos da la opción de descargar el paquete de 32 ó 64 bits

Al ejecutar el paquete saldrá un mensaje preguntando si deseamos instalar el paquete, nótese que indica sobre cual red virtual de Azure lo hará.

Al hacer clic en sí se instalará la respectiva conexión, si abrimos las conexiones de red, veremos la recién creada VNet1

Hacemos clic en Conectar

Saldrá una ventana donde debemos hacer clic en Conectar (Por alguna extraña razón es la misma ventana de siempre, aún dice Windows Azure)

Al hacer clic en el botón Conectar se establecerá el túnel VPN hacia la red virtual de Azure.

Si hacemos un ipconfig /all veremos la dirección IP del segmento que definimos

En la configuración de punto a sitio desde el portal también podemos ver las direcciones IP asignadas:

Ahora voy a ejecutar un ping desde mi máquina local a un servidor en Azure con dirección IP 192.168.1.4

Incluso, puedo ingresar a través de la red mediante una ruta UNC

Bien, esto es todo por ahora, como siempre espero les sea de utilidad.

Bibliografía:

https://docs.microsoft.com/es-es/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal

https://docs.microsoft.com/es-es/azure/vpn-gateway/vpn-gateway-certificates-point-to-site

Error al asignar licencia de O365 desde PowerShell

Probablemente en algún momento necesites asignar licencias de Office 365 a los usuarios de un tenant en particular, si se trata de un número considerable y tal vez sean diferentes tipos de licencias, hacerlo desde el portal no resultará muy cómodo, en estos casos lo que normalmente hacemos es recurrir a Windows PowerShell, donde tal vez se encuentren con un error como el siguiente:

Set-MsolUserLicense : You must provide a required property: Parameter name: UsageLocation

Bien, este error en resumen lo que trata de decirnos es que para poder asignar una licencia de O365 el usuario debe tener establecida una ubicación geográfica, el porqué lo voy a citar directamente del documento en Technet que habla sobre este particular.

"De una manera un poco indirecta, este mensaje de error indica que el usuario en cuestión no tiene asignada la propiedad UsageLocation. Como habrá adivinado, la propiedad UsageLocation (que indica la región o el país en el que el usuario suele usar Office 365) es extremadamente importante. ¿Por qué? Porque los servicios disponibles para un usuario dependen no solo del paquete de licencias que haya adquirido, sino también del lugar en el que vive el usuario: debido a reglas y normativas locales, algunos servicios tal vez no estén disponibles para algunos usuarios. Si un usuario no tiene UsageLocation, Office 365 no tiene manera de saber qué servicios pueden exponerse legalmente a dicho usuario. Por lo tanto, Office 365 no puede ofrecer servicios a dicho usuario, al menos no hasta que se haya especificado la propiedad UsageLocation."

Si deseamos consultar el valor de la propiedad UsageLocation debemos utilizar la siguiente instrucción:

Get-MsolUser -UserPrincipalName usuario@dominio | Select-Object UsageLocation 

Como podemos apreciar en la imagen anterior, bajo la propiedad UsageLocation no tenemos nada configurado

Dado lo anterior, lo que debemos hacer es establecer la propiedad UsageLocation como se muestra a continuación:

Set-MsolUser -UserPrincipalName usuario@dominio -UsageLocation 'PE'

Lo que debemos especificar es el código de la región de dos letras, por ejemplo: CO (Colombia), FR (Francia), PE (Perú), etc. Se trata del ISO 3166-1 alpha-2 (A2)

En mi caso establecí la ubicación para usuarios ubicados en Perú, como se muestra en la siguiente imagen:

 Después de establecer la ubicación, si volvemos a consultar la propiedad UsageLocation veremos el nuevo valor.

Bien, después de que los usuarios ya tengan establecida la ubicación, la asignación de licencias se realizará de forma correcta.

Bien, y esto es todo, espero les sea de utilidad.

Error al abrir Synchronization Service Manager - Azure AD Connect

Probablemente después de instalar Azure AD Connect e intente abrir la consola Synchronization Service Manager se encuentre con el siguiente mensaje de error:

Unable to connect to the Synchronization Service
Some possible reasons are:
1) The service is not started
2) Your account is not a member of a required security group.
See the Synchronization Service documentation for details.

Se trata de algo bastante simple de resolver, resulta que después de la instalación de Azure AD Connect, se crean unos grupos locales especiales, uno de ellos es ADSyncAdmins y se necesita ser miembro der este grupo para poder abrir la consola, sin embargo, si revisas el usuario con el que se hizo la instalación ya hace parte del grupo.

Pero Windows actualiza el Token con la pertenencia a grupos durante el inicio de sesión, por lo cual lo único que debemos hacer para que Windows sepa que el usuario pertenece a este nuevo grupo es cerrar y abrir sesión.

Después de esto, la consola abrirá sin problema alguno.

Espero resulte de utilidad!

MVA: Azure Active Directory desde cero

En esta ocasión escribo para compartirles que he creado mi primer curso para MVA, la academia virtual de Microsoft, el curso se llama Azure Active Directory desde cero, consta de 4 módulos donde hago una introducción breve a este servicio que hace parte de Microsoft Azure, la verdad no es para nada sencillo hacer este tipo de contenido, para mi no es fácil estar frente a una cámara, sin embargo hice el mejor esfuerzo, espero para los futuros cursos no estar tan nervioso. Por ahora dejo el vídeo del primer módulo y el enlace al sitio de MVA para el curso completo. Muchas gracias y por favor no olviden darme su feedback ya que es muy importante para tenerlo en cuenta en las próximas grabaciones.

Enlace al curso completo en MVA: Azure Active Directory desde cero

Video: Developing in a cloud world

Hola a todos, en esta ocasión deseo compartirles una serie de vídeos sobre la reciente iniciativa de Microsoft Latinoamérica llamada Developing in a cloud world, que básicamente se trata de una serie de vídeos donde se ensañan tecnologías y técnicas para desarrollar aplicaciones en la era cloud. En esta ocasión Microsoft me ha invitado para hablar sobre técnicas para crear infraestructura para aplicaciones utilizando técnicas de desarrollo, y que mejor ejemplo que ARM (Azure Resource Manager), así que no se pierdan mis vídeos junto con los de otros MVPs donde se habla de diversos temas relacionados con el desarrollo de aplicaciones para la nube. A continuación dejo el primero de mis 4 vídeos, así como el enlace a cada uno de los vídeos de la iniciativa.

Lista de vídeos Developing in a Cloud World:

1. Introducción a Cognitive Services - Computer Vision (Matias Quaranta)
2. Introducción a Cognitive Services - Text Analytics (Matias Quaranta)
3. Introducción a Cognitive Services - LUIS (Matias Quaranta)
4. IaaS sin Dolor: Creación de máquinas virtuales con ARM (César Herrada)
5. IaaS sin Dolor: Creación de Infraestructura con ARM (César Herrada)
6. IaaS sin Dolor: Creación de plantillas ARM desde Visual Studio y en Github (César Herrada)
7. IaaS sin Dolor: Despliegue de plantillas ARM desde Linux utilizando CLI (César Herrada)
8. Azure DevTest Labs y Visual Studio Team Services (Edinson Carreño)
9. DocumentDB - La Flexibilidad en los Datos (Miguel Quintero)
10. Azure IoT Hub (Luis Valencia)
11. Introduccion a Events Hub (Luis Valencia)

Muchas gracias por la atención y espero puedan ver todos los vídeos y darnos su opinión.

Un saludo!

MVP de Microsoft 2017

Bueno, que mejor manera de iniciar el año que recibiendo la noticia de haber sido reconocido como Microsoft MVP por tercer año consecutivo en la categoría Enterprise Mobility, mil gracias a Microsoft, a la comunidad de profesionales ITPros-DC y a todos los profesionales que hacen parte de la misma, pues sin ellos este premio no sería posible. Este 2017 será un año de grandes retos personales y profesionales, así que iniciaré con toda la energía a seguir haciendo lo que más me gusta, compartir el conocimiento!. A continuación una imagen del correo recibido por parte del programa MVP esta mañana.

Bien eso es todo. Un feliz 2017 para todos!

Eliminar grupos en Azure AD de forma masiva

Hola a todos, en este artículo vamos a ver cómo borrar grupos en Azure Active Directory de forma masiva, he decido escribir este post debido a que en una sincronización de identidades desde Active Directory local hacia Azure AD todos los grupos locales fueron sincronizados, lo cual era algo que no deseaba en principio, adicionalmente que se trataba de una gran cantidad de grupos como veremos más adelante. A continuación una imagen de los grupos vistos desde el portal clásico de Azure (nótese que hasta el grupo domain admins se encuentra allí)

Bien, para solucionar esto y no tener que eliminar los grupos uno por uno, vamos a recurrir a nuestro amigo PowerShell. Si no tienes el módulo de PowerShell para Azure Active Directory te recomiendo ver el siguiente vídeo dónde explico cómo hacerlo: Channel 9 - PowerShell para Azure AD. Una vez cargado el módulo de PowerShell nos conectamos a los servicios en línea de Microsoft usando el cmdlet 

Connect-Msolservice

Ahora ya podemos explorar objetos tales como usuarios, grupos y contactos. En este caso vamos a consultar por todos los grupos de seguridad existentes usando el siguiente cmdlet:

Get-MsolGroup -GroupType "Security"

Como lo indica la instrucción traerá todos los grupos de seguridad

Si cuento los grupos usando el siguiente cmdlet: (Get-MsolGroup -GroupType Security).count

Podemos ver que se trata de bastantes: 281 para ser más exactos.

Mi intención es borrar todos estos grupos, pero probablemente la suya no lo sea, es decir pueden existir ciertos grupos que deseemos conservar, por ejemplo los grupos de los servicios de sincronización o algún otro dependiendo de cada necesidad, si queremos hacerlo no queda más remedio que hacer las respectivas excepciones utilizando operadores para el manejo de cadenas en PowerShell. Por ejemplo veamos como es el caso donde queramos conservar los grupos que se crean para la sincronización.

En la siguiente imagen se puede apreciar que dichos grupos inician con la palabra ADSync

Con lo cual en el "where" podemos utilizar comodines para lograr nuestro propósito, y la instrucción quedaría dela siguiente forma:

Get-MsolGroup -GroupType “Security” | Where-Object {$_.DisplayName -NotLike “ADSync*”}

Nos arrojará todos los grupos de seguridad que su nombre no empiece por ADSync (-NotLike “ADSync*”)

Bien ahora que ya tenemos listados los grupos a eliminar, solo nos hace falta pasar el cmdlet que hace la tarea: Remove-MsolGroup

Con esto, la instrucción final queda  de la siguiente manera:

Get-MsolGroup -GroupType “Security” | Where-Object {$_.DisplayName -NotLike “ADSync*”} | Remove-MsolGroup -Force

Después de ejecutar lo anterior, podemos usar la siguiente instrucción para consultar todos los grupos existentes: Get-MsolGroup -All

Allí podemos ver que hay muchos grupos ADSync, pues se trata de diversas integraciones con directorios que he realizado en mi tenant, si se dan cuenta hay nombres de grupos repetidos, los cuales son diferenciados por el objectId

Pero si lo que queremos es borrar todos los grupos, en mi caso incluyendo los de sincronización de directorios, basta con ejecutar los siguiente: Get-MsolGroup -All | Remove-MsolGroup -Force

Después de hacerlo, volvemos a listar todos los grupos y como se puede ver ya no aparece ninguno, hemos borrado absolutamente todos los grupos.

Y si vamos al portal de Azure nos encontramos con lo siguiente:

Bien, como dato adicional les dejo algunos comandos útiles para Office 365:

Remover todos los usuarios sin licencia:

Get-MsolUser -All -UnlicensedUsersOnly | Remove-MsolUser -Force

Remover todos los contactos:

Get-MsolContact -All | Remove-MsolContact -Force

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

Grupo de estudio: Active Directory virtual

Este trimestre, en la comunidad ITPros-DC lanzamos nuestro primer grupo de estudio virtual, la oportunidad fue para Active Directory. La primer sesión se llevó a cabo el pasado jueves 1 de septiembre, este grupo a diferencia de los presenciales se lleva a cabo entre semana, los grupos de estudio presenciales si continúan los sábados.

Se ha creado un Meetup donde todos mantendremos al tanto del desarrollo del grupo . Las sesiones están siendo llevadas a cabo gracias a la tecnología de Citrix GoToTraining

Durante esta primera sesión vimos los siguientes temas:

Fundamentos de Active Directory (base de datos, Dominios, árboles, bosques, GC)
Instalación y puesta en marcha de un controlador de dominio.

Bien, la cita es el próximo jueves a las 8:00 pm. Los espero!

Microsoft Cloud Summit Exito total!

El pasado Jueves 25 de Agosto se llevó a cabo en Bogotá el evento Microsoft más importante del año Microsoft Cloud Summit.

Sin lugar a dudas un evento al mejor estilo de Microsoft donde los asistentes vieron las grandes ventajas que la nube de Microsoft nos ofrece. Muchas gracias a los que asistieron a este evento y un saludo todavía más especial para los que asistieron a mi charla :-) A continuación algunas imágenes del evento.