En este post vamos a ver como configurar un servidor SMTP en FortiAuthenticator para poder enviar correos electrónicos desde esta máquina, lo usaremos para todas las configuraciones que necesitemos, sobre todo, para poder enviar los tokens para el segundo factor de autenticación, vamos a configurar el SMTP Server de IONOS, si tenemos nuestro propio servidor SMTP los pasos a configurar son los mismos.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Antes de empezar con las configuraciones del servidor SMTP de IONOS, vamos a obtener el certificado emisor CA en un archivo .crt independiente, para ello, nos hemos creado este script en PowerShell, desde aquí lo podemos descargar:

• Ejecutamos el script en PowerShell, powershell -ExecutionPolicy Bypass -File «$env:USERPROFILE\Desktop\extraer.ps1» y debe mostrar el mensaje en verde, indicando que se creó IONOS_CA_Single.crt en el Escritorio:

• Ahora convertimos a Base64 usando Windows, para ello, hacemos doble clic sobre el archivo IONOS_CA_Single.crt del Escritorio, y en la ventana que se abre, vamos a la pestaña Detalles y hacemos clic en Copiar en archivo…:

• Pulsamos Siguiente, y seleccionamos X.509 codificado en base 64 (.CER), Siguiente:

• Lo guardamos en el escritorio como CA_Base64.cer y pulsamos Finalizar:

• Aquí tenemos el certificado que vamos a importar en nuestro FortiAuthenticator:

• Ahora acedemos a nuestro FortiAuthenticator y sobre Certificate Management > Certificate Authorities > Trusted CAs > Import, vamos a importar el certificado que creamos anteriormente:

• Y aquí vemos el certificado de IONOS activo y disponible:

• Ahora accedemos a System > Messaging > SMTP Servers > Create New:

• Configuramos el servidor SMTP con estos parámetros, Save:

• Como podemos ver, aquí lo tenemos ya configurado, realizamos un prueba de conexión para verificar que funciona correctamente:

• Aquí vemos el correo de prueba que nos ha llegado:

• Para terminar, sobre System > Messaging > Email Services, configuramos a los administradores y usuarios para que utilicen el servidor SMTP que hemos configurado, Save:

Saludos y espero que os resulte de ayuda

La entrada Configuración SMTP Server IONOS en FortiAuthenticator se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver la instalación y configuración inicial de FortiAuthenticator, realizaremos el despliegue y la instalación sobre una máquina virtual en VMware vSphere, a través de un OVF descargado de la web de soporte de Fortinet, una vez instalado veremos las configuraciones iniciales y a partir de ese momento realizaremos las configuraciones avanzadas a través del portal web de FortiAuthenticator.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Este es el OVF que vamos a desplegar:

• Comenzamos con el despliegue de la máquina en nuestro vCenter, para ello, damos a Implementar plantilla de OVF:

• Sobre Seleccione una plantilla de archivo OVF, le indicamos los tres archivos que vamos a utilizar para el despliegue de la máquina del FortiAuthenticator, Siguiente:

• Sobre Seleccionar un nombre y una carpeta, le indicamos el nombre de la máquina virtual, Siguiente:

• En Seleccionar un recurso informático, seleccionamos el clúster ya que tenemos un HA con DRS desplegado, Siguiente:

• En Revisar detalles, nos muestra un resumen y damos a Siguiente:

• En Contratos de licencia, aceptamos el EULA, Siguiente:

• Sobre Seleccionar almacenamiento, le indicamos el datastore donde vamos a desplegar la máquina con formato Thin Provision, Siguiente:

• En Seleccionar redes, le indicamos la red o redes que vamos a utilizar, Siguiente:

• En Listo para completar, nos muestra un resumen de todas las configuraciones del despliegue, Finalizar:

• Como podemos ver, ya tenemos la máquina de FortiAuthenticator desplegada, procedemos a iniciarla:

• Una vez iniciada, accedemos a la CLI y las credenciales por defecto son admin y el password en blanco, nos va a pedir introducir un password:

• Ahora le asignamos la configuración IP a la interface del puerto 1, ejecutando:

config system interface

edit port1

set ip 192.168.14.28/24

set allowaccess https-gui ssh

next

end

config router static

edit 0

set device port1

set dst 0.0.0.0/0

set gateway 192.168.14.210

next

end

config system dns

set primary 192.168.14.1

set secondary 192.168.14.2

end

• Aquí podemos ver la configuración realizada:

• Ahora accedemos a nuestro FortiAuthenticator por la interface web:

• Sobre Dashboard > Status, configuramos un nuevo nombre de host y la hora del sistema:

• Aquí vemos que ya lo tenemos configurado:

• Sobre Network > Interfaces, podemos ver la configuración que realizamos anteriormente por la CLI:

• Y habilitamos los servicios que nos interesen:

• Sobre Network > DNS, podemos ver la configuración que realizamos anteriormente por la CLI:

• También para Network > Static Routing:

• Para terminar con las configuraciones básicas, accedemos a Authentication > User Management > Local Users > Create New, para crear un nuevo usuario administrador y deshabilitaremos la cuenta que trae por defecto:

• Aquí tenemos el nuevo usuario creado:

• Iniciamos sesión con este nuevo usuario:

• Sobre Authentication > User Management > Local Users > admin > Edit, deshabilitamos el usuario que trae por defecto:

• Como podemos ver, ya lo tenemos deshabilitado:

• Para terminar con las configuraciones básicas, vamos a crearnos en nuestro DNS un registro tipo A apuntando a la IP del FortiAuthenticator, así ya podremos acceder vía web por el FQDN:

• Sobre Administration > System Access > GUI Access > Additional allowed hosts/domain names, debemos añadir el nombre FQDN de nuestro FortiAuthenticator, Save:

• Accedemos ahora por el FQDN:

Saludos y espero que os sea de ayuda

La entrada Instalación y Configuración inicial de FortiAuthenticator se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar, instalar y configurar FortiAuthenticator, realizaremos las configuraciones con un Active Directory y sincronizaremos nuestros usuarios y grupos con el FortiAuthenticator, configuraremos el cliente RADIUS y las políticas en el FortiAuthenticator, y en nuestro Fortigate configuraremos el servidor RADIUS, haremos el matching de los grupos, y desplegaremos una VPN IPSEC IKEv2 de acceso remoto para conectarnos con nuestros usuarios del dominio, también crearemos algunas políticas en el firewall para verificar las configuraciones y los accesos.

FortiAuthenticator es una plataforma centralizada de gestión de identidad y accesos (IAM) desarrollada por Fortinet, actúa como el núcleo de seguridad para verificar la identidad de los usuarios y dispositivos antes de permitirles el acceso a la red, aplicaciones o servicios corporativos.

Funciones principales:

• Autenticación de Doble Factor (2FA / MFA), gestiona y distribuye tokens de seguridad (físicos, por software como FortiToken, SMS o correo) para añadir una capa adicional de protección al inicio de sesión.
• Servidor RADIUS y TACACS+, autentica a usuarios que se conectan a través de VPNs, redes WiFi empresariales, switches y dispositivos de red.
• Portal Cautivo y Gestión de Invitados, proporciona portales web para la autenticación de usuarios temporales o visitantes, permitiendo el autorregistro o la aprobación por parte de patrocinadores.
• Single Sign-On (FSSO), facilita el inicio de sesión único integrándose con Active Directory, LDAP o proveedores de identidad SAML/OAuth, permitiendo que el cortafuegos (FortiGate) reconozca automáticamente qué usuario está tras cada dirección IP.
• Gestión de Certificados (PKI), funciona como una autoridad de certificación (CA) para emitir, gestionar y revocar certificados digitales para dispositivos y usuarios (útil para autenticación 802.1X).

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

Este post lo vamos a dividir en:

• Instalación y configuración inicial FortiAuthenticator.
• Configuración SMTP Server IONOS en FortiAuthenticator.
• Configuración conexión LDAP en FortiAuthenticator.
• Creación de grupos de usuarios Remote LDAP en FortiAuthenticator.
• Configuraciones RADIUS en FortiAuthenticator y Fortigate.
• Configuración VPN IPsec IKEv2 de acceso remoto con usuarios de Active Directory.

Saludos y espero que os resulte de ayuda

La entrada Despliegue, Instalación y Configuración de FortiAuthenticator se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como configurar FortiSwitches con la interface dedicada FortiLink en un firewall Fortigate, para hacer este post vamos a utilizar un Fortigate 60E y dos FortiSwitches 148F, la topología es muy sencilla, uno de los Fortiswitch 148F irá conectado por dos cables al firewall Fortigate 60E, por lo que tendremos un enlace redundante entre el firewall y este switch Core, el siguiente switch que será un switch de acceso, irá conectado al switch core también con dos cables, teniendo redundancia en este enlace, como no dispongo de más dispositivos, va a ser algo muy sencillito, si alguien de Fortinet lee este post y me quisiera prestar dos Fortiswitch de la gama 2XX o 4XX podríamos ver algo más profesional, haciendo un MC-LAG ICL (Multi-Chassis Link Aggregation Group Inter-Chassis Link),  entre los dos switches cores, consiguiendo que ambos se viesen como un solo switch, luego con un Fortigate60E más configuraríamos HA entre los dos firewalls.

• Para empezar, accedemos a nuestro firewall Fortigate 60E y sobre System > Feature Visibility habilitamos Switch Controller, habilitando esta característica podremos utilizar la unidad FortiGate para gestionar los FortiSwitches, añadiendo conmutadores virtuales y configurando las VLAN y los puertos de los FortiSwitches, podremos crear políticas de seguridad para implementar la autenticación 802.1X de los usuarios y crear políticas de control de acceso a la red para configurar automáticamente los dispositivos y los usuarios conectados a los FortiSwitches:

• Una vez habilitada la característica, accedemos a Wifi & Switch Controller > FortiLink Interface y nos creamos nuestra interface para FortiLink, en muchos modelos de Fortigate esta interface ya viene creada por defecto, en el Fortigate 60E la he tenido que crear, dónde hemos configurado un Nombre con su Alias, las Interfaces miembros del enlace, una dirección IP con su máscara, importante NO habilitar FortiLink split interface (solo habilitar en caso de que conectemos más de un switch al enlace o interface de FortiLink), habilitamos y configuramos un Servidor DHCP, muy importante habilitarlo ya que este servidor DHCP se va a encargar de asignar el direccionamiento IP a los distintos switches que vayamos conectando, le añadimos un comentario a modo de información:

• Ahora sobre Network > Interfaces > FortiLink, hemos configurado las distintas VLANs que vamos a utilizar en nuestros FortiSwitches:

• Así hemos configurado todas las VLANs de la interface fortilink:

• Ahora vamos a añadir el primer FortiSwitch 148F a nuestra infraestructura, para ello, conectamos los puertos 1 y 2 del Fortigate 60E, a los puertos 1 y 2 del FortiSwitch 148F, e iniciamos el FortiSwitch (tal y como viene de fábrica) conectándolo a corriente (AC), accedemos a Wifi & Switch Controller > Managed FortiSwitches y vemos que ya aparece el FortiSwitch 148F, los seleccionamos y lo autorizamos:

• Una vez autorizado, pasados unos minutos, vemos que ya lo tenemos Online y que le ha asignado una dirección IP desde el servidor DHCP que configuramos en la interface de FortiLink:

• Lo seleccionamos y editamos para cambiarle el nombre:

• Como podemos ver, ya le ha cambiado el nombre:

• Ahora sobre Wifi & Switch Controller > FortiSwitch Ports > Ports configuramos los puertos de nuestro FortiSwitch Core, en este caso, a los puertos 1 y 2 sólo le hemos añadido una Descripción, al puerto 10 le hemos asignado una VLAN en la Native VLAN, y en Allowed VLANs le hemos permitido todas las VLANs que hemos creado, ya que en este puerto vamos a conectar otro Switch de HP, concretamente un HP-1810-8G, en los puertos 47 y 48 solo le vamos a añadir una Descripción, ya que en estos puertos vamos a conectar nuestro FortiSwitch de acceso:

• Ahora vamos a añadir el segundo FortiSwitch 148F a nuestra infraestructura, para ello, conectamos los puertos 47 y 48 del sw-core1, a los puertos 47 y 48 del segundo FortiSwitch 148F, e iniciamos el FortiSwitch (tal y como viene de fábrica) conectándolo a corriente (AC), accedemos a Wifi & Switch Controller > Managed FortiSwitches y vemos que ya aparece el FortiSwitch 148F, los seleccionamos y lo autorizamos:

• Una vez autorizado, pasados unos minutos, vemos que ya lo tenemos Online y que le ha asignado una dirección IP desde el servidor DHCP que configuramos en la interface de FortiLink:

• Lo seleccionamos y editamos para cambiarle el nombre:

• Como podemos ver, ya le ha cambiado el nombre:

• Ahora sobre Wifi & Switch Controller > FortiSwitch Ports > Ports configuramos los puertos de este FortiSwitch de acceso, en este caso, a los puertos del 1 al 7 los hemos asignado cada uno a una VLAN, y en los puertos 47 y 48 solo le vamos a añadir una Descripción, ya que estos puertos los hemos utilizado para conectar nuestro FortiSwitch Core:

• Si accedemos a Wifi & Switch Controller > Managed FortiSwitches > List > Topology podemos ver la topología que hemos desplegado:

Saludos y espero que os sea de ayuda

La entrada Configuración FortiSwitches con interface dedicada FortiLink en un Fortigate se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como generar un certificado para SSL/SSH Inspection en un firewall Fortigate y firmarlo con nuestra entidad certificadora CA de Active Dircetory.

• Accedemos a nuestro servidor CA de Active Directory y ejecutamos certsrv.msc para crear una nueva plantilla de Entidad de certificación subordinada, ragasys-ADCS-CA > Plantillas de certificado > Administrar:

• Sobre Entidad de certificación subordinada damos a Plantilla duplicada:

• Sobre General, le indicamos un nombre y el periodo de validez, Aceptar:

• Como vemos, aquí la tenemos creada:

• Volvemos a la consola certsrv.msc y sobre Plantillas de certificado > Nuevo > Plantilla de certificado que se va a emitir:

• Seleccionamos la plantilla que habíamos creado y Aceptar:

• Como podemos ver, ya tenemos la plantilla operativa:

• Ahora vamos a generar el CSR desde nuestro Fortigate, System > Certificates > Generate:

• Le indicamos los datos necesarios y damos a OK:

• Como vemos, se nos queda la solicitud pendiente, damos a Descargar:

• Aquí tenemos el CSR descargado:

• Sobre nuestra CA solicitamos un certificado, solicitud avanzada de certificado:

• Copiamos el contenido del CSR, seleccionamos la plantilla que creamos anteriormente y damos a Enviar:

• Descargamos el certificado y la cadena de certificado (aunque la cadena no nos hará falta), codificado en Base64:

• Nos descargamos también el certificado de la CA en Base 64:

