LDAP: CONNECTION FAILED: connection.passwordRequired

#1

Hello!
The problem with setting up LDAP, when entering the login and password, it says that the login or password is not correct.

Config: /etc/prosody/conf.avail/192.168.0.154.cfg.lua

unlimited_jids = {
    "focus@auth.192.168.0.154",
    "jvb@auth.192.168.0.154"
}

VirtualHost "192.168.0.154"
    -- enabled = false -- Remove this line to enable this host
    authentication = "ldap2"
    -- Properties below are modified by jitsi-meet-tokens package config
    -- and authentication above is switched to "token"
    --app_id="example_app_id"
    --app_secret="example_app_secret"
    -- Assign this host a certificate for TLS, otherwise it would use the one
    -- set in the global section (if any).
    -- Note that old-style SSL on port 5223 only supports one certificate, and will always
    -- use the global one.
    ssl = {
        key = "/etc/prosody/certs/192.168.0.154.key";
        certificate = "/etc/prosody/certs/192.168.0.154.crt";
    }
    av_moderation_component = "avmoderation.192.168.0.154"
    speakerstats_component = "speakerstats.192.168.0.154"
    conference_duration_component = "conferenceduration.192.168.0.154"
    -- we need bosh
    modules_enabled = {
        "bosh";
        "pubsub";
        "ping"; -- Enable mod_ping
        "speakerstats";
        "external_services";

Config: /etc/prosody/conf.avail/ldap.cfg.lua

authentication = 'ldap2'

ldap = {
    hostname = 'srv-dc1.comp.local', 
    bind_dn = 'CN=testuser,OU=Отдел ИТ,OU=COMPANY,DC=dzl,DC=local', 
    bind_password = 'Sopr@', 
    user = {
        basedn = 'DC=dzl,DC=local', 
        filter = '(&(objectClass=user)(memberof=CN=Отдел ИТ,CN=COMPANY,DC=dzl,DC=local))', 
        usernamefield = 'sAMAccountName',
        namefield = 'cn', 
    },
}

55553333
555533331880×395 193 KB

Login and password from the user are entered correctly

#2

Are the requests reaching LDAP server?
Is it the LDAP server that is sending that response?

#3

Yes

root@SRV-MEET1:/var/log/prosody# ping srv-dc1.dzl.local
PING srv-dc1.dzl.local (192.168.0.164) 56(84) bytes of data.
64 bytes from srv-dc1.dzl.local (192.168.0.164): icmp_seq=1 ttl=128 time=0.598 ms
64 bytes from srv-dc1.dzl.local (192.168.0.164): icmp_seq=2 ttl=128 time=0.877 ms
64 bytes from srv-dc1.dzl.local (192.168.0.164): icmp_seq=3 ttl=128 time=0.719 ms
64 bytes from srv-dc1.dzl.local (192.168.0.164): icmp_seq=4 ttl=128 time=0.812 ms
64 bytes from srv-dc1.dzl.local (192.168.0.164): icmp_seq=5 ttl=128 time=0.859 ms
#4

Did you check the prosody logs

/var/log/prosody/...

#5

Yes, I don’t see any problem.

prosody.log

Jun 21 16:21:35 mod_bosh	info	Client tried to use sid '73934114-a040-47f9-b04a-559d1dc3575d' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid 'a3cfb871-b397-46c4-9401-049adf7fe0a0' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid '4a31a80e-7be8-4de6-b167-91c827bc234f' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid '611b804a-9042-4286-b4fd-5d54d37fe87c' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid '6180877e-28eb-4197-bf82-1269942a725d' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid 'bc2e87b0-a800-4b2b-8b8c-38942f1108c2' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid 'eebd84dc-5f8d-4ede-b86f-5c21ada5de40' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid '1f9be28d-9b67-4d56-8ccd-d1bc59028bf0' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid 'db22c382-ca7f-4df3-abbc-0ff7fc8a4413' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid '04bf9ff7-530f-4844-9009-fb78816c644d' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid 'c56e08e8-7fa9-4cc6-837e-66bd449b1732' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid '99d5da38-ad96-431a-8b17-6072486f83d3' which we don't know about
Jun 21 16:21:35 mod_bosh	info	Client tried to use sid '0f59ad6b-9e7e-469d-a304-9d0928a1fc77' which we don't know about
Jun 21 16:21:35 boshaf4db6da-6196-4b22-9e80-ab80f617b420	info	BOSH client disconnected: session close
Jun 21 17:36:06 mod_bosh	info	New BOSH session, assigned it sid '2a69ea2d-b56a-465b-b4df-8880cc51c9d4'
Jun 21 17:36:07 bosh2a69ea2d-b56a-465b-b4df-8880cc51c9d4	info	BOSH client disconnected: session close
Jun 21 17:36:22 mod_bosh	info	New BOSH session, assigned it sid '7c3981e8-ed1c-4766-8f99-4e538f998c1a'
Jun 21 17:36:51 mod_bosh	info	New BOSH session, assigned it sid '2219ed18-a65f-40b5-a3c2-31dc167954cb'
Jun 21 17:36:54 mod_bosh	info	New BOSH session, assigned it sid '8f511aa8-a328-45a6-a938-2cef0f0d1df7'
Jun 21 17:37:14 bosh7c3981e8-ed1c-4766-8f99-4e538f998c1a	info	BOSH client disconnected: session close
Jun 21 17:37:14 bosh2219ed18-a65f-40b5-a3c2-31dc167954cb	info	BOSH client disconnected: session close
Jun 21 17:37:14 bosh8f511aa8-a328-45a6-a938-2cef0f0d1df7	info	BOSH client disconnected: session close
Jun 21 17:37:14 mod_bosh	info	New BOSH session, assigned it sid 'dc63583a-113c-4bc3-bbce-8269136ae253'
Jun 21 17:37:14 boshdc63583a-113c-4bc3-bbce-8269136ae253	info	BOSH client disconnected: session close
Jun 21 17:37:22 mod_bosh	info	New BOSH session, assigned it sid 'd2efda11-8420-4dfb-9a35-defeaea8ad28'
Jun 22 08:51:55 mod_bosh	info	New BOSH session, assigned it sid 'e7b66a83-b02c-4101-ae60-45710926c34e'
Jun 22 08:51:55 boshe7b66a83-b02c-4101-ae60-45710926c34e	info	BOSH client disconnected: session close
Jun 22 08:52:01 mod_bosh	info	New BOSH session, assigned it sid '29c3f70c-67cb-4bd5-a04b-cb59455c9f8d'

My Linux server is not included in the domain network, in theory, AD accepts connections on port 389 even if the server is not in the domain.

#6

Understood, the main problem was the filter. Anyone who has a similar problem, check the correct syntax for writing filters.

filter        = '(&(objectClass=User)(memberof=CN