Opened 12 months ago

Last modified 11 months ago

#32332 new defect

Set up LDAP authn for nc.tpn

Reported by: ln5 Owned by: nextcloud-admin@…
Priority: Medium Milestone:
Component: Internal Services/Service - nextcloud Version:
Severity: Normal Keywords:
Cc: anarcat, micah Actual Points:
Parent ID: #32519 Points:
Reviewer: Sponsor:


All LDAP users should have a NC account.

Can this be done using the "LDAP User and group backend" application?

Child Tickets

Change History (8)

comment:2 Changed 12 months ago by anarcat

we don't usually allow apps to connect directly to the LDAP server. what we do is we sync the user list into the app, and then the app works standalone. i don't exactly know how it works,

in gitlab, for example, users have different passwords (but the same username) than in LDAP, and that's on purpose: that way a compromise in gitlab doesn't affect gitlab.

i don't know how this could be done in LDAP. the module you refer to seems to do "traditionnal" LDAP sync, which requires the same user/password, as far as i can tell.

we might need to implement our own thing if we want to stick with user policy, possibly with

which seems kind of a pain in the bottom. ;)

more research definitely seem necessary here.

comment:3 Changed 12 months ago by gaba

From micah in irc:

<micah> so as I see it the options are:
<micah> 1. tor nc admins manage accounts through the entire lifecycle (creation, delete, etc.)
<micah> 2. some kind of LDAP integration, either through a connection, or a regular dump of the data
<micah> 3. sone kind of tokenized single sign-on system that will delegate authentication
<micah> 4. adding some 3rd party app to nextcloud that enables users to register themselves, and restricts that registration to only people who have emails

I think we should go with the option 1. and the tor nc admins manage accounts. We create accounts when people need it and remove accouns when people leave the organization.

comment:4 Changed 12 months ago by anarcat

Cc: anarcat added

i'm okay with going manual for now, because i don't want this to block. but it's going to be an issue with onboarding/offboarding. we already have a lot of tools and steps to go through to get people in and out, and this will matters worse, so I'd like us to find a solution in the long term.

i think i would prefer straight out LDAP integration to nothing at all, actually. but there are security implications there, and it's more work, so maybe if we're going to work on this at all, we would try to make a sync work instead?

comment:5 Changed 12 months ago by micah

Cc: micah added

comment:6 Changed 12 months ago by anarcat

Parent ID: #32267

we decided not to block on this, so unlink from parent.

the goal here is to make sure that accesses get created and revoked when we add and removed people from LDAP. but we're not comfortable enabling the current LDAP support system as it gives too much access to our LDAP server. we don't have time to evaluate all the implications of that and possible alternatives.

comment:7 Changed 11 months ago by anarcat

Parent ID: #32519

note this is a wider problem than just nextcloud, i opened #32519 to cover for the other cases.

comment:8 Changed 11 months ago by anarcat

i just had the idea that we could leverage the "basic http auth" system for authentication here.

the idea would be that ud-ldap would populate a "htaccess/htpasswd" kind of file and Nextcloud would tap into that. It seems there's support for configuring nextcloud to authenticate against "environment variables" which we could leverage for this purpose:

The advantage of this approach is that it could possibly work for *ALL* web apps. We would reuse the webPassword field in LDAP and reuse it everywhere... It could be used for GitLab as well, for example...

Otherwise I don't think it's worth treating NC as a special snowflake. If we don't take the above approach, we should just hook it up directly into LDAP and accept that it might have problems if LDAP is down.

Note: See TracTickets for help on using tickets.