• Ahora sobre nuestro Fortigate, vamos a System > Certificates seleccionamos la solicitud pendiente y seleccionamos Import > Local Certificate:

• Subimos el certificado firmado por nuestra CA de Active Directory:

• Como podemos ver, aquí tenemos el certificado operativo firmado por nuestra CA y listo para usar con los perfiles de SSL/SSH Inspection:

• También debemos importar el certificado de nuestra CA de Active Directory, que nos descargamos anteriormente:

• Como podemos ver, aquí tenemos el certificado de nuestra CA de Active Directory:

• Ahora si accedemos a Security Profiles > SSL/SSH Inspection y seleccionamos cualquiera de nuestros perfiles para editar, vemos que ya podemos utilizar el certificado firmado por nuestra propia CA:

Saludos y espero que os resulte de ayuda

La entrada Fortigate – Generar certificado para SSL/SSH Inspection y firmarlo con CA de Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como configurar SSL/SSH Inspection en un firewall Fortigate.

• Los firewalls Fortigate pueden inspeccionar las conexiones SSL de dos formas diferentes:
• Certificate Inspection:
• Este modo sólo inspecciona la información de las cabeceras de los paquetes.
• Certificate inspection se usa para verificar la identidad de un servidor web.
• El único perfil de seguridad que podemos usar en este modo es Web Filter.
• Este método no introduce errores de certificados durante la navegación.
• No podemos inspeccionar los datos encriptados que pasan por el firewall.

• Full SSL Inspection o Deep Inspection:
• El Fortigate actúa como una CA, genera certificados, llaves privadas y actúa como web proxy.
• La CA puede ser auto firmada o emitida por alguna CA interna de la empresa.
• El certificado raíz de la CA debe ser importado en las computadoras clientes.
• Este modo de inspección nos permite desencriptar el contenido de las conexiones.
• Con el contenido desencriptado podemos inspeccionar los paquetes para aplicar poíticas.
• Podemos identificar aplicaciones o incluso virus dentro de las conexiones SSL.

Fuente: Curso Fortinet: De principiante a Experto de Eduardo Nazareno Anselmi

• Para empezar, sobre System > Feature Visibility tenemos que habilitar Certificates y Multiple Security Profiles:

• Sobre System > Certificates vemos que Fortinet nos proporciona esta entidad certificadora Fortinet_CA_SSL que utilizaremos en los distintos perfiles de SSL:

• Ahora sobre Security Profiles > SSL/SSH Inspection, vemos los distintos perfiles que nos vienen por defecto:

• Vamos a clonar el certificate-inspection y lo llamaremos certificate-inspection-rgs:

• Esta es la configuración, que como vemos, utiliza como CA certificate un certificado autofirmado que nos proporciona el propio firewall Fortinet_CA_SSL:

• Ahora, sobre una de nuestras reglas de salida a Internet, que la tenemos configurada como Proxy-based, ya que tenemos configurado, un web proxy transparente aplicamos el perfil de SSL Inspection certificate-inspection-rgs:

• Con esto tendríamos configurado esta primera parte de Certificate Inspection, ahora vamos a configurar Full SSL Inspection o Deep Inspection, para ello accedemos Security Profiles > SSL/SSH Inspection y clonamos el custom-deep-inspection a este nuevo perfil lo llamaremos deep-inspection-rgs:

• Esta es la configuración, que como vemos, utiliza como CA certificate un certificado autofirmado que nos proporciona el propio firewall Fortinet_CA_SSL, el cuál nos vamos a descargar, ya que este certificado raíz de la CA debe ser importado en las computadoras clientes, vemos que la configuración es mucho más completa que la anterior ya que aquí se si se va a realizar una inspección completa de los paquetes que pasen por el firewall, vemos también que hay excepciones para inspeccionar un determinado tipo de tráfico que sabemos que es legítimo:

• Aquí vemos que nos hemos descargado el certificado raíz de la CA y que importaremos en las máquinas clientes:

• Ahora, sobre una de nuestras reglas de salida a Internet, que la tenemos configurada como Proxy-based, ya que tenemos configurado, un web proxy transparente aplicamos el perfil de SSL Inspection deep-inspection-rgs:

• Ahora, si nos abrimos cualquier página web que no esté en las excepciones, nos va a indicar que no es posible abrirla, ya que las máquinas clientes necesitan tener importado el certificado raíz de la CA:

• Para importarlo nos abrimos en la máquina cliente una consola mmc:

• Sobre Archivo damos a Agregar o quitar complemento:

• Certificados y Agregar:

• Cuenta de equipo:

• Equipo local, finalizamos y aceptamos:

• Ahora accedemos a Certificados > Entidades de certificación raíz de confianza > Certificados > Importar:

• Se nos abre este asistente para importar el certificado raíz de la CA de Fortinet que nos hemos descargado antes:

• Aquí vemos el certificado importado:

• Ahora si accedemos a la misma web que nos la estaba restringiendo anteriormente, vemos que ya tenemos acceso, ya que la inspección se está haciendo correctamente:

• Como hemos visto, el certificado lo hemos importado de manera manual en la máquina cliente, para no tener que hacer esto en todos los equipos de nuestra infraestructura, nos hemos creado esta GPO en nuestro Active Directory, en la Administración de directivas de grupo:

• Esta GPO la vinculamos sobre la Unidades Organizativas que nos interesen:

• Si accedemos desde cualquiera de nuestros equipos al que le hemos aplicado la GPO, vemos que ya tenemos acceso, ya que la inspección se está realizando correctamente:

Saludos y espero que os sea de ayuda

La entrada Fortigate – SSL/SSH Inspection se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam ONE 13.1.0.7034 a la nueva versión 13.1.0.7233 liberada por Veeam hace algunos días, corrige estas vulnerabilidades.

• Como podemos ver aquí, tenemos descargada la v13.1.0.7233 de Veeam ONE:

• Vemos que la versión que tenemos instalada es la 13.1.0.7034:

• Nos montamos la imagen ISO, y ejecutamos el setup para proceder con la instalación del upgrade a la v13.1.0.7233:

• Ejecutamos el Update:

• Seleccionamos Update Veeam ONE:

• Aceptamos el EULA:

• Nos indica que ha detectado una versión previa de Veeam ONE, y que va a actualizar a ésta última, clic sobre Next para proceder con el update:

• Procedemos a Instalar:

• Comienza con la actualización:

• Como podemos ver la actualización a v13.1.0.7233, ha finalizado correctamente:

• Una vez finalizada la instalación, podemos ver, que ya tenemos instalada la última versión de Veeam ONE v13.1.0.7233:

Saludos y espero que os resulte de ayuda

La entrada Actualizar Veeam ONE 13.1.0.7034 a la nueva versión 13.1.0.7233 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam Backup & Replication 13.1.0.411 a la nueva versión 13.1.1.18, en este link podemos ver las nuevas características de esta versión.

• Como podemos ver, la versión de nuestro Veeam Backup & Replication es la v13.1.0.411:

• Desde aquí nos descargamos la ISO, versión 13.1.1.18 para sistemas Microsoft Windows:

• Aquí tenemos ya, la nueva ISO v13.1.1.18 para Microsoft Windows descargada:

• Montamos la ISO y ejecutamos el setup:

• Comienza la actualización, Modify:

• Seleccionamos Modify Veeam Backup & Replication:

• Aceptamos el EULA:

• Nos indica todos los componentes que van a ser actualizados, Upgrade:

• Comienza con la actualización:

• Como podemos ver, la actualización a v13.1.1.18, ha finalizado correctamente:

Saludos y espero que os sea de ayuda

