Docker-jitsi-meet: Unable to Use LDAP Auth (No Login Window)

Created on 1 Apr 2020  路  13Comments  路  Source: jitsi/docker-jitsi-meet

Good Nighttime,
I'm using the current docker-jitsi-meet image behind an Apache 2.6 reverse proxy that does the SSL handling. The LDAP Daemon is listening only the the local host.

My docker-compose is the following:

networks:
  meet.jitsi: {}
services:
  jicofo:
    depends_on:
    - prosody
    environment:
      ENABLE_AUTH: '1'
      JIBRI_BREWERY_MUC: jibribrewery
      JIBRI_PENDING_TIMEOUT: '90'
      JICOFO_AUTH_PASSWORD: passw0rd
      JICOFO_AUTH_USER: focus
      JICOFO_COMPONENT_SECRET: s3cr37
      JICOFO_RESERVATION_REST_BASE_URL: null
      JIGASI_BREWERY_MUC: jigasibrewery
      JIGASI_SIP_URI: null
      JVB_BREWERY_MUC: jvbbrewery
      TZ: Europe/Berlin
      XMPP_AUTH_DOMAIN: auth.meet.jitsi
      XMPP_DOMAIN: xmpp.jitsi
      XMPP_INTERNAL_MUC_DOMAIN: internal-muc.meet.jitsi
      XMPP_SERVER: xmpp.jitsi
    image: jitsi/jicofo
    networks:
      meet.jitsi: null
    volumes:
    - /etc/jitsi/jicofo:/config:rw
  jvb:
    depends_on:
    - prosody
    environment:
      DOCKER_HOST_ADDRESS: 136.243.230.177
      JVB_AUTH_PASSWORD: passw0rd
      JVB_AUTH_USER: jvb
      JVB_BREWERY_MUC: jvbbrewery
      JVB_ENABLE_APIS: null
      JVB_PORT: '10000'
      JVB_STUN_SERVERS: meet-jit-si-turnrelay.jitsi.net:443
      JVB_TCP_HARVESTER_DISABLED: "true"
      JVB_TCP_PORT: '4443'
      TZ: Europe/Berlin
      XMPP_AUTH_DOMAIN: auth.meet.jitsi
      XMPP_INTERNAL_MUC_DOMAIN: internal-muc.meet.jitsi
      XMPP_SERVER: xmpp.jitsi
    image: jitsi/jvb
    networks:
      meet.jitsi: null
    ports:
    - 10000:10000/udp
    - 4443:4443/tcp
    volumes:
    - /etc/jitsi/jvb:/config:rw
  prosody:
    environment:
      AUTH_TYPE: ldap
      ENABLE_AUTH: '1'
      ENABLE_GUESTS: '0'
      GLOBAL_CONFIG: null
      GLOBAL_MODULES: null
      JIBRI_RECORDER_PASSWORD: passw0rd
      JIBRI_RECORDER_USER: recorder
      JIBRI_XMPP_PASSWORD: passw0rd
      JIBRI_XMPP_USER: jibri
      JICOFO_AUTH_PASSWORD: passw0rd
      JICOFO_AUTH_USER: focus
      JICOFO_COMPONENT_SECRET: s3cr37
      JIGASI_XMPP_PASSWORD: passw0rd
      JIGASI_XMPP_USER: jigasi
      JVB_AUTH_PASSWORD: passw0rd
      JVB_AUTH_USER: jvb
      JWT_ACCEPTED_AUDIENCES: null
      JWT_ACCEPTED_ISSUERS: null
      JWT_ALLOW_EMPTY: null
      JWT_APP_ID: null
      JWT_APP_SECRET: null
      JWT_ASAP_KEYSERVER: null
      JWT_AUTH_TYPE: null
      JWT_TOKEN_AUTH_MODULE: null
      LDAP_AUTH_METHOD: bind
      LDAP_BASE: DC=network,DC=internal
      LDAP_BINDDN: cn=binddn,dc=network,dc=internal
      LDAP_BINDPW: [bindpw goes here]
      LDAP_FILTER: (objectclass=posixAccount)
      LDAP_START_TLS: null
      LDAP_TLS_CACERT_DIR: null
      LDAP_TLS_CACERT_FILE: null
      LDAP_TLS_CHECK_PEER: null
      LDAP_TLS_CIPHERS: null
      LDAP_URL: ldap://localhost/
      LDAP_USE_TLS: '0'
      LDAP_VERSION: null
      LOG_LEVEL: null
      TZ: Europe/Berlin
      XMPP_AUTH_DOMAIN: auth.meet.jitsi
      XMPP_DOMAIN: xmpp.jitsi
      XMPP_GUEST_DOMAIN: guest.meet.jitsi
      XMPP_INTERNAL_MUC_DOMAIN: internal-muc.meet.jitsi
      XMPP_INTERNAL_MUC_MODULES: ''
      XMPP_MODULES: ''
      XMPP_MUC_DOMAIN: muc.meet.jitsi
      XMPP_MUC_MODULES: ''
      XMPP_RECORDER_DOMAIN: recorder.meet.jitsi
    expose:
    - '5222'
    - '5347'
    - '5280'
    image: jitsi/prosody
    networks:
      meet.jitsi:
        aliases:
        - xmpp.jitsi
    volumes:
    - /etc/jitsi/prosody:/config:rw
  web:
    environment:
      DISABLE_HTTPS: '1'
      ENABLE_AUTH: '1'
      ENABLE_GUESTS: '0'
      ENABLE_HTTP_REDIRECT: '0'
      ENABLE_LETSENCRYPT: '0'
      ENABLE_RECORDING: null
      ENABLE_TRANSCRIPTIONS: null
      ETHERPAD_URL_BASE: null
      JIBRI_BREWERY_MUC: jibribrewery
      JIBRI_PENDING_TIMEOUT: '90'
      JIBRI_RECORDER_PASSWORD: passw0rd
      JIBRI_RECORDER_USER: recorder
      JIBRI_XMPP_PASSWORD: passw0rd
      JIBRI_XMPP_USER: jibri
      JICOFO_AUTH_USER: focus
      LETSENCRYPT_DOMAIN: null
      LETSENCRYPT_EMAIL: null
      PUBLIC_URL: https://jitsi
      TZ: Europe/Berlin
      XMPP_AUTH_DOMAIN: auth.meet.jitsi
      XMPP_BOSH_URL_BASE: http://xmpp.meet.jitsi:5280
      XMPP_DOMAIN: xmpp.jitsi
      XMPP_GUEST_DOMAIN: guest.meet.jitsi
      XMPP_MUC_DOMAIN: muc.meet.jitsi
      XMPP_RECORDER_DOMAIN: recorder.meet.jitsi
    image: jitsi/web
    networks:
      meet.jitsi:
        aliases:
        - xmpp.jitsi
    ports:
    - 5080:80/tcp
    - 5443:443/tcp
    volumes:
    - /etc/jitsi/web:/config:rw
    - /etc/jitsi/web/letsencrypt:/etc/letsencrypt:rw
    - /etc/jitsi/transcripts:/usr/share/jitsi-meet/transcripts:rw
version: '3.0'

My Apache 2.6 reverse proxy is configured the following

<VirtualHost jitsi:443>
    [SSL-Settings]
    ProxyVia On
    ProxyRequests Off
    ProxyPreserveHost on
    <Location />
        ProxyPass http://localhost:5080/
        ProxyPassReverse http://localhost:5080/
    </Location>
    <Proxy *>
        Options FollowSymLinks MultiViews
        Require all granted
    </Proxy>
</VirtualHost>

Most helpful comment

That is not the file that is being used. Check on /etc on the container itself.

All 13 comments

The issue is the saslauth-configuration generated by docker compose

{{ if eq (.Env.AUTH_TYPE | default "internal") "ldap" }}
ldap_servers: {{ .Env.LDAP_URL }}
ldap_search_base: {{ .Env.LDAP_BASE }}
{{ if .Env.LDAP_BINDDN | default "" }}
ldap_bind_dn: {{ .Env.LDAP_BINDDN }}
ldap_bind_pw: {{ .Env.LDAP_BINDPW }}
{{ end }}
ldap_filter: {{ .Env.LDAP_FILTER | default "uid=%u" }}
ldap_version: {{ .Env.LDAP_VERSION | default "3" }}
ldap_auth_method: {{ .Env.LDAP_AUTH_METHOD | default "bind" }}
  {{ if .Env.LDAP_USE_TLS | default "0" | toBool }}
ldap_tls_key: /config/certs/{{ .Env.XMPP_DOMAIN }}.key
ldap_tls_cert: /config/certs/{{ .Env.XMPP_DOMAIN }}.crt
    {{ if .Env.LDAP_TLS_CHECK_PEER | default "0" | toBool }}
ldap_tls_check_peer: yes
ldap_tls_cacert_file: {{ .Env.LDAP_TLS_CACERT_FILE | default "/etc/ssl/certs/ca-certificates.crt" }}
ldap_tls_cacert_dir: {{ .Env.LDAP_TLS_CACERT_DIR | default "/etc/ssl/certs" }}
    {{ end }}
    {{ if .Env.LDAP_TLS_CIPHERS }}
ldap_tls_ciphers: {{ .Env.LDAP_TLS_CIPHERS }}
    {{ end }}
  {{ end }}
{{ end }}
{{ if .Env.LDAP_START_TLS | default "0" | toBool }}
ldap_start_tls: yes
{{ end }}

The issue is the saslauth-configuration generated by docker compose

What exactly?

@saghul It looks like the saslauth config is completely invalid and is filled with the jinja template used for rendering the config out of the env.
I temporarily worked around this by writing the config by hand and mounting it to the container

The problem is here probably:

https://github.com/jitsi/docker-jitsi-meet/blob/768b6c4a50d75b143ca5006e63182f1eb924076c/prosody/rootfs/etc/cont-init.d/10-config#L3-L12

Its only running the previous condition, on this one the file already exists, so its not being processed by the tpl command ?

Edit... just noticed its two diferent paths.

Did you already have a default /etc/saslauthd.conf file? Sorry I have no LDAP setup I can test with here. if it ddoes have a default file, then we'd need to remove it at container build time.

I was able to fix it by stopping all of the services, removing the containers, cleaning out the config volumes, and starting it again. Because the config is persisted in the volumes it seems like you have to delete their contents if you want the environment varables to properly update the config.

I'm not sure if that is intentional or if that should be a bug report.

That is intentional and documented.

There is no saslauth running on the host itself, thus the /etc/saslauthd.conf is not existing.
The one within the container is - as written - not generated properly.

Not ssure I follow. What are its contents? Is it not being templated correctly?

This seems to be the problem I am suffering too. The saslauthd.conf does not get rendered and is output as a jinja template.

~/.jitsi-meet-cfg/prosody/saslauthd.conf

{{ if eq (.Env.AUTH_TYPE | default "internal") "ldap" }}
ldap_servers: {{ .Env.LDAP_URL }}
ldap_search_base: {{ .Env.LDAP_BASE }}
{{ if .Env.LDAP_BINDDN | default "" }}
ldap_bind_dn: {{ .Env.LDAP_BINDDN }}
ldap_bind_pw: {{ .Env.LDAP_BINDPW }}
{{ end }}
ldap_filter: {{ .Env.LDAP_FILTER | default "uid=%u" }}
ldap_version: {{ .Env.LDAP_VERSION | default "3" }}
ldap_auth_method: {{ .Env.LDAP_AUTH_METHOD | default "bind" }}
  {{ if .Env.LDAP_USE_TLS | default "0" | toBool }}
ldap_tls_key: /config/certs/{{ .Env.XMPP_DOMAIN }}.key
ldap_tls_cert: /config/certs/{{ .Env.XMPP_DOMAIN }}.crt
    {{ if .Env.LDAP_TLS_CHECK_PEER | default "0" | toBool }}
ldap_tls_check_peer: yes
ldap_tls_cacert_file: {{ .Env.LDAP_TLS_CACERT_FILE | default "/etc/ssl/certs/ca-certificates.crt" }}
ldap_tls_cacert_dir: {{ .Env.LDAP_TLS_CACERT_DIR | default "/etc/ssl/certs" }}
    {{ end }}
    {{ if .Env.LDAP_TLS_CIPHERS }}
ldap_tls_ciphers: {{ .Env.LDAP_TLS_CIPHERS }}
    {{ end }}
  {{ end }}
{{ end }}
{{ if .Env.LDAP_START_TLS | default "0" | toBool }}
ldap_start_tls: yes
{{ end }}

That is not the file that is being used. Check on /etc on the container itself.

That is not the file that is being used. Check on /etc on the container itself.

Interesting. So the mounted file in /config should be jinja? I have edited it and have successfully authenticated. I'll revert it and retry.

Thanks for the response.

I must have entered something incorrectly as I tore it all down and it rebuilt and worked.

Thank you.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ErrorInPersona picture ErrorInPersona  路  3Comments

0187773933 picture 0187773933  路  7Comments

CosmoMyzrailGorynych picture CosmoMyzrailGorynych  路  5Comments

TeGuy picture TeGuy  路  4Comments

gerroon picture gerroon  路  6Comments