Security concern: Enterprise User can be "owned" by the incorrect group

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: gitlab-com/www-gitlab-com@1ee40a32

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

• Communicate to group owners that we are going to replace the old enterprise user definition to the new definition. Meaning that the existing enterpriuse users 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 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.
• Ensure that the rollout of enterprise_users_automatic_claim has been 100% completed.
  • Make sure &9675 (closed) that implements the new enterprise user definition is done.
  • Ensure the updated definition is documented. See #422097 (closed)
• Replace the old enterprise user definition in the GitLab system with the new definition. (Implementation change: changing existing enterprise users administration features and other enterprise related checks in the code from using provisioned_by_group_id to enterprise_group_id). Analyze git grep 'provisioned_by_group' command output to see where the logic should be changed to use the new Enterprise User definition.
  • Update Enterprise Members badging to new definition.
  • Update Members filter for Enterprise users uses new definition.
  • Update the ability to disable 2FA to new definition.
  • See #429637 (closed)

Other Enterprise User features that require follow up

• If a new attribute is added to identify enterprise users, it should be available via (users) API to admins at least. | Completed in #416657 (closed)
• Expose attributes in admin UI: !132938 (merged)

Follow up issues:

1. Visibility of private emails to group owners: https://docs.gitlab.com/ee/api/members.html#limitations | Related issue #391453 (closed)
2. Update can_create_group and projects_limit via SAML: https://docs.gitlab.com/ee/user/group/saml_sso/index.html#supported-user-attributes | See #412898 (closed)
   • Note: I suggest we only update these for Enterprise Users, because what if they have SAML with multiple top-level groups?
3. Optional. Expose enterprise_group_id and enterprise_group_associated_at via members API for group owners when enterprise_group_id matches top-level group.
4. Maintenance. List of provisioned users API endpoint. We may want to deprecate this endpoint in favour of having the "enterprise user" designation included in the members API. | See #429285 (closed)