LDAP同期

LDAPをGitLabと連携するように設定した場合、GitLabは自動的にユーザーとグループを同期することができます。

LDAP同期は、LDAP IDが割り当てられている既存のGitLabユーザーのユーザーとグループ情報を更新します。LDAPを通して新しいGitLabユーザーを作成することはありません。

同期がいつ行われるかは変更できます。

ユーザー同期

GitLab 15.11で導入されたLDAPユーザーのプロファイル名の同期を防止します。

GitLabは1日に1回、LDAPに対してGitLabユーザーをチェックし更新するワーカーを実行します。

このプロセスは以下のアクセスチェックを実行します：

ユーザーが LDAP に存在することを確認します。
LDAPサーバーがActive Directoryの場合、ユーザーがアクティビティ（ブロック/無効状態ではない）であることを確認します。このチェックは、LDAP設定でactive_directory: true が設定されている場合にのみ実行されます。

Active Directory では、ユーザー・アカウント制御属性 (userAccountControl:1.2.840.113556.1.4.803) のビット 2 が設定されている場合、ユーザーは無効/ブロックされた状態としてマークされます。

詳細はLDAPのビットマスク検索を参照してください。

このプロセスでは、以下のユーザー情報も更新されます：

名前。同期のイシューのため、以下の場合、name は同期されません。 ユーザーによるプロフィール名の変更を防止が有効になっているか、sync_name がfalseに設定されている場合は同期されません。
メールアドレス
sync_ssh_keys が設定されている場合は SSH 公開キー。
Kerberos が有効な場合は Kerberos ID。

LDAPユーザーのプロファイル名の同期

デフォルトでは、GitLabはLDAPユーザーのプロファイル名フィールドを同期します。

この同期を防ぐには、sync_name をfalse に設定します。

Linux package (Omnibus)

/etc/gitlab/gitlab.rb を編集します：

gitlab_rails['ldap_servers'] = {
  'main' => {
    'sync_name' => false,
    }
}

ファイルを保存して GitLab を再設定してください：
```
sudo gitlab-ctl reconfigure
```

Helm chart (Kubernetes)

Helm の値をエクスポートします：

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml を編集します：

global:
  appConfig:
    ldap:
      servers:
        main:
          sync_name: false

ファイルを保存して、新しい値を適用します：
```
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
```

Docker

docker-compose.yml を編集します：

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
            'sync_name' => false,
            }
        }

ファイルを保存して GitLab を再起動します：
```
docker compose up -d
```

Self-compiled (source)

/home/git/gitlab/config/gitlab.yml を編集します：

production: &base
  ldap:
    servers:
      main:
        sync_name: false

ファイルを保存して GitLab を再起動します：

# For systems running systemd
sudo systemctl restart gitlab.target
   
# For systems running SysV init
sudo service gitlab restart

ブロックユーザー

ユーザーがブロックされるのは、以下のいずれかの場合です：

アクセスチェックが失敗し、そのユーザーがGitLabでldap_blocked 状態に設定されている場合。
そのユーザーがサインインしても LDAP サーバーが利用できません。

ユーザーがブロックされている場合、そのユーザーはサインインすることも、コードをプッシュまたはプルすることもできません。

ブロックされたユーザーが LDAP でサインインしたときにブロックが解除されるのは、以下のすべてが真である場合です：

すべてのアクセス・チェック条件が真。
ユーザーのサインイン時に LDAP サーバーが利用可能であること。

LDAPユーザー同期が実行されているときにLDAPサーバーが利用できない場合、すべてのユーザーがブロックされます。

LDAPユーザー同期が実行されたときにLDAPサーバーが利用できないためにすべてのユーザーがブロックされた場合、その後のLDAPユーザー同期ではこれらのユーザーのブロックは自動的に解除されません。

LDAPユーザー同期スケジュールの調整

デフォルトでは、GitLabは1日1回、サーバー時間の午前1時30分にワーカーを実行し、LDAPに対してGitLabユーザーをチェックして更新します。

以下の設定値をcron形式で設定することで、LDAPユーザーの同期時間を手動で設定することができます。必要であれば、crontabジェネレータを使うこともできます。以下の例では、LDAPユーザー同期を12時間に一度、毎正時に実行するように設定しています。

Linux package (Omnibus)

/etc/gitlab/gitlab.rb を編集します：

gitlab_rails['ldap_sync_worker_cron'] = "0 */12 * * *"

ファイルを保存して GitLab を再設定してください：
```
sudo gitlab-ctl reconfigure
```

Helm chart (Kubernetes)

Helm の値をエクスポートします：

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml を編集します：

