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
  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. efinir 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.

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"
$passwdEmail = "passwdEmail"
$asuntoEmail = "asuntoEmail"

# Convertir password a un string seguro
$secPasswdEmail = ConvertTo-SecureString $passwdEmail -AsPlainText -Force
$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!

04 septiembre, 2019

WMI Explorer: Restricción de las políticas de grupo GPO con filtrado WMI y Querys en SCCM

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 - Domain Controller
  • ProductType 3 = Server OS - No son 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%

Algunos ejemplos.
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"

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.

En conclusión, 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/RaspberryPi-samba-proftpd.

Saludos!

01 agosto, 2019

Renovar certificados: 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 en los Virtual Host en el caso de Apache por ejemplo.
<VirtualHost *:443>
...
SSLEngine on
SSLCertificateFile /ruta/a/public.crt
SSLCertificateKeyFile /ruta/a/private.key
SSLCertificateChainFile /ruta/a/intermediate.crt
...
</VirtualHost>
Para comprobar la integridad de los ficheros de certificados, debemos verificar que la suma de verificación (checksum) calculada a través una función hash el certificado, la clave privada y el CSR (Certificate Signing Request) deberían ser los mismos resultados para todos.

Si se obtiene un valor MD5 o SHA256 diferente, significa que el certificado, la clave privada y el CSR no coinciden.

Para comprobar estos valores podemos hacer uso de las herramientas que nos proporciona OpenSSL.

Método 1: Usando OpenSSL y MD5

# openssl rsa -noout -modulus -in private.key | openssl md5
# openssl req -noout -modulus -in intermediate.csr | openssl md5
# openssl x509 -noout -modulus -in public.crt | openssl md5

Método 2: Usando OpenSSL y sha256sum

# openssl pkey -in private.key -pubout -outform pem | sha256sum
# openssl req -in intermediate.csr -pubkey -noout -outform pem | sha256sum
# openssl x509 -in public.crt -pubkey -noout -outform pem | 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!

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.

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"
# Número 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 domnio disponible al nivel más alto posible.

Verificar que la replicación antes de realizar la migración a través una cmd:
repadmin /showrepl
repadmin /replsummary

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 3: 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 4: 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 5: 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 6: 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 7: 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 8: Comprobar el estado de los servicios FRS y DFS-R.

Por último, comprobamos la correcta replicación entre todos los controladores de dominio.
repadmin /replsummary
Figura 9: Comprobar finalmente la correcta replicación entre todos los controladores.

Saludos!

12 abril, 2019

Fallos en la replicación FRS y DFSR en Active Directory: Como forzar la sincronización no-autoritativa y autoritativa [Burflags]

Replicación FRS y DFSR

  • FRS (File Replication Service) servicio para distribuir archivos compartidos y objetos de directiva de grupo entre controladores de dominio a través del recurso C:\Windows\SYSVOL. Windows Server 2003 R2 y Windows Server 2008 son compatibles con DFS (Distributed File System) y el servicio de replicación de archivos.
  • DFSR (Distributed File System Replication) disponible por defecto a partir de Windows Server 2008 R2, reemplaza al sistema FRS para la replicación del recurso SYSVOL en los servicios de dominio de Active Directory. DFS replica los objetos de configuración almacenados de Active Directory.

Restauración "no autoritativa" y "autoritativa"

  • Restauración No-Autoritativa: conserva los USN (Update Sequence Number) de los objetos del Directorio Activo desde la fecha que se creó la copia de seguridad del estado del sistema (System State). El sistema de replicación de Active Directory utiliza este número para detectar y propagar los cambios de Active Directory entre los distintos servidores de la organización. Debido a que el USN del servidor restaurando siempre será anterior a los USN actuales, los datos de este servidor nunca se replicarán con el resto de controladores de dominio. Por el contrario, si existen datos más recientes en los otros servidores, el sistema de replicación de AD los utilizará para actualizar los datos restaurados. Este procedimiento se suele realizar cuando queremos restaurar algún complemento del Sistema Operativo como una cuenta de usuario, equipo, DC, etc.
  • Restauración Autoritativa: debemos de realizar primero una restauración no autoritativa y luego mediante la utilidad NTDSUTIL realizar una restauración autoritativa. De esta forma se consigue que los Objetos restaurados se les cambie el número de secuencia de actualización USN para que sea mayor al de cualquier otro USN del directorio. Así el servidor restaurado se asegura de que cualquier dato u objeto sea replicado y distribuido adecuadamente en todos los controladores de dominio.

Fallo de replicación FRS

En el caso de que tengamos dos o más controladores de dominio y que se apague un controlador de dominio el cual no esté correctamente sincronizado. Posteriormente, se levante un nuevo controlador de dominio con un sistemas operativo más actual que PDC (Primary Domain Controller) si el DC viejo se volviese a levantar puede que ocurra fallos en la sincronización.

Figura 1: Mensaje de fallo de replicación FRS en servicios de Active Directory.

Registro de evento Id. 1308: KCC (Knowledge Consistency Checker) ha detectado errores. KCC Es un proceso integrado que se ejecuta en todos los controladores de dominio y genera la topología de replicación de bosque de Active Directory.

Figura 2: Comprobador de coherencia de la información KCC . Id. 1308.

Registro de evento Id. 13508: Problemas en la replicación de objetos de los servicios de AD entre uno de los controladores de dominio. En este caso el servidor "X3550" no sincroniza con el servidor "SRVDOMINIO".

Figura 3: Fallo de sincronización de uno de los controladores de dominio. Id. 13508.

¿Cómo reinicializar o forzar la sincronización de replicación autoritativa o no autoritativa? 


El valor del registro Burflags genera la copia de cada controlador de dominio del árbol de volumen del sistema (SYSVOL) en todos los controladores de dominio de Active Directory.

Los valores D2 y D4 Burflags son los que controlan como se replica FRS entre los controladores de dominio.

  • Si se inicia FRS con valor del registro Burflags establecido en D4 (sincronización autoritativa):
FRS trata inicialmente los archivos y carpetas de su copia local del árbol de SYSVOL como autorizados para el conjunto de réplicas. Si tenemos varios controladores de dominio, Burflags se debería establecer con valor D4 en un controlador de dominio único y en D2 en los demás controladores de dominio de ese dominio. Esta configuración se conoce como "Restauración autoritativa".

  • Si se inicia FRS con el valor del registro Burflags establecido en D2 (sincronización no autoritativa):
FRS realiza una sincronización completa de los archivos y carpetas desde un asociado de replicación directo o transitivo que aloje la copia autorizada de los archivos y carpetas del conjunto de réplicas. Esta configuración se conoce como "Restauración no autoritativa" aunque no se produzca ninguna restauración del estado del sistema (System State). La configuración D2 regenera la parte de FRS del controlador de dominio como si fuera nuevo.


Configurar las réplicas de SYSVOL como autoritativo

[1] - Detener el servicio FRS de todos los controladores de dominio.
[2] - En el PDC (Principal Domain Controller). (podemos averiguar el PDC haciendo un "netdom query fsmo"). Nos situamos en la siguiente rama del registro.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID
GUID (Globally Unique Identifier) del conjunto de réplicas del volumen del sistema del dominio.

[3] - Creamos o modificamos el valor DWORD BurFlags y lo establecemos a D4.

Figura 2: Repliación FRS: Sincronización autoritativa BurFlags con valor D4.

[4] - Reiniciamos el controlador de dominio principal y comprobamos que los servicios de Active Directory estén nuevamente sincronizados.

Más info: https://support.microsoft.com/es-es/help/315457/how-to-rebuild-the-sysvol-tree-and-its-content-in-a-domain

Después de forzar la sincronización entre los controladores de dominio, puede que nos interese transferir los roles FSMO y hacer purgado de los servicios del dominio (de darse el caso). Transferir roles FSMO Windows Server y hacer purgado de los servicios del dominio.

Saludos!

12 marzo, 2019

Gestión de backups de recurso compartido CIFS a un servidor FTP remoto de forma sincronizada con rsync

Una forma de  realizar backups de ficheros o directorios independientes entre un sistema Windows y servidor FTP remoto y los ficheros a realizar el backup están en un recurso compartido CIFS (SMB) de Windows, si disponemos de un sistema Linux podremos montar en dos directorios el recurso compartido Windows y el servidor FTP remoto. A posteriori realizar la copia sincronizada con rsync entre el directorio montado con CIFS y el directorio remoto FTP donde se almacenará la copia.

