LDAP Auth: Filtering for group membership + Bind user

[le-firehawk]

Hello,
I have recently been attempting to set up LDAP authentication for my Jitsi Meet instance with mild success.
I am running the stable branch for all docker images:

I am connecting to a FreeIPA instance (v4.11.1)

The configuration I have confirmed as working is the following (extracted from .env)
LDAP_URL=ldap://ipa01.my.domain LDAP_BASE=CN=accounts,DC=my,DC=domain LDAP_FILTER='(uid=%u)' LDAP_VERSION=3 LDAP_USE_TLS=1

In the above case, all other LDAP related values are commented out, and authentication works globally.
I however want to only allow login from users of group 'fs-jitsi'. I have attempted this by doing the following:

• Setting LDAP_BASE to CN=fs-jitsi,CN=accounts,DC=my,DC=domain
• Setting LDAP_FILTER to LDAP_FILTER='(&(memberOf=CN=fs-jitsi,CN=groups,CN=accounts,DC=my,DC=domain)(uid=%u))' <- This was mimicking the functional LDAP filter I use in Nextcloud

Perhaps I was missing something in the docs, or this feature is not supported via docker env?

Error Message:

I get a similar message when defining a bind user for LDAP lookup, which makes me think I may be using an incorrect schema value somewhere
LDAP_BINDDN=UID=jitsigroup,CN=users,CN=accounts,DC=my,DC=domain LDAP_BINDPW=password

This is my first time posting an issue, so please let me know if there's any additional info I need to provide.

[aaronkvanmeerten]

This looks more like an LDAP issue than a docker-jitsi-meet issue. Can you try also posting this question on the community forums? https://community.jitsi.org/ has a lot of helpful folks.

[damencho]

Try logging in with [email protected]. not just the username, but add and the correct domain.

[le-firehawk]

This looks more like an LDAP issue than a docker-jitsi-meet issue. Can you try also posting this question on the community forums? https://community.jitsi.org/ has a lot of helpful folks.

In cyrus-sasl docs, the value I'm looking for appears, however I cannot find a corresponding docker environment variable: https://github.com/winlibs/cyrus-sasl/blob/d933c030ce12ec0668469d79ab8378e347a1b3ba/saslauthd/LDAP_SASLAUTHD#L144

[le-firehawk]

Try logging in with [email protected]. not just the username, but add and the correct domain.

This is the result I got (I didn't actually use my.domain):

To clarify, if I run LDAP without the group membership check or bind user, it works as expected

[aaronkvanmeerten]

https://github.com/winlibs/cyrus-sasl/blob/d933c030ce12ec0668469d79ab8378e347a1b3ba/saslauthd/LDAP_SASLAUTHD#L144

Yes I concur: we would welcome a PR to address this. Here's the file you'd want to start with:

docker-jitsi-meet/prosody/rootfs/defaults/saslauthd.conf

Line 4 in 0298a30

In addition, you'll want to add any new environment variables you define to the docker-compose.yml to ensure it gets passed to the prosody container.

To test changes to the defaults/saslauthd.conf you can open a shell to a running prosody container, and then edit /defaults/saslauthd.conf , then run:
tpl /defaults/saslauthd.conf

[le-firehawk]

https://github.com/winlibs/cyrus-sasl/blob/d933c030ce12ec0668469d79ab8378e347a1b3ba/saslauthd/LDAP_SASLAUTHD#L144

Yes I concur: we would welcome a PR to address this. Here's the file you'd want to start with:

docker-jitsi-meet/prosody/rootfs/defaults/saslauthd.conf

Line 4 in 0298a30

In addition, you'll want to add any new environment variables you define to the docker-compose.yml to ensure it gets passed to the prosody container.

To test changes to the defaults/saslauthd.conf you can open a shell to a running prosody container, and then edit /defaults/saslauthd.conf , then run: tpl /defaults/saslauthd.conf

I'll see what I can do

[aaronkvanmeerten]

I'll see what I can do

No pressure, if you end up stuck just reach out and one of us will try to move it along too. We don't have an example LDAP deployment to work with so we'll need your help to know what success looks like :)

[le-firehawk]

Update:
I have translated the various LDAP-related parameters into the .../rootfs/defaults/saslauthd.conf file and verified saslauthd accepts those parameters.

When it comes to the values of those parameters, my success comes to an end. As mentioned initially, a blanket LDAP yes/no works with a basic configuration, however I could not get saslauthd to respect any filter, group DN, or group filter (Hundreds of trials). This is despite verifying the syntax of my queries with ldapsearch...

ldapsearch -WH ldap://ipa01.my.domain -b 'CN=accounts,DC=my,DC=domain' -D 'uid=jitsisystemuser,cn=users,cn=accounts,dc=my,dc=domain' '(&(uid=test-user)(memberOf=CN=fs-jitsi,CN=groups,CN=accounts,DC=my,DC=domain))' memberOf

Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <CN=accounts,DC=my,DC=domain> with scope subtree
# filter: (&(uid=test-user)(memberOf=CN=fs-jitsi,CN=groups,CN=accounts,DC=my,DC=domain))
# requesting: memberOf 
#
<... output omitted ...>

memberOf: cn=fs-jitsi,cn=groups,cn=accounts,dc=my,dc=domain
memberOf: cn=fs-<...>

# search result
search: 2
result: 0 Success <-- 0 = Exit code

# numResponses: 2
# numEntries: 1

When applying in .env:

LDAP_BASE='CN=accounts,DC=my,DC=domain'
LDAP_BINDDN=uid=jitsisystemuser,cn=users,cn=accounts,dc=my,dc=domain
LDAP_BINDPW=password
LDAP_FILTER='(&(uid=%u)(memberOf=CN=fs-jitsi,CN=groups,CN=accounts,DC=my,DC=domain))'

Still, the same error is returned. Even with the new parameters:
LDAP_GROUP_DN=cn=fs-jitsi,dc=my,dc=domain

I think the next step is to reach out to saslauthd team and ask them to verify the above values, and hopefully offer insight into the correct definitions for basic LDAP and FreeIPA, the latter being much less frequently referenced

[aaronkvanmeerten]

Is there perhaps a debug mode in your ldap server or the saslauth module where you could see the incoming query format to determine whether your settings of configuration match your expectation?

[le-firehawk]

On jitsi-docker end, the saslauthd process is already launched in debug mode (See. prosody/rootfs/etc/services.d/10-saslauthd/run), and its output is entirely unhelpful. I may try to capture some logs on FreeIPA side as you suggested, but that's for tomorrow...

[le-firehawk]

Apologies for the delay in update, I've been caught up in other things.

[le-firehawk]

It seems cryus saslauthd does not want to play with any form of LDAP filter

Here is the filters I have tried:

LDAP_FILTER=(&(uid=%u)) # Works
#LDAP_FILTER=(&(uid=%u)(|(objectclass=inetOrgPerson))(|(memberof=cn=fs-jitsi,cn=groups,cn=accounts,dc=my,dc=domain))) # Unknown error
#LDAP_FILTER='(&(uid=%u)(memberOf=CN=fs-jitsi,CN=groups,CN=accounts,DC=my,DC=domain))' # Unknown error
#LDAP_FILTER='(&(memberOf=cn=fs-jitsi,cn=groups,cn=accounts,dc=my,dc=domain)(uid=%u))' # Unknown error

I also experimented with the additional options from my pull request, applying any one of them would stop authentication from working:

#LDAP_GROUP_ATTR=memberOf
#LDAP_GROUP_DN=CN=fs-jitsi,DC=my,DC=domain
#LDAP_GROUP_DN=cn=fs-jitsi,dc=my,dc=domain
#LDAP_GROUP_DN='dc=my,dc=domain'
#LDAP_GROUP_DN='cn=fs-jitsi,cn=groups,cn=accounts,dc=my,dc=domain'

#LDAP_GROUP_MATCH_METHOD=filter
#LDAP_GROUP_FILTER=(|(cn=fs-jitsi))
#,cn=groups,cn=accounts,dc=my,dc=domain

#LDAP_GROUP_SEARCH_BASE=CN=fs-jitsi,CN=accounts,CN=groups,DC=my,DC=domain

I will try to get a second opinion from my senpai on what I may be doing wrong

[duburcqa]

I'm also facing a similar issue. I'm not able to find a pattern that is recognised by cryus to take into account group filter.

PS: I finally found a way ! (Just a few minutes after posting my first message...). Here is my configuration:

ldap_servers: ldaps://<LDAP_SERVER_ADDRESS>:636
ldap_bind_dn: uid=<LDAP_BIND_USER>,cn=users,cn=accounts,dc=local,dc=<LDAP_REALM>
ldap_bind_pw: *******************
ldap_auth_method: bind
ldap_search_base: cn=accounts,dc=local,dc=tplusone,dc=io
ldap_group_search_base: cn=groups,cn=accounts,dc=local,dc=tplusone,dc=io
ldap_group_attr: memberOf
ldap_filter: (&(uid=%u)(!(nsAccountLock=true))(memberOf=cn=<LDAP_JITSI_GROUP>,cn=groups,cn=accounts,dc=local,dc=<LDAP_REALM>))

[le-firehawk]

@duburcqa Great work! Just for clarity, that snippet is of /etc/saslauthd.conf as seen by the container? Could you kindly try to recreate this configuration via the docker env variables I set in the pull request #1798? I will also do the same with mine

(To do this)

Add to prosody container

volumes:
       - ${VOLUMES_ROOT_PATH}/saslauthd.conf:/defaults/saslauthd.conf:ro

Define the following additional environment variables

environment:
       - LDAP_BASE
       - LDAP_BINDDN
       - LDAP_BINDPW
       - LDAP_FILTER
       - LDAP_GROUP_ATTR
       - LDAP_GROUP_DN
       - LDAP_GROUP_MATCH_METHOD
       - LDAP_GROUP_FILTER
       - LDAP_GROUP_SEARCH_BASE
       - LDAP_VERSION

Create ${VOLUMES_ROOT_PATH}/saslauthd.conf

See https://github.com/le-firehawk/docker-jitsi-meet/raw/master/prosody/rootfs/defaults/saslauthd.conf

[le-firehawk]

Unfortunately I could not get cyrus to work whenever the filter isn't simply (&(uid=%u)), or whenever a bind_dn is defined. Here is my config with filters that does not work:

ldap_servers: ldap://ipa01.local.my.domain:389
ldap_search_base: dc=local,dc=my,dc=domain
ldap_version: 3
ldap_auth_method: bind
ldap_filter: (&(uid=%u)(!(nsAccountLock=true))(memberOf=cn=fs-jitsi,cn=groups,cn=accounts,dc=local,dc=my,dc=domain))
ldap_group_attr: memberOf
ldap_group_search_base: cn=groups,cn=accounts,dc=local,dc=my,dc=domain
ldap_start_tls: yes

[duburcqa]

Hum, strange. Are you sure that you need (nsAccountLock=true)? This field is specific to FreeIPA LDAP.

[le-firehawk]

I am also running FreeIPA (v4.11.1). Regardless of that field, I have been tackling this group membership issue with a variety of suggested configurations. For context, omitting all group membership control (i.e. setting ldap_filter to (&(uid=%U)), and disabling bind user (anonymous bind) allow LDAP to work without issue.

[duburcqa]

Strange, apparently our configuration is pretty similar yet we are observing different behaviours... Are you sure you can check group membership using anonymous bind ? My knowledge about LDAP is pretty limited. Have you checked that it works using ldapsearch ?

[duburcqa]

After checking the documentation here, I'm not sure that you can expect the same result using anonymous bind versus classical bind.

Update: I did some trials on by side, I get the same behaviour as you if I disable 'bind' authentication mode. It works without group check but not with group check. So this is the key!

[le-firehawk]

You are correct that I get different results when I authenticate (see below). Authentication itself however is still giving me issues, I shall attack from that angle.

(With authentication)

ldapsearch -W -H ldap://ipa01.my.domain -D "uid=jitsisystemuser,cn=users,cn=accounts,dc=my,dc=domain" -b "cn=fs-jitsi,cn=groups,cn=accounts,dc=my,dc=domain"

# fs-jitsi, groups, accounts, my.domain
dn: cn=fs-jitsi,cn=groups,cn=accounts,dc=my,dc=domain
cn: fs-jitsi
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
ipaUniqueID: <someID>
memberOf: cn=main-users,cn=groups,cn=accounts,dc=my,dc=domain
member: uid=<user>,cn=users,cn=accounts,dc=my,dc=domain

[duburcqa]

Here is my config that working that is the closest to yours. I hope this helps !

ldap_servers: ldap://<LDAP_SERVER_ADDRESS>
ldap_bind_dn: uid=<LDAP_BIND_USER>,cn=users,cn=accounts,dc=local,dc=<LDAP_REALM>
ldap_bind_pw: *******************
ldap_auth_method: bind
ldap_search_base: cn=accounts,dc=local,dc=tplusone,dc=io
ldap_group_search_base: cn=groups,cn=accounts,dc=local,dc=<LDAP_REALM>
ldap_group_attr: memberOf
ldap_filter: (&(uid=%u)(!(nsAccountLock=true))(memberOf=cn=<LDAP_JITSI_GROUP>,cn=groups,cn=accounts,dc=local,dc=<LDAP_REALM>))
ldap_tls_check_peer: yes  # optional. It works in both cases.
ldap_start_tls: yes
ldap_version: 3

[le-firehawk]

Thanks for that

[le-firehawk]

Finally managed to break through the issue, it was indeed a problem with the credentials for the service account. Either password was too long, or mismatched. Filters above work as required. I will switch my focus to annotating my findings in the env.example. Thanks again!

[duburcqa]

Perfect ! Yes adding more details would be beneficial to many I think. Being able to apply group filter does not sound very uncommon. FYI regarding password length, personally I'm using 24 characters and it works just great.

[le-firehawk]

I was using 128, went to 64 :))

If you get a chance to check out my changes at https://github.com/jitsi/docker-jitsi-meet/pull/1798/files and provide any feedback there, that'd be great

[le-firehawk]

I am satisfied this has been resolved, the significant findings have been captured in the env.example as part of my pull request. @aaronkvanmeerten I'll close this issue now