Explicit admin control with LDAP Sync Group filtering

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

The problem identified here is a security issue related to explicit control of the admins permissions as filtered through LDAP/AD synchronization.

No user should be able to remove or add, admin privileges to a users account if they are explicitly set with LDAP/AD integration and the admin_group sync.

Problem to solve

Admin users setup through LDAP sync and "admin_group" filter are not explicitly controlled through that group filtering. Any admin within GitLab can grant or remove a users admin rights no matter what group filtering is defined as within LDAP or Active Directory.

Ideally any user in the ldap/ad filtered admin_group, should only be able to have their admin revoked via Active Directory or an X# layer approval method within the Gitlab GUI, preferably as a code merge approval method (Infrastructure as Code Methodology).

The current configuration means any user with admin permissions within the GitLab admin section could remove admin for all other admins within the GitLab UI and "take over" a GitLab instance (Hope you have backups!).

Intended users

Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/

User experience goal

This is a general security concern as it relates to regulations for myself but I am sure other company's, and relates to general best security practices of separation of duties. All personas should be worried about this but in the end the personas concerned the most are those listed above.

From an users perspective they should be able to put in a request for admin from within GitLab or a traditional support system, be added to the approved AD/LDAP group by anther appropriate admin (or themselves in some cases), and have admin when they login. They should then not be able to add or remove other admins within the system without another party being involved.

Proposal

  • Develop/Mod the code so that users in the admin_group are explicitly controlled when using the ldap sync and admin_group filter feature. Also consider this as an option for free instances to help better control and lock down the admin controls with an approval system if ldap sync is not used or have not paid for the feature set.

    - This locks control of Admin to only those users in the filtered admin_group

  • Add a manual LDAP sync button ("Sync LDAP Now") within the GitLab admin section that checks for any current LDAP sync runs and allows to quickly resync LDAP/AD if a users admin is granted or revoked. This would be outside the typical cron syncs.

    - This allows for quicker granting and removal of permissions and not having to wait for the next cron rotation.

  • Add a feature for a two layer plus approval method Merge Request style that follows an approval path for granting admin rights to users when LDAP/AD integration is not utilized or within the Core+ tier and self managed instances.

    - This stops admins from accidentally or maliciously granting/removing permissions.

Further details

We do not see any well rounded workarounds to this problem. We have tested that a user in the ldap/ad admin group, if they have their admin removed within gitlab through the user management interface does not receive their admin back immediately or after an ldap sync. This behavior is good in that if you need to quickly revoke and admins permissions it will keep them out but a nefarious party could potentially lock out all admins and do all sorts of damage. The only limiting factor would be to limit admin even tighter then we already have to reduce the attack surface (3 admins vs 7, 10, 20, etc.) but that also adds more risk to who is actually responsible for instance management.

Permissions and Security

  • Admin

Documentation

Availability & Testing

Available Tier

  • Free
  • Premium/Silver
  • Ultimate/Gold

What does success look like, and how can we measure that?

https://support.gitlab.com/hc/en-us/requests/186431

What is the type of buyer?

This feature should be available in all tears as it is an inherent security risk to having no checks and balances to the adding or removal of admins to instances.

Is this a cross-stage feature?

Links / references

https://docs.gitlab.com/ee/administration/auth/ldap/index.html#ldap-sync-configuration-settings

Edited by 🤖 GitLab Bot 🤖