Accedemos al sistema linux e instalamos los paquetes cifs-utils para poder montar sistemas de ficheros compartidos desde un sistema Windows y curlftpfs para montar el servidor FTP remoto.
sudo apt install -y cifs-utils
sudo apt install -y curlftpfs
Creamos un directorio para montar el recurso compartido Windows y otro para montar el espacio del servidor FTP remoto y otorgamos permisos de control total, aunque esto dependerá de la gestión de usuarios y grupos de como tengamos configurado el entorno Linux. (Como ejemplo se montará partiendo de /mnt).
mkdir /mnt/ftpbackup ; chmod -R 777 /mnt/ftpbackup
mkdir /mnt/cifsbackup ; chmod -R 777 /mnt/cifsbackup
Montamos el recurso compartido cifs de Windows.
mount -t cifs //server/compartida /mnt/cifsbackup -o username=user,password=passw,domain=dominio
  • //server/compartida: Será el recurso compartido cifs de Windows.
  • /mnt/cifsbackup: Directorio que se usará para montar el recurso cifs de Windows en la máquina Linux.
  • User, password y dominio: Será el usuario, contraseña y dominio si se trata de un usuario de dominio, si se trata de un usuario local de Windows sería el hostname de la máquina Windows.

Montamos el directorio del servidor FTP remoto en el directorio local de la máquina Linux. (Como ejemplo se montará partiendo de /mnt.)
curlftpfs user:passw@serverftp /mnt/ftpbackup
  • user: Usuario de acceso al servidor FTP.
  • passw: Password de acceso al servidor FTP.
  • serverftp: URL, IP o hostname de acceso al servidor FTP.
  • /mnt/ftpbackup: Directorio donde se montará el servidor FTP remoto en la máquina Windows.

Una vez montados ambos recursos solo queda realizar el backup y que sincronice los datos desde el recurso compartido cifs de Windows hacia el servidor FTP remoto, al estar montados en el sistema Linux estos se tratarían como directorios locales.
rsync -rtvp --log-file=/var/log/ficherolog /mnt/cifsbackup /mnt/ftpbackup
  • r: Recursividad entre directorios.
  • r: Preserva la modificación de fechas.
  • v: Vervose, muestra más detalles.
  • p: Preserva los permisos de los ficheros y directorios.
  • --log-file=/var/log/ficherolog: Almacena los resultados en un fichero de log.
  • /mnt/cifsbackup: Datos origen.
  • /mnt/ftpbackup: Datos destino.

Para desmontar los recursos de los directorios.
umount /mnt/ftpbackup
umount /mnt/smbbackup
Para automatizar este proceso podemos crear un fichero bash script .sh que monten ambos recursos, realize el backup con rsync, enviarse el fichero de log a una dirección de correo electrónico y finalmente desmontar ambos recursos para que no permanezacan en la máquina Linux si no lo deseamos.

Si queremos programar la ejecución de este script .sh a una fecha/hora concreta añadimos el script a una nnueva línea en /etc/crontab de modo que se ejecute de forma programada.

Saludos!

27 febrero, 2019

vSphere Web Client: Opciones deshabilitadas en la máquina virtual

Este troubleshooting está recogido en la base de conocimiento https://kb.vmware.com/s/article/2048748.

El no poder ver las opciones habilitadas para poder editar la configuración entre otras de la VM pueden ser por debido a varias causas, las más habilitales puede ser por la configuración de permisos o por tareas ejecutándose en segundo plano.

Figura 1: Opciones deshabilitadas en la máquina virtual en vSphere web client.

Para consultar las tareas en background de la VM afectada, nos nos conectamos por SSH al host ESXi y listamos sus VMs.
vim-cmd vmsvc/getallvms
Listar tareas de esa VM (vmid)
vim-cmd vmsvc/get.tasklist <vmid>
Hay tareas corriendo, si el resultado es algo como:
(ManagedObjectReference)
['vim.Task:haTask-8-vim.VirtualMachine.createSnapshot-534613324',
'vim.Task:haTask-8-vim.VirtualMachine.powerOn-534613303']
No hay tareas corriendo en background, si el resultado es algo como:
(ManagedObjectReference) []
Figura 2: Finalizar procesos VMs en host WMware ESXi.