La entrada Actualizar Veeam Backup & Replication v13.1.0.411 a v13.1.1.18 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam ONE 13.0.2.6723 a la nueva versión 13.1.0.7034 liberada por Veeam hace algunos días.

• Como podemos ver aquí, tenemos descargada la v13.1.0.7034 de Veeam ONE:

• Vemos que la versión que tenemos instalada es la 13.0.2.6723:

• Nos montamos la imagen ISO, y ejecutamos el setup para proceder con la instalación del upgrade a la 1.0.7034:

• Ejecutamos el Upgrade:

• Seleccionamos Upgrade Veeam ONE:

• Aceptamos el EULA:

• Nos indica que ha detectado una versión previa de Veeam ONE, y que va a actualizar a ésta última, clic sobre Next para proceder con el upgrade:

• Debemos especificar una cuenta para el servicio de Veeam ONE, esta cuenta la creamos y la configuramos en la primera instalación que hicimos de Veeam ONE, por lo que, en este caso, sólo debemos de introducir el password que configuramos en la instalación original:

• Comienza a verificar el sistema para identificar cualquier tipo de problema:

• Damos a Upgrade para proceder con la actualización:

• Comienza con la actualización:

• Como podemos ver la actualización a v13.1.0.7034, ha finalizado correctamente:

• Una vez finalizada la instalación, podemos ver, que ya tenemos instalada la última versión de Veeam ONE v13.1.0.7034:

Saludos y espero que os resulte de ayuda

La entrada Actualizar Veeam ONE 13.0.2.6723 a la nueva versión 13.1.0.7034 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam Backup & Replication v13.0.2.29 a la nueva versión 13.1.0.411, en este link podemos ver las nuevas características de esta versión.

• Como podemos ver, la versión de nuestro Veeam Backup & Replication es la v13.0.2.29:

• Desde aquí nos descargamos la ISO, versión 13.1.0.411 para sistemas Microsoft Windows:

• Aquí tenemos ya, la nueva ISO v13.1.0.2411 para Microsoft Windows descargada:

• Montamos la ISO y ejecutamos el setup:

• Comienza la actualización, Upgrade:

• Instalamos Microsoft .NET 10.0.10 Windows Server Hosting:

• Seleccionamos Upgrade Veeam Backup & Replication:

• Aceptamos el EULA:

• Marcamos los checks para actualizar la licencia y recibir soporte, Next:

• Comienza a chequear las configuraciones y si nos falta algún componente, lo irá instalando:

• Nos indica algunos avisos de compatibilidades, pero nada importante que nos impida actualizar:

• Nos indica todos los componentes que van a ser actualizados, Upgrade:

• Comienza con la actualización, aquí debemos de tener un poco de paciencia ya que el proceso es bastante lento:

• Como podemos ver, la actualización a v13.1.0.411, ha finalizado correctamente:

Saludos y espero que os sea de ayuda

La entrada Actualizar Veeam Backup & Replication v13.0.2.29 a v13.1.0.411 se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo actualizar un host ESXi versión VMware vSphere 8.0 Update 3j a la versión 8.0 Update 3k a través de ESXCLI, en este link os dejo toda la información.

• Como podemos ver, nuestros hosts ESXi está en la versión 8.0.3 build 25429389:

• Para empezar nos descargamos de la web de Broadcom WMware el patch para la instalación offline a través de la ESXCLI de ESXi 8.0 Update 3k build 25595708:

• Cargamos este archivo en un datastore de nuestro vCenter:

• Ponemos el host ESXi que queremos actualizar en modo mantenimiento:

• Accedemos por SSH al host ESXi que queremos actualizar:

• Ejecutamos el siguiente comando para listar los perfiles disponibles del parche descargado, esxcli software sources profile list -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3k-25595708-depot.zip:

• Para realizar el upgrade ejecutamos el comando esxcli software profile update -p ESXi-8.0U3k-25595708-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3k-25595708-depot.zip –no-hardware-warning una vez que ha finalizado, nos indica que debemos de reiniciar, * NOTA al final explicamos el comando hay temas a tener en cuenta:

• Una vez que el host ha iniciado, lo sacamos del modo mantenimiento:

• Como podemos ver, la actualización se ha realizado correctamente y ya tenemos el host ESXi en la versión 8.0 Update 3k Build 25595708:

• * NOTA a tener en cuenta esxcli software profile update -p ESXi-8.0U3k-25595708-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3k-25595708-depot.zip –no-hardware-warning
• ESXi-8.0U3k-25595708-standard nombre del perfil que contiene la versión y el número de compilación
• VMware-ESXi-8.0U3k-25595708-depot.zip archivo utilizado para la actualización de ESXi
• –no-hardware-warning esta parte es por si nos da un error de CPU, por si la CPU de nuestro equipo no es compatible con la nueva release para que ignore este error, en mi caso la CPU de mi equipo no es compatible 100% con esta nueva reléase por eso lo añado al comando, ya que es un entorno de laboratorio, en producción el comando a ejecutar sería esxcli software profile update -p ESXi-8.0U3k-25595708-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3k-25595708-depot.zip

• Para el segundo host realizamos las mismas operaciones para actualizarlo:

Saludos y espero que os sea de ayuda

La entrada Actualizar VMware vSphere ESXi 8.0 Update 3j a 8.0 Update 3k con ESXCLI se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar nuestro vCenter Server Appliance a la última release liberada por VMware, la 8.0 Update 3k build 25600417, del 29 de julio de 2026.

En este enlace os dejo la información sobre esta nueva actualización:

• VMware vCenter Server 8.0 Update 3i Release Notes
• Nos conectamos a la interfaz VAMI de nuestro VCSA a través del puerto 5480 e iniciamos sesión:

• Una vez que hemos iniciado sesión podemos ver, que nuestro VCSA está en la versión 8.0.3.00900 build 25413364:

• Sobre las opciones del menú nos vamos a Actualizar y Comprobamos actualizaciones, como podemos ver, tenemos disponible la release 8.0 Update 3k, la seleccionamos y damos clic sobre Realizar copias intermedias e instalar:

• Se nos abrirá este asistente, donde aceptamos el EULA, clic a Siguiente:

• Empieza a ejecutar comprobaciones previas a la actualización:

• Omitimos y continuamos:

• Realizamos copias de seguridad del vCenter y finalizamos:

• Como podemos ver comienza el proceso de actualización:

• Como podemos ver, la instalación ha sido completada y correcta:

• Una vez finalizada, volvemos a iniciar sesión en la interfaz VAMI del VCSA a través del puerto 5480, y aquí vemos que nuestro VCSA está en la última release liberada por VMware, la 8.0 Update 3k build 25600417:

• Ahora accedemos a la interface HTML5 de nuestro VCSA recién actualizado:

• Introducimos las credenciales e iniciamos:

• Aquí podemos ver también que nuestro VCSA está en la última release liberada por VMware, la 8.0 Update 3k build 25600417:

Saludos y espero que os resulte de ayuda

La entrada Actualizar vCenter Server Appliance 8.0 Update 3j a 8.0 Update 3k se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo actualizar un host ESXi versión VMware vSphere 8.0 Update 3i a la versión 8.0 Update 3j a través de ESXCLI, en este link os dejo toda la información.

• Como podemos ver, nuestros hosts ESXi está en la versión 8.0.3 build 25205845:

• Para empezar nos descargamos de la web de Broadcom WMware el patch para la instalación offline a través de la ESXCLI de ESXi 8.0 Update 3j build 25429389:

• Cargamos este archivo en un datastore de nuestro vCenter:

• Ponemos el host ESXi que queremos actualizar en modo mantenimiento:

• Accedemos por SSH al host ESXi que queremos actualizar:

• Ejecutamos el siguiente comando para listar los perfiles disponibles del parche descargado, esxcli software sources profile list -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3j-25429389-depot.zip:

• Para realizar el upgrade ejecutamos el comando esxcli software profile update -p ESXi-8.0U3j-25429389-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3j-25429389-depot.zip –no-hardware-warning una vez que ha finalizado, nos indica que debemos de reiniciar, * NOTA al final explicamos el comando hay temas a tener en cuenta:

• Una vez que el host ha iniciado, lo sacamos del modo mantenimiento:

• Como podemos ver, la actualización se ha realizado correctamente y ya tenemos el host ESXi en la versión 8.0 Update 3j Build 25429389 :

• * NOTA a tener en cuenta esxcli software profile update -p ESXi-8.0U3j-25429389-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3j-25429389-depot.zip –no-hardware-warning
• ESXi-8.0U3j-25429389-standard nombre del perfil que contiene la versión y el número de compilación
• VMware-ESXi-8.0U3j-25429389-depot.zip archivo utilizado para la actualización de ESXi
• –no-hardware-warning esta parte es por si nos da un error de CPU, por si la CPU de nuestro equipo no es compatible con la nueva release para que ignore este error, en mi caso la CPU de mi equipo no es compatible 100% con esta nueva reléase por eso lo añado al comando, ya que es un entorno de laboratorio, en producción el comando a ejecutar sería esxcli software profile update -p ESXi-8.0U3j-25429389-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3j-25429389-depot.zip

• Para el segundo host realizamos las mismas operaciones para actualizarlo:

Saludos y espero que os sea de ayuda

La entrada Actualizar VMware vSphere ESXi 8.0 Update 3i a 8.0 Update 3j con ESXCLI se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar nuestro vCenter Server Appliance a la última release liberada por VMware, la 8.0 Update 3j build 25413364, del 27 de mayo de 2026.

En este enlace os dejo la información sobre esta nueva actualización:

• VMware vCenter Server 8.0 Update 3i Release Notes
• Nos conectamos a la interfaz VAMI de nuestro VCSA a través del puerto 5480 e iniciamos sesión:

• Una vez que hemos iniciado sesión podemos ver, que nuestro VCSA está en la versión 8.0.3.00800 build 25197330:

• Sobre las opciones del menú nos vamos a Actualizar y Comprobamos actualizaciones, como podemos ver, tenemos disponible la release 8.0 Update 3j, la seleccionamos y damos clic sobre Realizar copias intermedias e instalar:

• Se nos abrirá este asistente, donde aceptamos el EULA, clic a Siguiente:

• Empieza a ejecutar comprobaciones previas a la actualización:

• Omitimos y continuamos:

• Realizamos copias de seguridad del vCenter y finalizamos:

• Como podemos ver comienza el proceso de actualización:

• Como podemos ver, la instalación ha sido completada y correcta:

• Una vez finalizada, volvemos a iniciar sesión en la interfaz VAMI del VCSA a través del puerto 5480, y aquí vemos que nuestro VCSA está en la última release liberada por VMware, la 8.0 Update 3j build 25413364:

• Ahora accedemos a la interface HTML5 de nuestro VCSA recién actualizado:

• Introducimos las credenciales e iniciamos:

• Aquí podemos ver también que nuestro VCSA está en la última release liberada por VMware, la 8.0 Update 3j build 25413364:

Saludos y espero que os resulte de ayuda

La entrada Actualizar vCenter Server Appliance 8.0 Update 3i a 8.0 Update 3j se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver el funcionamiento y las configuraciones de Microsoft Entra Domain Services, que una vez instaladas las RSAT, es básicamente igual que un Active Directory clásico que hemos configurado y administrador a lo largo de los años, sólo hay que tener en cuenta algunas particularidades.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Si accedemos a la consola de Usuarios y equipos de Active Directory, está será la organización que nos vamos a encontrar por defecto, luego podemos crear nuevas Unidades Organizativas (OU) y organizar el AD según nos convenga en nuestra infraestructura:

• Vamos a explicar las más importantes y las particularidades de cada una, para empezar, tenemos la Unidad Organizativa (OU), AADDC Computers, en esta OU se van a ir añadiendo todas las máquinas que unamos a nuestro dominio, luego crearemos otras OUs y podemos mover estas máquinas a las nuevas OUs para tener más organizado nuestro Active Directory:

• La OU AADDC Users, va a contener todos los usuarios y grupos que se sincronizan desde Microsoft Entra ID, aquí no debemos mover los usuarios ni grupos de OU, ni editarlos, ni cambiar passwords…, nada, no los debemos tocar, si queremos editarlos lo debemos hacer desde Microsoft Entra ID, y los cambios se sincronizaran con Microsoft Entra Domain Services, lo que si podemos hacer es crear usuarios y grupos locales propios del dominio de AD en otras OU, y usar estos usuarios por ejemplo para algún tema de servicios:

• La OU AADDSDomainAdmin, es un contenedor protegido y reservado para las operaciones del servicio gestionado, microsoft delega ciertos privilegios allí para que la infraestructura funcione de forma transparente sin otorgarnos los permisos de «Enterprise Admin» o «Domain Admin» tradicionales del Active Directory clásico, NO debemos tocar absolutamente nada de lo que vemos en esta OU, ni cambiarle la contraseña al usuario dcaasadmin, ni modificar el grupo AADDS Service Administrators Group, el usuario dcaasadmin, Microsoft lo utiliza de forma automatizada para realizar tareas de mantenimiento, aplicar parches de seguridad del sistema operativo a los controladores de dominio, monitorizar la salud del directorio y asegurar la replicación subyacente, si le cambiamos la contraseña o intentamos deshabilitarlo, bloquearemos los scripts de automatización de Azure y el servicio pasará automáticamente a estado «Alert» o «Unhealthy» en nuestro portal y podríamos llegar a romper la infraestructura desplegada:

• En la OU Domain Controllers, al igual que en un Active Directory clásico se van a ubicar nuestros controladores de dominio, en este caso los dos DC PaaS que se han desplegado con el servicio de Microsoft Entra Domain Services:

• Estas son las OUs nuevas que nos hemos creado:

• Hemos movido esta máquina a una de las OU nuevas que nos hemos creado:

• Al igual que el Active Directory clásico, esta es la consola de Administración de directivas de grupo y estas son las GPO que trae por defecto, AADDC Computers GPO, AADC Users GPO, Default Domain Controllers Policy y Default Domain Policy, NO EDITAR NI TOCAR bajo ningún concepto, si queremos aplicar alguna GPO, creamos una nueva y la vinculamos sobre la OU que nos interese, también podemos trabajarlas aplicando filtros de seguridad a grupos y usuarios, como hicimos en este post, como podemos ver la replicación entre los controladores de dominio es correcta:

• La GPO AADDC Computers GPO vinculada sobre la OU AADDC Computers tiene esta configuración para que los miembros el grupo AAD DC Administrators sean administradores locales de las máquinas de nuestro dominio, esta GPO tiene problemas con los equipos que están en idioma español o cualquier idioma diferente al Inglés, ya que el grupo administrators no existe, en español el grupo es administradores, por lo que la GPO se aplica pero los usuarios de grupo AAD DC Administrators una vez hagan logon en las máquinas no van a ser administradores locales:

• Para solucionarlo, hemos creado esta GPO:
• Abrimos la consola de Administración de Directivas de Grupo, clic derecho sobre Objetos de directiva de grupo y seleccionamos Nuevo, le damos el nombre LocalAdmin, clic derecho sobre la nueva GPO y damos a Editar, no dirigimos a la siguiente ruta:
• Configuración del equipo > Preferencias > Configuración de Panel de control -> Usuarios y grupos locales, clic derecho en el espacio en blanco > Nuevo > Grupo local.
• Configuración clave dentro del grupo:
• Acción: Actualizar
• Nombre de grupo: Aquí está el secreto, no lo escribas a mano, hacemos clic en el desplegable de la derecha y buscamos el grupo integrado Administradores (integrados).
• Nota técnica, al seleccionarlo desde el desplegable, la GPO no guarda el texto «Administradores», sino que guarda el SID universal S-1-5-32-544, de esta forma, si el equipo está en español, francés o inglés, la GPO afectará al grupo correcto de administración local.
• Miembros, clic en Agregar y buscamos el grupo del dominio: RAGASYS\AAD DC Administrators.

• También podemos vincular esta GPO a las OUs personalizadas que hemos creado:

• Para hacer una prueba, hemos creado esta GPO, con este filtrado de seguridad y la hemos vinculado sobre la OU AADDC Users:

• Si volvemos a iniciar sesión con un usuario perteneciente a este grupo, se nos abre la calculadora:

• Nuestro DNS podemos administrarlo como lo hemos hecho siempre en Active Directory clásico:

• Hemos creado estor registros CNAME para nuestros Controladores de dominio:

• Ya podemos acceder a la consola DNS por nombre en lugar de por IP:

• Nos podemos crear zonas de búsqueda inversa al igual que hacemos en Active Directory clásico, y como vemos se han replicado correctamente del dc01 al dc02:

• En el DNS no se debe de tocar nada más, ni reenviadores ni ningún tema de configuración.
• En la consola de Sitios y servicios de Active Directory no debemos de tocar nada, ya que como es un servicio PaaS podemos averiar la replicación entre los controladores de dominio, comentan que se pueden crear subredes, pero según he estado viendo y trabajando prefiero dejarlo tal cuál viene, NO TOCAR:

Saludos y espero que os sea de ayuda

La entrada Funcionamiento y Configuraciones de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como instalar las herramientas de administración remota RSAT en una máquina virtual unida a nuestro dominio, y así poder administrar el dominio de Microsoft Entra Domain Services al igual que hemos hecho siempre con nuestros controladores de dominio on-premise.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Esta es la configuración de red de la máquina dónde vamos a instalar las herramientas de administración remota RSAT, como podemos ver los DNS son las IPs de los controladores de dominio PaaS que se desplegamos con el servicio de Microsoft Entra Domain Services:

• Verificamos las comunicaciones con nuestros dos controladores de dominio PaaS:

• Unimos la máquina al dominio con el usuario al que elegimos como administrador del dominio:

• Una vez unido al dominio, reiniciamos y podemos iniciar sesión con este usuario en la máquina:

• Ejecutamos este comando para instalar las herramientas de administración remota RSAT que vamos a necesitar para administrar nuestro domino de Microsoft Entra Domain Services, Install-WindowsFeature -Name RSAT-AD-Tools, RSAT-DNS-Server, GPMC -IncludeAllSubFeature
• Ejecutando este comando tendremos las Consolas que tiene un Controlador de Dominio:
• Usuarios y equipos de Active Directory (ADUC)
• Administración de Directivas de Grupo (GPMC)
• Administrador de DNS
• Centro de Administración de Active Directory (ADAC)
• Sitios y servicios de Active Directory
• Dominios y confianzas de Active Directory
• Editor ADSI (ADSI Edit)

• Si nos abrimos el Administrador del Servidor > Herramientas, podemos ver todas las consolas que hemos instalado:

Saludos y espero que os resulte de ayuda

La entrada Instalación herramientas de administración remota RSAT en máquina virtual para Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo desplegar y configurar Microsoft Entra Domain Services (MEDS), veremos el despliegue de este servicio y las configuraciones iniciales para empezar a funcionar.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a realizar será crearnos nuestro dominio administrado, para ello, desde Azure portal accedemos a Microsoft Entra Domain Services > + Crear:

• Sobre Datos básicos le indicamos la Suscripción, el Grupo de recursos, le indicamos el Nombre de dominio DNS, la Región y el SKU, en SKU seleccionaremos Estándar, para implementaciones en producción seleccionar Enterprise o Prémium, clic en Siguiente:

• Sobre Redes seleccionamos la Red virtual que tenemos desplegada en nuestra infraestructura con la subred que configuramos para este servicio, en este caso 192.168.130.0/24, clic en Siguiente:

• Sobre Administración seleccionamos Administrar pertenencia al grupo e incluiremos los miembros que van a ser los Administradores de Microsoft Entra Domain Services, los usuarios que sean miembros de este grupo serán los administradores de nuestro dominio, estos usuarios que se incluyan aquí no van a ser administradores de dominio como en un Active Directory clásico, en este servicio administrado Microsoft no nos proporciona un administrador del dominio total, nos ofrece este grupo y el servicio PaaS de Microsoft Entra Domain Services una vez desplegado, le asigna automáticamente los permisos necesarios a este grupo sobre el dominio, vamos lo que hace básicamente es delegar los permisos necesarios en el Active Directory para poder trabajar y configurar lo que necesitemos en nuestra infraestructura, clic en Siguiente:

• Sobre Sincronización seleccionamos el Tipo de sincronización, en este caso Todo, clic en Siguiente:

• Sobre Configuración de seguridad lo dejamos todo por defecto, clic en Siguiente:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, clic en Siguiente:

• Sobre Revisar y crear nos muestra un resumen de todo lo configurado, clic en Crear:

• Aceptamos:

• Podemos ver que la implementación se ha completado correctamente:

• Si accedemos al grupo de recursos que nos creamos anteriormente, podemos ver todos los recursos que se han creado:

• Si accedemos al recurso Microsoft Entra Domain Services (ragasys.net), sobre información general, podemos ver, que el estado del dominio está En ejecución:

• Como podemos ver se muestra una advertencia que debemos corregir, pulsamos sobre la flecha:

• Ejecutamos el diagnóstico:

• El diagnóstico nos indica que debemos de establecer la configuración del servidor DNS de direcciones IP de servicio de dominios administrados 192.168.130.4,192.168.130.5 para las redes virtuales West Europe/opnsense-vnet/SubnetMEDS-192_168_130_0-24, estas dos direcciones IP son los dos controladores de dominio de nuestra infraestructura PaaS, clic a Corregir:

• De nuevo nos indica los problemas detectados (Registros de DNS) y como solucionarlo, clic sobre Corregir:

• Como vemos, los diagnósticos se han completado correctamente:

• Si accedemos a Redes Virtuales > opnsense-vnet > Servidores DNS, podemos ver que se han agregado los dos controladores de dominio como servidores DNS de nuestra red virtual:

• Si accedemos a Redes Virtuales > opnsense-vnet > Dispositivos conectados, podemos ver los Dispositivos conectados a nuestra vnet, en este caso está conectado nuestro firewall opnsense y los dos controladores de dominio PaaS que hemos desplegado:

• Ahora en el grupo de seguridad de red que se nos ha creado tras el despliegue (aadds-nsg), vemos las reglas que incluye por defecto, tanto las de entrada como las de salida:

• Para que todas las comunicaciones pasen por nuestro firewall OPNsense desplegado en Azure, debemos de crear estas dos reglas en el grupo de seguridad de red, una de entrada y otra de salida:

• Para terminar y que nuestros usuarios de Microsoft Entra ID puedan iniciar sesión en el dominio de Microsoft Entra Domain Services, deben de hacer un cambio de contraseña para habilitar el hash de contraseña en Microsoft Entra Domain Services:

• Nosotros hemos realizado el cambio de contraseña al usuario que incluimos en el grupo AAD DC Administrators:

• En el próximo post instalaremos las RSAT en una máquina unida a este dominio y veremos que los accesos a estos controladores de dominio es exactamente igual que los que nos montamos en una infraestructura on-premise.

Saludos y espero que os sea de ayuda

La entrada Despliegue y configuración de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo preparar los recursos de nuestra infraestructura, para el despliegue, la instalación y configuración de Microsoft Entra Domain Services (MEDS), veremos la red virtual a crear con la subred, las tablas de rutas que tenemos que configurar, creación de reglas en Fortigate on-premise y OPNsense Azure y grupo de administración de Microsoft Entra Domain Services para administrar nuestro dominio.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vamos a ver la red virtual que tenemos creada en Azure y la subred que vamos a utilizar para desplegar este servicio PaaS de Microsoft Entra Domain Services.
• Esta es la red virtual que vamos a utilizar con su espacio de direcciones configurado:

• Esta es la subred que vamos a utilizar para este servicio:

• Ahora, nos creamos esta tabla de rutas, llamada rt_meds_fw para enseñarle a los futuros controladores de dominio cómo responder a los servidores que tengamos en Azure y a los que tengamos en nuestra infraestructura on-premise, a través del firewall OPNsense que tenemos montado en Azure, importante no incluir NUNCA en esta tabla de ruta el rango de la subred donde van a estar los controladores de dominio de Microsoft Entra Domain Services 192.168.130.0/24:

• Modificamos la tabla de rutas MasterRoutes_rgs que ya la teníamos creada, para obligar a los servidores que tenemos en Azure a pasar por el firewall cuando busquen el Active Directory:

• Una vez creadas las tablas de rutas, tenemos que configurar las reglas o políticas en nuestros firewalls, tal y como vemos en topología de nuestra infraestructura, podemos ver que tenemos dos firewalls, un Fortigate para a parte on-premise y un OPNsense para la parte de Azure, entre ellos, tenemos configurada una VPN site to site, para el acceso entre los recursos de ambos entornos.
• Primero vamos a mostrar la regla que tenemos creada en nuestro firewall on-premise Fortigate, con esta regla, le estamos diciendo que todos nuestros equipos ubicados en la red 192.168.14.0/24 puedan acceder a los servicios de Microsoft Entra Domain Services, ubicados en los dos controladores de dominio que se desplegaran una vez que tengamos el servicio desplegado en Azure, en el grupo domaincontrollers_meds hemos ubicado los dos controladores de dominio, que tendrán las primeras IPs disponibles que tenga Azure para esa subred, normalmente las terminadas en .4 y .5 si usamos una máscara /24:

• Ahora vamos a mostrar las reglas que tenemos creadas en nuestro firewall de Azure OPNsense, con estas reglas, le estamos diciendo que todos nuestros equipos ubicados en las redes 192.168.128.0/24 de Azure y 192.168.14.0/24 om-premise, puedan acceder a los servicios de Microsoft Entra Domain Services, ubicados en los dos controladores de dominio que se desplegaran una vez que tengamos el servicio desplegado en Azure, en el grupo domaincontrollers_meds hemos ubicado los dos controladores de dominio, que tendrán las primeras IPs disponibles que tenga Azure para esa subred, normalmente las terminadas en .4 y .5 si usamos una máscara /24:

• Habilitamos también el ICMP para la pruebas de conexión:

• Por último, vamos a ver el grupo en Microsoft Entra ID al que tenemos que agregar los miembros que queramos que administren el dominio de Microsoft Entra Domain Services, el grupo está creado por defecto en Microsoft Entra ID, y se llama AAD DC Administrators:

Saludos y espero que os resulte de ayuda

La entrada Preparación de recursos para infraestructura de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar, instalar y configurar Microsoft Entra Domain Services (MEDS), Microsoft Entra Domain Services (anteriormente Azure Active Directory Domain Services), que forma parte de Microsoft Entra, nos va a permitir usar servicios de dominio administrados, como la unión a un dominio de Windows, directiva de grupo, LDAP y la autenticación Kerberos, sin tener que implementar, administrar o aplicar revisiones a controladores de dominio.

Con Microsoft Entra Domain Services, vamos a tener exactamente lo mismo que tendríamos con controladores de dominios on-premise de manera tradicional con el servicio o función de Active Directory Domain Services, como el directorio LDAP, DNS, GPOs, Sitios y servicios, etc…, con algunas particularidades que iremos viendo a lo largo de estos posts.

Con Microsoft Entra Domain Services tendremos:

• PaaS alojado en la nube de Azure
• Autenticación LDAP, Kerberos y NTLM
• Usuarios, Grupos, Unidades Organizativas
• GPOs
• Integración con Microsoft Entra ID
• Sin cuenta de administrador de dominio

Los servicios de dominio de Microsoft Entra Domain Services proporcionan servicios de dominio administrados como unión de dominio, directiva de grupo, LDAP, autenticación Kerberos / NTLM que es totalmente compatible con Windows Server Active Directory. Nosotros consumiremos estos servicios de dominio, sin implementar, administrar ni aplicar parches a los controladores de dominio. Microsoft Entra Domain Services se integra con el inquilino de Azure AD existente. Esta integración permite a los usuarios iniciar sesión con sus credenciales corporativas, y podremos usar grupos y cuentas de usuario existentes para proteger el acceso a los recursos.

Para entendernos, podemos decir, que esta es la parte de PaaS (Plataforma como Servicio) de nuestros controladores de dominio en Windows Server.

Para implementar Microsoft Entra Domain Services necesitamos:

• Una suscripción de Azure activa.
• Un inquilino de Microsoft Entra ID asociado con su suscripción, ya sea sincronizado con un directorio local o un directorio solo en la nube.
• Privilegios de administrador global en el inquilino de Microsoft Entra ID para habilitar Microsoft Entra Domain Services.
• Privilegios de colaborador en la suscripción de Azure para crear los recursos necesarios de Microsoft Entra Domain Services.
• Una red virtual con servidores DNS que pueden consultar la infraestructura necesaria, como el almacenamiento. Los servidores DNS que no pueden realizar consultas generales de Internet pueden impedir la capacidad de crear un dominio administrado.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

Este post lo vamos a dividir en:

• Preparación de recursos para infraestructura de Microsoft Entra Domain Services
• Despliegue y configuración de Microsoft Entra Domain Services
• Instalación herramientas de administración remota RSAT en máquina virtual para Microsoft Entra Domain Services
• Funcionamiento y configuraciones de Microsoft Entra Domain Services

Saludos y espero que os sea de ayuda

La entrada Despliegue, Instalación y Configuración de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo crear un almacén de datos ZFS en Proxmox Backup Server (PBS) para los repositorios de las copias de seguridad inmutables, esta inmutabilidad será de forma manual.

La topología utilizada sería la siguiente:

• Antes de empezar, vemos que en nuestro Proxmox Backup Server, le hemos añadido tres discos de 200GB dónde vamos a montar un RAIDZ (RAID 5) con ZFS para crear el repositorio de nuestras copias de seguridad inmutables:

• Desde la consola web de nuestro PBS, accedemos a Almacenamiento/Discos, y podemos ver, que ya tenemos disponibles los tres discos de 200 GB que hemos añadido:

• Clicamos sobre Almacenamiento/Discos > ZFS:

