Opened 2 weeks ago

Last modified 8 days 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: Points:
Reviewer: Sponsor:

Description

All LDAP users should have a NC account.

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

Child Tickets

Change History (6)

comment:2 Changed 2 weeks 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 https://docs.nextcloud.com/server/17/admin_manual/configuration_user/instruction_set_for_users.html

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

more research definitely seem necessary here.

comment:3 Changed 2 weeks 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 torproject.org emails
<micah> https://apps.nextcloud.com/apps/registration

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 days 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 days ago by micah

Cc: micah added

comment:6 Changed 8 days 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.

Note: See TracTickets for help on using tickets.