Check LDAP external users at sign in

Overview

External users in GitLab have restricted permissions and must be explicitly added to a project/group for access - https://docs.gitlab.com/ee/user/permissions.html#external-users

The LDAP group sync option external_users offers the ability to specify a group that contains "external users". By default an ldap_group_sync_worker is run every hour. This will mark any already created users as external.

Problem

1. Alice adds Bob to the GitLab LDAP base - dc=example,dc=org
2. Alice also immediately adds Bob to the GitLab LDAP external_groups - cn=external,dc=example,dc=org
3. Bob signs into GitLab and is not an external users.
   1. Bob is able to access all internal projects
4. After 1 hour (or less) the ldap_group_sync_worker marks Bob as an external user

The problem is that the user (Bob) will have access to internal projects until he is marked as an external user via the sync.

Possible Solution

Check the users DN on login and compare it against the external_groups + group_base value

Links

• https://gitlab.zendesk.com/agent/tickets/76859

added SP3 customer labels

Thanks @MrChrisW This is really important!

Putting a higher support priority on it as it's actually a fairly severe issue IMO.

added SP1 and removed SP3 labels

@mydigitalself This is a support scheduling request. We'd like to get this issue prioritized.

@dblessing @DouweM will Sync at login (https://gitlab.com/gitlab-org/gitlab-ee/issues/906) not fix this, or does more work need to be done?

changed milestone to %9.4

@mydigitalself I think more work needs to be done, the sync on login only works if the LDAP provides a memberof field.

If it does and the external groups are present, these will be synced within a few seconds. That means that within a few seconds after the first login, he would still see the groups he's not supposed to see.

If the LDAP does not support memberof then he will have access to the internal projects until the sync is done.

@dblessing Would it make sense to mark users as external by default if external_groups are configured?

@reprazent Honestly that would cause lots of confusion among the users.. They'll start asking stuff like how come I can't see any projects that I'm supposed to be seeing.. Etc

@farahfa In 9.3 we will sync the groups at login (on supported LDAPs), so this would only be the first login, and the next refresh the projects should be there. We also show a message that groups are being synced when logging in telling they should refresh to see the updated memberships.

So I think external as a default if this option is enabled might be a simple solution to avoid leaking data.

I don't know however how many LDAPs provide the memberof field. Because if this is not supported, then it could take up to 1 hour before the user gets to see anything. Which would be very annoying, as you mentioned.

So I think external as a default if this option is enabled might be a simple solution to avoid leaking data.

@reprazent I agree.

I don't know however how many LDAPs provide the memberof field. Because if this is not supported, then it could take up to 1 hour before the user gets to see anything. Which would be very annoying, as you mentioned.

ActiveDirectory has memberOf, and on OpenLDAP it can be enabled: http://www.adimian.com/blog/2014/10/how-to-enable-memberof-using-openldap/

@dblessing Do you know what the most commonly used LDAP servers are, and whether they support memberOf or not?

In terms of customer's Microsoft Active Directory would by far be the most commonly used directory server.

We should be able to easily check if the user is in the external group(s) on sign in. The configuration specifies the group's CN. Grab that group from LDAP and see if the user is a member.

added Deliverable label

@reprazent @DouweM is it clear what the final proposed solution here is yet and can we update that in the description?

@dblessing Good point, we don't need to depend on memberOf since we already know both user and group.

@mydigitalself Yep, clear enough.

added customer+ label

changed milestone to %9.5

assigned to @mkozono

changed milestone to %10.0

mentioned in merge request !2720 (merged)

added In dev label

closed via merge request !2720 (merged)

mentioned in commit 3201a490

removed In dev label