Finalizar procesos

ps | grep vmx
kill <pid>
Si con simplemente kill no se finalizan, usar el parámetro -9
kill -9 <pid>
Esperamos unos 30 segundos aproximadamente y volvemos a listar los procesos con ps para comprobar que se finalizó correctamente.

Más info: https://kb.vmware.com/s/article/1014165.

Establecer permisos en la VM

Otorgar permisos a vSphere Web Client cambiando el rol de este grupo a Administrador.

Figura 3: Cambiar el rol del grupo de vSphere Web Client a permisos de Administrador.

Figura 4: Permisos de Administrador al grupo vSphere Web Client.

Comprobamos que las opciones vuelven estar disponibles y habilitadas para la VM.

Figura 5: Opciones habilitadas de la VM en vSphere Web Client.

Saludos!

24 febrero, 2019

NETSH portproxy: Port forwarding local en Windows

Un método para crear túneles haciendo un reenvío de puertos usando un sistema Windows es el uso de la utilidad de comandos NETSH.

Netsh tiene una propiedad llamada portproxy la cual actua como un proxy en las redes y aplicaciones IPv4 e IPv6.

Mostraré un ejemplo que podría ser típico, se trata de un reenvío de puertos local con el fin de establecer una conexión de Escritorio Remoto (RDP) entre dos máquinas Windows.

Si se trata de un reenvío de puertos entre redes IPv4 la sintaxis sería:
netsh interface portproxy add v4tov4 listenport=<Puerto-Local> listenaddress=<IP-Local> connectport=<Puerto-Remoto> connectaddress=<IP-Remota>
En siguiente ejemplo se reenvía desde la máquina local y puerto local de escucha 9090 a la máquina remota 10.0.0.19 y puerto remoto al que nos conectaremos 3389.
netsh interface portproxy add v4tov4 listenport=9090 listenaddress=localhost connectport=3389 connectaddress=10.0.0.19
  • listenport: Puerto IPv4 local en el que se escucha.
  • connectaddress: Dirección IPv4 local a la que conectarse.
  • connectport: Puerto IPv4 remoto al que conectarse.
  • listenaddress: Dirección IPv4 remota en la que se escucha.
Figura 1: Reenvío de puertos con Netsh estableciendo una conexión RDP entre dos máquinas Windows.

Para comprobar las reglas añadidas de reenvío de puertos con Netsh porproxy podemos consultar la tabla de reglas.
netsh interface portproxy show v4tov4  #Lista reglas en redes IPv4.
netsh interface portproxy show all     #Lista todas las reglas.
Para "romper" la conexión o eliminar las reglas establecidas.
netsh interface portproxy delete v4tov4 listenport=9090 listenaddress=localhost
Figura 2: Comprobar reglas añadidas y puertos de Netsh portproxy en una conexión RDP y eliminar reglas.

Saludos!

16 febrero, 2019

Plink SSH: Auto aceptar hostkey fingerprint al crear un túnel local port forwarding en SSH versión 2

Hostkey o fingerprint SSH

Cuando nos conectamos a través de un cliente SSH como PuTTY, por primera vez en una conexión se nos mostrará una alerta de seguridad indicando que el host key no está cacheado en el registro, no es más que la huella digital o fingerprint de la máquina remota a la que nos conectamos usado como método de confianza para garantizar la autenticidad de la máquina remota.

Esta host key al no estar registrada o cacheada por la máquina cliente que establece la conexión por primera vez, nos alerta de que no hay garantía de que el servidor remoto sea quien creemos que es.

ssh:ed25519 se trata de un esquema de firma digital EdDSA. Mantiendo la seguridad de otros esquemas con la principal ventaja de aportar más velocidad, más info aquí.

Figura 1: Alerta de seguridad - Host key de la primera conexión SSH.

Usando PuTTY las SSH host keys se cachean almacenándose en el registro de Windows.
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
En un tipo de valor de cadena (REG_SZ).

Figura 2: Registro Windows - SSH Host Keys de Putty.

Conexión SSH con Plink

Comentado lo anterior, vamos a ver entonces con Plink (utlidad de comandos de Putty) como podemos conectarnos por SSH estableciendo un túnel port forwarding auto aceptando el hostkey.

Pero que pasa si no tenemos una interfaz gráfica ni un Putty y solo disponemos de una terminal de comandos en la que podemos incorporar un Plink.

Cuando nos conectamos directamente al servidor SSH con Plink lo hacemos del siguiente modo.
plink <host_servidor_SSH>
De esta forma nos solicitará almacenar o no la hostkey en caché, sería la equivalencia a la ventana de alerta de seguridad de la hostkey que se muestran en las conexiones con Putty. Continuamos (y yes) almacenando la clave, nos pedirá usuario y contraseña. Y vemos que nos conecta al servidor remoto correctamente (independientemente de la mala interpretación en la codificación de caracteres).

Figura 3: Conexión estándar SSH con Plink (Putty).

Creando un túnel SSH port forwarding con Plink

Con Plink al igual que con Putty podemos crear un túnel SSH.
plink.exe -L <puerto_local>:<host_remoto>:<puerto_remoto> -P 22 -pw <password> <usuario>@<host_server_SSH>
De esta forma simplemente aceptaremos el cacheo de hostkey y tendremos el reenvío de puertos establecido en la conexión SSH.

Figura 4: Conexión túnel SSH port forwarding con Plink (Putty).

Hay un tip un poco "sucio" que es auto aceptar la host key con: "echo y | plink...". Quedando algo como esto.
echo y | plink.exe -L <puerto_local>:<host_remoto>:<puerto_remoto> -P 22 -pw <password> <usuario>@<host_server_SSH>
Figura 5: Auto aceptando hostkey ssh con "echo y | plink..."

Auto aceptar hostkey con Plink creando un túnel SSH port forwarding

Hasta aquí todo correcto. El problema de esto es si queremos conectarnos con un reenvío de puertos forzando una versión particular del procotolo SSH con plink, hay que especificar los parámetros: -ssh -2 (la versión SSH).

De este modo al intentar conectarnos por SSH estableciendo el reenvío de puertos para crear el túnel SSH. Y no tenemos la hostkey inicialmente cacheada en la máquina cliente, nos encontraremos con el siguiente problema.
Connection abandoned.
Disconected: Aborted at host key verification.
Conectándose de este modo, forzando la versión 2 del protocolo SSH, no aparece la solicitud y/n (si o no) para cachear la host key y directamente aborta la conexión.

Figura 6: Intento de conexión abortada con Plink especificando la versión 2 del protocolo SSH.

Aquí el truco sucio de "echo y | plink..." no funciona.

La única forma de auto aceptar el host key de una conexión con plink forzando a la versión 2 del protocolo SSH y que tenga establecido un port forwarding para el uso de un túnel SSH. Sería especificar el parámetro -hostkey seguido del fingerprint correspondiente.

La hostkey la podemos ver en una primera conexión, aunque esta no se establezca abortándose, igualmente se nos mostrará el fingerprint del host remoto correspondiente al servidor SSH.
plink.exe -ssh -2 -batch -v -L <puerto_local>:<host_remoto>:<puerto_remoto> -P <puerto_ssh> -pw <password> <usuario>@<servidor_remoto_ssh> -hostkey <hostkey_fingerprint>
Se especifica la host key correspondiente al servidor remoto SSH y vemos como la conexión se establece automáticamente.

Figura 7: Especificar la hostkey del servidor SSH cuando esta aún no está cacheada en el equipo cliente.

Probamos a conectarnos a través del túnel SSH creado. En este ejemplo era un reenvío de puertos del tipo local para una conexión RDP de Escritorio remoto.

Figura 8: Conexión RDP tunelizado por SSH.

Conexión establecida por RDP a través del tunelizado SSH. En una primera instancia auto aceptando la hostkey del servidor SSH cuando esta aún no está cacheada en la máquina cliente.

Figura 9: Conexión tunelizada por SSH - Conexión RDP establecida.

Saludos!

11 febrero, 2019

Resetear la password SSO Administrator@vsphere.local de VMware vCenter (VCSA)

Para resetear la password SSO del usuario "Administrator@vsphere.local" de vCenter. Accemos a la gestión del VCSA (vCenter Server Appliance) por el puerto 5480 con el usuario root y password.
https://IP-vCenter_o_hostname:5480
Una vez en el appliance de vCenter, en la sección de Acceso marcamos:
  • Habilitar inición de sesión en SSH.
  • Habilitar el shell Bash.
Figura 1: Habilitar el acceso SSH y Shell Bash para VCSA.

Nos conectamos por SSH al vCenter y habilitamos el uso de acceso a Shell Bash y entramos en la Shell.
shell.set --enabled true
shell
Una vez estamos en el Shell prompt ":~ #" ejecutamos vdcadmintool desde su ruta absoluta.
/usr/lib/vmware-vmdir/bin/vdcadmintool
Este ejecutará un menú de opciones, para este caso elegirémos la opción 3 "Reset account password". Establecemos la cuenta SSO "Administrator@vsphere.local" y nos generará una password aletoria. Con la opción 0 salimos del menú.

Figura 2: Resetear passworrd SSO Administrator desde vdcadmintool.

Accedemos ahora a vSphere Web Client.
https://IP-vCenter
Nos identificamos con el usuario SSO Administrator@vsphere.local y la password generada anteriormente.

Figura 3: SSO Administrator@vsphere.local vSphere Web Client.

Una vez logueados cambiamos la password por la que queramos establecer.

Figura 4: Cambiar password SSO Administrator@vsphere.local.

Por último podemos configurar que la password nunca expire. Configuración > Directivas > Directiva de constraseñas, editamos la directiva y establecemos a 0 días la duración máxima en la que la contraseña se debe cambiar.

Figura 5: Configurar que la password de SSO Administrator@vsphere.local nunca expire.

Saludos!

06 febrero, 2019

Habilitar virtualización anidada VT-x/AMD-V en Virtualbox cuando no se puede activar (nested virtualization)

[1] - Habilitar la virtualización a nivel de BIOS/UEFI en el host anfitrión. Opción VT-x (procesadores Intel) o AMD-v (procesadores AMD).

[2] - Comprobar que no haiga otro hypervisor (VMware o Hyper-V por ejemplo) usándose o con una mayor prioridad que no sea Virtualbox instalado en el host anfitrión.

[3] - La característica de viritualización anidad o nested virtualization en Virtualbox solo está disponible en versiones igual o superior a 6.0.

Esta característica es visible y se puede habilitar en: Sistemas > Procesador > Habilitar PAE/NX y Habilitar VT-x/AMD-V anidado.

En la siguiente screenshot se muestra como la característica es visible pero no nos permite habilitarla, pero esta opción se puede forzar para habilitarla en la máquina virtual seleccionada.

Figura 1: Caracteristica extendida - No es posible habilitar la virtualización aninada para la VM seleccionada.

[4] - Listar el nombre e ID de las VMs creadas con Virtualbox en nuestro host afitrión, esto lo haremos con la utilizada de comandos de VBoxManage.exe de Virtualbox. En el caso de Windows, desde una CMD accedemos a la ruta donde se encuentra este binario.
C:\Program Files\Oracle\VirtualBox
[5] - Listamos las VMs disponibles.
VBoxManage list vms
[6] - Modificamos la característica de la VM seleccionada, forzando así que se habilite la virtualización anidada con el parámetro --nested-hw-virt on.
VBoxManage modifyvm "Nombre-VM o {ID-VM}" --nested-hw-virt on
Referencia: https://docs.oracle.com/cd/E97728_01/F12469/html/nested-virt.html

Figura 2: Virtualización anidada habilitada para la VM seleccionada.

[7] - Si se habilitó correctamente la virtualización anidada podemos comprobarlo desde la VM seleccionada.

En el caso de usar un procesador Intel.
cat /proc/cpuinfo | grep vmx
En el caso de usar un procesador AMD.
cat /proc/cpuinfo | grep smv
Si todo a salido correctamente se debería mostrar contenido resultante que contiene "vmx" (en este caso de ejemplo se trataba de un procesador Intel). De no estar habilitada la virtualización anidada para la máquina virtual seleccionada no nos mostraría nada como resultado del cat.
 
Figura 3: Comprobación de que la virtualización anidada está habilitada en la VM seleccionada.

Saludos!
Entradas Relacionadas