Conectar Jitsi Meet a Active Directory: Guía completa de configuración y resolución de problemas

Jitsi Meet — una plataforma de código abierto para videoconferencias. Se puede conectar a Active Directory (AD) para que los empleados inicien sesión con cuentas corporativas: no es necesario crear usuarios por separado y la desactivación de una cuenta en AD cierra inmediatamente el acceso a las conferencias.

En esta guía se describe cómo conectar Jitsi Meet en Docker a AD en Windows Server 2016 y el procedimiento de depuración que ayuda a encontrar rápidamente la causa de un error. La instalación de Jitsi en Docker está descrita en el artículo “Cómo instalar Jitsi Meet en su servidor con Docker”, la comparación con servicios en la nube — en el artículo “Jitsi Meet contra Google Meet”. Si en lugar de AD utiliza un directorio en Linux, vea el artículo sobre FreeIPA.

Importante: sin cifrado, las contraseñas de los usuarios se transmiten por la red en texto claro. Para comprobar el esquema esto es aceptable, pero en un sistema en producción se necesita LDAPS (puerto 636) con un certificado correcto — la configuración se indica más abajo.

Preparación de Active Directory

Se necesita una cuenta de servicio separada (cuenta bind), en nombre de la cual Prosody buscará usuarios en el directorio.

1. Creamos la cuenta bind

1. En la consola Active Directory Users and Computers cree un usuario, por ejemplo:

   • Name = bind
   • SamAccountName = binduser

2. Establezca una contraseña larga y aleatoria y quite la casilla User must change password at next logon.

3. Con el asistente de delegación (Delegate Control) otorgue el permiso “Read all user information” sobre la unidad organizativa (OU) correspondiente.

2. Obtenemos el DN del usuario

En el controlador de dominio ejecute en PowerShell:

Get-ADUser -Identity "binduser" -Properties DistinguishedName

Ejemplo de salida:

CN=bind,CN=Users,DC=example,DC=local

Este valor DistinguishedName será necesario para la configuración de Jitsi.

3. Debilitamos temporalmente los requisitos de firma LDAP (solo para pruebas)

Si al conectarse por ldap:// aparece el error Strong auth required, el controlador exige firma LDAP. Para comprobar el esquema se puede debilitar temporalmente el requisito:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LDAPServerIntegrity" -Value 1
Restart-Service NTDS -Force

El valor 1 significa “firma negociada” (Negotiate signing). Tras la comprobación vuelva al valor 2 y pase a LDAPS: no se debe dejar la política debilitada en el controlador de dominio.

Configuración de Jitsi Meet en Docker

En el directorio docker-jitsi-meet agregue los parámetros LDAP en el archivo .env (nombres de variables según env.example del proyecto):

ENABLE_AUTH=1
AUTH_TYPE=ldap
LDAP_URL=ldap://your-dc.example.com:389/
LDAP_BASE=DC=example,DC=local
LDAP_BINDDN=CN=bind,CN=Users,DC=example,DC=local
LDAP_BINDPW=YourBindPassword
LDAP_FILTER=(sAMAccountName=%u)
LDAP_AUTH_METHOD=bind
LDAP_VERSION=3
LDAP_USE_TLS=0
LDAP_TLS_CHECK_PEER=0
ENABLE_GUESTS=0

Para iniciar sesión con una dirección del tipo user@domain.local reemplace el filtro:

LDAP_FILTER=(userPrincipalName=%u)

Opción para un sistema en producción: LDAPS

LDAP_URL=ldaps://your-dc.example.com:636/
LDAP_USE_TLS=1
LDAP_TLS_CHECK_PEER=1
LDAP_TLS_CACERT_FILE=/etc/ssl/certs/ca-certificates.crt

Con LDAP_TLS_CHECK_PEER=1 se verifica el certificado del controlador, por lo que el certificado raíz de su autoridad de certificación debe estar en el almacén apuntado por LDAP_TLS_CACERT_FILE (o LDAP_TLS_CACERT_DIR) dentro del contenedor. En lugar de LDAPS puede usar STARTTLS: LDAP_START_TLS=1 con la dirección ldap://.

Resolución del nombre del controlador: extra_hosts

El contenedor prosody puede no resolver el nombre del controlador de dominio si Docker usa servidores DNS públicos. En ese caso añada la dirección del controlador manualmente mediante extra_hosts en docker-compose.yml.

Ejemplo de sección:

services:
  prosody:
    image: jitsi/prosody:latest
    extra_hosts:
      - "your-dc.example.com:192.168.1.10"

Reinicie los contenedores:

docker compose down
docker compose up -d

Verificamos la configuración de Prosody

Compruebe que los ajustes se hayan aplicado en la configuración de saslauthd dentro del contenedor:

docker compose exec prosody bash
cat /etc/saslauthd.conf

Los parámetros deben coincidir con las variables del .env.

Pruebas y depuración

Antes de iniciar sesión desde el navegador, verifique LDAP y SASL desde el contenedor.

1. Instalamos herramientas

apt-get update
apt-get install -y ldap-utils 

2. Comprobamos la cuenta bind

ldapsearch -x -H ldap://your-dc.example.com:389 \
  -D "CN=bind,CN=Users,DC=example,DC=local" \
  -w 'YourBindPassword' \
  -b "DC=example,DC=local" "(sAMAccountName=user)"

Si el comando devuelve la entrada del usuario, la conexión y la búsqueda funcionan.

3. Comprobamos la autorización del usuario

testsaslauthd -u user -p 'UserPassword' -s xmpp -r meet.jitsi

Resultado esperado:

0: OK "Success."

Comprobamos el inicio de sesión a través de la interfaz web

Abra https://your-jitsi.com e inicie sesión con una cuenta de AD. Si la configuración es correcta, el usuario podrá crear conferencias.

Depuración y diagnóstico de errores

Compruebe por orden: red, cuenta de servicio, búsqueda del usuario, inicio de sesión del usuario.

Comprobamos la conexión de red y la disponibilidad del AD

Revisamos los registros de Prosody

docker compose logs prosody | grep -i "auth\|ldap\|failure"

Para diagnóstico detallado, inicie saslauthd en modo depuración:

killall saslauthd
saslauthd -d -a ldap -O /etc/saslauthd.conf -n 5

Y vuelva a realizar la comprobación:

testsaslauthd -u user -p 'Password' -s xmpp -r meet.jitsi

Errores típicos:

• Unknown — DN o filtro incorrecto.
• Invalid credentials — error en la contraseña de binduser.
• Bind failed — problema de TLS o política de seguridad de AD.

Comprobamos el estado en Active Directory

En el controlador de dominio, compruebe el estado de la cuenta:

Get-ADUser user -Properties LockedOut, BadLogonCount, DistinguishedName
Unlock-ADAccount -Identity user

Los intentos fallidos de inicio de sesión aparecen en Event Viewer → Windows Logs → Security (eventos 4625). Si no hay tales eventos, la solicitud de Jitsi al controlador no llega: compruebe la red y la dirección en LDAP_URL.

Problemas comunes y sus soluciones

Conclusión

Conectar Jitsi Meet a Active Directory integra el inicio de sesión de las conferencias con las cuentas corporativas. Lo más importante es especificar correctamente el DN de la cuenta de servicio y el filtro de búsqueda, y verificarlos con ldapsearch y testsaslauthd antes de iniciar sesión desde el navegador. Tras la verificación, active obligatoriamente LDAPS y restaure los requisitos estrictos de firma LDAP en el controlador de dominio.