Block built-in Administrator user

How to Use GitLab Self-managed
1

Hi there,

After installing GitLab it creates a root user called Administrator (admin@example.com) which you log in with to create the first users (or that’s what I guessed I was supposed to do).

Now that the instance is bootstrapped with administrators, is it safe to block the built-in admin account? It makes me nervous having this admin account sitting there as additional attack surface.

Thanks in advance

2

I haven’t tried, but I don’t see why it wouldn’t be safe.

Maybe keep an administrator logged in using one browser and test that root can’t log in, but another user can using another browser.

If something starts failing (can’t see what it would be), you can unblock the root account from the administrator that is logged in).

2 Likes
3

Hi,

I would enable 2FA and generate a strong password for the root account which you’ll put into your company’s “password safe”.

While you can reset/enable accounts using the rails console on your server, there could be situations where you need immediate admin actions and no other logins available. Then you’ll have the documented way of using the root login with 2FA and the password safe.

Disabling the account also is an option, depending on your emergency workflows.

Cheers,
Michael

2 Likes
4

Thanks for the replies.

I’ve just found this paragraph in the documentation that encourages even deleting the built-in user: Licensing and subscription FAQ | GitLab

5

While you can delete it, make sure you have at least one local account with administrator privileges :slight_smile:

2 Likes
6

@dnsmichi as per @james-ct reply, the GitLab docs even encourage deleting the root account. Given our remaining admins are authenticated with SAML (okta) is it safe to do this? It seems it is possible to create admin users through the rails console, so in the worst case scenario existing admins can’t gain access to GitLab due to okta auth issues, a “local” admin could be created? Is this a correct assumption? Thanks

7

@pero Yes. My reply was with the requirement in mind that you’d need an account outside of any dependencies (e.g. when the network is down, SSO unreachable, DNS resolution broken and SSH won’t work for the rails console). Since this truly is a worst-case scenario where you have more urgent problems in your infrastructure, this should not be an argument. I think it is safe to delete the root user and rely on SAML/okta, and have a documented way for emergency cases (e.g. electing an admin, and disabling SSO).