• En este post vamos a ver como auditar los accesos a los a los objetos en nuestros equipos unidos a un dominio de Active Directory.
• Lo primero que debemos hacer es crearnos una GPO para habilitar la auditoría de objetos en nuestro Active Directory, para ello nos abrimos la consola de Administración de directivas de grupo y sobre Objetos de directivas de grupo le indicamos que queremos crearnos una nueva GPO:

• Le damos un nombre a la GPO y la editamos:

• Accedemos a Configuración del equipo > Dircetivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría y configuramos-habilitamos la directiva Auditar el acceso a objetos:

• Ahora, esta configuración es opcional, pero muy recomendable, vamos a habilitar la auditoría avanzada, para ello, accedemos a Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Configuración de directiva avanzada de auditoría > Directiva de auditoría detallada > Acceso a objetos y configuramos-habilitamos las directivas Auditar almacenamiento extraíble y Auditar sistema de archivos:

• Una vez editada, aquí tenemos la configuración para habilitar la auditoría a objetos en nuestros equipos del AD:

• Aunque la GPO activa la auditoría, nosotros necesitamos configurar en cada equipo o mediante script qué carpetas/archivos serán auditados, vamos a ver un ejemplo:
• Para hacerlo de forma manual en una carpeta de cualquiera de nuestros equipos del dominio, debemos dar clic derecho sobre la carpeta > Propiedades > Pestaña Seguridad > Opciones avanzadas > Auditoría y agregamos:
• Usuario: Todos
• Tipo: Todo
• Se aplica a: Esta carpeta, subcarpetas y archivos
• Permisos avanzados: Crear archivos/escribir datos, Crear carpetas/anexar datos, Eliminar subcarpetas y archivos, Eliminar.

• Esto puede automatizarse mediante scripts de PowerShell, hemos creado este script, llamado auditoriausuarios.ps1, que lo podemos descargar desde este enlace, dónde vamos a auditar las carpetas del escritorio, documentos y descargas de todos los usuarios:

• Nos creamos este script en .bat, para cuando configuremos la GPO, invoquemos desde este script, al script de PowerShell:

• Ahora accedemos a cualquiera de nuestros controladores de dominio y copiamos estos dos scripts en esta ruta:

• En la consola de Administración de directivas de grupo, volvemos a editar la GPO que creamos y configuramos para la auditoria de objetos:

• Accedemos a Configuración del equipo > Directivas > Configuración de Windows > Scripts (Inicio o apagado) > Inicio > Scripts > Agregar > Examinar y añadimos el script .bat, Aceptar:

• Y así nos quedaría la GPO, completamente configurada:

• Ahora esta GPO, la vamos a vincular sobre la OU Equipos, para que empiece a auditar el acceso a los objetos:

• Como podemos ver, aquí la tenemos vinculada:

• Sobre uno de nuestros equipos del dominio ejecutamos un gpupdate /force para aplicar las nuevas directivas:

• Una vez aplicada la GPO, vamos que en las carpetas han cambiado sus permisos de auditoría:

• Con todo esto ya tenemos configurado las auditorías de los acceso a objetos en los equipos de nuestro Active Directory.
• Los registros de auditoría quedan todos guardados en el Visor de eventos de los equipos de los usuarios, en los Registros de Windows > Seguridad:

• Ahora vamos a crear y eliminar algunos ficheros de uno de nuestros equipos y veremos en el visor de eventos que usuario a creado y eliminado estos ficheros.
• Creamos estos dos ficheros:

• Eliminamos estos dos ficheros:

• Con el ID de evento 4663 vemos como se crean los ficheros:

• Y con el ID de evento 4659 vemos como se eliminan los ficheros:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como migrar controladores de dominio con Windows Server 2022 a Windows Server 2025.

En este laboratorio, tenemos dos controladores de dominio con Windows Server 2022, y los vamos a migrar a Windows Server 2025.

• Como podemos ver, tenemos dos controladores de dominio en nuestra infraestructura con el sistema operativo MS Windows Server 2022 Standard:

• Los roles o funciones que tienen estos servidores son los siguientes, “Servicios de dominio de Active Directory y DNS”:

• Ahora debemos desplegar dos nuevos servidores con el sistema operativo MS Windows Server 2025 Standard, los actualizamos y los configuramos como un controlador de dominio adicional:

• Empezamos la configuración de nuestros controladores de dominio adicionales asignándole un nombre y una dirección IP estática, como DNS primario le asignamos la dirección IP de uno de los controladores de dominio y como DNS secundario la dirección IP del otro controlador de dominio, más tarde, le configuraremos su propia dirección IP como DNS:

• Ahora agregamos estos equipos como un miembro más del dominio:

• Le proporcionamos las credenciales del Administrador del dominio y reiniciamos el equipo:

• Como podemos ver se ha agregado correctamente, reiniciamos el servidor:

• Para el otro equipo hacemos las mismas operaciones.
• Ahora nos vamos a la consola de Usuarios y equipos de Active Directory en el controlador de dominio principal y cómo podemos ver, estos equipos ya pertenecen al dominio ragasys.local:

• Ahora iniciamos sesión en DCRGS03 (Servidor que hemos terminado de unir al dominio) como Administrador del dominio:

• En el Administrador del servidor agregamos roles y características:

• Se nos abre el asistente típico para desplegar los roles y características, hacemos clic en siguiente:

• Sobre Tipo de instalación, elegimos la opción, Instalación basada en características o roles:

• Seleccionamos nuestro servidor dcrgs03:

• Sobre Roles de servidor, marcamos la opción Servicios de dominio de Active Directory:

• Agregamos las características:

• Clic en siguiente:

• Todas las características que requiere nuestro controlador de dominio de Active Directory se seleccionan por defecto por lo que hacemos clic en siguiente:

• Información sobre Active Directory :

• Sobre Confirmación, iniciamos el despliegue del rol Servicios de dominio de Active Directory, marcamos que reinicie automáticamente en caso necesario y clic sobre Instalar:

• Comienza el despliegue de los Servicios de dominio de Active Directory:

• Una vez finalizada la instalación cerramos el asistente:

• Sobre el Administrador del servidor promovemos este servidor a controlador de dominio:

• Sobre Configuración de implementación, marcamos la opción Agregar un controlador de dominio a un dominio existente, seleccionamos nuestro nombre de dominio y le proporcionamos las credenciales del Administrador del dominio, clic en Siguiente:

• Sobre las Opciones del controlador de dominio, seleccionamos la función de DNS, ya que es un requisito imprescindible para Active Directory, también seleccionamos que sea Catálogo Global y luego introducimos una contraseña segura que será necesaria en caso de restauración de Active Directory:

• Sobre Opciones de DNS, la dejamos por defecto, ya que el DNS lo tenemos configurado sobre el controlador de dominio principal, por lo que el controlador de dominio adicional se va a configurar automáticamente con la misma configuración que el principal:

• En Opciones adicionales, le indicamos que replique desde cualquier controlador de dominio:

• Sobre Rutas de acceso las dejamos por defecto:

• Sobre Opciones de preparación, nos indica que para instalar este controlador de dominio el asistente debe realizar las operaciones de preparar el esquema y el bosque, y preparar el dominio:

• Sobre Revisar opciones, nos muestra un resumen de las configuraciones seleccionadas, clic en Siguiente:

• Sobre Comprobación de requisitos previos, nos muestra que todas las comprobaciones se realizaron correctamente, clic a Instalar:

• Sobre Instalación, podemos ver como comienza a instalar y configurar los Servicios de dominio de Active Directory, una vez instalados, el servidor se va a reiniciar automáticamente:

• Tras el reinicio, nos abrimos la consola de Usuarios y equipos de Active Directory, y cómo podemos ver, este equipo ya está como un Domain Controller más de nuestra infraestructura:

• Para el otro controlador de dominio DCRGS04, con Windows Server 2025 realizamos las mismas operaciones, y cómo podemos ver, este equipo está también, como un Domain Controller más de nuestra infraestructura:

• También podemos comprobarlo con el comando netdom query dc:

• Con el comando repadmin /showrepl, verificamos que nuestros nuevos controlador de dominio están replicando correctamente:

• Con el comando dcdiag /test:replications comprobamos la replicación y cualquier error de replicación entre los controladores de dominio:

• Con el comando dcdiag /test:connectivity comprobamos la conectividad y cualquier error de conexión entre los controladores de dominio:

• Con el comando dcdiag /test:DNS comprobamos que el DNS esté funcionando correctamente:

• Estas mismas pruebas de diagnóstico, las debemos de realizar sobre el controlador de domino principal y así nos aseguramos que nuestros controladores de dominio estén en perfecto estado.
• Una vez que tenemos agregados los dos controladores de dominio adicionales con sistema operativo MS Windows Server 2025, y por tanto, superior a MS Windows Server 2022, vamos a proceder a transferir los roles FSMO del controlador de dominio principal al adicional, así el nuevo controlador de dominio con el Server 2025 quedará como principal.
• Todos los dominios de Active Directory disponen de cinco roles FSMO (Flexible Single Master Operations), los roles FSMO son funciones específicas que realizan los controladores de dominio a nivel de bosque o de dominio:

• Sobre cualquiera de nuestros controladores de dominio vamos a ejecutar el siguiente comando netdom query fsmo para ver quien tiene asignados estos roles FSMO, y como podemos ver todos los roles los tiene asignados nuestro primer controlador de dominio con Windows Server 2022 (dcrgs01):

• Ahora lo que vamos a realizar será transferir los cinco roles FSMO a uno de los dos controladores de dominio adicionales con Windows Server 2025 (dcrgs03), convirtiéndolo así en el domain controller principal, para ello, utilizaremos Powershell.
• Para transferir los roles fsmo del controlador de dominio dcrgs01 al controlador de domino dcrgs03, ejecutamos el siguiente comando, Move-ADDirectoryServerOperationMasterRole -Identity «DCRGS03» -OperationMasterRole SchemaMaster, RIDMaster, InfrastructureMaster, DomainNamingMaster, PDCEmulator:

• Volvemos a ejecutar el comando netdom query fsmo, y cómo podemos ver, los roles fsmo ya los tiene asignados el dcrgs03:

• También podemos usar este otro comando Move-ADDirectoryServerOperationMasterRole -Identity «DCRGS03» -OperationMasterRole 0, 1, 2, 3, 4
• Cada número se corresponde con los roles fsmo:

0    PDCEmulator
1    RIDMaster
2    InfrastructureMaster
3    SchemaMaster
4    DomainNamingMaster

• Si los cinco roles FSMO no los transferimos de forma manual, el proceso de despromoción los transferirá de forma automática a cualquier Controlador de dominio disponible, a mí personalmente prefiero hacerlo de forma manual.
• Ahora accedemos a la configuración TCP/IPv4 de nuestros nuevos controladores de dominio recién desplegados y configuramos como DNS principal su propia dirección IP y como DNS secundario la dirección IP del controlador de dominio principal:

• Ahora ya podemos despromocionar como controlador de dominio los servidores con MS Windows Server 2022, para ello, vamos a realizar lo siguiente:
• Nos abrimos el Administrador del servidor y pinchamos sobre la opción Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Sobre Roles de servidor, desmarcamos el check “Servicios de dominio de Active Directory” y sobre el asistente que se nos abre hacemos clic en “Quitar características”:

• Se nos abre el siguiente asistente, que nos indica que tenemos que disminuir el nivel, por lo tanto, hacemos clic sobre “Disminuir el nivel de este controlador de dominio”:

• Se nos vuelve a abrir otro asistente, dónde verificamos que las credenciales sean las correctas, esta es la opción más importante del asistente, ya que al ser un controlador de dominio adicional o secundario NO aparece la opción de marcar el check “Último controlador de dominio en el dominio”, clic sobre “siguiente”:

• Marcamos el check “Continuar con la eliminación” y clic sobre siguiente:

• Introducimos la nueva contraseña para el administrador local, al eliminar el rol de controlador de dominio, la cuenta de usuario de administrador pasará a formar parte de los usuarios locales de la máquina, clic sobre “siguiente”:

• Revisamos y hacemos clic sobre “Disminuir nivel”, al finalizar la operación se reiniciará el servidor:

• Como podemos ver comienza el proceso de degradación de nuestro controlador de dominio:

• El sistema nos va a indicar que ha disminuido el nivel del controlador de dominio, y se va a reiniciar automáticamente.
• Para el otro controlador de dominio (dcrgs02) con MS Windows Server 2022, realizamos las mismas operaciones.
• Una vez que los equipos han reiniciado verificamos que los dos servidores con MS Windows Server 2022 ya no son controladores de dominio, en el Administrador del servidor nos vuelve a indicar con una advertencia “Promover este servidor a controlador de dominio”:

• Sobre la consola de Usuarios y equipos de Active Directory del Controlador de dominio principal, podemos ver como los Controladores de dominio con Windows Server 2022 han pasado a formar parte del dominio como un equipo más de éste:

• Para desinstalar los binarios de los Servicios de dominio de Active Directory, lo haremos a través del Administrador del Servidor > Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Desmarcamos el check, Servicios de dominio de Active Directory, y Quitar características:

• Desmarcamos el check, Servidor DNS, y Quitar características:

• Una vez desmarcados estos dos checks, damos clic a “siguiente”:

• Aquí no tocamos nada, clic sobre “siguiente”:

• Nos muestra un resumen de las opciones configuradas para eliminar, le indicamos que reinicie en caso necesario y procedemos a quitar:

• Comienza con la eliminación:

• Tras el reinicio podemos ver que la eliminación ha sido correcta:

• Todo se ha eliminado correctamente, en la bandera de las advertencias, ya NO nos avisa de la promoción de este servidor a Controlador de dominio, ya que todos los binarios han sido eliminados:

• Para el otro equipo Windows Server 2022 (dcrgs02) realizamos las mismas operaciones.
• Sobre el controlador de dominio principal (dcrgs03), en Sitios y servicios de Active Directory eliminamos los dos controladores de dominio antiguos:

• Para terminar ya sólo nos quedaría elevar los Niveles Funcionales a nivel de dominio y de bosque.
• Empezaremos elevando el Nivel Funcional del bosque, para ello, nos abrimos la herramienta Dominios y Confianzas de Active Directory:

• Como podemos observar, el Nivel Funcional del bosque se encuentra en Windows Server 2016, y lo vamos a Elevar a Windows Server 2025:

• Nos indica que este cambio afecta a todo el bosque, y que una vez que hayamos elevado el nivel funcioanl del bosque, ya no podremos revertirlo, Aceptar:

• Como podemos ver, el nivel funcional se aumentó correctamente, Aceptar:

• Ahora vamos a elevar el Nivel Funcional del dominio, para ello, nos abrimos la herramienta Usuarios y equipos de Active Directory:

• Automáticamente al elevar el Nivel Funcional del bosque se eleva también el del dominio, como podemos ver, el nivel funcional del dominio se encuentra en Windows Server 2025:

• Con la herramienta Centro de Administración de Active Directory tenemos opción a Elevar los Niveles Funcionales a nivel de bosque y de dominio:

• Para terminar, vamos a cambiarle las direcciones IP a los dos Controladores de dominio nuevos, y les vamos a dejar las IPs de los controladores de dominio antiguo:

• En la consola DNS nos debería de quedar de esta forma:

• Si en nuestra infraestructura, estábamos utilizando los nombres antiguos de los controladores de dominio en algún servicio (dcrgs01 y dcrgs02), nos vamos a crear estos registros del tipo CNAME en el DNS, para que estos servicios no se vean afectados:

• Con esto ya tendríamos migrado nuestros controladores de dominio de MS Windows Server 2022 a MS Windows Server 2025.

Saludos y espero que os resulte de ayuda

En este post (hoy cortito), vamos a ver, cómo configurar las políticas de contraseñas granulares en nuestro Active Directory, estas políticas van a prevalecer sobre las políticas de contraseñas configuradas en las políticas de grupo (GPO) y las asignaremos a grupos de usuarios.

• Si accedemos a la consola de Administración de directivas de grupo de nuestro Active Directory, podemos ver que tenemos esta política configurada:

• Para configurar una política distinta de contraseña a un grupo de usuarios y que prevalezca sobre esta política, debemos de acceder a la consola, Centro de Adminsitración de Active Directory > Dominio > System > Password Settings Container > Nuevo > Configuración de contraseña:

• Configuramos la política de contraseña que nos interese, y le asignamos el grupo de usuarios al que le queremos aplicar esta política:

• Y aquí tenemos, nuestra política granular creada:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo configurar Windows LAPS para la contraseña DSRM (restauración de servicios de directorio) de Active Directory, esta contraseña la asignamos cuando desplegamos el rol de Servicios de dominio de Active Directory, esta es una nueva característica del nuevo Windows LAPS.

• Lo primero que vamos a realizar es acceder a uno de nuestros controladores de dominio y nos abrimos la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre uno de ellos, y sobre la pestaña LAPS podemos ver, que es aquí dónde nos va a mostrar la contraseña de DSRM, una vez que tengamos la GPO configurada y vinculada sobre la OU Domain Controllers:

• Nos abrimos la consola Administración de directivas de grupo y nos vamos a crear una nueva GPO llamada LAPS_DSRM con la siguiente configuración:

• Luego vinculamos esta GPO sobre la OU Domain Controllers:

• Ahora si nos abrimos un PowerShell sobre el controlador de dominio DCRGS01 y ejecutamos un gpupdate /force, vamos a forzar a que se activen estas nuevas configuraciones de directivas que hemos creado:

• Si accedemos de nuevo a la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre DCRGS01, y sobre la pestaña LAPS podemos ver, que ya se ha aplicado esta nueva GPO para controlar las contraseñas de DSRM de los controladores de dominio de nuestra infraestructura:

• Ahora si nos abrimos un PowerShell sobre el controlador de dominio DCRGS02 y ejecutamos un gpupdate /force, vamos a forzar a que se activen estas nuevas configuraciones de directivas que hemos creado:

• Si accedemos de nuevo a la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre DCRGS02, y sobre la pestaña LAPS podemos ver, que ya se ha aplicado esta nueva GPO para controlar las contraseñas de DSRM de los controladores de dominio de nuestra infraestructura:

Saludos y espero que os resulte de ayuda

• Para empezar, vamos a ajustar el comportamiento de los servicios NSS y PAM en cada cliente que tengamos que configurar, comenzamos por instalar los siguientes paquetes:
• libnss-ldap, permite que NSS obtenga de LDAP información administrativa de los usuarios (Información de las cuentas, de los grupos, información de la máquina, los alias…)
• libpam-ldap, facilita la autenticación con LDAP a los usuarios que utilicen PAM.
• ldap-utils, facilita la interacción con LDAP desde cualquier máquina de la red.
• Para instalarlos ejecutamos, apt-get install libnss-ldap libpam-ldap ldap-utils -y:

• Durante el proceso de instalación, se activa un asistente que nos permite configurar el comportamiento de ldap-auth-config.
• Nos solicita la dirección URi del servidor LDAP, debemos de poner ldap://IPServidorLDAP:

• Indicamos el dn de nuestro dominio:

• A continuación, nos pide el número de versión del protocolo LDAP que estamos utilizando, en nuestro caso la 3:

• Ahora le indicaremos si las utilidades que utilicen PAM deberán comportarse del mismo modo que cuando cambiamos contraseñas locales, esto hará que las contraseñas se guarden en un archivo independiente que sólo podrá ser leído por el superusuario, le indicamos que Sí:

• El sistema nos pregunta si queremos que sea necesario identificarse para realizar consultas en la base de datos de LDAP, elegimos la opción No:

• Le indicamos el nombre de la cuenta LDAP que tendrá privilegios para realizar cambios en las contraseñas, deberemos escribir un dn:

• Le indicamos la password:

• Una vez que se ha instalado todo correctamente, habremos terminado la configuración básica del cliente LDAP:

• Para completar la configuración, debemos cambiar algunos parámetros en los archivos de configuración del cliente, en concreto, deberemos editar /etc/nsswitch.conf, /etc/pam.d/common-password y /etc/pam.d/common-session.
• Editamos el archivo nano /etc/nsswitch.conf y localizamos las líneas que comienzan por passwd, group y shadow y les añadimos el texto ldap, para indicar el nuevo origen para autenticar las cuentas:

• Editamos el archivo nano /etc/pam.d/common-password que proporciona un conjunto común de reglas PAM para la comprobación de contraseñas, la opción use_authtok, impide utilizar un segundo método de autenticación cuando ya ha sido aplicado otro anterior, aunque éste haya sido insatisfactorio, para evitar este comportamiento, deberemos eliminar la opción use_authtok:

• Editamos el archivo nano /etc/pam.d/common-session que ofrece un conjunto de reglas PAM para el inicio de sesión, aquí será donde indiquemos que se debe crear un directorio home durante el primer inicio de sesión, también para los usuarios autenticados mediante LDAP, este comportamiento lo conseguiremos añadiendo al final del archivo la siguiente línea, session optional    pam_mkhomedir.so skel=/etc/skel umask=077:

• Una vez completados los pasos anteriores, ya estamos listos para activar el servicio libnss-ldap, sin embargo, para lograrlo necesitaremos instalar el programa sysv-rc-conf, para ello, ejecutamos, apt-get install sysv-rc-conf:

• Vemos que nos nos ha dejado instalarlo, porque no localiza el paquete, nos descargamos el paquete a través de este link y lo instalamos ejecutando dpkg -i sysv-rc-conf_0.99-7_all.deb, como vemos nos da errores de dependencia:

• Para solucionarlo, ejecutamos apt install -f:

• Si sigue dando problemas ejecutamos apt –fix-broken install

• Si el paquete se isntala correctamente ya podemos iniciar sesión con los usuarios del ldap:

• Como podemos ver, ya estoy logueado con el usuario del dominio:

Saludos y espero que os sea de ayuda

• Lo primero que debemos de configurar, es el DNS de la máquina cliente Ubuntu para que apunte al controlador de dominio samba:

• Configuramos el fichero hosts con nano /etc/hosts y añadimos estas entradas:

• Le hacemos un ping para verificar que tenemos conexión a nuestro controlador de dominio samba:

• Modificamos el fichero nano /etc/resolv.conf para el DNS, introduciendo los siguientes parámetros:

• Ahora bajamos la versión open del pbis del siguiente enlace
• Una vez bajado el script, le daremos permiso de ejecución para posteriormente ejecutarlo:

• Ejecutamos el script y comenzará el proceso de instalación, una vez instalado ya estaremos listos para agregar nuestro Ubuntu al dominio:

• Para unir el equipo al dominio introducimos el siguiente comando, domainjoin-cli join –disable ssh JRRG.LOCAL Administrator:

• Ahora reiniciamos el equipo para que los cambios tengan efecto:

• Como podemos ver, en nuestro controlador de dominio Ubuntu Samba si introducimos el comando samba-tool computer list se ha agregado la máquina Ubuntu como cliente:

• El siguiente paso sería configurar el terminal Ubuntu para que funcione correctamente el inicio de sesión de los usuarios del dominio, para ello ejecutamos las siguientes configuraciones:

/opt/pbis/bin/config UserDomainPrefix JRRG

/opt/pbis/bin/config AssumeDefaultDomain true

/opt/pbis/bin/config LoginShellTemplate /bin/bash

/opt/pbis/bin/config HomeDirTemplate %H/%D/%U

/opt/pbis/bin/config RequireMemberShipOf “JRRG\\Domain^Users”

• Ahora editamos el archivo /etc/pam.d/common-session y modificaremos la línea correspondiente a session pam_lsass.so:

• Por ultimo, permitiremos que en la pantalla de inicio se permita iniciar sesión a cualquier usuario, para ello editamos la configuración de lightdm en la ubicación /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf, dónde añadimos la siguiente línea, greeter-show-manual-login=true:

• Reiniciamos el equipo:

• Ahora cerramos la sesion del equipo con el usuario local, y vamos a acceder con uno de nuestros usuarios del dominio:

• Como podemos ver, ya estoy logueado con el usuario del dominio:

• Ahora desde el equipo Ubuntu 22.04 LTS vamos a verificar, que podemos acceder al recurso compartido que creamos anteriormente en nuestro controlador de dominio samba, y que podemos crear un documento
• Instalamos smbclient con apt-get install smbclient y ejecutamos smbclient –list 192.168.5.52 o podemos poner en lugar de la direccion IP del servidor el nombre, como podemos ver, accedemos a los recursos compartidos de nuestro controlador de dominio samba:

• Accedemos al recurso compartido (share) que creamos anteriormente y nos creamos un fichero .txt para verificar que todo esto funciona correctamente, nos conectamos al servidor, nos pedirá las credenciales de usuario, nos ubicamos sobre el recurso compartido y añadimos el fichero .txt:

• Ahora vamos a ver la parte de Webmin en el controlador de dominio samba, lo primero que vamos a realizar será descargarnos la última versión de webmin, en este link realizamos la descarga:

• Procedemos a instalar el paquete, ejecutando dpkg -i webmin_2.105_all.deb y apt-get install -f:

• Ahora desde cualquier equipo de nuestra infraestructura accedemos al controlador de dominio samba a través de webmin, desde cualquier navegador ponemos http://192.168.5.52:10000 e introducimos las credenciales:

• Si accedemos a Servers > Samba Windows File Sharing podemos ver los recursos compartidos de nuestro controlador de dominio samba:

• Si accedemos a Samba Users podemos ver los usuarios creados para Samba y para nuestro dominio:

Saludos y espero que les resulte de ayuda

• Lo primero que vamos a realizar, será configurar el DNS del Windows 10 para que apunte al controlador de dominio samba:

• Accedemos a la Configuración avanzada del Sistema, sobre la pestaña Nombre de equipo > Cambiar introducimos el nombre de nuestro dominio:

• Nos pedirá las credenciales del administrador del dominio samba para poder unirlo:

• Como podemos ver, se ha unido correctamente a nuestro dominio:

• Ahora nos pide que reiniciemos el equipo:

• Una vez reiniciado, vamos a acceder al equipo con uno de los usuarios que nos creamos anteriormente en controlador de dominio samba:

• Aquí vemos el equipo unido al dominio samba:

• Si accedemos a nuestro controlador de dominio Samba y ejecutamos el comando samba-tool computer list podemos ver, el listado de máquinas unidas a nuestro dominio:

• Crearemos dos grupos, cada uno de ellos con dos usuarios, para ello, ejecutamos samba-tool group add nombregrupo:

• Añadimos dos usuarios a cada grupo, para ello, ejecutamos samba-tool group addmembers nombregrupo nombreusuario:

• Con el commando samba-tool group listmembers «nombregrupo», vemos los miembros de cada grupo:

• Con el comando samba-tool group list podemos ver todos los grupos de nuestro dominio samba:

• En el fichero de configuración de samba, nano /etc/samba/smb.conf hemos configurado el siguiente recurso compartido, con los siguientes permisos:

• A la carpeta local /opt/share le asignamos permisos de control total con chmod 777 /opt/share ya que los permisos más restrictivos lo va a gestionar el servicio de samba:

• Ahora desde el equipo windows 10 vamos a verificar, que podemos acceder a un recurso compartido de nuestro controlador de dominio samba, y que podemos crear un documento:

• Como podemos ver, nos aparecen los recursos compartidos por el servidor:

• Accedemos al recurso compartido (share) que creamos anteriormente y nos creamos un fichero .txt para verificar que todo esto funciona correctamente, esto ha sido con el usuario2 que tiene permisos de escritura:

• Si accedemos al recurso compartido (share) con el usuario3, que sólo tiene permisos de lectura, no nos dejará crear ningún fichero:

Saludos y espero que os sea de ayuda

En este post vamos a ver como agregar una máquina Ubuntu desktop 22.04 como cliente del dominio Windows Server 2022.

• Lo primero que vamos a configurar será el fichero /etc/hosts para que el equipo linux pueda resolver el nombre de nuestro controlador de dominio:

• Le hacemos un ping al nombre del controlador de dominio y como podemos ver, ya nos resuelve:

• A continuación vamos a configurar la conexión de red, para ello, editamos el fichero /etc/netplan/01-network-manager-all.yaml:

• Aplicamos la nueva configuración de red con netplan apply:

• Con nslookup nombre del dominio vemos si el equipo está resolviendo bien el dominio:

• Una vez que hemos verificado que la comunicación entre el equipo linux y el servidor funciona correctamente, actualizaremos el sistema operativo con las últimas versiones de los paquetes disponibles en los repositorios, para ello, ejecutaremos apt-get update && apt-get upgrade recibiremos un detalle con todos los paquetes que van a actualizarse le indicamos que SI los instale:

• Modificaremos el hostname del equipo para que incluya al dominio, hostnamectl set-hostname asoubntdesk.jrrg.local:

• Editamos de nuevo el fichero hosts, nano /etc/hosts e introducimos nuestro hostname:

• Reiniciamos el equipo, reboot:

• Instalamos los paquetes necesarios, para ello, ejecutamos el siguiente commando, apt install -y realmd sssd sssd-tools libnss-sss libpam-sss krb5-user adcli samba-common-bin packagekit:

• También ahora nos aparece un listado con todos los paquetes que van a actualizarse y un resumen final con el número de paquetes que se actualizarán, los paquetes nuevos que se instalarán y los que se eliminarán de la instalación.
• Ahora nos pregunta por el reino (realm en inglés). En realidad, se refiere al nombre del dominio al que vamos a unirnos, debemos de ponerlo en MAYÚSCULAS:

• Si por alguna razón esta pantalla no aparece o queremos hacer alguna modificación posteriormente, podemos editar el fichero /etc/krb5.conf. En este mismo fichero es bueno añadir tres entradas en la sección [libdefaults] que le dirán específicamente al cliente que use los servidores DNS para las búsquedas.

rdns = false

dns_lookup_realm = true

dns_lookup_kdc = true

• Ahora añadimos nuestro controlador de dominio como servidor de tiempo, nano /etc/systemd/timesyncd.conf:

• Realizamos lo siguiente:
• timedatectl set-ntp true, Habilita la sincronización por NTP
• systemctl restart systemd-timesyncd.service, reinicia el servicio
• timedatectl –adjust-system-clock, fuerza la sincronización
• Luego podemos comprobar el estado hacienda, timedatectl status
• En caso de que haya que cambiar la zona horaria, ejecutamos timedatectl set-timezone Europe/Madrid

• Nos creamos el fichero /etc/realmd.conf con la siguiente configuración, hay que asegurarse que la ruta a la OU es la misma que la que hemos creado para la nueva máquina:

[users]

default-home = /home/%D/%U

default-shell = /bin/bash

[active-directory]

default-client = sssd

os-name = Ubuntu Desktop

os-version = 22.04 LTS

[service]

automatic-install = no

[jrrg.local]

fully-qualified-names = yes

automatic-id-mapping = no

user-principal = yes

manage-system = yes

computer-ou= OU=Equipos,OU=JRRG,DC=jrrg,DC=local

dyndns_update = true

dyndns_refresh_interval = 43200

dyndns_update_ptr = true

dyndns_ttl = 3600

• Ahora configuramos la creación automática del home del usuario, para ello, ejecutamos pam-auth-update y seleccionamos la opción de crear el directorio home al hacer login:

• Una vez que se ha instalado y configurado todo, vamos a unir el equipo linux al dominio, para ello, ejecutamos realm join –verbose –user=Administrador jrrg.local:

• Si accedemos a nuestro controlador de dominio, podemos ver el equipo unido al dominio:

• Una vez unido al dominio debemos modificar a True la entrada ldap_id_mapping en el fichero /etc/sssd/sssd.conf para poder hacer login, también podemos añadir el sufijo del dominio por defecto con el parámetro

default_domain_suffix = JRRG.LOCAL

full_name_format = %1$s

[sssd]

domains = jrrg.local

config_file_version = 2

services = nss, pam

default_domain_suffix = JRRG.LOCAL

full_name_format = %1$s

[domain/jrrg.local]

default_shell = /bin/bash

krb5_store_password_if_offline = True

cache_credentials = True

krb5_realm = JRRG.LOCAL

realmd_tags = manages-system joined-with-adcli

id_provider = ad

fallback_homedir = /home/%d/%u

ad_domain = jrrg.local

use_fully_qualified_names = True

ldap_id_mapping = True

access_provider = ad

• Para que los cambios se apliquen reiniciamos el servicio sssd, con systemctl restart sssd y con systemctl status sssd vemos el estado del servicio:

• Si quisiéramos sacar el equipo del dominio debemos de ejecutar realm leave –verbose –user=Administrador JRRG.LOCAL
• Para que los usuarios del dominio puedan logarse, se debe reconfigurar la pantalla de login, para ello, añadimos al fichero /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf la línea, greeter-show-manual-login=true:

• Ahora cerramos la sesión del equipo con el usuario local, y vamos a acceder con uno de nuestros usuarios del dominio:

• Como podemos ver, ya estoy logueado con el usuario del dominio:

• Para dar permisos de sudo a los usuarios del dominio se pueden crear grupos de seguridad en AD para que al añadirlos se les apliquen esos permisos por pertenecia al grupo.
• Para habilitar un grupo de AD y que tenga permisos de sudo, en el fichero de /etc/sudoers añadir:

%<nombre_grupo_AD> ALL=(ALL:ALL) ALL

Ejemplo:

%DomainAdminsJRRG ALL=(ALL:ALL) ALL

• Ahora desde el equipo Ubuntu 22.04 LTS vamos a verificar, que podemos acceder al recurso compartido que creamos anteriormente en nuestro controlador de dominio, y que podemos crear un documento.
• Instalamos smbclient con apt-get install smbclient y ejecutamos smbclient –list 192.168.5.51 o podemos poner en lugar de la direccion IP del servidor el nombre, como podemos ver, accedemos a los recursos compartidos de nuestro controlador de dominio:

• Accedemos al recurso compartido (share) que creamos anteriormente y nos creamos un fichero .txt para verificar que todo esto funciona correctamente, nos conectamos al servidor, nos pedirá las credenciales de usuario, nos ubicamos sobre el recurso compartido y añadimos el fichero .txt:

Saludos y espero que os resulte de ayuda

• Accedemos a la Configuración avanzada del Sistema, sobre la pestaña Nombre de equipo > Cambiar introducimos el nombre de nuestro dominio:

• Nos pedirá las credenciales del administrador del dominio para poder unirlo:

• Como podemos ver, se ha unido correctamente a nuestro dominio:

• Ahora nos pide que reiniciemos el equipo:

• Una vez reiniciado, vamos a acceder al equipo con uno de los usuarios que nos creamos anteriormente en el Active Directory:

• Aquí vemos el equipo unido al dominio:

• Si accedemos al controlador de dominio podemos ver el equipo como miembro del dominio:

• Ahora desde el equipo windows 10 vamos a verificar, que podemos acceder al recurso compartido que creamos anteriormente en nuestro controlador de dominio, y que podemos crear un documento:

• Como podemos ver, nos aparecen los recursos compartidos por el servidor:

• Accedemos al recurso compartido (share) que creamos anteriormente y nos creamos un fichero .txt para verificar que todo esto funciona correctamente:

Saludos y espero que os sea de ayuda

• Instalar Ubuntu Desktop con OpenLDAP, generando un dominio con identificador jrrg.local:
• Empezaremos a preparar el equipo con Ubuntu Desktop 22.04.3 LTS, lo primero será activar el usuario root, accedemos a un terminal y ejecutamos passwd root, introducimos la password del usuario root y listo:

• Para iniciar sesion como root en el modo gráfico, lo primero que vamos a realizar será editar el fichero custom.conf, nano /etc/gdm3/custom.conf, localizar la categoría [security] e introducimos el texto AllowRoot=true:

• Ahora editamos el archivo gdm-password, nano /etc/pam.d/gdm-password, localizamos la línea auth required so user != root quiet_success y la comentamos con #:

• Para terminar hacemos un ultimo ajuste en el archive .profile, nano /root/.profile, localizamos una línea con este contenido mesg n 2> /dev/null || true y lo sustituimos por if `tty -s`; then mesg n fi:

• Ahora ya podemos iniciar sesión como root en el modo gráfico:

• Actualizamos el sistema operativo con las últimas versiones de los paquetes disponibles en los repositorios, para ello, ejecutaremos apt-get update && apt-get upgrade:

• Editamos el fichero hosts, nano /etc/hosts e introducimos el nombre del servidor, tanto el nombre DNS como el nombre NETBIOS:

• A continuación vamos a configurar la conexión de red, para ello, editamos el fichero nano /etc/netplan/01-network-manager-all.yaml:

• Aplicamos la nueva configuración de red con netplan apply:

• Si ejecutamos ip a podmeos ver que los cambios se han aplicado:

• Ahora vamos a cambiarle el nombre al equipo, para ello, ejecutamos hostnamectl set-hostname dc03aso y reiniciamos el equipo para que se apliquen los cambios:

• Una vez que hemos realizado la configuraciones previas, vamos a instalar el software necesario para implementar
• OpenLDAP, para ello ejecutamos el comando apt-get install slapd ldap-utils –y:

• Nos pedirá la contraseña del administrador del directorio LDAP:

• Una vez concluida la instalación, podemos verificar que todo está correcto usando el comando slapcat, dónde obtenemos la información de la base de datos LDAP, su salida se produce en formado LDIF:

• A continuación, instalaremos la librería NSS para LDAP, esta librería ofrece una interfaz para acceder y configurar distintas bases de datos utilizadas para almacenar cuentas de usuario, apt-get install libnss-ldap:

• Nos solicita la dirección URi del servidor LDAP, introducimos su dirección IP:

• Introducimos el Distinguised Name (DN) del dominio:

• Le indicamos la version de LDAP que vamos a utilizar, en este caso la 3:

• Le indicamos si las utilidades que utilicen PAM deberán comportarse del mismo modo que cuando cambiamos contraseñas locales, seleccionamos Sí:

• Nos pregunta si queremos que sea necesario identificarse para realizar consultas en la base de datos de LDAP, seleccionamos No:

• Le indicamos el nombre de la cuenta LDAP que tendrá privilegios para realizar cambios en las contraseñas:

• Le indicamos la contraseña:

• El siguiente paso será crear la estructura del directorio, crearemos un archivo que va a contener los tipos de objeto básicos del directorio, para ello, ejecutamos nano ldif e introducimos este contenido:

dn: ou=usuarios,dc=jrrg,dc=local

objectClass: organizationalUnit

ou: usuarios

dn: ou=grupos,dc=jrrg,dc=local

objectClass: organizationalUnit

ou: grupos

• Ahora, debemos añadir la información a la base de datos OpenLDAP, para ello, ejecutamos ldapadd -x -D cn=admin,dc=jrrg,dc=local -W -f baseldap.ldif:

• A continuación, añadiremos la unidad organizativa para los equipos, para ello, ejecutamos nano equipos.ldif e introducimos este contenido:

dn: ou=equipos,dc=jrrg,dc=local

objectClass: organizationalUnit

ou: equipos

• Ahora, debemos añadir la información a la base de datos OpenLDAP, para ello, ejecutamos ldapadd -x -D cn=admin,dc=jrrg,dc=local -W -f equipos.ldif:

• Ahora vamos a añadir usuarios, para ello, ejecutamos nano ldif e introducimos este contenido:

dn: uid=usuario1,ou=usuarios,dc=jrrg,dc=local

objectClass: inetOrgPerson

objectClass: posixAccount

objectClass: shadowAccount

uid: usuario1

sn: usu1

givenName: usuario1

cn: usuario1

displayName:usuario1

uidNumber:2000

gidNumber:20000

userPassword: Pa$sw0rd

gecos: usuario1

loginShell: /bin/bash

homeDirectory: /home/usuario1

shadowExpire: -1

shadowFlag: 0

shadowWarning: 7

shadowMin: 8

• Introducimos el comando ldapadd -x -D cn=admin,dc=jrrg,dc=local -W -f usuarios.ldif:

• Modificamos el fichero nano ldif y añadimos estos tres usuarios más, los campos uidNumber y gidNumber serán 2001 (usuario2), 2002 (usuario3) y 2003 (usuario4):

• Ahora vamos a crear dos grupos, para ello, ejecutamos nano ldif e introducimos este contenido:

dn: cn=grupo1,ou=grupos,dc=sor,dc=local

objectClass: posixGroup

cn: grupo1

