2020-10-23 20:08:35 -04:00
---
2020-11-17 10:09:28 -05:00
stage: Manage
2022-01-26 22:14:06 -05:00
group: Authentication and Authorization
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-10-23 20:08:35 -04:00
---
2021-01-28 01:08:59 -05:00
# LDAP Rake tasks **(FREE SELF)**
2020-04-27 02:09:51 -04:00
The following are LDAP-related Rake tasks.
2015-12-22 16:09:35 -05:00
## Check
2021-04-25 20:09:41 -04:00
The LDAP check Rake task tests the `bind_dn` and `password` credentials
(if configured) and lists a sample of LDAP users. This task is also
2015-12-22 16:09:35 -05:00
executed as part of the `gitlab:check` task, but can run independently
using the command below.
**Omnibus Installation**
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
sudo gitlab-rake gitlab:ldap:check
```
**Source Installation**
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production
```
2021-04-25 20:09:41 -04:00
By default, the task returns a sample of 100 LDAP users. Change this
2015-12-22 16:09:35 -05:00
limit by passing a number to the check task:
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
rake gitlab:ldap:check[50]
```
2021-01-29 10:09:40 -05:00
## Run a group sync **(PREMIUM SELF)**
2019-07-26 11:36:48 -04:00
2021-05-11 20:10:27 -04:00
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14735) in GitLab 12.2.
2019-07-26 11:36:48 -04:00
2021-10-26 20:13:04 -04:00
The following task runs a [group sync ](../auth/ldap/ldap_synchronization.md#group-sync ) immediately.
This is valuable when you'd like to update all configured group memberships against LDAP without
2019-07-26 11:36:48 -04:00
waiting for the next scheduled group sync to be run.
2020-12-04 16:09:29 -05:00
NOTE:
2019-07-26 11:36:48 -04:00
If you'd like to change the frequency at which a group sync is performed,
2021-10-26 20:13:04 -04:00
[adjust the cron schedule ](../auth/ldap/ldap_synchronization.md#adjust-ldap-group-sync-schedule )
2019-07-26 11:36:48 -04:00
instead.
**Omnibus Installation**
2020-01-30 10:09:15 -05:00
```shell
2019-07-26 11:36:48 -04:00
sudo gitlab-rake gitlab:ldap:group_sync
```
**Source Installation**
2020-01-30 10:09:15 -05:00
```shell
2019-07-26 11:36:48 -04:00
bundle exec rake gitlab:ldap:group_sync
```
2015-12-22 16:09:35 -05:00
## Rename a provider
2021-04-25 20:09:41 -04:00
If you change the LDAP server ID in `gitlab.yml` or `gitlab.rb` you need
to update all user identities or users aren't able to sign in. Input the
old and new provider and this task updates all matching identities in the
2015-12-22 16:09:35 -05:00
database.
`old_provider` and `new_provider` are derived from the prefix `ldap` plus the
LDAP server ID from the configuration file. For example, in `gitlab.yml` or
`gitlab.rb` you may see LDAP configuration like this:
```yaml
main:
label: 'LDAP'
host: '_your_ldap_server'
port: 389
uid: 'sAMAccountName'
...
```
`main` is the LDAP server ID. Together, the unique provider is `ldapmain` .
2021-05-11 20:10:27 -04:00
WARNING:
If you input an incorrect new provider, users cannot sign in. If this happens,
run the task again with the incorrect provider as the `old_provider` and the
correct provider as the `new_provider` .
2015-12-22 16:09:35 -05:00
**Omnibus Installation**
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
sudo gitlab-rake gitlab:ldap:rename_provider[old_provider,new_provider]
```
**Source Installation**
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
bundle exec rake gitlab:ldap:rename_provider[old_provider,new_provider] RAILS_ENV=production
```
### Example
Consider beginning with the default server ID `main` (full provider `ldapmain` ).
If we change `main` to `mycompany` , the `new_provider` is `ldapmycompany` .
To rename all user identities run the following command:
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
sudo gitlab-rake gitlab:ldap:rename_provider[ldapmain,ldapmycompany]
```
Example output:
2020-01-23 01:08:32 -05:00
```plaintext
2015-12-22 16:09:35 -05:00
100 users with provider 'ldapmain' will be updated to 'ldapmycompany'.
If the new provider is incorrect, users will be unable to sign in.
Do you want to continue (yes/no)? yes
User identities were successfully updated
```
### Other options
2021-04-25 20:09:41 -04:00
If you do not specify an `old_provider` and `new_provider` the task prompts you
2015-12-22 16:09:35 -05:00
for them:
**Omnibus Installation**
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
sudo gitlab-rake gitlab:ldap:rename_provider
```
**Source Installation**
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
bundle exec rake gitlab:ldap:rename_provider RAILS_ENV=production
```
**Example output:**
2020-01-23 01:08:32 -05:00
```plaintext
2015-12-22 16:09:35 -05:00
What is the old provider? Ex. 'ldapmain': ldapmain
What is the new provider? Ex. 'ldapcustom': ldapmycompany
```
2021-04-25 20:09:41 -04:00
This task also accepts the `force` environment variable, which skips the
2015-12-22 16:09:35 -05:00
confirmation dialog:
2020-01-30 10:09:15 -05:00
```shell
2015-12-22 16:09:35 -05:00
sudo gitlab-rake gitlab:ldap:rename_provider[old_provider,new_provider] force=yes
```
2020-12-10 16:10:15 -05:00
## Secrets
2021-09-08 17:10:58 -04:00
GitLab can use [LDAP configuration secrets ](../auth/ldap/index.md#use-encrypted-credentials ) to read from an encrypted file.
The following Rake tasks are provided for updating the contents of the encrypted file.
2020-12-10 16:10:15 -05:00
### Show secret
Show the contents of the current LDAP secrets.
**Omnibus Installation**
```shell
sudo gitlab-rake gitlab:ldap:secret:show
```
**Source Installation**
```shell
bundle exec rake gitlab:ldap:secret:show RAILS_ENV=production
```
**Example output:**
```plaintext
main:
password: '123'
user_bn: 'gitlab-adm'
```
### Edit secret
Opens the secret contents in your editor, and writes the resulting content to the encrypted secret file when you exit.
**Omnibus Installation**
```shell
sudo gitlab-rake gitlab:ldap:secret:edit EDITOR=vim
```
**Source Installation**
```shell
bundle exec rake gitlab:ldap:secret:edit RAILS_ENV=production EDITOR=vim
```
### Write raw secret
Write new secret content by providing it on STDIN.
**Omnibus Installation**
```shell
echo -e "main:\n password: '123'" | sudo gitlab-rake gitlab:ldap:secret:write
```
**Source Installation**
```shell
echo -e "main:\n password: '123'" | bundle exec rake gitlab:ldap:secret:write RAILS_ENV=production
```
### Secrets examples
**Editor example**
The write task can be used in cases where the edit command does not work with your editor:
```shell
# Write the existing secret to a plaintext file
sudo gitlab-rake gitlab:ldap:secret:show > ldap.yaml
# Edit the ldap file in your editor
...
# Re-encrypt the file
cat ldap.yaml | sudo gitlab-rake gitlab:ldap:secret:write
# Remove the plaintext file
rm ldap.yaml
```
**KMS integration example**
It can also be used as a receiving application for content encrypted with a KMS:
```shell
gcloud kms decrypt --key my-key --keyring my-test-kms --plaintext-file=- --ciphertext-file=my-file --location=us-west1 | sudo gitlab-rake gitlab:ldap:secret:write
```
2021-01-29 13:09:17 -05:00
**Google Cloud secret integration example**
2020-12-10 16:10:15 -05:00
2021-01-29 13:09:17 -05:00
It can also be used as a receiving application for secrets out of Google Cloud:
2020-12-10 16:10:15 -05:00
```shell
gcloud secrets versions access latest --secret="my-test-secret" > $1 | sudo gitlab-rake gitlab:ldap:secret:write
```