global:
  appConfig:
    cron_jobs:
      ldap_sync_worker:
        cron: "0 */12 * * *"

ファイルを保存して、新しい値を適用します：
```
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
```

Docker

docker-compose.yml を編集します：

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_sync_worker_cron'] = "0 */12 * * *"

ファイルを保存して GitLab を再起動します：
```
docker compose up -d
```

Self-compiled (source)

/home/git/gitlab/config/gitlab.yml を編集します：

production: &base
  ee_cron_jobs:
    ldap_sync_worker:
      cron: "0 */12 * * *"

ファイルを保存して GitLab を再起動します：

# For systems running systemd
sudo systemctl restart gitlab.target
   
# For systems running SysV init
sudo service gitlab restart

グループの同期

LDAP がmemberof プロパティをサポートしている場合、ユーザーが初めてサインインした時に GitLab はそのユーザーがメンバーであるべきグループの同期をトリガーします。そうすることで、グループやプロジェクトへのアクセスを許可するために毎時の同期を待つ必要がなくなります。

グループ同期プロセスは毎正時に実行されます。group_base 、グループCNに基づくLDAP同期が機能するようにLDAP設定で設定する必要があります。これにより、LDAPグループメンバーに基づいてGitLabグループメンバーシップが自動的に更新されます。

group_base 設定は、’organization’や’organizational unit’などのベースとなるLDAPの’コンテナ’で、GitLabで利用可能なLDAPグループを含んでいる必要があります。たとえば、group_base はou=groups,dc=example,dc=com となります。設定ファイルでは、次のようになります。

Linux package (Omnibus)

/etc/gitlab/gitlab.rb を編集します：

gitlab_rails['ldap_servers'] = {
  'main' => {
    'group_base' => 'ou=groups,dc=example,dc=com',
    }
}

ファイルを保存して GitLab を再設定してください：
```
sudo gitlab-ctl reconfigure
```

Helm chart (Kubernetes)

Helm の値をエクスポートします：

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml を編集します：

global:
  appConfig:
    ldap:
      servers:
        main:
          group_base: ou=groups,dc=example,dc=com

ファイルを保存して、新しい値を適用します：
```
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
```

Docker

docker-compose.yml を編集します：

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
            'group_base' => 'ou=groups,dc=example,dc=com',
            }
        }

ファイルを保存して GitLab を再起動します：
```
docker compose up -d
```

Self-compiled (source)

/home/git/gitlab/config/gitlab.yml を編集します：

production: &base
  ldap:
    servers:
      main:
        group_base: ou=groups,dc=example,dc=com

ファイルを保存して GitLab を再起動します：

# For systems running systemd
sudo systemctl restart gitlab.target
   
# For systems running SysV init
sudo service gitlab restart

グループ同期を利用するためには、グループオーナーかメンテナーのロールを持つユーザーが一つ以上のLDAPグループリンクを作成する必要があります。

グループリンクの追加

CNとフィルタを使ったグループリンクの追加については、GitLabグループのドキュメントを参照してください。

管理者の同期

グループ同期の延長として、GitLabのグローバル管理者を自動的に管理することができます。admin_group にグループCNを指定すると、LDAPグループのメンバー全員に管理者権限が与えられます。設定は以下のようになります。

admin_group. admin_groupと一緒にgroup_base も指定しない限り、管理者は同期されません。admin_groupまた admin_group、完全な DN ではなく、admin_groupCN のみを指定 admin_groupします。さらに、LDAPユーザーがadmin ロールを持っていて、admin_group グループのメンバーでない場合、GitLabは同期時にそのadmin ロールを失効させます。

Linux package (Omnibus)

/etc/gitlab/gitlab.rb を編集します：

gitlab_rails['ldap_servers'] = {
  'main' => {
    'group_base' => 'ou=groups,dc=example,dc=com',
    'admin_group' => 'my_admin_group',
    }
}

ファイルを保存して GitLab を再設定してください：
```
sudo gitlab-ctl reconfigure
```

Helm chart (Kubernetes)

Helm の値をエクスポートします：

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml を編集します：

global:
  appConfig:
    ldap:
      servers:
        main:
          group_base: ou=groups,dc=example,dc=com
          admin_group: my_admin_group

ファイルを保存して、新しい値を適用します：
```
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
```

Docker

docker-compose.yml を編集します：

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
            'group_base' => 'ou=groups,dc=example,dc=com',
            'admin_group' => 'my_admin_group',
            }
        }

ファイルを保存して GitLab を再起動します：
```
docker compose up -d
```

Self-compiled (source)

/home/git/gitlab/config/gitlab.yml を編集します：

production: &base
  ldap:
    servers:
      main:
        group_base: ou=groups,dc=example,dc=com
        admin_group: my_admin_group

ファイルを保存して GitLab を再起動します：

# For systems running systemd
sudo systemctl restart gitlab.target
   
# For systems running SysV init
sudo service gitlab restart

グローバルグループメンバーシップのロック

GitLab 12.0から導入されました。

GitLab管理者は、グループのメンバーがLDAPと同期しているサブグループに新しいメンバーを招待できないようにすることができます。

グローバルグループメンバーシップロックは、LDAP同期が設定されているトップレベルグループのサブグループにのみ適用されます。LDAP同期が設定されているトップレベルグループのメンバーシップを変更できるユーザーはいません。

グローバル・グループ・メンバーシップ・ロックが有効になっている場合：

アクセスレベルを含め、グループのメンバーシップを管理できるのは管理者のみです。
ユーザーは、プロジェクトを他のグループと共有したり、グループで作成されたプロジェクトにメンバーを招待したりすることはできません。

グローバルグループメンバーシップのロックを有効にします：

LDAPを設定します。
左のサイドバーで、Search を選択するか、次のページに進んでください。
Admin Areaを選択します。
左サイドバーで、設定 > 一般を選択します。
表示とアクセス制御」セクションを展開します。
LDAP 同期に対してメンバーシップをロックする］チェックボックスが選択されていることを確認します。

LDAPグループ同期設定管理の変更

デフォルトでは、オーナーロールを持つグループメンバーはLDAPグループ同期設定を管理できます。

GitLab管理者はグループオーナーからこの権限を削除することができます：

LDAPを設定します。
左のサイドバーで、Search を選択するか、次のページに進んでください。
Admin Areaを選択します。
左サイドバーで、設定 > 一般を選択します。
表示とアクセス制御] を展開します。
Allow group owners to manage LDAP-related settings] チェックボックスがオンになっていないことを確認します。

Allow group owners to manage LDAP-relatedsettings] が無効になっている場合：

グループオーナーは、トップレベルグループとサブグループのLDAP同期設定を変更できません。
インスタンス管理者は、インスタンス上のすべてのグループのLDAPグループ同期設定を管理できます。

LDAPグループ同期スケジュールの調整

デフォルトでは、GitLabは毎正時にグループ同期プロセスを実行します。表示されている値はcron形式です。必要であれば、Crontab Generatorを使うことができます。

同期プロセスを頻繁に開始しすぎると、複数の同期が同時に実行される可能性があります。この問題は、主に多数のLDAPユーザーを持つインストールで発生します。先に進む前に、LDAPグループ同期ベンチマークのメトリクスをレビューして、インストールとの比較を確認してください。

以下の設定値を設定することで、LDAP グループ同期時間を手動で構成できます。以下の例では、グループ同期を2時間に1回、毎正時に実行するように設定しています。

Linux package (Omnibus)

/etc/gitlab/gitlab.rb を編集します：

gitlab_rails['ldap_group_sync_worker_cron'] = "0 */2 * * *"

ファイルを保存して GitLab を再設定してください：
```
sudo gitlab-ctl reconfigure
```

Helm chart (Kubernetes)

Helm の値をエクスポートします：

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml を編集します：

global:
  appConfig:
    cron_jobs:
      ldap_group_sync_worker:
        cron: "*/30 * * * *"

ファイルを保存して、新しい値を適用します：
```
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
```

Docker

docker-compose.yml を編集します：

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_group_sync_worker_cron'] = "0 */2 * * *"

ファイルを保存して GitLab を再起動します：
```
docker compose up -d
```

Self-compiled (source)

/home/git/gitlab/config/gitlab.yml を編集します：

production: &base
  ee_cron_jobs:
    ldap_group_sync_worker:
      cron: "*/30 * * * *"

ファイルを保存して GitLab を再起動します：

# For systems running systemd
sudo systemctl restart gitlab.target
   
# For systems running SysV init
sudo service gitlab restart

外部グループ

external_groups 設定を使用すると、これらのグループに属するすべてのユーザーを外部ユーザーとしてマークできます。グループメンバーシップは、LdapGroupSync のバックグラウンドタスクで定期的にチェックされます。

Linux package (Omnibus)

/etc/gitlab/gitlab.rb を編集します：

gitlab_rails['ldap_servers'] = {
  'main' => {
    'external_groups' => ['interns', 'contractors'],
    }
}

ファイルを保存して GitLab を再設定してください：
```
sudo gitlab-ctl reconfigure
```

