miércoles, 12 de mayo de 2021

NTLM sobre NGINX reverse proxy



Cómo autenticar un usuario con NTLM a través de NGINX.



Si tenemos un aplicativo web corriendo sobre un Microsoft IIS que requiera usuario y contraseña en un pop up para acceder a una determinada parte de la web, probablemente se use el protocolo NTLM.

NTLM (sucesor de NT LAN Manager) recoge un nombre de dominio, un nombre de usuario y una contraseña y usa cifrado para autenticar a un usuario sin enviar la contraseña del usuario a través de la conexión. En su lugar, el sistema que solicita la autenticación debe realizar un cálculo que demuestre que tiene acceso a las credenciales NTLM protegidas.

La autenticación NTLM implica por tanto tres actores: un cliente, un servidor y un controlador de dominio que realice los cálculos de autenticación en nombre del servidor.

Para saber si un Windows Server usa autenticación NTLM o no, podemos echar un ojo a los headers que envía el servidor y ver si está presente el siguiente header:

WWW-Authenticate: NTLM

Si el header está presente, pasamos el dominio de la web a través de NGINX y enviamos las peticiones hacia el Windows Server, no nos funcionará la autenticación de usuarios.

NTLM no funcionará porque los paquetes TCP no se reenvían exactamente como los recibió el proxy inverso. Por este motivo, muchos servidores 'proxy inverso' no funcionan con la autenticación NTLM ya que reenvían las solicitudes HTTP correctamente pero no los paquetes TCP.

Para solucionar el problema, me temo que debemos adquirir una licencia de NGINX Plus y usar el módulo NTLM, solo disponible en la versión de pago.

Para permitir autenticación NTLM a través de NGINX deberemos usar el siguiente código:

upstream http_backend { server 192.168.1.1:443; ntlm; } server { ... location /http/ { proxy_pass https://http_backend; proxy_http_version 1.1; proxy_set_header Connection ""; } }

Lo que hace este código es mandar las peticiones TCP enviadas a /http/ a un upstream y servir una conexión distinta para cada usuario. Huelga decir que con la orden "ntlm" (solo disponible en NGINX Plus) especificamos que se está usando NTLM en la autenticación de los usuarios.

Importante: para que la autenticación NTLM funcione correctamente, es necesario que la directiva proxy_http_version sea "1.1" y el campo de encabezado "Conexión" sea borrado.


Fuentes:

https://docs.microsoft.com/es-es/windows/win32/secauthn/microsoft-ntlm
https://nginx.org/en/docs/http/ngx_http_upstream_module.html#ntlm
0

miércoles, 5 de mayo de 2021

Eliminar kernels viejos en SUSE Linux



Cómo eliminar un kernel viejo de un SUSE Linux para liberar espacio.



Hoy he actualizado un SUSE Linux Enterprise Server y el sistema me ha devuelto un error indicando que faltaba espacio en disco para instalar un nuevo kernel:

... (182/184) Installing: kernel-default-5.3.18-59.19.1.x86_64 ......................................................................[error] Installation of kernel-default-5.3.18-59.19.1.x86_64 failed: Error: Subprocess failed. Error: RPM failed: installing package kernel-default-5.3.18-59.19.1.x86_64 needs 76MB on the /boot filesystem

Para hacer espacio, tenía dos opciones:

- Borrar archivos no usados.
- Añadir espacio en disco a la máquina virtual.

He optado por la primera y he eliminado el kernel antiguo:

HOST # zypper purge-kernels Reading installed packages... Preparing to purge obsolete kernels... Configuration: latest,latest-1,running Running kernel release: 4.12.14-150.32-default Running kernel arch: x86_64 Resolving package dependencies... The following package is going to be REMOVED: kernel-default-4.12.14-150.22.1 1 package to remove. After the operation, 218.7 MiB will be freed. Continue? [y/n/v/...? shows all options] (y):

Tras eliminar el kernel viejo, el nuevo kernel se ha instalado sin problemas:

HOST # zypper up Refreshing service 'Basesystem_Module_x86_64'. Refreshing service 'Containers_Module_x86_64'. Refreshing service 'Desktop_Applications_Module_x86_64'. Refreshing service 'Development_Tools_Module_x86_64'. Refreshing service 'Legacy_Module_x86_64'. Refreshing service 'Public_Cloud_Module_x86_64'. Refreshing service 'Python_2_Module_x86_64'. Refreshing service 'SUSE_Cloud_Application_Platform_Tools_Module_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'. Refreshing service 'Server_Applications_Module_x86_64'. Loading repository data... Reading installed packages... The following NEW package is going to be installed: kernel-default-5.3.18-59.19.1 The following package requires a system reboot: kernel-default-5.3.18-59.19.1 1 new package to install. Overall download size: 64.2 MiB. Already cached: 0 B. After the operation, additional 148.4 MiB will be used. Note: System reboot required. Continue? [y/n/v/...? shows all options] (y): y Retrieving package kernel-default-5.3.18-59.19.1.x86_64 (1/1), 64.2 MiB (148.4 MiB unpacked) Retrieving: kernel-default-5.3.18-59.19.1.x86_64.rpm ......[done (11.7 MiB/s)] Checking for file conflicts: ...........................................[done] (1/1) Installing: kernel-default-5.3.18-59.19.1.x86_64 .................[done]

Tras esto, el nuevo kernel ha quedado instalado.
0