• Creamos el pool ZFS:

• Le indicamos los tres discos que vamos a utilizar, le asignamos un nombre y marcamos el check para que automáticamente nos agregue el Datastore al almacenamiento de nuestro PBS, como nivel de RAID en este caso le indicamos RAIDZ que equivale a un RAID 5, Crear:

• Como podemos ver, aquí se ha creado el pool de ZFS:

• Y aquí vemos, el almacén de datos creado:

• Estas son las opciones de RAID que tenemos en ZFS con Proxmox:
• Single Disk (Disco Único), es la configuración más básica, no hay redundancia. Cómo funciona: Los datos se escriben en un solo disco. Seguridad: Nula. Si el disco falla, pierdes todos los datos. Uso ideal: Pruebas, entornos de desarrollo no críticos o si tienes una estrategia de backup externa extremadamente sólida.
• Mirror (RAID 1), el clásico «espejo», requiere al menos 2 discos. Cómo funciona: Todo lo que se escribe en el Disco A se replica exactamente en el Disco B. Seguridad: Alta. Puede fallar un disco y el sistema seguirá funcionando. Rendimiento: Muy bueno en lectura (lee de ambos), pero la capacidad total es solo la de un disco.
• RAID 10 (Striped Mirrors), es una combinación de Mirroring y Striping, requiere al menos 4 discos (siempre en pares). Cómo funciona: Crea parejas de espejos (mirrors) y luego reparte los datos entre esas parejas. Seguridad: Puede fallar un disco por cada pareja de espejos. Es el más resistente y el que mejor se recupera . Rendimiento: Es el rey del rendimiento en ZFS, especialmente para bases de datos y muchas máquinas virtuales.
• RAIDZ (Equivalente a RAID 5), requiere al menos 3 discos. Cómo funciona: Utiliza un disco para «paridad», los datos se distribuyen entre todos los discos. Seguridad: Soporta el fallo de 1 disco, si falla un segundo disco antes de reemplazar el primero, se pierde todo. Capacidad: Pierdes el espacio equivalente a un disco. Nota: No se recomienda con discos mecánicos de gran capacidad (8TB+) debido al largo tiempo de reconstrucción.
• RAIDZ2 (Equivalente a RAID 6), requiere al menos 4 discos. Cómo funciona: Doble paridad distribuida. Seguridad: Soporta el fallo de 2 discos simultáneamente. Es el estándar de oro para almacenamiento masivo de datos. Capacidad: Pierdes el espacio equivalente a dos discos.
• RAIDZ3, requiere al menos 5 discos. Cómo funciona: Triple paridad distribuida. Seguridad: Soporta el fallo de hasta 3 discos. Es extremadamente seguro. Uso ideal: Solo para servidores con muchísimos discos (ej. 10 o 12 discos por vdev) donde la probabilidad de fallos múltiples es mayor.
• Una vez que hemos creado el repositorio ZFS en Proxmox Backup Server, sobre nuestro cluster de Proxmox VE, accedemos a Centro de datos > Almacenamiento > Agregar > Proxmox Backup Server:

• Sobre General, le indicamos el ID, Servidor y credenciales del PBS, los nodos a los que le vamos a presentar el datastore para los backups, Activar, como contenido de backup, le asignamos un nombre al datastore y le indicamos la Huella digital de nuestro PBS:

• La Huella digital del PBS, la copiamos del servidor PBS:

• Sobre Retención de respaldos, lo dejamos tal cuál nos lo muestra, ya que esto lo configuraremos en los propios trabajos de backups:

• Sobre Cifrado, le indicamos que autogenere una llave de cifrado para el cliente, Agregar:

• Descargamos la llave de cifrado y la guardamos en un lugar seguro, Cerrar:

• Y aquí tenemos ya creado y configurado nuestro datastore ZFS de Proxmox Backup Server que utilizaremos como repositorio de nuestros backups inmutables:

• Una vez creado y configurado el repositorio ZFS, vamos a crearnos una tarea de copia de seguridad inmutable, para ello, sobre nuestro cluster de Proxmox VE, accedemos a Centro de datos > Respaldo > Agregar:

• Sobre General, le indicamos el nodo (en nuestro caso, como es un clúster, Todo), el almacenamiento donde vamos a guardar los backups (Proxmox Backup Server), la programación, Compresión, Modo, le agregamos un comentario de descripción del backup y seleccionamos las máquinas a respaldar:

• Sobre Notificaciones, le podemos indicar la cuenta de correo, a la que queremos que nos lleguen los avisos de los respaldos:

• Sobre Retención, le vamos a indicar que nos mantenga los últimos 7 respaldos, a partir del séptimo irá sobrescribiendo los más antiguos, Crear:

• Aquí vemos la tarea creada:

• Ahora para probar la tarea, la vamos a lanzar de forma manual, Ejecutar ahora:

• Aquí vemos que el respaldo comienza a realizarse:

• Una vez finalizado, accedemos a nuestro Proxmox Backup Server > Almacén de datos > dts01zfspbs > Contenido, y podemos ver el contenido de nuestras copias de seguridad:

• Para hacer este backup inmutable, pulsamos sobre el símbolo del escudo GRIS que nos aparece en nuestro backup:

• Y marcamos el check Protegido, Aceptar:

• Como podemos ver, el escudo cambia a color VERDE y nos aparece el backup como protegido:

• Si intentamos eliminar su contenido, nos va a dar este mensaje de error:

• Esto pasa cuando protegemos un backup:
• El servidor le pone un atributo de «SÓLO LECTURA» a nivel de kernel de Linux.
• Incluso si un virus entra con permisos de administrador e intenta borrar la carpeta del backup, el sistema de archivos ZFS rechazará la orden porque el archivo tiene el bit de inmutabilidad activo.
• La inmutabilidad en PBS significa que el software le pone un candado digital (fattr) a los archivos en el pool de ZFS, mientras ese candado esté puesto, ni el propio Proxmox puede borrar los datos para dejar espacio a backups nuevos.
• Esta inmutabilidad que hemos mostrado es MANUAL, es decir, que por cada punto de retención que se vaya creando tendremos que habilitar de manera manual el candado.
• Esto es lo que pasaría:
• Día 1 al 7, realizamos los backups y les ponemos el candado, quedando protegidos, tenemos 7 puntos de recuperación inmutables.
• Día 8, se realiza el octavo backup y como los 7 anteriores tienen el candado activado y están protegidos, el sistema de limpieza (Prune) no puede borrar el día 1.
• Resultado, ahora tenemos 8 backups ocupando espacio en nuestro datastore ZFS.
• Tendríamos que entrar una vez por semana, quitarle el candado al más viejo (Día 1) y ponérselo al más nuevo (Día 8), esto permite que el proceso de Garbage Collection de ZFS, libere los bloques de datos del Día 1.
• Para restaurar una máquina completa sobrescribiendo la actual, accedemos a la propia máquina > Respaldo > Almacenamiento > Seleccionamos el backup > Restaurar:

• Si queremos restaurar archivos, accedemos a la propia máquina > Respaldo > Almacenamiento > Seleccionamos el backup > Restauración de archivo:

• Si quisiera restaurar la máquina completa sin sobrescribir la original, dts01zfspbs > Respaldos > Seleccionamos el backup > Restaurar:

• Le indico el datastore donde la quiero restaurar, y el nuevo ID de máquina virtual, Restaurar:

Saludos y espero que os sea de ayuda

La entrada Crear almacén de datos ZFS en Proxmox Backup Server para los repositorios de copias de seguridad inmutables se publicó primero en RAGASYS SISTEMAS.