Cerrar

Ya hace unos meses que se había puesto en versión preliminar la opción de configurar NAT en nuestras subredes IP de las vNet de Azure, algo que, nos viene muy bien. Como sabéis, cada máquina virtual tiene un salida a Internet mostrando una dirección IP Pública Dinámica, por lo que si tenemos 10 servidores o 100 en nuestra vNet pues tendremos a cada servidor con una IP Pública diferente y cambiante en cada reinicio de cada servidor.

En cualquier red On-Premises tenemos un Router/Firewall configurado con NAT, de tal forma que podemos compartir la IP Pública que tenemos en Internet con todos los equipos de nuestra red. Esto nos viene perfecto si tenemos otro servicios a los que queremos conectarnos y lo queremos filtrar por IP o bien tenemos una aplicación que realiza envíos de correos pero no podemos utilizar la autenticación. En este caso en concreto nos viene perfecto el tener una IP Pública fija y compartida para un grupo de equipos, puesto que, como indicaba, si tenemos un servicios de envío de correo pues nos será más sencillo realizar las diferentes configuraciones …

Hoy quería comentaros un pequeño TIP de seguridad sobre el cual llevo semanas intentando escribir, básicamente es para ayudar al usuario final a identificar en donde puede que iniciar sesión con seguridad. Seguro que todos hemos recibido múltiples correos indicando que alguien ha compartido documentación

Muchos de vosotros seguro que conocéis que es DirectAccess, algo que, MSFT ha reemplazado por otra tecnología: Always On VPN. En su momento, había publicado varios artículos sobre DirectAccess, un servicio que, a mi, siempre me ha encantado:

Pues bien, ahora el siguiente paso/fase de migración sería implementar Always ON VPN, pero… vamos a hacerlo ya en Azure con Azure Gateway VPN (P2S) puesto que el ROL de RRAS en modo IaaS en Azure no está soportado: Microsoft server software support for Microsoft Azure virtual machines:

“Básicamente” Always On VPN una conexión permanente de acceso remoto (finalidad igual a DirectAccess pero un modo de conexión diferente) en el cual los usuarios “no tienen intervención alguna”, básicamente cuando el equipo tiene acceso a Internet automáticamente se conecta. Entre los requisitos básicos a nivel de los clientes remotos es que tengan Windows 10 Enterprise, algo que, en muchas ocasiones los clientes no quieren adquirir y únicamente tienen versiones Pro de Windows 10

Después de iniciar en el anterior artículo una serie de artículos sobre VDI (Microsoft Azure: Windows Virtual Desktop + Acceso Condicional + Teams), hoy me gustaría comentaros como realizar una serie de configuraciones “básicas” iniciales para casi cualquier entorno de red. En este caso, voy a centrar las diferentes configuraciones en un despliegue de VDI en un entorno de ADDS con Azure AD Connect y el servicio de Azure Files basada en la identidad a través de SMB (Bloque de mensajes del servidor) con Active Directory. Azure Files es un excelente servicio para migrar nuestros File Server y dejar así de tener que administrar servidores, pasando a consumir un servidor de ficheros como servicio pero sin perder el control de accesos con los grupos de nuestro ADDS …

Archivos
  • 2020 (21)
  • 2019 (55)
  • 2018 (47)
  • 2017 (47)
  • 2016 (24)
  • 2015 (107)
  • 2014 (139)
  • 2013 (311)
  • 2012 (353)

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies