Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LDAP Auth: Filtering for group membership + Bind user #1797

Closed
le-firehawk opened this issue May 1, 2024 · 26 comments
Closed

LDAP Auth: Filtering for group membership + Bind user #1797

le-firehawk opened this issue May 1, 2024 · 26 comments

Comments

@le-firehawk
Copy link

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:
image

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:
image

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
Copy link
Member

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
Copy link
Member

damencho commented May 1, 2024

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

@le-firehawk
Copy link
Author

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
Copy link
Author

le-firehawk commented May 1, 2024

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):
image

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

@aaronkvanmeerten
Copy link
Member

aaronkvanmeerten commented May 1, 2024

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:

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
Copy link
Author

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:

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
Copy link
Member

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
Copy link
Author

le-firehawk commented May 3, 2024

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
Copy link
Member

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
Copy link
Author

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
Copy link
Author

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

@le-firehawk
Copy link
Author

le-firehawk commented May 24, 2024

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
Copy link

duburcqa commented Jun 1, 2024

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
Copy link
Author

le-firehawk commented Jun 2, 2024

@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
Copy link
Author

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
Copy link

duburcqa commented Jun 4, 2024

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

@le-firehawk
Copy link
Author

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
Copy link

duburcqa commented Jun 4, 2024

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
Copy link

duburcqa commented Jun 4, 2024

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
Copy link
Author

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
Copy link

duburcqa commented Jun 4, 2024

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
Copy link
Author

Thanks for that

@le-firehawk
Copy link
Author

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
Copy link

duburcqa commented Jun 4, 2024

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
Copy link
Author

le-firehawk commented Jun 4, 2024

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants