Jitsi, Authentication against local AD server not working

Support
1

NethServer Version: NethServer 7.9.2009
Module: Jitsi, Local Active Directory
VM in parallels
Self-signed certificate
LDAP ip: 192.168.10.10
Jitsi/prosody IP: 172.28.0.2

Hi all,

I installed jitsi following the procedure in the wiki. Jitsi is reachable on https://meet.nethserver.home:8443/

Now I’m trying to get authentication to work. I tried everything I could think of, but can’t get it to work. And I cannot find what’s wrong…
So I might be a bit to excessive in the information below, but the question is: How can I solve this? What else can I do to investigate this?

Thanks for your time!

René

Enable guests

I started by just making sure Jitsi works for guest. For this I made the following changes in /opt/jitsi/docker-jitsi-meet/.env

# replace meet.jitsi with local settings
:%s/meet.jitsi/nethserver.home/gc

# add port to PUBLIC_URL
# PUBLIC_URL=https://meet.nethserver.home
PUBLIC_URL=https://meet.nethserver.home:8443
# disable authentication
#ENABLE_AUTH=1
ENABLE_AUTH=0

Resulting .env file:

JICOFO_COMPONENT_SECRET=b9049e3eb1bba74f9188c99c35d51a1b
JICOFO_AUTH_PASSWORD=ad1fb3944c74ae217f20079f01ca7d03
JVB_AUTH_PASSWORD=f966be726ce89809e729b2525942505f
JIGASI_XMPP_PASSWORD=42043ee1107a0d6712fcf18778ebb41c
JIBRI_RECORDER_PASSWORD=624fc344ffbf51c38d6eb6cb663baca7
JIBRI_XMPP_PASSWORD=5022d94d6ebef29e01d48676acc8b38d
CONFIG=/opt/jitsi/.jitsi-meet-cfg
HTTP_PORT=8000
HTTPS_PORT=8443
TZ=Europe/Amsterdam
PUBLIC_URL=https://meet.nethserver.home:8443
ETHERPAD_TITLE="Video Chat"
ETHERPAD_DEFAULT_PAD_TEXT="Welcome to Web Chat!\n\n"
ETHERPAD_SKIN_NAME="colibris"
ETHERPAD_SKIN_VARIANTS="super-light-toolbar super-light-editor light-background full-width-editor"
ENABLE_AUTH=0
ENABLE_GUESTS=1
AUTH_TYPE=ldap
LDAP_URL=ldaps://172.28.0.0:636
LDAP_BASE=dc=ad,dc=nethserver,dc=home
LDAP_BINDDN=CN=binduser,OU=users,DC=AD,DC=NETHSERVER,DC=HOME
LDAP_BINDPW="bKlDbcv_ITSx2Qic"
LDAP_FILTER=(uid=%u)
LDAP_AUTH_METHOD=bind
LDAP_USE_TLS=1
XMPP_DOMAIN=nethserver.home
XMPP_SERVER=xmpp.nethserver.home
XMPP_BOSH_URL_BASE=http://xmpp.nethserver.home:5280
XMPP_AUTH_DOMAIN=auth.nethserver.home
XMPP_MUC_DOMAIN=muc.nethserver.home
XMPP_INTERNAL_MUC_DOMAIN=internal-muc.nethserver.home
XMPP_GUEST_DOMAIN=guest.nethserver.home
XMPP_MODULES=
XMPP_MUC_MODULES=
XMPP_INTERNAL_MUC_MODULES=
JVB_BREWERY_MUC=jvbbrewery
JVB_AUTH_USER=jvb
JVB_STUN_SERVERS=meet-jit-si-turnrelay.jitsi.net:443
JVB_PORT=10000
JVB_TCP_HARVESTER_DISABLED=true
JVB_TCP_PORT=4443
JVB_TCP_MAPPED_PORT=4443
JICOFO_AUTH_USER=focus
JIGASI_XMPP_USER=jigasi
JIGASI_BREWERY_MUC=jigasibrewery
JIGASI_PORT_MIN=20000
JIGASI_PORT_MAX=20050
XMPP_RECORDER_DOMAIN=recorder.nethserver.home
JIBRI_RECORDER_USER=recorder
JIBRI_RECORDING_DIR=/config/recordings
JIBRI_XMPP_USER=jibri
JIBRI_BREWERY_MUC=jibribrewery
JIBRI_PENDING_TIMEOUT=90
JIBRI_STRIP_DOMAIN_JID=muc
JIBRI_LOGS_DIR=/config/logs
RESTART_POLICY=unless-stopped

