miércoles, 29 de julio de 2020

Obtener nombres propios dados los 'user logon names' o samAccountName en Active Directory



Cómo obtener el nombre de una persona teniendo su nombre de usuario de Active Directory.



Si tenemos el nombre de usuario de varias personas y queremos saber rápidamente cual es el nombre completo de cada una de ellas, podemos usar un pequeño script de PowerShell.

A continuación, muestro un par de scripts que nos permiten recuperar el nombre completo dado un nombre de usuario sobre un directorio activo corriendo en Windows Server 2016 o superior.

Imaginemos que tenemos una lista de usuarios llamada users.txt con nombres de usuario, por ejemplo, jgarcia, jtorres, mvarela, etc. uno en cada línea. Para extraer sus nombres completos de Active Directory podemos usar el siguiente script:

$List = Get-Content ".\users.txt"
ForEach ($User in $List) {
Get-ADUser -Filter "SamAccountName -eq '$User'" | Select-Object samaccountname, name
} 

El output del script será:

PS C:\Temp> C:\Temp\script.ps1 samaccountname name -------------- ---- jgarcia Juan Garcia jtorres Javier Torres mvarela Marta Varela agutierrez Álvaro Gutiérrez mperez Martín Pérez

De esta forma veremos el output en la terminal, pero ¿qué ocurre si queremos exportar el resultado a un archivo, como por ejemplo, un csv?

Con el siguiente script podemos escribir los nombres propios y los user logon name en un csv:

$aResults = @()
$List = Get-Content ".\users.txt"
ForEach($Item in $List){
$Item = $Item.Trim()
$User = Get-ADUser -Filter "SamAccountName -eq '$Item'" | Select-Object samaccountname, name
$hItemDetails = New-Object -TypeName psobject -Property @{
FullName = $Item
UserName = $User.SamAccountName
}
#Add data to array
$aResults += $hItemDetails
}
$aResults | Export-CSV ".\Results.csv"

Podemos modificar el script para escribir solo los nombres propios en el archivo, si así lo necesitamos, quitando el parámetro SamAccountName del selector Select-Object.


Fuentes:

https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-aduser?view=win10-ps

miércoles, 22 de julio de 2020

Tipos de red móvil



¿Qué significa que una conexión de red móvil sea H, H+, 3G, 4G o 5G?



En la parte superior de la pantalla de un teléfono móvil aparece, además de la hora y el nivel de batería, una sigla que nos indica la velocidad de conexión de la que dispone ese dispositivo en esa ubicación.


Esta sigla puede ser G, E, 3G, H, 4G... Cada una hace referencia a un tipo de conexión y velocidad.
Vamos a ver las diferencias entre cada una de ellas, ordenadas de más lenta a más rápida.

G

La letra G representa una conexión GPRS, es decir, la calidad de conexión más baja que puede usar un teléfono móvil. Su velocidad de navegación oscila entre los 56 y los 144 KB/s.

E

La conexión EDGE es una versión mejorada del GPRS la cual permite usar algunas aplicaciones livianas como WhatsApp o Telegram. Su velocidad es de 384 KB/s.

3G

3G es una red de tercera generación. Fue creada para transmitir voz y datos y su velocidad oscila entre los 384 KB/s y 2 MB/s, por lo que permite navegar por internet sin problemas.

H

La letra H representa la conexión HDSPA o 3.5G. Esta conexión llega a 14 MB/s de bajada y entre 386 KB/s y 5.76 MB/s de subida.

H+

Esta conexión equivale a 3.8 G, con una velocidad constante de descarga de 84 MB/s y una velocidad de subida de 22 MB/s.

4G o LTE

4G es la red de cuarta generación. Su velocidad ronda los 100 MB/s de descarga y los 50 MB/s de subida, aunque en zonas urbanas estos números pueden ser mayores.

4G+

4G+ es la etapa intermedia entre 4G y 5G. La velocidad de esta conexión es el doble o triple que el 4G convencional, según la zona.

5G

El 5G es la quinta generación de red móvil. Permite una velocidad de descarga de hasta 10 GB/s.


Fuentes:

https://www.xataka.com.mx/movistar4glte/h-h-lte-que-significan-estos-simbolos-en-la-pantalla-de...
https://larepublica.pe/tecnologia/2020/07/18/smartphone-que-significan-las-letras-e-h-h-3g-4g...
0

