Stemming from https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/5005 where I'm proposing we revert the definition update that would allow for this. There is a possible security concern with the way we identify Enterprise Users, which follows the current definition with a recent update: https://gitlab.com/gitlab-com/www-gitlab-com/-/commit/1ee40a32b466be840b5d62316e6bdb4e63c85d48 ## Concern Marking a user an "Enterprise User" of a group means that the owner of the top-level group has various controls over the user account, such as disabling 2FA. ## Example scenario 1. A malicious actor creates a SCIM app that provisions GitLab user accounts with `@company.com` email addresses. 2. A user deletes/ignores the confirmation email. 3. Sometime later, `company.com` sets up SAML (and optionally SCIM) for their users. 4. The user confirms their account, and starts using GitLab. 5. The user account is now confirmed, has access and is using GitLab. 6. The user is an Enterprise User under the malicious actor's group. 7. Somehow the malicious actor gets access to the user's email, then on GitLab: 1. Disables 2FA for the user. 2. Triggers a password reset link. 3. Gets access to the account, and everything in `company.com`'s group as well. While this is an unlikely scenario, it's possible. In general, a user should not be an "Enterprise" user except when the paid group owns a domain and the user's primary email matches. ## Customer scenario We have 2 customers saying they "own" the same users: - A: https://gitlab.zendesk.com/agent/tickets/385027 - B: https://gitlab.zendesk.com/agent/tickets/376140 which also spawned https://gitlab.com/gitlab-com/support/internal-requests/-/issues/18596 The complication: Many of the users are provisioned by (and therefore Enterprise Users of) GroupB. However, their email address matches GroupA, who has a verified domain. According to the original definition, they should belong to GroupA, but they are marked as Enterprise Users of GroupB. ## Solution - [x] Communicate to group owners that we are going to replace [the old enterprise user definition](https://docs.gitlab.com/ee/user/enterprise_user/#provision-an-enterprise-user) to [the new definition](https://about.gitlab.com/handbook/support/workflows/gitlab-com_overview.html#enterprise-users). Meaning that [the existing enterpriuse users](https://docs.gitlab.com/ee/user/enterprise_user/#provision-an-enterprise-user) features to be only available according to the new definition. Group owners should add and verify all needed domains to their groups. That will allow the GitLab system to know which users are enterprise users as per the new definition. Groups with verified domains are prepared for the definition change in the GitLab system. It won't remove the ability to [manage their enterprise user accounts](https://docs.gitlab.com/ee/user/enterprise_user/#manage-enterprise-users-in-a-namespace) according to the new enterprise user definition. Groups that haven't verified domains will lose the ability to manage their enterprise user accounts till they verify their domains. - It was done, see https://gitlab.com/gitlab-com/marketing/marketing-operations/-/issues/7935. - [x] Ensure that [the rollout of `enterprise_users_automatic_claim`](https://gitlab.com/gitlab-org/gitlab/-/issues/421407) has been 100% completed. - [x] Make sure https://gitlab.com/groups/gitlab-org/-/epics/9675 that implements [the new enterprise user definition](https://about.gitlab.com/handbook/support/workflows/gitlab-com_overview.html#enterprise-users) is done. - [x] Ensure the updated definition is documented. See https://gitlab.com/gitlab-org/gitlab/-/issues/422097 - [x] https://gitlab.com/gitlab-org/gitlab/-/issues/429637+ - [x] https://gitlab.com/gitlab-org/gitlab/-/issues/391453+ - [x] https://gitlab.com/gitlab-org/gitlab/-/issues/429285+ - [x] https://gitlab.com/gitlab-org/gitlab/-/issues/412898+ - [x] **Replace the remaining old enterprise user definition in the GitLab system if any with the new definition**. Analyze `git grep 'provisioned_by_group'` command output to see where the logic should be changed to use the new Enterprise User definition. ## Other Enterprise User features that require follow up - [x] If a new attribute is added to identify enterprise users, it should be available via (users) API to admins at least. | Completed in gitlab#416657 - [x] Expose attributes in admin UI: gitlab!132938