Helm chart (Kubernetes)

Helm の値をエクスポートします：

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml を編集します：

global:
  appConfig:
    ldap:
      servers:
        main:
          external_groups: ['interns', 'contractors']

ファイルを保存して、新しい値を適用します：
```
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
```

Docker

docker-compose.yml を編集します：

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
            'external_groups' => ['interns', 'contractors'],
          }
        }

ファイルを保存して GitLab を再起動します：
```
docker compose up -d
```

Self-compiled (source)

/home/git/gitlab/config/gitlab.yml を編集します：

production: &base
  ldap:
    servers:
      main:
        external_groups: ['interns', 'contractors']

ファイルを保存して GitLab を再起動します：

# For systems running systemd
sudo systemctl restart gitlab.target
   
# For systems running SysV init
sudo service gitlab restart

グループ同期の技術的な詳細

このセクションでは、どのようなLDAPクエリが実行され、グループ同期にどのような動作が期待できるかを概説します。

LDAPグループメンバーシップが変更された場合、グループメンバーのアクセスはより高いレベルからダウングレードされます。例えば、あるグループのオーナーが、次のグループ同期で開発者ロールに変更された場合、そのユーザーのアクセスはそれに応じて調整されます。唯一の例外は、ユーザーがグループの最後のオーナーである場合です。グループには、管理業務を遂行するために少なくとも一人のオーナーが必要です。

サポートされるLDAPグループタイプ/属性

GitLabはメンバー属性を使用するLDAPグループをサポートしています：

member
submember
uniquemember
memberof
memberuid

これは、グループ同期が（少なくとも）以下のオブジェクトクラスを持つLDAPグループをサポートしていることを意味します：

groupOfNames
posixGroup
groupOfUniqueNames

その他のオブジェクトクラスは、メンバが前述の属性のいずれかとして定義されていれば動作するはずです。

Active Directory はネストされたグループをサポートしています。設定ファイルでactive_directory: true が設定されている場合、グループ同期はメンバーシップを再帰的に解決します。

ネストされたグループメンバーシップ

ネストされたグループのメンバーシップは、ネストされたグループが設定されたgroup_base にある場合にのみ解決されます。例えば、GitLab がcn=nested_group,ou=special_groups,dc=example,dc=com という DN のネストされたグループを見つけたとしても、設定されているgroup_base がou=groups,dc=example,dc=com であれば、cn=nested_group は無視されます。

クエリ

各 LDAP グループは、ベースgroup_base とフィルター(cn=<cn_from_group_link>) で最大 1 回クエリされます。
LDAPグループにmemberuid 属性が設定されている場合、GitLabは各ユーザーの完全なDNを取得するために、メンバーごとに別のLDAPクエリを実行します。これらのクエリはベースbase 、スコープ’base object’、そしてuser_filter が設定されているかどうかに応じたフィルターで実行されます。フィルターは(uid=<uid_from_group>) またはuser_filter の結合です。

ベンチマーク

グループ同期は可能な限りパフォーマンスが高くなるように設計されています。データはキャッシュされ、データベースクエリは最適化され、LDAPクエリは最小限に抑えられています。最後にベンチマークを実行したところ、以下のメトリクスが得られました：

20,000のLDAPユーザー、11,000のLDAPグループ、そしてそれぞれ10のLDAPグループリンクを持つ1,000のGitLabグループの場合：

初期同期（GitLabに既存のメンバーが割り当てられていない）に1.8時間かかりました。
その後の同期（メンバーシップのチェック、書き込みなし）にかかった時間：15分

これらのメトリクスはベースラインを提供するためのものであり、パフォーマンスはさまざまな要因によって変化します。このベンチマークは極端なものであり、ほとんどのインスタンスではこれほど多くのユーザーやグループを使用することはありません。ディスク速度、データベース・パフォーマンス、ネットワーク、LDAPサーバーの応答時間は、これらのメトリクスに影響を与えます。

トラブルシューティング

LDAPのトラブルシューティングについては、管理者ガイドを参照してください。

LDAP同期

ユーザー同期

LDAPユーザーのプロファイル名の同期

ブロックユーザー

LDAPユーザー同期スケジュールの調整

グループの同期

グループリンクの追加

管理者の同期

グローバルグループメンバーシップのロック

LDAPグループ同期設定管理の変更

LDAPグループ同期スケジュールの調整

外部グループ

グループ同期の技術的な詳細

サポートされるLDAPグループタイプ/属性

ネストされたグループメンバーシップ

クエリ

ベンチマーク

トラブルシューティング

Help & feedback

Docs

Product

Feature availability and product trials

Get Help