doc/administration/raketasks/user_management.md
{{< details >}}
{{< /details >}}
GitLab provides Rake tasks for managing users. Administrators can also use the Admin area to manage users.
To add a user as a developer to all projects, run:
# omnibus-gitlab
sudo gitlab-rake gitlab:import:user_to_projects[[email protected]]
# installation from source
bundle exec rake gitlab:import:user_to_projects[[email protected]] RAILS_ENV=production
To add all users to all projects, run:
# omnibus-gitlab
sudo gitlab-rake gitlab:import:all_users_to_all_projects
# installation from source
bundle exec rake gitlab:import:all_users_to_all_projects RAILS_ENV=production
Administrators are added as maintainers and all other users are added as developers.
To add a user as a developer to all groups, run:
# omnibus-gitlab
sudo gitlab-rake gitlab:import:user_to_groups[[email protected]]
# installation from source
bundle exec rake gitlab:import:user_to_groups[[email protected]] RAILS_ENV=production
To add all users to all groups, run:
# omnibus-gitlab
sudo gitlab-rake gitlab:import:all_users_to_all_groups
# installation from source
bundle exec rake gitlab:import:all_users_to_all_groups RAILS_ENV=production
Administrators are added as owners so they can add additional users to the group.
project_limit:0 and can_create_group: falseTo update all users in given group to project_limit: 0 and can_create_group: false, run:
# omnibus-gitlab
sudo gitlab-rake gitlab:user_management:disable_project_and_group_creation\[:group_id\]
# installation from source
bundle exec rake gitlab:user_management:disable_project_and_group_creation\[:group_id\] RAILS_ENV=production
It updates all users in the given group, its subgroups and projects in this group namespace, with the noted limits.
Enable this setting to keep new users blocked until they have been cleared by the administrator.
Defaults to false:
block_auto_created_users: false
This task disables two-factor authentication (2FA) for all users that have it enabled. This can be
useful if the GitLab config/secrets.yml file has been lost and users are unable
to sign in, for example.
To disable two-factor authentication for all users, run:
# omnibus-gitlab
sudo gitlab-rake gitlab:two_factor:disable_for_all_users
# installation from source
bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_ENV=production
GitLab stores the secret data required for two-factor authentication (2FA) in an encrypted
database column. The encryption key for this data is known as otp_key_base, and is
stored in config/secrets.yml.
If that file is leaked, but the individual 2FA secrets have not, it's possible to re-encrypt those secrets with a new encryption key. This allows you to change the leaked key without forcing all users to change their 2FA details.
To rotate the two-factor authentication encryption key:
Look up the old key in the config/secrets.yml file, but make sure you're working
with the production section. The line you're interested in looks like this:
production:
otp_key_base: fffffffffffffffffffffffffffffffffffffffffffffff
Generate a new secret:
# omnibus-gitlab
sudo gitlab-rake secret
# installation from source
bundle exec rake secret RAILS_ENV=production
Stop the GitLab server, back up the existing secrets file, and update the database:
# omnibus-gitlab
sudo gitlab-ctl stop
sudo cp config/secrets.yml config/secrets.yml.bak
sudo gitlab-rake gitlab:two_factor:rotate_key:apply filename=backup.csv old_key=<old key> new_key=<new key>
# installation from source
sudo /etc/init.d/gitlab stop
cp config/secrets.yml config/secrets.yml.bak
bundle exec rake gitlab:two_factor:rotate_key:apply filename=backup.csv old_key=<old key> new_key=<new key> RAILS_ENV=production
The <old key> value can be read from config/secrets.yml (<new key> was
generated earlier). The encrypted values for the user 2FA secrets are
written to the specified filename. You can use this to rollback in case of
error.
Change config/secrets.yml to set otp_key_base to <new key> and restart. Again, make sure
you're operating in the production section.
# omnibus-gitlab
sudo gitlab-ctl start
# installation from source
sudo /etc/init.d/gitlab start
If there are any problems (perhaps using the wrong value for old_key), you can
restore your backup of config/secrets.yml and rollback the changes:
# omnibus-gitlab
sudo gitlab-ctl stop
sudo gitlab-rake gitlab:two_factor:rotate_key:rollback filename=backup.csv
sudo cp config/secrets.yml.bak config/secrets.yml
sudo gitlab-ctl start
# installation from source
sudo /etc/init.d/gitlab start
bundle exec rake gitlab:two_factor:rotate_key:rollback filename=backup.csv RAILS_ENV=production
cp config/secrets.yml.bak config/secrets.yml
sudo /etc/init.d/gitlab start
You can assign users in bulk to GitLab Duo using a CSV file with the names of the users.
The CSV file must have a header named username, followed by the usernames on each subsequent row.
username
user1
user2
user3
user4
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
To perform bulk user assignment for GitLab Duo Pro, you can use the following Rake task:
bundle exec rake duo_pro:bulk_user_assignment DUO_PRO_BULK_USER_FILE_PATH=path/to/your/file.csv
If you prefer to use square brackets in the file path, you can escape them or use double quotes:
bundle exec rake duo_pro:bulk_user_assignment\['path/to/your/file.csv'\]
# or
bundle exec rake "duo_pro:bulk_user_assignment[path/to/your/file.csv]"
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
This Rake task bulk assigns GitLab Duo Pro or Enterprise seats at the instance level to a list of users from a CSV file, based on the available purchased add-on.
To perform bulk user assignment for a GitLab Self-Managed instance:
bundle exec rake gitlab_subscriptions:duo:bulk_user_assignment DUO_BULK_USER_FILE_PATH=path/to/your/file.csv
If you prefer to use square brackets in the file path, you can escape them or use double quotes:
bundle exec rake gitlab_subscriptions:duo:bulk_user_assignment\['path/to/your/file.csv'\]
# or
bundle exec rake "gitlab_subscriptions:duo:bulk_user_assignment[path/to/your/file.csv]"
GitLab.com administrators can also use this Rake task to bulk assign GitLab Duo Pro or Enterprise seats for GitLab.com groups, based on the available purchased add-on for that group.
To perform bulk user assignment for a GitLab.com group:
bundle exec rake gitlab_subscriptions:duo:bulk_user_assignment DUO_BULK_USER_FILE_PATH=path/to/your/file.csv NAMESPACE_ID=<namespace_id>
If you prefer to use square brackets in the file path, you can escape them or use double quotes:
bundle exec rake gitlab_subscriptions:duo:bulk_user_assignment\['path/to/your/file.csv','<namespace_id>'\]
# or
bundle exec rake "gitlab_subscriptions:duo:bulk_user_assignment[path/to/your/file.csv,<namespace_id>]"
When using the Rake task for bulk user assignment, you might encounter the following errors:
User is not found: The specified user was not found. Please ensure the provided username matches an existing user.ERROR_NO_SEATS_AVAILABLE: No more seats are available for user assignment. Please see how to view assigned GitLab Duo users to check current seat assignments.ERROR_INVALID_USER_MEMBERSHIP: The user is not eligible for assignment due to being inactive, a bot, or a ghost. Please ensure the user is active and, if on GitLab.com, a member of the provided namespace.