Connecting Jitsi Meet to Active Directory: A Complete Guide to Configuration and Troubleshooting

Jitsi Meet — an open platform for video conferencing. It can be connected to Active Directory (AD) so that employees sign in with corporate accounts: you don’t need to create users separately, and disabling an account in AD immediately closes access to conferences.

This guide covers connecting Jitsi Meet in Docker to AD on Windows Server 2016 and a debugging workflow that helps quickly find the cause of an error. Installing Jitsi in Docker is described in the article How to Install Jitsi Meet on Your Server Using Docker, comparison with cloud services — in the article Jitsi Meet vs Google Meet: which to choose when control over your data matters. If a Linux directory is used instead of AD, see the article on FreeIPA.

Important: without encryption user passwords are transmitted over the network in clear text. For testing the scheme this is acceptable, but in a production system you need LDAPS (port 636) with a valid certificate — configuration is given below.

Preparing Active Directory

You need a separate service account (bind account) under which Prosody searches for users in the directory.

1. Create the bind account

1. In the Active Directory Users and Computers console create a user, for example:

   • Name = bind
   • SamAccountName = binduser

2. Set a long random password and clear the User must change password at next logon flag.

3. Using the Delegation of Control wizard (Delegate Control) grant the «Read all user information» rights to the required Organizational Unit (OU).

2. Get the user’s DN

On the domain controller run in PowerShell:

Get-ADUser -Identity "binduser" -Properties DistinguishedName

Example output:

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

This DistinguishedName value will be needed when configuring Jitsi.

3. Temporarily relax LDAP signing requirements (for testing only)

If connecting via ldap:// returns the error Strong auth required, the controller requires LDAP signing. For testing the scheme you can temporarily relax the requirement:

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

Value 1 means “Negotiate signing”. After testing, set it back to 2 and switch to LDAPS: you must not leave a relaxed policy on the domain controller.

Configuring Jitsi Meet in Docker

In the docker-jitsi-meet directory add LDAP parameters to the .env file (variable names follow the project’s env.example):

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

To allow login using an address like user@domain.local replace the filter:

LDAP_FILTER=(userPrincipalName=%u)

Production option: 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

With LDAP_TLS_CHECK_PEER=1 the controller’s certificate is checked, so the root certificate of your certification authority must be in the store referenced by LDAP_TLS_CACERT_FILE (or LDAP_TLS_CACERT_DIR) inside the container. Instead of LDAPS you can use STARTTLS: LDAP_START_TLS=1 with the address ldap://.

Name resolution of the controller: extra_hosts

The prosody container may be unable to resolve the domain controller’s name if Docker uses public DNS servers. In that case add the controller address manually via extra_hosts in docker-compose.yml.

Example section:

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

Restart the containers:

docker compose down
docker compose up -d

Verify Prosody configuration

Check that the settings made it into the saslauthd configuration inside the container:

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

The parameters should match the variables from .env.

Testing and troubleshooting

Before logging in through the browser, test LDAP and SASL from inside the container.

1. Install tools

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

2. Test the bind account

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)"

If the command returned the user entry, the connection and search are working.

3. Test user authentication

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

Expected result:

0: OK "Success."

Verify login via the web interface

Open https://your-jitsi.com and sign in with the AD account. With correct configuration the user can create conferences.

Debugging and diagnosing errors

Check in order: network, service account, user search, user authentication.

Check network connection and AD availability

View Prosody logs

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

For detailed diagnosis run saslauthd in debug mode:

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

And repeat the check:

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

Common errors:

• Unknown — incorrect DN or filter.
• Invalid credentials — wrong binduser password.
• Bind failed — TLS issue or AD security policy.

Check state in Active Directory

On the domain controller check the account state:

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

Failed login attempts are shown in Event Viewer → Windows Logs → Security (event 4625). If there are no such events, the request from Jitsi is not reaching the controller — check the network and the address in LDAP_URL.

Common issues and solutions

Conclusion

Connecting Jitsi Meet to Active Directory moves conference sign-in to corporate accounts. The key points are correctly specifying the service account DN and the search filter and verifying them with ldapsearch and testsaslauthd before logging in via the browser. After verification be sure to enable LDAPS and restore strict LDAP signing requirements on the domain controller.