Completely rebuild and restart docker

docker-compose down && rm -rf ../.jitsi-meet-cfg/ && docker-compose up -d

Jitsi meet is now working for guests

Test LDAP connection

To make sure I can reach the AD server from the jitsi-prosody container I tested this using:

docker exec -ti docker-jitsi-meet_prosody_1 bash
apt-get update
apt-get install ldap-utils

ldapsearch -H ldaps://192.168.10.10:636 -x -D CN=ldapservice,CN=Users,DC=ad,DC=nethserver,DC=home -w bKlDbcv_ITSx2Qic -b CN=Users,DC=ad,DC=nethserver,DC=home

This works without problems.

Enable authentication in .env file

To get authentication to work I made the following changes to /opt/jitsi/docker-jitsi-meet/.env

# enable authentication
ENABLE_AUTH=1
#ENABLE_AUTH=0
# LDAP url for connection
LDAP_URL=ldaps://192.168.10.10:636
# LDAP base DN. Can be empty
LDAP_BASE=CN=Users,DC=ad,DC=nethserver,DC=home
# LDAP user DN. Do not specify this parameter for the anonymous bind
LDAP_BINDDN=CN=ldapservice,CN=Users,DC=ad,DC=nethserver,DC=home
# LDAP user password. Do not specify this parameter for the anonymous bind
LDAP_BINDPW=bKlDbcv_ITSx2Qic
# LDAP TLS using
#LDAP_USE_TLS=1
LDAP_USE_TLS=0

After rebuilding/restarting Docker a host needs to log in when starting a meeting in Jitsi. But logging in with NSuser@nethserver.home and password does not work.

Firefox logging

Firefox console gives a strange error:

021-03-22T11:59:04.358Z [modules/UI/authentication/AuthHandler.js] <b/</n</<>:  authenticateAndUpgradeRole failed 
{…}
connectionError: "connection.passwordRequired"
​credentials: Object { jid: "NSuser@nethserver.home", password: "PassWord" }
message: null
logging in prosody.log

The logging in the prosody.log is not really descriptive either :smirk:

saslauthd[275] :released accept lock
saslauthd[276] :acquired accept lock
saslauthd[275] :attempting a read lock on slot: 692
saslauthd[275] :[login=NSuser] [service=xmpp] [realm=nethserver.home]: not found, update pending
saslauthd[275] :attempting to release lock on slot: 692
saslauthd[275] :auth failure: [user=NSuser] [service=xmpp] [realm=nethserver.home] [mech=ldap] [reason=Unknown]
saslauthd[275] :response: NO
Testing with testsaslauthd

Testing with testsaslauthd doesn’t give a lot of information. Logging in prosody is the same as above.

docker exec -ti docker-jitsi-meet_prosody_1 bash
testsaslauthd -u NSuser -p PassWord -r nethserver.home -s xmpp
0: NO "authentication failed"
Samba logging

Man, it was hard to find this…
I finally found out that I needed to change /var/lib/machines/nsdc/etc/samba/smb.conf And I added the following:

log level = 1 auth_audit:10 auth_json_audit:10 
log file = /var/log/samba.log.%m
max log size = 50
debug timestamp = yes

After restarting samba (via nsdc)

systemctl stop nsdc
systemctl start nsdc

I could find the following in the log which correlates to issuing the testsaslauthd command (using: journalctl -M nsdc -f)