miércoles, 15 de julio de 2020

Backups de volúmenes de AWS desde CLI



Cómo crear backups de volúmenes EBS de instancias EC2 de AWS desde CLI.



Si usamos AWS, puede resultar interesante crear bakups / snapshots / copias de seguridad del disco principal de una instancia EC2 mediante CLI desde un Linux o Windows que tengan el AWS CLI instalado.

Para crear un snapshot del volumen de una instancia desde CLI, es interesante parar primero la instancia para evitar que se escriban datos al disco mientras se realiza la copia.

Para parar una instancia EC2 desde CLI, buscamos primero la ID de la instancia usando su tag "Name" (en este caso, busco la instance ID de una instancia llamada Test1):

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-instances --filters 'Name=tag:Name,Values=Test1' --query 'Reservations[0].Instances[0].InstanceId' "i-04aebf98625bacce4"

Hemos obtenido el instance ID "i-04aebf98625bacce4".

Ahora buscamos el volume ID del disco EBS de la instancia Test1:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-instances --filter 'Name=tag:Name,Values=Test1' --query 'Reservations[0].Instances[0].BlockDeviceMappings[0].Ebs.{VolumeId:VolumeId}' { "VolumeId": "vol-0b2efa7e024e758e5" }

Paramos la instancia:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 stop-instances --instance-ids i-04aebf98625bacce4 { "StoppingInstances": [ { "InstanceId": "i-04aebf98625bacce4", "CurrentState": { "Code": 64, "Name": "stopping" }, "PreviousState": { "Code": 16, "Name": "running" } } ] }

Miramos si ya está apagada la instancia:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 wait instance-stopped --instance-id i-04aebf98625bacce4

Creamos un snapshot del volumen:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 create-snapshot --volume-id vol-0b2efa7e024e758e5 { "Description": "", "Tags": [], "Encrypted": false, "VolumeId": "vol-0b2efa7e024e758e5", "State": "pending", "VolumeSize": 8, "StartTime": "2020-06-17T10:45:11.000Z", "Progress": "", "OwnerId": "077455710323", "SnapshotId": "snap-0f2af28035ea778e5" }

Miramos si ya ha acabado el proceso:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 wait snapshot-completed --snapshot-id snap-0f2af28035ea778e5

Ya podemos iniciar la instancia:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 start-instances --instance-ids i-04aebf98625bacce4 { "StartingInstances": [ { "InstanceId": "i-04aebf98625bacce4", "CurrentState": { "Code": 0, "Name": "pending" }, "PreviousState": { "Code": 80, "Name": "stopped" } } ] }

Por último, podemos mirar qué snapshots hay del volumen de esta instancia en nuestra cuenta:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-snapshots --filters "Name=volume-id,Values=vol-0b2efa7e024e758e5" { "Snapshots": [ { "Description": "", "Encrypted": false, "VolumeId": "vol-0b2efa7e024e758e5", "State": "completed", "VolumeSize": 8, "StartTime": "2020-07-15T10:50:02.036Z", "Progress": "100%", "OwnerId": "077455710323", "SnapshotId": "snap-0c9062daba8a9f4f7" } ] }

Vemos que tenemos un snapshot del volumen de la instancia con fecha de hoy. Misión cumplida.


Fuentes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
0

miércoles, 8 de julio de 2020

Arrancar YaST2 en modo gráfico vía X11



Cómo acceder al YaST2 de un SLES en modo gráfico desde Windows.



Alguien me pidió acceso al entorno gráfico de un SUSE Linux Enterprise Server para instalar cierto software mediante YaST2. El servidor en cuestión no tenía entorno gráfico instalado y el usuario no quería usar YaST2 en modo texto, así que la única alternativa para arrancar YaST2 en modo gráfico era usar X11 Forwarding vía SSH conectado desde un Windows.


Windows



En Windows, suelo usar PuTTy para realizar conexiones SSH hacia servidores Linux. En él, podemos permitir X11 Forwarding en su correspondiente apartado:



Además, debemos instalar algún gestor de ventanas X en Windows como, por ejemplo, Xming.


SUSE



Para poder hacer X11 Forwarding desde un host remoto corriendo SUSE - es decir, para poder visualizar las ventanas de las aplicaciones gráficas de una máquina remota con SUSE desde nuestro PC - primero debemos editar el archivo de configuración de SSH del host remoto:

root@host:~ # vi /etc/ssh/sshd_config

Y configurar el parámetro X11 Forwarding en yes:

X11Forwarding yes

Una vez configurado, reiniciamos el daemon de ssh para aplicar los cambios:

root@host:~ # service sshd restart

Ahora vamos a permitir a la cuenta root ejecutar aplicaciones mediante X11 Forwarding. Para ello, vamos a copiar una cookie de Xorg de un usuario cualquiera hacia root para usarla desde root.

Para permitir a root realizar X11 Forwarding, primero abrimos una shell como un usuario "no root":

root@host:~ # su - usuario

Ahora miramos el valor de la variable DISPLAY:

usuario@host:~> echo $DISPLAY localhost:10.0

Volvemos a root y exportamos el display hallado anteriormente hacia una variable de entorno temporal:

root@host:~ # export DISPLAY=localhost:10

Copiamos la "Xorg authorization cookie" del usuario elegido hacia el home de la cuenta root:

root@host:~ # cp /home/usuario/.Xauthority ~

Activamos las conexiones remotas:

root@host:~ # xhost +local: non-network local connections being added to access control list

Probamos que el X11 Forwarding funcione ejecutando una instancia de algún programa con GUI, como por ejemplo xclock (debemos instalarlo previamente con "zypper in xclock"):

root@host:~ # xclock

Si todo ha ido bien, deberíamos ver algo así en Windows:



Si podemos ver una ventana con xclock, ya podemos ejecutar YaST2 en modo gráfico como root:

root@host:~ # yast2


Fuentes:

https://www.suse.com/c/running-graphical-programs-remotely-root/
0

miércoles, 1 de julio de 2020

Permitir conexiones UDP a través de NGINX



Permitir tráfico por un puerto UDP a través de un reverse proxy NGINX.



NGINX usado como reverse proxy permite configurar conexiones TCP más allá de HTTP y HTTPS usando políticas stream; permite, por ejemplo, abrir el puerto 25 (TCP) de la máquina donde corre NGINX y redirigirilo hacia el puerto 25 de nuestro servidor de correo.

Aparte de redirigir puertos TCP, NGINX también permite redirigir tráfico de puertos UDP hacia un servidor final usando el mismo recurso que se usa para la pila TCP, es decir, stream. Recordemos que UDP (User Datagram Protocol) es el protocolo usado por aplicaciones no transaccionales como DNS, SNMP, syslog, RADIUS, etc. las cuales podemos pasar a través de NGINX sin ningún problema.

Para poder redigir puertos UDP a través de NGINX necesitamos que este esté compilado con el flag --with-stream (o disponer de NGINX Plus, el cual ya está compilado con este módulo).

Además de compilar NGINX con --with-stream, debemos incluir esta línea en nginx.conf y reiniciar nginx:

load_module lib64/nginx/modules/ngx_stream_module.so;

Esto activa el módulo stream en NGINX.

Una vez hecho esto, ya podemos aceptar peticiones hacia puertos UDP.

Por ejemplo, si queremos mandar tráfico hacia dos servidores DNS ubicados tras un proxy inverso NGINX, debemos crear un bloque stream y usar una configuración tipo:

stream { upstream dns_servers { server 192.168.1.1:53; server 192.168.1.2:53; } server { listen 53 udp; # enviamos el tráfico del puerto 53 UDP hacia el grupo "dns_servers" proxy_pass dns_servers; } }

En el código anterior, vemos un bloque "server" dentro de stream. En él, NGINX acepta peticiones hacia su puerto 53 UDP, que a su vez, se envían al grupo de servidores llamado "dns_servers".

Al mismo tiempo, vemos que el grupo "dns_servers" está formado por 2 servidores "finales" (los servidores DNS) a los cuales se envía tráfico destinado a su puerto 53 (en el bloque upstream no hace falta indicar TCP o UDP). De este modo, el tráfico UDP se enviará a ambos servidores por round robin.

A partir de este momento, al enviar tráfico hacia el puerto 53 UDP de la IP de NGINX, este se enviará por detrás mediante round robin (balanceo equitativo) hacia los servidores finales que hayamos designado, en este caso, a dos servidores DNS.


Fuentes:

https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/#upstream
0