gidNumber: 10000

• Introducimos el comando ldapadd -x -D cn=admin,dc=jrrg,dc=local -W -f grupos.ldif:

• Modificamos el fichero nano ldif y añadimos un grupo más, el campo gidNumber será 10001 (grupo2):

• Ahora podemos comprobar todo lo configurado, para ello podemos utilizar, el comando ldapsearch , que nos permite hacer una búsqueda en el directorio, ldapsearch -xLLL -b «dc=jrrg,dc=local» uid=usuario1 sn givenName cn:

• Con el comando slapcat nos muestra el contenido completo del directorio:

• A continuación, vamos a instalar y configurar la interfaz web LDAP Account Manager para administrar OpenLDAP, para ello, ejecutamos apt-get install ldap-account-manager -y:

• Abrimos el navegador y escribimos en la barra de direcciones, http://localhost/lam
• Esto nos lleva a la página inicial de LDAP Account Manager, para iniciar la configuración, basta con hacer clic sobre el enlace LAM configuration:

• Al hacerlo, llegamos a una página donde tenemos dos opciones, Editar la configuración general y Editar perfiles del servidor:

• Comenzaremos editando la configuración general para establecer el perfil del servidor, para ello, hacemos clic sobre Editar la configuración general.
• Antes de entrar en la opción elegida, LDAP Account Manager nos pide la contraseña maestro, esta contraseña no está relacionada con la que escribimos para la administración del directorio OpenLDAP, sino que es propia de LDAP Account Manager, su valor predeterminado es lam, aunque luego la vamos a cambiar.
• Escribimos la contraseña y hacemos clic sobre en OK:

• Aquí dejaremos todos los valores predeterminados, solo vamos a cambiar la contraseña maestra de LDAP Account Manager:

• A continuación, vamos a editar el perfil del servidor:

• Introducimos la nueva password:

• Nos muestra la página Configuración de los perfiles y como puedes ver, la página se divide en cuatro puntos:
• Configuración general, que contiene la información global del servidor LDAP, como el nombre del host o las características de seguridad.
• Tipos de cuentas, donde se indican las diferentes clases de cuentas que administraremos, como usuarios, grupos o equipos.
• Módulos, que contiene la lista de módulos que definen las características de las cuentas que vamos a administrar (si son cuentas Unix, Samba, Koalab, etc).
• Preferencias del módulo, que contiene aspectos específicos del módulo que hayamos seleccionado en la solapa anterior.
• Nosotros veremos solo las dos primeras.
• En Configuración general, vanos a configurar estos parámetros:

• Ahora accedemos a Tipos de cuentas, La sección Tipos de cuentas disponibles muestra una lista de los posibles tipos de cuentas, podemos activar cualquiera de ellos haciendo clic en el signo más que hay junto a cada uno de ellos y la sección Tipos de cuentas activos contiene los tipos de cuentas que se encuentran vigentes en nuestro Sistema:

• Una vez que hemos completado las preferencias, tendremos LDAP Account Manager listo para comenzar a utilizarlo, accedemos a la página principal y nos autenticamos:

• Aqui vemos los usuarios y grupos que tenemos creados, como también podemos ver dese aquí podremos crear nuevos usuarios y nuevos grupos:

• En el grupo1 vamos a añadir como miembros al usuario1 y usuario2 y en el grupo2 vamos a añadir como miembros al usuario3 y usuario4:

• Si volvemos a la configuración de los perfiles del servidor, he creado un tipo de cuenta nueva para los Equipos:

• Ahora si accedemos al panel principal de LDAP Account Manager, podemos ver, que ya podremos añadir equipos al dominio:

Saludos y espero que os sea de ayuda

• Actualizamos el sistema operativo con las últimas versiones de los paquetes disponibles en los repositorios, para ello, ejecutaremos apt-get update && apt-get upgrade:

• Editamos el fichero hosts, nano /etc/hosts e introducimos el nombre del servidor, tanto el nombre DNS como el nombre NETBIOS:

• A continuación vamos a configurar la conexión de red, para ello, editamos el fichero nano /etc/netplan/01-network-manager-all.yaml:

• Aplicamos la nueva configuración de red con netplan apply:

• Si ejecutamos ip a podmeos ver que los cambios se han aplicado:

• Ahora vamos a cambiarle el nombre al equipo, para ello, ejecutamos hostnamectl set-hostname dc02aso y reiniciamos el equipo para que se apliquen los cambios:

• Seguiremos por instalar los paquetes necesarios, además de los paquetes propios de Samba necesitaremos disponer de algunos otros, que deberán estar preinstalados antes de comenzar con el proceso de configuración, aunque todos ellos están en los repositorios. Son los siguientes:
• samba: servidor de archivos, impresión y autenticación para SMB/CIFS.
• smbclient: clientes de línea de comandos para SMB/CIFS.
• krb5-config: Archivos de configuración para Kerberos Version 5.
• winbind: Servicio para resolver información sobre usuarios y grupos de servidores Windows NT.
• Ejecutamos este comando, apt-get install samba krb5-config winbind smbclient:

• Cuando llegue el momento de instalar Kerberos, nos preguntará por el reino, que se refiere al nombre del dominio, en nuestro caso JRRG.LOCAL:

• Nos solicita el nombre de los servidores de Kerberos para nuestro reino, en este caso, se refiere a los controladores de dominio que tengamos definidos, en nuestro caso, sólo tenemos uno que se llama dc02aso:

• Nos solicita el servidor administrativo para nuestro reino de Kerberos, como sólo tenemos uno, volvemos a escribir su nombre, dc02aso:

• Como podemos ver, la instalación finaliza satisfactoriamente:

• Una vez completada la instalación de los paquetes, vamos a configurar samba:
• Lo primero que haremos será renombrar el fichero de configuración de samba, ya que para poder realizar la promoción de este servidor a controlador de dominio debe utilizar su propio fichero de configuración de samba personalizado, mv /etc/samba/smb.conf /etc/samba/smb.conf.orig:

• Después de esto, ya estaría preparado nuestro equipo Ubuntu para promoverlo a controlador de dominio samba, para ello, usaremos el comando samba-tool domain provision, y lo haremos de forma interactiva, para que sea el propio comando el que nos solicite los valores que necesite y, cuando sea posible, nos sugiera sus valores predeterminados, dejamos todos los valores como nos va indicando y solo cambiamos el DNS forwarder que ponemos el de google, también nos indica que configuremos la password del Administrator del dominio:

• Con todo esto que hemos realizado, además de configurarse Samba de forma adecuada, se ha generado un archivo de configuración para Kerberos en la ruta /var/lib/samba/private/krb5.conf, solo tenemos que copiarlo a la ubicación adecuada, cp /var/lib/samba/private/krb5.conf /etc/:

• Ahora vamos a ajustar la resolución de nombres, y comenzaremos deteniendo los servicios implicados, systemctl stop smbd nmbd winbind systemd-resolved:

• Los deshabilitamos, para que no vuelvan a iniciarse si reiniciamos el equipo, systemctl disable smbd nmbd winbind systemd-resolved:

• Nos aseguraremos de que el servicio samba-ad-dc se podrá iniciar sin dificultades, evitando cualquier enmascaramiento que pueda existir, systemctl unmask samba-ad-dc:

• Eliminamos el archivo conf que, en realidad, será un enlace a ../run/systemd/resolve/stub-resolv.conf, para comprobarlo, comenzamos por consultar su entrada en el directorio, ls -l /etc/resolv.conf:

• Procedemos a eliminar el enlace, rm /etc/resolv.conf:

• Utilizamos el editor nano para crear un nuevo archivo que lo sustituya, nano /etc/resolv.conf:

• Editamos los valores adecuados para nuestro dominio:

domain jrrg.local

nameserver 127.0.0.1

• Volvemos a iniciar el servicio samba-ad-dc, systemctl start samba-ad-dc:

• Lo habilitamos, para que también se inicie automáticamente al arrancar el Sistema, systemctl enable samba-ad-dc:

• Ahora vamos a comprobar la instalación, para consultar el nivel de nuestro dominio, es decir, el tipo de servidor que hemos implementado, ejecutamos este commando, samba-tool domain level show:

• Ahora vamos a crear cuatro cuentas de usuario, al igual que hicimos para el controlador de dominio windows, para ello, ejecutamos este commando, samba-tool user create nombreusuario:

• Confirmamos que el servidor DNS funciona de manera adecuada.
• Comprobamos el servicio LDAP sobre el protocolo TCP, para lo que escribiremos, host -t SRV _ldap._tcp.jrrg.local, si todo es correcto, recibiremos una respuesta parecida a ésta, _tcp.jrrg.local has SRV record 0 100 389 dc02aso.jrrg.local.

• Comprobamos el registro SRV para el protocolo Kerberos sobre UDP, para lo que escribiremos, host -t SRV _kerberos._udp.jrrg.local, si todo es correcto, recibiremos una respuesta parecida a ésta, _udp.jrrg.local has SRV record 0 100 88 dc02aso.jrrg.local.

• Para terminar, comprobamos la resolución del nombre de nuestro servidor, host -t A dc02aso.jrrg.local, si todo es correcto, recibiremos una respuesta parecida a ésta, jrrg.local has address 192.168.5.52:

• Comprobamos con nslookup que nuestro dominio resuelve correctamente:

• Ahora vamos a comprobar el funcionamiento de Kerberos para ver si nuestros usuarios pueden autenticar de forma correcta, para ello, ejecutamos este comando, smbclient -L dc02aso.jrrg.local -U ‘administrator’:

• Para terminar, si reiniciásemos nuestro servidor o nuestra conexión de red, el fichero resolv.conf se restablecería con la configuración original y todo dejaría de funcionar, ya que no tendríamos resolución de nombres, para evitar que esto no suceda lo que vamos a hacer es protegerlo contra escritura, para ello, ejecutamos el comando chattr +i /etc/resolv.conf:

• Una vez ejecutado, podemos consultar si está protegido, ejecutando el comando lsattr /etc/resolv.conf:

Saludos y espero que os sea de ayuda

En este primer post, vamos a ver como instalar y configurar Active Directory Domain Services en Windows Server 2022.

• Empezamos la configuración de nuestro controlador de dominio asignándole un nombre y una dirección IP estática, y como DNS le asignamos su propia dirección IP, ya que se encargará de toda la gestión DNS de nuestro entorno:

• Abrimos el Administrador del servidor y agregamos roles y características:

• Se nos abre el siguiente asistente, clic en siguiente:

• Elegimos la opción instalación basada en características o roles:

• Seleccionamos nuestro servidor dc01aso:

• Ahora agregamos el rol de Servicios de dominio de Active Directory:

• Agregamos las características:

• Continuamos con la instalación del rol:

• Todas las características que requiere nuestro controlador de dominio de Active Directory se seleccionan por defecto por lo que hacemos clic en siguiente:

• Aquí nos muestra información sobre Active Directory, clic en siguiente:

• Iniciamos el despliegue de la función Servicios de dominio de Active Directory, clic sobre “Instalar”:

• Una vez finalizada la instalación cerramos y reiniciamos nuestro controlador de dominio:

• Tras el reinicio nos abrimos el Administrador del servidor y promovemos este servidor a controlador de dominio:

• Se nos abre el siguiente asistente y añadimos un nuevo bosque, ya que este es nuestro primer controlador de dominio en la infraestructura, escribimos nuestro nombre de dominio raíz:

• Seleccionamos el nivel funcional de nuestro bosque, en este caso Windows Server 2016, ya que no tenemos otros controladores de dominio sobre Windows Server 2003, 2008 0 2012. También seleccionamos la función de DNS en la que apoyaremos toda la infraestructura de nombres de nuestra red, aparte de que es un requisito imprescindible para Active Directory, luego introducimos una contraseña segura que será necesaria en caso de restauración de Active Directory:

• Windows no puede encontrar una delegación para el servidor DNS ya que éste es el primer bosque de nuestro entorno, hacemos clic en siguiente:

• Agregamos el nombre NETBIOS:

• Las rutas de acceso las dejamos por defecto:

• Nos muestra un resumen de las opciones configuradas:

• Vemos que la comprobación de los requisitos previos está correcta, clic sobre Instalar:

• Comienza el proceso de instalación y promoción a controlador de dominio:

• Una vez que la instalación termina, nuestro servidor se reinicia automáticamente, y tras el reinicio, introducimos las credenciales de Administrador que será la cuenta del administrador del dominio:

• Con esto ya tendríamos nuestro servidor promovido a controlador de dominio:

• Ahora vamos a abrir la consola de DNS y agregamos una zona nueva para la resolución inversa:

• Vamos configurando el asistente con los siguientes parámetros:

• Para verificar que la zona de resolución inversa está funcionando correctamente, sobre la zona de búsqueda directa y sobre las propiedades del registro tipo A de nuestro servidor controlador de dominio, marcamos el check PTR:

• Y como vemos en nuestra zona de búsqueda inversa se actualiza el registro:

• Otra de las configuraciones que debemos realizar en nuestro DNS es agregar los reenviadores (pondremos los DNS públicos de google 8.8.8.8 y 8.8.4.4, el DNS público de IBM 9.9.9.9 especializado en bloquear malware) y el 1.1.1.1 para que el servidor DNS resuelva también dominios externos, para ello hacemos lo siguiente:

• Así quedarían configurados nuestros reenviadores:

• Configuramos la dirección IP que dará servicio a las consultas DNS:

• Con todo esto, ya tendríamos nuestro controlador de dominio implementado en nuestra infraestructura, ya podríamos empezar a crear usuarios y a organizar el Active Directory.
• Ahora vamos a crear varias unidades organizativas, grupos y usuarios.
• Estas son las unidades organizativas que hemos creado:

• Ahora vamos a crear varios usuarios:

• Crearemos dos grupos, cada uno de ellos con dos usuarios:

• Ahora vamos a crear una carpeta compartida en nuestro controlador de dominio llamada share, con permisos de escritura para los grupos creados, para el uso compartido avanzado le vamos a asignar control total a Todos, y luego filtraremos los permisos a los grupos creados con los permisos NTFS en Seguridad > Opciones avanzadas:

Saludos y espero que os resulte de ayuda

En estos posts vamos a mostrar como desplegar, instalar y configurar servicios de directorios en sistemas operativos Windows y Linux.

Este post lo vamos a dividir en:

• Instalar y configurar Active Directory en Windows Server 2022
• Instalar y configurar Controlador de dominio Samba
• Instalar y configurar Controlador de dominio OpenLDAP
•  Agregar Windows 10 como cliente del dominio Windows Server 2022
• Agregar Ubuntu desktop 22.04 como cliente del dominio Windows Server 2022
• Agregar Windows 10 como cliente del dominio Samba
• Agregar Ubuntu desktop 22.04 como cliente del dominio Samba
• Agregar Ubuntu desktop 22.04 como cliente del dominio OpenLDAP

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo solucionar el problema de la replicación de la carpeta SYSVOL entre los controladores de dominio.

• Si accedemos al visor de eventos en cualquiera de nuestros controladores de dominio, y nos encontramos con estos dos ID de eventos 4612 y 5002, tenemos un problema en la replicación DFSR de la carpeta SYSVOL:

• Para solucionar este problema, lo primero que vamos a realizar será parar el servicio Replicación DFS en todos los controladores de dominio:

• En la herramienta ADSIEDIT.MSC, modificamos el siguiente DN y dos atributos en el controlador de dominio que deseamos convertir en autoritativo (preferiblemente el emulador PDC, que suele ser el más actualizado para contenidos de replicación sysvol):

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE

msDFSR-options=1

• Modificamos el siguiente DN y atributo único en todos los demás controladores de dominio en ese dominio:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE

• Ahora forzamos la replicación de Active Directory en todo el dominio y validamos que es correcto en todos los DC con repadmin /syncall dc01 /APed:

• Iniciamos el servicio DFSR en el controlador de dominio que se configuró como autorizado, es decir, DC01:

• Ahora veremos el ID de evento 4114 en el registro de eventos de DFSR, lo que indica que la replicación de sysvol ya no se está replicando:

• En la herramienta ADSIEDIT.MSC, volvemos a modificar el siguiente DN y este atributo en el controlador de dominio que convertimos en autoritativo, en nuestro caso DC01:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=TRUE

• Ahora volvemos a forzar la replicación de Active Directory en todo el dominio y validamos que es correcto en todos los DC con repadmin /syncall dc01 /APed:

• Volvemos a modificar el siguiente DN y atributo único en todos los demás controladores de dominio en ese dominio:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=TRUE

• Ahora paramos el servicio de Replicación DFS con Invoke-Command -ComputerName dc01, dc02 -ScriptBlock {Stop-Service DFSR} y volvemos a iniciarlo con Invoke-Command -ComputerName dc01, dc02 -ScriptBlock {Start-Service DFSR}:

• Ejecutamos el siguiente comando DFSRDIAG POLLAD desde un símbolo del sistema con permisos de administrador en el mismo servidor que configuramos como autorizado, DC01:

• Ahora veremos el ID de evento 4602 en el registro de eventos de DFSR, lo que indica que se ha inicializado la replicación de sysvol, ese controlador de dominio ahora ha realizado una replicación D4 de sysvol:

• Para terminar, ejecutamos el siguiente comando DFSRDIAG POLLAD desde un símbolo del sistema con permisos de administrador en todos los controladores de dominio no autoritativos, DC02:

• En el DC02, veremos el ID de evento 4604 en el registro de eventos de DFSR, indicando que la carpeta SYSVOL se ha replicado correctamente:

• Para verificar que la carpeta SYSVOL se está replicando correctamente accedemos a \\Controladordominio\netlogon y en el dc01 creamos un fichero llamado testdc01 que se debe de replicar en dc02, y en el dc02 creamos un fichero llamado testdc02 que se debe de replicar en dc01:

NOTA: Nos podemos encontrar con este error al ejecutar el comando DFSRDIAG POLLAD:

• Para solucionarlo nos abrimos un PowerShell como administrador y ejecutamos Install-WindowsFeature RSAT-DFS-Mgmt-Con:

• Una vez instaladas las herramientas remotas RSAT para DFS, volvemos a ejecutar DFSRDIAG POLLAD y veremos que se ejecuta correctamente:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como transferir los roles FSMO entre Controladores de dominio ejecutando un comando con PowerShell, en otros posts realizados, hemos visto como transferir estos roles a través de las consolas de Windows, en esta ocasión, vamos a ver cómo hacerlo con PowerShell.

• Todos los dominios de Active Directory disponen de cinco roles FSMO (Flexible Single Master Operations), los roles FSMO son funciones específicas que realizan los controladores de dominio a nivel de bosque o de dominio:

• Para ver los controladores de dominio que tenemos en nuestra infraestructura nos abrimos un PowerShell con permisos de administrador en cualquiera de nuestros controladores de dominio, y ejecutamos netdom query dc:

• Sobre cualquiera de nuestros controladores de dominio vamos a ejecutar el siguiente comando netdom query fsmo para ver quien tiene asignados estos roles FSMO, y cómo podemos ver todos los roles los tiene asignados nuestro primer controlador de dominio dc01:

• Para transferir los roles fsmo del controlador de dominio dc01 al controlador de domino dc02, ejecutamos el siguiente comando, Move-ADDirectoryServerOperationMasterRole -Identity «DC02» -OperationMasterRole SchemaMaster, RIDMaster, InfrastructureMaster, DomainNamingMaster, PDCEmulator:

• Volvemos a ejecutar el comando netdom query fsmo, y como podemos ver, los roles fsmo ya los tiene asignados el dc02:

• También podemos usar este otro comando Move-ADDirectoryServerOperationMasterRole -Identity «DC01» -OperationMasterRole 0, 1, 2, 3, 4 ahora hemos transferido todos los roles del dc02 al dc01:

• Volvemos a ejecutar el comando netdom query fsmo, y como podemos ver, los roles fsmo ya los tiene asignados el dc01:

• Cada número se corresponde con los roles fsmo:

0    PDCEmulator
1    RIDMaster
2    InfrastructureMaster
3    SchemaMaster
4    DomainNamingMaster

Saludos y espero que os resulte de ayuda

En este post vamos a ver como migrar un controlador de dominio con Windows Server 2019 a Windows Server 2022.

En este laboratorio, sólo tenemos un controlador de dominio con Windows Server 2019, el cual lo vamos a migrar a Windows Server 2022.

• Como podemos ver, tenemos un controlador de dominio en nuestra infraestructura con el sistema operativo MS Windows Server 2019 Standard:

• Los roles o funciones que tiene este servidor son los siguientes, “Servicios de dominio de Active Directory, DNS y DHCP”:

• Ahora debemos desplegar un nuevo server con el sistema operativo MS Windows Server 2022 Standard, lo actualizamos y lo configuramos como un controlador de dominio adicional:

• Empezamos la configuración de nuestro controlador de dominio adicional asignándole un nombre y una dirección IP estática, como DNS primario le asignamos la dirección IP del controlador de dominio principal y como DNS secundario no configuramos nada, más tarde, le configuraremos su propia dirección IP:

• Ahora agregamos este equipo como un miembro más del dominio:

• Le proporcionamos las credenciales del Administrador del dominio y reiniciamos el equipo:

• Como podemos ver se ha agregado correctamente, reiniciamos el servidor:

• Ahora nos vamos a la consola de Usuarios y equipos de Active Directory en el controlador de dominio principal y cómo podemos ver, este equipo ya pertenece al dominio ragasys.net:

• Iniciamos sesión en DC02 (Servidor que hemos terminado de unir al dominio) como Administrador del dominio:

• En el Administrador del servidor agregamos roles y características:

• Se nos abre el asistente típico para desplegar los roles y características, hacemos clic en siguiente:

• Sobre Tipo de instalación, elegimos la opción, Instalación basada en características o roles:

• Seleccionamos nuestro servidor dc02:

• Sobre Roles de servidor, marcamos la opción Servicios de dominio de Active Directory:

• Agregamos las características:

• Clic en siguiente:

• Todas las características que requiere nuestro controlador de dominio de Active Directory se seleccionan por defecto por lo que hacemos clic en siguiente:

• Información sobre Active Directory :

• Sobre Confirmación, iniciamos el despliegue del rol Servicios de dominio de Active Directory, marcamos que reinicie automáticamente en caso necesario y clic sobre Instalar:

• Comienza el despliegue de los Servicios de dominio de Active Directory:

• Una vez finalizada la instalación cerramos el asistente:

• Sobre el Administrador del servidor y promovemos este servidor a controlador de dominio:

• Sobre Configuración de implementación, marcamos la opción Agregar un controlador de dominio a un dominio existente, seleccionamos nuestro nombre de dominio y le proporcionamos las credenciales del Administrador del dominio, clic en Siguiente:

• Sobre las Opciones del controlador de dominio, seleccionamos la función de DNS, ya que es un requisito imprescindible para Active Directory, también seleccionamos que sea Catálogo Global y luego introducimos una contraseña segura que será necesaria en caso de restauración de Active Directory:

• Sobre Opciones de DNS, la dejamos por defecto, ya que el DNS lo tenemos configurado sobre el controlador de dominio principal, por lo que el controlador de dominio adicional se va a configurar automáticamente con la misma configuración que el principal:

• En Opciones adicionales, le indicamos que replique desde el controlador de dominio principal:

• Sobre Rutas de acceso las dejamos por defecto:

• Sobre Revisar opciones, nos muestra un resumen de las configuraciones seleccionadas, clic en Siguiente:

• Sobre Comprobación de requisitos previos, nos muestra que todas las comprobaciones se realizaron correctamente, clic a Instalar:

• Sobre Instalación, podemos ver como comienza a instalar y configurar los Servicios de dominio de Active Directory, una vez instalados, el servidor se va a reiniciar automáticamente:

• Tras el reinicio, nos abrimos la consola de Usuarios y equipos de Active Directory, y cómo podemos ver, este equipo ya está como un Domain Controller más de nuestra infraestructura:

• También podemos comprobarlo con el comando netdom query dc:

• Ahora accedemos a la configuración TCP/IPv4 de nuestro controlador de dominio recién desplegado y configuramos como DNS principal su propia dirección IP y como DNS secundario la dirección IP del controlador de dominio principal:

• Con el comando repadmin /showrepl, verificamos que nuestro nuevo controlador de dominio está replicando con el controlador de domino principal:

• Con el comando dcdiag /test:replications comprobamos la replicación y cualquier error de replicación entre los controladores de dominio:

• Con el comando dcdiag /test:connectivity comprobamos la conectividad y cualquier error de conexión entre los controladores de dominio:

• Con el comando dcdiag /test:DNS comprobamos que el DNS esté funcionando correctamente:

• Estas mismas pruebas de diagnóstico, las debemos de realizar sobre el controlador de domino principal y así nos aseguramos que nuestros controladores de dominio estén en perfecto estado.
• Una vez que tenemos agregado un controlador de dominio adicional con sistema operativo MS Windows Server 2022, y por tanto, superior a MS Windows Server 2019, vamos a proceder a transferir los roles FSMO del controlador de dominio principal al adicional, así el nuevo controlador de dominio con el Server 2022 quedará como principal.
• Todos los dominios de Active Directory disponen de cinco roles FSMO (Flexible Single Master Operations), los roles FSMO son funciones específicas que realizan los controladores de dominio a nivel de bosque o de dominio:

• Sobre cualquiera de nuestros controladores de dominio vamos a ejecutar el siguiente comando netdom query fsmo para ver quien tiene asignados estos roles FSMO, y como podemos ver todos los roles los tiene asignados nuestro primer controlador de dominio con Windows Server 2019 (dc01):

• Ahora lo que vamos a realizar será transferir los cinco roles FSMO al controlador de dominio adicional (Windows Server 2022), convirtiéndolo así en el domain controller principal, para ello utilizaremos las siguientes herramientas.
• Para transferir los roles de PDC Emulator, RID Master e Infraestructure Master vamos a utilizar la herramienta Usuarios y equipos de Active Directory, que nos la abrimos en nuestro controlador de dominio adicional con MS Windows Server 2022:

• Primero vamos a transferir el RID Master:

• Segundo vamos transferir el PDC Emulator:

• En tercer lugar vamos a transferir el Infrastructure Master:

• En cuarto lugar, vamos a transferir el Domain Naming Master, para ello vamos a utilizar la herramienta Dominios y Confianzas Active Directory, que nos la abrimos en nuestro controlador de dominio adicional con MS Windows Server 2022:

• En quinto lugar, vamos a transferir el Schema Master, para ello vamos a utilizar la herramienta de consola Esquema de Active Directory, para poder utilizar esta herramienta tenemos que registrar la dll dll y personalizarnos una consola mmc, para ello, en nuestro controlador de dominio principal con MS Windows Server 2019 hacemos lo siguiente:

• Al intentar cambiarlo nos da el siguiente error, ya que como destino se encuentra el mismo controlador de dominio:

• Procedemos a cambiar el controlador de dominio de Active Directory:

• Como podemos ver ya tenemos como destino el controlador de dominio adicional:

• Como podemos ver, ya tenemos como Schema Master al controlador de dominio adicional (Windows server 2022):

• Una vez que hemos realizado la transferencia de los cinco roles FSMO entre los controladores de dominio, sobre cualquiera de ellos vamos a ejecutar el siguiente comando netdom query fsmo para verificar que la transferencia se ha realizado correctamente, y como podemos ver, todos los roles los tiene asignados el que estaba como controlador de dominio adicional, lo hemos convertido por tanto en el controlador de dominio principal:

• Si los cinco roles FSMO no los transferimos de forma manual, el proceso de despromoción los transferirá de forma automática a cualquier Controlador de dominio disponible, a mí personalmente prefiero hacerlo de forma manual.

• Ahora ya podemos despromocionar como controlador de dominio el servidor con MS Windows Server 2019, para ello, vamos a realizar lo siguiente:
• Nos abrimos el Administrador del servidor y pinchamos sobre la opción Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Sobre Roles de servidor, desmarcamos el check “Servicios de dominio de Active Directory” y sobre el asistente que se nos abre hacemos clic en “Quitar características”:

• Se nos abre el siguiente asistente, que nos indica que tenemos que disminuir el nivel, por lo tanto, hacemos clic sobre “Disminuir el nivel de este controlador de dominio”:

• Se nos vuelve a abrir otro asistente, dónde verificamos que las credenciales sean las correctas, esta es la opción más importante del asistente, ya que al ser un controlador de dominio adicional o secundario NO aparece la opción de marcar el check “Último controlador de dominio en el dominio”, clic sobre “siguiente”:

• Marcamos el check “Continuar con la eliminación” y clic sobre siguiente:

• En las opciones de eliminación marcamos el check para “Quitar delegación de DNS”, introducimos las credenciales y clic sobre “siguiente”:

• Introducimos la nueva contraseña para el administrador local, al eliminar el rol de controlador de dominio, la cuenta de usuario de administrador pasará a formar parte de los usuarios locales de la máquina, clic sobre “siguiente”:

• Revisamos y hacemos clic sobre “Disminuir nivel”, al finalizar la operación se reiniciará el servidor:

• Como podemos ver comienza el proceso de degradación de nuestro controlador de dominio:

• El sistema nos va a indicar que ha disminuido el nivel del controlador de dominio, y se va a reiniciar automáticamente.
• Una vez que el equipo ha reiniciado verificamos que este servidor ya no es un controlador de dominio, en el Administrador del servidor nos vuelve a indicar con una advertencia “Promover este servidor a controlador de dominio”:

• Sobre la consola de Usuarios y equipos de Active Directory del Controlador de dominio principal, podemos ver como el Controlador de dominio secundario ha pasado a formar parte del dominio como un equipo más de éste:

• Para desinstalar los binarios de los Servicios de dominio de Active Directory, lo haremos a través del Administrador del Servidor > Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Desmarcamos los checks, Servicios de dominio de Active Directory y Servidor DNS:

• Para los Servicios de dominio de Active Directory nos pide quitar las siguientes características:

• Para el Servidor DNS nos pide quitar las siguientes características:

• Una vez desmarcados estos dos checks, damos clic a “siguiente”:

• Aquí no tocamos nada, clic sobre “siguiente”:

• Nos muestra un resumen de las opciones configuradas para eliminar, le indicamos que reinicie en caso necesario y procedemos a quitar:

• Comienza con la eliminación:

• Tras el reinicio podemos ver que la eliminación ha sido correcta:

• Todo se ha eliminado correctamente, en la bandera de las advertencias, ya NO nos avisa de la promoción de este servidor a Controlador de dominio, ya que todos los binarios han sido eliminados:

• El único Controlador de dominio de nuestra infraestructura sería el servidor con MS Windows Server 2022:

• Para terminar ya sólo nos quedaría elevar los Niveles Funcionales a nivel de dominio y de bosque.
• Empezaremos elevando el Nivel Funcional del bosque, para ello, nos abrimos la herramienta Dominios y Confianzas de Active Directory:

• Como podemos observar, el Nivel Funcional del bosque se encuentra en Windows Server 2016, ya que Microsoft no ha sacado niveles funcionales nuevos desde Windows Server 2016:

• Ahora vamos a elevar el Nivel Funcional del dominio, para ello, nos abrimos la herramienta Usuarios y equipos de Active Directory:

• Automáticamente al elevar el Nivel Funcional del bosque se eleva también el del dominio, pero como ya comentamos antes, Microsoft no ha sacado niveles funcionales nuevos desde Windows Server 2016:

• Con la herramienta Centro de Administración de Active Directory tenemos opción a Elevar los Niveles Funcionales a nivel de bosque y de dominio:

Saludos y espero que os resulte de ayuda

En este post vamos a ver una buena práctica en nuestro Active Directory referente a la Group Policy Object (GPO).

• Cuando desplegamos los roles de Servicios de dominio de Active Directory en un Windows Server, por defecto las GPO “Default Domain Policy” y “Default Domain Controllers Policy”, ya están creadas y vinculadas a las siguientes ubicaciones:

• Como buena práctica, es aconsejable, no editar estas dos GPOs, ya que vienen con unas configuraciones por defecto, para que nuestro Active Directory funcione correctamente, todas las configuraciones las llevaremos a cabo, creándonos nuevas GPOs y vinculándolas sobre la OUs correspondientes.
• También otra buena práctica, y a ésta es a la que vamos a hacer referencia en este artículo, es que vamos a intentar evitar vincular sobre la raíz de nuestro dominio las nuevas GPOs que nos iremos creando a lo largo del tiempo, ¿y por qué hacemos esto?, pues la explicación es básica, si nos equivocamos diseñando una GPO con configuraciones de sistemas críticas y la vinculamos sobre la raíz del dominio, en muchas ocasiones la vuelta atrás no va a ser posible y la podemos liar bien gorda sobre la infraestructura, aquí muestro un ejemplo de lo que NO debemos de hacer:

• ¿Qué hacemos entonces?, en mi caso, lo que siempre hago, es crearme una Unidad Organizativa (OU) con el nombre de la empresa, podemos decir, que esta es la OU principal y dentro de ella voy anidando otras OUs:

• Ahora, todas las nuevas GPOs que nos vayamos creando a lo largo del tiempo, las iremos vinculando sobre las Unidades Organizativas que nos interesen, y no sobre la raíz del dominio:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como configurar un dominio personalizado (utilizaremos nuestro dominio empresarial), en Azure Active Directory, y una vez que tengamos este dominio operativo, vamos a configurar el sufijo UPN (User Principal Name) en nuestro Active Directory de Windows Server, esto lo vamos a realizar ya que en un post posterior vamos a sincronizar nuestro Active Directory local con AzureAD, utilizando la herramienta Azure AD Connect.

• Para configurar nuestro dominio personalizado, desde Azure Active Directory, accedemos a Nombres de domino personalizados:

• Como podemos ver, nos muestra el dominio inicial que configuramos cuando desplegamos un nuevo inquilino (nombredenuestrempresa.onmicrosoft.com), para añadir un dominio personalizado, nos vamos a Agregar un dominio personalizado:

• Introducimos el nombre de nuestro dominio empresarial y que tenemos comprado a un proveedor de dominios en Internet, y agregamos el dominio:

• Una vez agregado nuestro dominio, nos va a mostrar, el tipo de registro TXT que tenemos que crear en nuestro DNS público (el que hemos comprado al proveedor de dominios en Internet), una vez que lo hemos registrado, damos a clic a Comprobar, así verifica Azure que este dominio pertenece a nosotros:

• Aquí vemos cómo se añade el registro TXT en nuestro DNS público:

• Una vez comprobado, podemos ver que ya tenemos nuestro dominio empresarial personalizado configurado y listo para usarlo:

• Ahora sobre Información general > Cambiar inquilino vamos a convertirlo en el inquilino predeterminado:

• Vamos a realizar una prueba creando un usuario nuevo, así vamos a ver como ya nos asigna el sufijo DNS de nuestro dominio personalizado, para ello, accedemos a Usuarios > Nuevo usuario:

• Configuramos los datos de la identidad y la contraseña, creamos el usuario:

• Aquí vemos el usuario creado con nuestro dominio personalizado:

• Con esto ya tendríamos nuestro dominio personalizado, configurado en Azure Active Directory, ahora este dominio lo vamos a agregar como sufijo UPN (User Principal Name) en nuestro Active Directory local (el de Windows Server de toda la vida), para ello, vamos a acceder a cualquiera de nuestros controladores de dominio y nos abrimos la consola de Dominios y confianzas de Active Directory:

• Sobre Dominios y confianzas de Active Directory nos abrimos las Propiedades:

• Y agregamos el sufijo UPN alternativo, que en este caso va a ser el dominio personalizado que hemos configurado en Azure Active Directory:

• Una vez agregado, guardamos los cambios:

• Ahora si nos abrimos la consola de Usuarios y equipos de Active Directory y accedemos a las propiedades de cualquiera de nuestros usuarios, podemos ver que podemos configurar el sufijo UPN local y el sufijo UPN alternativo para utilizarlo con Azure Active Directory, para que las cuentas de los usuarios se sincronicen con Azure Active Directory a través de Azure AD Connect (que lo vamos a ver más adelante) debemos de tener configurado como UPN principal en la cuenta del usuario, el dominio personalizado de Azure:

Saludos y espero que os sea de ayuda

En este post vamos a ver como solucionar el warning que tiene como ID de evento 2213, este Warning se produce ya que la carpeta SYSVOL no se está replicando en el controlador de dominio que muestra el Warning, suele ser producido por un apagado inesperado del servidor, ya sea por algún cuelgue que nos obligó a darle un botonazo, por falta de suministro eléctrico, etc…, lo que está pasando es que la replicación DFSR en el controlador de domino afectado se ha quedado en pausa:

• En el visor de eventos del controlador de dominio que tiene el Warning, sobre “Registro de aplicaciones y servicios > Replicación DFS” veremos este Warning, y sobre el mismo evento nos da la solución para quitar la pausa de la replicación DFSR:

• Para solucionar este Warning nos abrimos un cmd con permisos de administrador en el controlador de dominio afectado e introducimos el siguiente comando wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=»79D93885-2932-11E4-93E8-806E6F6E6963″ call ResumeReplication:

• A partir de la aplicación del comando, la carpeta SYSVOL empezará a replicar en el controlador de domino que estaba dando el Warning y que tenía la replicación en pausa, veremos entonces el ID de evento 2214 que se ha registrado en el controlador de domino, indicando que la replicación DFS se ha restablecido correctamente:

• Una vez solucionado este warning, nos podemos encontrar con este error, ID evento 4012, si el controlador de domino ha estado más de 60 días sin replicar con los otros controladores del dominio, para solucionarlo, podemos seguir este link, ya que en su día ya lo explicamos en este mismo blog:

Saludos y espero que os sea de ayuda

En este post vamos a ver como transferir los roles FSMO de un controlador de dominio dañado y nos es imposible volver a iniciarlo, ni lo podemos recuperar de ninguna de las maneras, estos roles FSMO se los vamos a transferir a otro controlador de domino de nuestra infraestructura. Tenemos dos controladores de dominio DC01RGS y DC02RGS.

• El DC01RGS tiene los cinco roles FSMO, y este es el controlador de dominio que se nos ha averiado:

• Desde el controlador de dominio que tenemos operativo, DC02RGS, comprobamos los controladores de dominio que tenemos en nuestra infraestructura con el comando netdom query dc:

• Desde el controlador de dominio que tenemos operativo, DC02RGS vamos a ejecutar el siguiente comando netdom query fsmo para ver quien tiene asignados estos roles FSMO, y como podemos ver todos los roles los tiene asignados nuestro primer controlador de dominio DC01RGS:

• Para transferir los roles FSMO de un controlador de dominio dañado a otro que está operativo vamos a utilizar el comando ntdsutil desde una consola de PowerShell, luego introducimos roles para entrar al modo mantenimiento de FSMO, luego introducimos connections y connect to server FQDN del domain controller operativo, una vez realizada la conexión, introducimos q para volver al modo mantenimiento de FSMO:

• Vamos a introducir cinco comandos, el primero de ellos es seize infrastructure master, la salida de estos comandos nos va a dar una serie de errores, pero es normal, ya que se está intentando conectar al controlador de dominio averiado:

• El segundo de ellos es seize naming master:

• El tercero de ellos es seize PDC:

• El cuarto de ellos es seize RID master:

• El quinto de ellos es seize schema master:

• Como podemos ver con el comando netdom query fsmo, ya tenemos los cinco roles FSMO transferidos al controlador de dominio DC02RGS, que es el que tenemos operativo:

• Una vez que tenemos todos los roles FSMO asignados al controlador de dominio que tenemos operativo, debemos de realizar limpieza de todos los objetos que hacen referencia al controlador de dominio que se nos ha dañado.
• En primer lugar vamos a eliminar el controlador de dominio dañado desde la consola de Usuarios y equipos de Active Directory:

• Como podemos ver ya está eliminado:

• Por último vamos a eliminar el controlador de dominio dañado desde de la consola de Sitios y Servicios de Active Directory:

• Marcamos el check “Usar el control de servidor Eliminar subárbol”, para que elimine todos los objetos que hacen referencia al controlador de dominio dañado:

• Como podemos ver ya está eliminado y en el NTDS Settings del DC02RGS ya no se está replicando con el Controlador de dominio dañado DC01RGS:

Saludos y espero que os sea de ayuda