Mar 19 16:45:01 nsdc-myhost.ad.nethserver.home samba[25]: Auth: [LDAP,simple bind] user [(null)]\[ldapservice@AD.NETHSERVER.HOME] at [Fri, 19 Mar 2021 16:45:01.750952 CET] with [Plaintext] status [NT_STATUS_OK] workstation [(null)] remote host [ipv4:192.168.10.2:50188] became [NETHSERVER]\[ldapservice] [S-1-5-21-2079265069-3524957898-2694064665-1103]. local host [ipv4:192.168.10.10:636]
Mar 19 16:45:01 nsdc-myhost.ad.nethserver.home samba[25]: {"timestamp": "2021-03-19T16:45:01.751064+0100", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 0}, "status": "NT_STATUS_OK", "localAddress": "ipv4:192.168.10.10:636", "remoteAddress": "ipv4:192.168.10.2:50188", "serviceDescription": "LDAP", "authDescription": "simple bind", "clientDomain": null, "clientAccount": "ldapservice@AD.NETHSERVER.HOME", "workstation": null, "becameAccount": "ldapservice", "becameDomain": "NETHSERVER", "becameSid": "S-1-5-21-2079265069-3524957898-2694064665-1103", "mappedAccount": "ldapservice", "mappedDomain": "NETHSERVER", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "Plaintext", "duration": 4186}}
Mar 19 16:45:01 nsdc-myhost.ad.nethserver.home samba[25]: Successful AuthZ: [LDAP,simple bind] user [NETHSERVER]\[ldapservice] [S-1-5-21-2079265069-3524957898-2694064665-1103] at [Fri, 19 Mar 2021 16:45:01.753384 CET] Remote host [ipv4:192.168.10.2:50188] local host [ipv4:192.168.10.10:636]
Mar 19 16:45:01 nsdc-myhost.ad.nethserver.home samba[25]: {"timestamp": "2021-03-19T16:45:01.753482+0100", "type": "Authorization", "Authorization": {"version": {"major": 1, "minor": 1}, "localAddress": "ipv4:192.168.10.10:636", "remoteAddress": "ipv4:192.168.10.2:50188", "serviceDescription": "LDAP", "authType": "simple bind", "domain": "NETHSERVER", "account": "ldapservice", "sid": "S-1-5-21-2079265069-3524957898-2694064665-1103", "sessionId": "7d875063-b6c5-4536-83a5-7c5b348facb9", "logonServer": "NSDC-MYHOST", "transportProtection": "TLS", "accountFlags": "0x00000210"}}
Mar 19 16:47:22 nsdc-myhost.ad.nethserver.home samba[25]: Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[MYHOST$@AD.NETHSERVER.HOME] at [Fri, 19 Mar 2021 16:47:22.021236 CET] with [aes256-cts-hmac-sha1-96] status [NT_STATUS_OK] workstation [(null)] remote host [ipv4:192.168.10.2:42913] became [NETHSERVER]\[MYHOST$] [S-1-5-21-2079265069-3524957898-2694064665-1104]. local host [NULL]
Mar 19 16:47:22 nsdc-myhost.ad.nethserver.home samba[25]: {"timestamp": "2021-03-19T16:47:22.021284+0100", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 0}, "status": "NT_STATUS_OK", "localAddress": null, "remoteAddress": "ipv4:192.168.10.2:42913", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientAccount": "MYHOST$@AD.NETHSERVER.HOME", "workstation": null, "becameAccount": "MYHOST$", "becameDomain": "NETHSERVER", "becameSid": "S-1-5-21-2079265069-3524957898-2694064665-1104", "mappedAccount": "MYHOST$", "mappedDomain": "NETHSERVER", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "aes256-cts-hmac-sha1-96", "duration": 2587}}
Mar 19 16:47:22 nsdc-myhost.ad.nethserver.home samba[25]: Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[MYHOST$@AD.NETHSERVER.HOME] at [Fri, 19 Mar 2021 16:47:22.027792 CET] with [aes256-cts-hmac-sha1-96] status [NT_STATUS_OK] workstation [(null)] remote host [ipv4:192.168.10.2:53986] became [NETHSERVER]\[MYHOST$] [S-1-5-21-2079265069-3524957898-2694064665-1104]. local host [NULL]
Mar 19 16:47:22 nsdc-myhost.ad.nethserver.home samba[25]: {"timestamp": "2021-03-19T16:47:22.027831+0100", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 0}, "status": "NT_STATUS_OK", "localAddress": null, "remoteAddress": "ipv4:192.168.10.2:53986", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientAccount": "MYHOST$@AD.NETHSERVER.HOME", "workstation": null, "becameAccount": "MYHOST$", "becameDomain": "NETHSERVER", "becameSid": "S-1-5-21-2079265069-3524957898-2694064665-1104", "mappedAccount": "MYHOST$", "mappedDomain": "NETHSERVER", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "aes256-cts-hmac-sha1-96", "duration": 2554}}
Mar 19 16:47:22 nsdc-myhost.ad.nethserver.home samba[25]: Successful AuthZ: [LDAP,krb5] user [NETHSERVER]\[MYHOST$] [S-1-5-21-2079265069-3524957898-2694064665-1104] at [Fri, 19 Mar 2021 16:47:22.044082 CET] Remote host [ipv4:192.168.10.2:48232] local host [ipv4:192.168.10.10:389]
Mar 19 16:47:22 nsdc-myhost.ad.nethserver.home samba[25]: {"timestamp": "2021-03-19T16:47:22.044201+0100", "type": "Authorization", "Authorization": {"version": {"major": 1, "minor": 1}, "localAddress": "ipv4:192.168.10.10:389", "remoteAddress": "ipv4:192.168.10.2:48232", "serviceDescription": "LDAP", "authType": "krb5", "domain": "NETHSERVER", "account": "MYHOST$", "sid": "S-1-5-21-2079265069-3524957898-2694064665-1104", "sessionId": "01ed47a4-77c0-4f49-a8b6-3c5ffab60f17", "logonServer": "NSDC-MYHOST", "transportProtection": "SEAL", "accountFlags": "0x00000080"}}

As far as I can tell, this confirms the ‘ldapservice’ user is authenticated. But I cannot tell what query is run against the ldap server.

Wireshark

I even installed wireshark to make sure there is traffic between the prosody container and the ldap server:

21 11.700735869 192.168.10.2 -> 192.168.10.10 TLSv1.2 176 Application Data
 22 11.700757082 192.168.10.10 -> 172.28.0.2   TCP 54 ldaps > 34116 [RST] Seq=1 Win=0 Len=0
 23 11.700905168 192.168.10.2 -> 192.168.10.10 TCP 74 34246 > ldaps [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=7195153 TSecr=0 WS=128
 24 11.700915629 192.168.10.10 -> 172.28.0.2   TCP 74 ldaps > 34246 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=7195153 TSecr=7195153 WS=128
 25 11.700933182 192.168.10.2 -> 192.168.10.10 TCP 66 34246 > ldaps [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=7195153 TSecr=7195153
 26 11.701126657 192.168.10.2 -> 192.168.10.10 SSL 403 Client Hello
 27 11.701132658 192.168.10.10 -> 172.28.0.2   TCP 66 ldaps > 34246 [ACK] Seq=1 Ack=338 Win=30080 Len=0 TSval=7195153 TSecr=7195153
 28 11.718625324 192.168.10.10 -> 172.28.0.2   TLSv1.2 2437 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
 29 11.718721269 192.168.10.2 -> 192.168.10.10 TCP 66 34246 > ldaps [ACK] Seq=338 Ack=2372 Win=34048 Len=0 TSval=7195171 TSecr=7195171
 30 11.719317974 192.168.10.2 -> 192.168.10.10 TLSv1.2 78 Certificate
 31 11.719346052 192.168.10.2 -> 192.168.10.10 TLSv1.2 141 Client Key Exchange
 32 11.719373913 192.168.10.2 -> 192.168.10.10 TLSv1.2 72 Change Cipher Spec
 33 11.719384729 192.168.10.2 -> 192.168.10.10 TLSv1.2 111 Hello Request, Hello Request
 34 11.719708012 192.168.10.10 -> 172.28.0.2   TCP 66 ldaps > 34246 [ACK] Seq=2372 Ack=476 Win=30080 Len=0 TSval=7195172 TSecr=7195171
 35 11.719808893 192.168.10.10 -> 172.28.0.2   TLSv1.2 117 Change Cipher Spec, Hello Request, Hello Request
 36 11.720065803 192.168.10.2 -> 192.168.10.10 TLSv1.2 176 Application Data
 37 11.727595457 192.168.10.10 -> 172.28.0.2   TLSv1.2 109 Application Data
 38 11.727684515 192.168.10.2 -> 192.168.10.10 TLSv1.2 176 Application Data
 39 11.730318469 192.168.10.10 -> 172.28.0.2   TLSv1.2 109 Application Data
 40 11.770065539 192.168.10.2 -> 192.168.10.10 TCP 66 34246 > ldaps [ACK] Seq=696 Ack=2509 Win=34048 Len=0 TSval=7195222 TSecr=7195182
2

@Reheer

Hi

A lot of Web-Apps (Not only Java based ones!) NEED a valid SSL Cert on your AD.
The AD uses a self generated cert, even if NethServer has LE certs.

What you can do is have the Certs copied over (And the name / fqdn for your AD in the cert).
See here:

And look for this string:
" The next step will make sure that java and other more strict apps can connect to the AD and use it :"

I have this working on my home NethServer…

My 2 cents
Andy

3

@Andy_Wismer Thank you for your help!

Following that guide didn’t solve the problem. But it gave some new inspiration…

Spoiler: what I tried didn’t solve the problem either. But I did learn some new things, so that’s a win… I’m starting to think I’d better wait with wanting to solve this till I have a VPS running with a public IP/FQDN and a Let’s Encrypt certificate.

But if anyone has got any other viable ideas…

I decided to try with a custom key so I did the following.

create custom private key
# cd /var/lib/machines/nsdc/var/lib/samba/private/tls
# openssl req -newkey rsa:2048 -keyout myKey.pem -nodes -x509 -days 365 -out myCert.pem
Generating a 2048 bit RSA private key
...................+++
......................................+++
writing new private key to 'myKey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:NL
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:NSDC-MYHOST.ad.nethserver.home
Email Address []:

# chmod 600 myKey.pem

Edit /var/lib/machines/nsdc/etc/samba/smb.conf

        tls enabled  = yes
        tls keyfile  = tls/myKey.pem
        tls certfile = tls/myCert.pem
        tls cafile   =

Create /etc/e-smith/events/certificate-update/nsdc-cert

#!/bin/bash
cp -f /etc/pki/tls/private/myKey.key /var/lib/machines/nsdc/var/lib/samba/private/tls/myKey.pem
cp -f /etc/pki/tls/certs/myCert.crt /var/lib/machines/nsdc/var/lib/samba/private/tls/myCert.pem
chmod 600 /var/lib/machines/nsdc/var/lib/samba/private/tls/myKey.pem
chmod 644 /var/lib/machines/nsdc/var/lib/samba/private/tls/myCert.pem

Reboot the server

test ssl in Prosody container

Copy the Certificate to the prosody container

docker cp myCert.pem docker-jitsi-meet_prosody_1:/usr/share/ca-certificates/myCert.crt

In the prosody container: add the certificate to trusted CA’s

dpkg-reconfigure ca-certificates

Test the ssl connection

openssl s_client -showcerts -connect 192.168.10.10:636

CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C = NL, L = Default City, O = Default Company Ltd, CN = NSDC-MYHOST.ad.nethserver.home
verify return:1
---
Certificate chain
 0 s:C = NL, L = Default City, O = Default Company Ltd, CN = NSDC-MYHOST.ad.nethserver.home
   i:C = NL, L = Default City, O = Default Company Ltd, CN = NSDC-MYHOST.ad.nethserver.home
-----BEGIN CERTIFICATE-----
MIIDqTCCApGgAwIBAgIJAKm4TXsLKASyMA0GCSqGSIb3DQEBCwUAMGsxCzAJBgNV
BAYTAk5MMRUwEwYDVQQHDAxEZWZhdWx0IENpdHkxHDAaBgNVBAoME0RlZmF1bHQg
Q29tcGFueSBMdGQxJzAlBgNVBAMMHk5TREMtTVlIT1NULmFkLm5ldGhzZXJ2ZXIu
aG9tZTAeFw0yMTAzMjIxNTU1MTBaFw0yMjAzMjIxNTU1MTBaMGsxCzAJBgNVBAYT
Ak5MMRUwEwYDVQQHDAxEZWZhdWx0IENpdHkxHDAaBgNVBAoME0RlZmF1bHQgQ29t
cGFueSBMdGQxJzAlBgNVBAMMHk5TREMtTVlIT1NULmFkLm5ldGhzZXJ2ZXIuaG9t
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYIkOHSlTw0WfisQp4p
H5vULL83OsZDy/amdg0wl/PQ/Rmn4L3S5qHF8aultm/GoH4wZhdAIESCaO32YMjr
ggtFBEbQvEsiFflep1Mqqifs6c3ZkXHLq8Aq/Tvy6NvkoroKnyFaUggYb8FT9Az5
SOZjDOKA9cC/AFLNZPjzmCWOcG5rTKLglkPbH5nGPJx4cNZK2cfALBiyj+U23yXP
Zy225eUwGRK2PboeANlotq/ZvzDLIDrhGqKj7CVJ71ZNyT58p9wCRmEznOq8D/Yv
7AzMcj0TVBwDeb7gWM3BesfuYX9YJOFWBT+7CYraOSM7IVZLmhoeOt6LbqFgRKVJ
DOcCAwEAAaNQME4wHQYDVR0OBBYEFFitE1IXR1/ceQOV9lyY+JI5tX/NMB8GA1Ud
IwQYMBaAFFitE1IXR1/ceQOV9lyY+JI5tX/NMAwGA1UdEwQFMAMBAf8wDQYJKoZI
hvcNAQELBQADggEBAHDZc7auJjg1nDRPib+JzOTGAULU4FxwsJdMMOuVMxMvsNJr
1nJywTxBaad2/3EnJ/Vb0IM4RgE2qaer6EeIZ8xPa1Jixblle1S/6f+euIINz7RN
vsRwhUssNOM27Z9UHkLcktsx3gAnr6n/uKnq6oYGOWzk4gULB59fFqS+WorEcuY1
kdDxSMuKVuUx3uqPzOBVJiiAprwl5WLVYtfDF4lAbTrZJs8lce2Cq8lBjLkDhlGY
efwJYWdbCADeAAwkDn1AUmJ75QnhoGf4dFAf4PG3khiJRW4dstBKN93QK8eC/MtA
wTCjWAG+ycJ5LO3ICvh9yvItqKVzkMSGH2UFUBo=
-----END CERTIFICATE-----
---
Server certificate
subject=C = NL, L = Default City, O = Default Company Ltd, CN = NSDC-MYHOST.ad.nethserver.home

issuer=C = NL, L = Default City, O = Default Company Ltd, CN = NSDC-MYHOST.ad.nethserver.home

---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512:RSA+SHA224:DSA+SHA224:ECDSA+SHA224
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1489 bytes and written 421 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 74A58560D0D857094E3A554106A41BD21CCCDD1650EBC3C2EACE443FF46D41F4
    Session-ID-ctx: 
    Master-Key: 73E21C2AAD477FDC4CA5C68803F60089290B349986BE202DC9DFC7F313DD2B4A6AD15ED854193190E959E4E8BDBCEFDA
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1616434177
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
closed

Succes !

testing saslauthd

in prosody container I first used the ldapsearch commands as in this guide These ldapsearch commands all succeed.

testsaslauth still fails:

testsaslauthd -u NSuser -p PassWord -r nethserver.home -s xmpp
0: NO "authentication failed"
1 Like
4

It’s a long road to the top, but a facinating journey, with lot’s of learning en route!
-> And always worth it! What you’ve learned, no one can take from you!

My 2 cents
Andy

5

It took a while, but I figured out how to solve this problem. This was allready a few weeks ago, but I didn’t have time to report back. So this won’t be as detailed as I would like :nerd_face:

I first tried moving away from Active Directory by using a local LDAP server in hopes of better logging. This didn’t work out as I still ran into the same problems.

So I reverted back to AD and found that I could add a debug parameter to the /etc/saslauthd.conf file in the prosody container:

ldap_debug: 7

Through trial and error this resulted in the conclusion that my certificate wasn’t correct. For some reason samba doesn’t respond with it’s hostname (NSDC-MYHOST.ad.nethserver.home) as I expected, but with it’s IP-address.

So using the IP-address of the AD (192.168.10.10) while creating a custom private key as noted previously, solved the problem (for now).

I wouldn’t mind it if someone could explain why the hostname doesn’t work…

Thanks,

René

6

Hi @Reheer,

I am wrting a test post about Partainer CE -2.1.1 and I describe how to attach a volume for the Let’s Encrypt certificate inside the container when starting it.

I just send you an invitation to my test post.

Hope it will give you some hints as I have the same problem with LDAP connection for Jisti-Meet since a few weeks now and I cannot find adequate answers.

As noted by Andy, you need a LE cert for Jitsi to run properly - I had problem before that as I am testing on a LOCAL VM.

I am using the latest version of all components;

  • Docker-CE_20.10.6 (2021-04-12),
  • Docker-Compose-1.29,1
  • Portainer-2.1.1 (with security)
  • Jitsi Meet- 2.0.5765 (21-04-15)

I can access my Jitsi-Meet from the Internet with TOR.
This LDAP question is the last bug I have to resolve as I don’t use AD.

Michel-André

7

Thank you for your help!

By now I’m convinced I will have to wait for the moment I can get to work on a VPS with a Let’s Encrypt certificate, hoping that will make a solution possible.

Regards,
René