Lock memberships to LDAP sync

Description

As a company, we have our own access control (integrated with LDAP) to assign permissions. Gitlab allows us to sync these permissions to Gitlab roles using LDAP synchronizations.

There currently seems no secure way to prevent overriding these synced permissions, namely masters and owners can still add (or override) members. The lock membership feature is not useful because it can be turned off.

This makes our business' access control less authoritative than we need it to, to stay compliant (for example, with SOX).

We'd like it to be possible to make the LDAP synchronizations fully authoritative for group and project membership. The only way to override membership synced by LDAP synchronizations should be by means of administrator intervention.

Proposal

An option in Gitlab that will lock down membership to a group and its projects to LDAP synchronizations only.

Add this option to the "Visibility and access controls" section of the "General" area of the admin settings panel:

• Rename "LDAP group settings" to "LDAP settings"

• Add "Lock memberships to LDAP synchronizations" as a toggle-able checkbox. This should default to false.

• Like the existing Allow group owners to manage LDAP-related group settings, both LDAP options should only be displayed if LDAP is configured.

• When this lock is enabled, only an Administrator may be able to: 1) Add/Remove members 2) Change the access level of existing members.

• Only an administrator may be able to enable/disable the lock.

• When this lock is enabled or disabled, log an audit event.

When this lock is enabled, we should remove all existing users added to projects/groups outside of LDAP. We should inform the admin enabling the lock that this will take place.

For groups without LDAP group sync enabled:

• Group Owners should not be able to add members manually to these groups. Instead, they should see an error.
• Instance administrators should be able to add members manually with the LDAP lock enabled.

Links / references

Customers

https://gitlab.my.salesforce.com/00161000006fkPe
https://gitlab.my.salesforce.com/00161000006fjFi
https://gitlab.my.salesforce.com/0016100000fdr2y https://gitlab.my.salesforce.com/0016100001HGPYw

added customer label

Customer Ticket: https://gitlab.zendesk.com/agent/tickets/86347 (internal only)

Customer in sfdc: https://gitlab.my.salesforce.com/0016100000fdr2y

/cc @xyzzy this impacts us in the same way described in OP. for this feature request.

@jramsay can you please comment regarding this proposal? Two very large customers are impacted by this. /cc @xyzzy

Thanks for the feedback @tdevelioglu and @LongLiveCHIEF, this is a nice improvement. It should be relatively straightforward since we've got most of the pieces of the puzzle already.

We don't have capacity in the next release, but I have added this to the %"Next 2-3 months" milestone so that it will be addressed soon.

added backend label

It may be a bug, but I'm currently experiencing this now. I recently added LDAP synchronisation to an existing group, and it removed all of the non-LDAP members, and I no longer even have the ability to add new group members. I have to add them explicitly to each project.

@LongLiveCHIEF Are you still experiencing this? If so can you open a support ticket?

@jramsay Is the milestone still accurate for this issue?

@jeremy_ could you please take a look at this issue?

added priority3 severity3 and removed ~1672339 labels

@jeremy_ can you please comment on this issue?

Thanks for the patience here. Let me restate the issue and echo the solution - if LDAP group sync is active, disallow overriding these permission settings from the sync and disallow adding or removing members. This would be an admin-level setting.

The milestone feels fairly accurate, as of now. We'll see if we can't get to this within a few months. @teemo, let me know if you'd like to discuss.

assigned to @jeremy_

changed the description

https://gitlab.zendesk.com/agent/tickets/100208 (for internal use)

added CS Top 10 (2018CQ3) label

@jeremy_ This was marked Next 2-3 releases 8 months ago, and identified by CS as a top 10 issue. Can you reassess the schedule?

added Manage [DEPRECATED] devopsmanage labels and removed 1 deleted label

added [deprecated] Accepting merge requests label

removed [deprecated] Accepting merge requests label

@jeremy Can we get an updated milestone on this?

changed milestone to %12.0

added priority1 label and removed priority3 label

Thanks, all. We'll make this a top priority for %12.0.

added customer+ label

changed milestone to %11.11

added UX label

This is very important to https://gitlab.my.salesforce.com/0016100001HGPYw

changed the description

It's unclear what

only an Administrator may be able to: 1) Add/Remove members 2) Change the access level of existing members.

means. Is that the overall Gitlab installation Administrator or the project owner?

My use case is that we still want the project owners to retain the choice and ability to add new LDAP groups but not individual members. We have tens of thousands of repos, so turning this on/off on a per-repo basis is not feasible. We need to turn it on/off on a GitLab server-wide basis.

As part of this discussion one should consider local users that are part of a group. If one needs to disable per-project access to "invited" users (ie locally specified users instead of users who receive access via an LDAP-synced group) one also needs to consider the same for groups.

There is another issue raised that seems to be in direct opposition to this one. https://gitlab.com/gitlab-org/gitlab-ee/issues/1793 They are requesting the LDAP controls be overridden by adding members even when LDAP groups are being utilized. If that occurs the audit-ability will be severally weakened.I know my organization needs to have the access controlled solely by LDAP groups so that individual access cannot be granted even at the project level. There are legal and security compliance for us to maintain. If people want the ability to override LDAP only access then please have it as a setting administrators can manage.

This case seems to be covered by the global setting we have - 'Allow group owners to manage LDAP-related settings'. If unchecked, only global admins can manage LDAP group links, etc.

We have this unselected but owners can still override LDAP by adding individuals at the project level. This is our greatest concern in this regard.

There is another setting at the group level: 'Prevent adding new members to project membership within this group'. But I assume this is able to be controlled by a Group Owner so it probably still has some concern.

At one point in the past we discussed that perhaps the solution in some of these cases is that the org should decide to restrict group owners to global administrators. But maybe we can also consider that when this 'Allow group owners to manage LDAP-related settings' is unchecked that any group setting regarding members if not changeable by group owners.

@jeremy What do you think?

mentioned in issue #1793

added groupauthentication and authorization [DEPRECATED] label

added Deliverable label

Would appreciate any input on how I'm thinking about this:

The problem: we want to create an environment where an instance can use LDAP as their single source of truth for authorization. We also want to allow for some flexibility, however. Some instances may need to allow outside vendors or contractors access into their instance without adding them to LDAP.

The proposal:

1. This issue would add an admin-panel level setting that can only be toggled by GitLab administrators. When checked, only admins would be able to manually add users to groups OR projects outside of the LDAP sync.

   • We should also add this as an audit event.

2. To allow for some flexibility, we need a setting to optionally extend manual member management to group Owners. I agree that it makes sense to simply add this behavior to "allow group Owners to manage LDAP-related settings" as @dblessing described.

   • What happens when this is unchecked? Members of groups (and their subgroups/projects) are not manually editable by Owners.
   • What happens when this is checked? A configuration option is exposed in group LDAP settings that reads "Lock membership of this group to LDAP". This should default to true.

When the LDAP lock is disabled, I suggest we notify the user making the change that they'll be able to add members to the group and subgroups/projects. We should leave the group's membership unchanged.

When the LDAP lock is re-enabled, I suggest we err on the side of caution and remove all members who have been manually added. We should warn the user making the settings change that some users who are outside of LDAP may lose access.

With this approach, someone like @stephen.m.carlson can just turn on the admin-level setting to lock memberships to LDAP. If "allow group owners to manage LDAP-related settings" is unchecked, managing this stays at the admin level and can't be worked around.

If you're an organization that uses LDAP but is concerned about the extra burden on GitLab administrators, you can consider enabling "allow group owners to manage LDAP-related settings" and promote other users to Owner level for select groups.

added estimationneeded label

assigned to @pshutsin

assigned to @jamedjo

unassigned @pshutsin

added direction label

changed the description

changed title from Lock group/project membership to LDAP synchronizations only to Lock memberships to LDAP sync

changed the description

removed UX label

One thing we've run into on our 11.2.3 instance is that, currently, LDAP-managed groups can't delegate/invite permissions to other GitLab groups, even if that group is also LDAP-synced. We'd like to be able to set up a membership-only (no projects) LDAP group, and invite it to have Maintainer privileges on an individual projects basis within an LDAP-synced GitLab group.

I know these member-only groups/teams are coming soon without this workaround, but can that be considered for the rollout here? We want to maintain LDAP-controlled access to specific projects, but the additional flexibility of adding project-level permissions granting/sharing to other LDAP-synced groups would be ideal.

Additionally, once a group is synced to LDAP, it technically no longer needs an Owner (since group membership is no longer managed within GitLab). And our Security Engineering team doesn't actually want to let any of the group users to be Owners, as they could then remove the LDAP synchronization.

As the GitLab admin for my organization I'm now the Owner of a group I created and synced to LDAP, but this means I'm getting emails for all the projects & MRs in that group. And I can't remove myself as Owner because GitLab doesn't seem to allow the only Owner to leave. Is there a way to remove my ownership? As a temporary workaround, would it be possible to unsubscribe from all member email notifications for the group?

And our Security Engineering team doesn't actually want to let any of the group users to be Owners, as they could then remove the LDAP synchronization.

Makes sense. After this improvement is implemented in %12.0, a group Owner won't be able to removed the LDAP sync until you selectively allow it in https://gitlab.com/gitlab-org/gitlab-ee/issues/1793.

As a temporary workaround, would it be possible to unsubscribe from all member email notifications for the group?

Is it possible to set your notifications for the group to Disabled as described in https://docs.gitlab.com/ee/workflow/notifications.html?

@jeremy that works for the notifications. I'd prefer not to actually be a member of a group just because I administratively created it. But I might possibly end up being able to leave the group after I can set up an Owner LDAP group and disallow them from breaking the LDAP sync connection.

changed milestone to %12.0

removed groupauthentication and authorization [DEPRECATED] label

added groupauthentication and authorization [DEPRECATED] label

Premium customer with 2600 seats have requested this as high priority: https://gitlab.my.salesforce.com/0016100000fdr2y

How is this going? I'm not sure if my comments above are being addressed since they were never acknowledged.

Is this feature only going to be in the 12.x releases?

changed weight to 5

added estimationcompleted label and removed estimationneeded label

unassigned @jamedjo

@brad.beyenhof I am chatting with the PM today to get an update. We will let you know this afternoon how it's going.

added planning priority label

I also ran into another problem:

1. a group of projects has an LDAP group granted Developer privileges
2. a workaround "team" group of people is created, also with LDAP sync (all members are a subset of the Developers group from above)
3. a project is created in the group from 1)
4. the project from 3) is shared to the team group in 2), in an attempt to let that team be Maintainers
5. the team group doesn't actually get maintainer rights on the project. I know the "share with group says "Max access level," but it's not at all clear how it should work or why (and it definitely didn't work how I expected).

Note that I don't want the team members to be maintainers of the whole group namespace, just on projects they own/maintain within the group. And it's all still LDAP-controlled, though not all in the same namespace.

mentioned in issue #9683

@jeremy Could you please comment if the milestone 12.0 is accurate?