一般的なLDAPの設定

GitLabはLDAPとインテグレーションし、ユーザー認証をサポートします。

このインテグレーションは、以下を含むほとんどのLDAP準拠のディレクトリサーバーで動作します：

  • Microsoft Active Directory
  • Appleオープンディレクトリ
  • LDAPを開く
  • 389 サーバー

GitLab Enterprise Editions(EE) では、グループメンバーシップの同期や複数のLDAPサーバーのサポートなど、インテグレーションが強化されています。

注：Microsoft Active Directory Trustはサポートされていません。

概要

LDAPはLightweight Directory Access Protocolの略で、インターネットプロトコル（(IP) ）ネットワーク上で分散ディレクトリ情報サービスにアクセスし、メンテンスするための標準アプリケーションプロトコルです。

セキュリティ

GitLabはLDAPユーザーを想定しています：

  • LDAPのmail、email、userPrincipalName 属性を変更することはできません。LDAPサーバー上でEメールの変更を許可されたLDAPユーザーは、GitLabサーバー上のあらゆるアカウントを乗っ取る可能性があります。
  • そうでなければ、同じメールアドレスを持つLDAPユーザーが同じGitLabアカウントを共有することが可能です。

LDAPユーザーがLDAPサーバー上で’mail’、’email’、’userPrincipalName’属性の変更を許可されている場合、またはメールアドレスを共有している場合は、LDAPインテグレーションを使用しないことをお勧めします。

ユーザー削除

LDAPサーバーからユーザーを削除した場合、GitLabでも同様にブロックされます。 ユーザーは即座にログインをブロックされます。 ただし、LDAPチェックのキャッシュ時間は1時間（注を参照）なので、すでにログインしているユーザーやSSH経由でGitを使用しているユーザーは、最大1時間までGitLabにアクセスすることができます。 GitLab管理エリアでユーザーを手動でブロックすると、すべてのアクセスを即座にブロックすることができます。

注：GitLab Enterprise Edition Starterは設定可能な同期時間をサポートしています。

git パスワード認証

LDAPが有効なユーザーは、アプリケーションの設定でGitのパスワード認証が無効になっていても、GitLabのユーザー名またはメールアドレスとLDAPパスワードを使って常にGitを認証することができます。

既存の GitLab ユーザーの LDAP サインインの有効化

ユーザーが初めてLDAPを使ってGitLabにサインインするとき、そのLDAPメールアドレスが既存のGitLabユーザーのプライマリメールアドレスである場合、LDAP DNは既存のユーザーと関連付けられます。 LDAPメールアドレス属性がGitLabのデータベースに見つからない場合、新しいユーザーが作成されます。

言い換えると、既存のGitLabユーザーがLDAPサインインを有効にしたい場合は、GitLabのメールアドレスとLDAPのメールアドレスが一致していることを確認し、LDAP認証情報を使ってGitLabにサインインします。

GoogleセキュアLDAP

GitLab 11.9 で導入されました。

Google Cloud Identityは Secure LDAP サービスを提供しており、GitLab で認証とグループ同期を設定することができます。 詳細な設定方法はGoogle Secure LDAPを参照ください。

構成

LDAPインテグレーションを有効にするには、Omnibus GitLabの場合は/etc/gitlab/gitlab.rb 、ソースからのインストールの場合は/home/git/gitlab/config/gitlab.yml 、それぞれLDAPサーバーの設定を追加する必要があります。

LDAPの設定をチェックするRakeタスクがあります。 以下のドキュメントを使ってLDAPを設定した後、LDAPcheck Rake taskの情報を参照してください。

注:encryption の値simple_tls は、LDAP ライブラリの「Simple TLS」に対応します。start_tls は StartTLS に対応し、通常の TLS と混同しないでください。 通常、simple_tls を指定するとポート 636 になり、start_tls (StartTLS) はポート 389 になります。plain もポート 389 でオペレーションします。 削除された値:tls はstart_tls に、ssl はsimple_tlsに置き換えられました。
注：LDAPユーザーには、サインインに使用するかどうかにかかわらず、電子メールアドレスが設定されている必要があります。

構成例

オムニバス構成 

gitlab_rails['ldap_enabled'] = true
gitlab_rails['prevent_ldap_sign_in'] = false
gitlab_rails['ldap_servers'] = {
'main' => {
  'label' => 'LDAP',
  'host' =>  'ldap.mydomain.com',
  'port' => 389,
  'uid' => 'sAMAccountName',
  'encryption' => 'simple_tls',
  'verify_certificates' => true,
  'bind_dn' => '_the_full_dn_of_the_user_you_will_bind_with',
  'password' => '_the_password_of_the_bind_user',
  'encryption' => 'plain',
  'verify_certificates' => true,
  'tls_options' => {
    'ca_file' => '',
    'ssl_version' => '',
    'ciphers' => '',
    'cert' => '',
    'key' => ''
  },
  'timeout' => 10,
  'active_directory' => true,
  'allow_username_or_email_login' => false,
  'block_auto_created_users' => false,
  'base' => 'dc=example,dc=com',
  'user_filter' => '',
  'attributes' => {
    'username' => ['uid', 'userid', 'sAMAccountName'],
    'email' => ['mail', 'email', 'userPrincipalName'],
    'name' => 'cn',
    'first_name' => 'givenName',
    'last_name' => 'sn'
  },
  'lowercase_usernames' => false,

  # EE Only
  'group_base' => '',
  'admin_group' => '',
  'external_groups' => [],
  'sync_ssh_keys' => false
  }
}

ソース構成 

production:
  # snip...
  ldap:
    enabled: false
    prevent_ldap_sign_in: false
    servers:
      main:
        label: 'LDAP'
        ...

基本構成設定

設定 説明 必須 使用例
label LDAPサーバーの親しみやすい名前です。 サインインページに表示されます。 はい 'Paris' または'Acme, Ltd.'
host LDAPサーバーのIPアドレスまたはドメイン名。 はい 'ldap.mydomain.com'
port LDAP サーバーに接続するポート。 文字列ではなく常に整数値です。 はい 389 または636 (SSLの場合)
uid ユーザー名の LDAP 属性。uidにマップされる値ではなく、属性である必要があります。 はい 'sAMAccountName''uid'、'userPrincipalName'
bind_dn バインドするユーザの完全な DN。 いいえ 'america\momo' または'CN=Gitlab,OU=Users,DC=domain,DC=com'
password バインドユーザーのパスワード。 いいえ 'your_great_password'
encryption 暗号化方式。method 鍵は非推奨で、encryptionを使用します。 はい 'start_tls' または'simple_tls' または'plain'
verify_certificates 暗号化方式がstart_tls またはsimple_tlsの場合、SSL 証明書の検証を有効にします。 デフォルトは true です。 いいえ ブーリアン
timeout LDAP クエリのタイムアウトを秒単位で設定します。 LDAP サーバが応答しなくなった場合に、要求がブロックされるのを回避するのに役立ちます。 値が 0 の場合、タイムアウトはありません。 いいえ 10 または30
active_directory この設定では、LDAPサーバーがActive Directory LDAPサーバーであるかどうかを指定します。 ADサーバーでない場合は、AD固有のクエリをスキップします。 LDAPサーバーがADでない場合は、この設定をfalseにします。 いいえ ブーリアン
allow_username_or_email_login 有効にすると、GitLab はサインイン時にユーザーが送信した LDAP ユーザー名の最初の@ 以降を無視します。ActiveDirectory でuid: 'userPrincipalName' を使っている場合は、この設定を無効にする必要があります。userPrincipalName に@が含まれているからです。 いいえ ブーリアン
block_auto_created_users GitLab インストールのアクティブユーザー数を厳密に管理するには、この設定を有効にして、管理者によってクリアされるまで新規ユーザーをブロックし続けます (デフォルト: false)。 いいえ ブーリアン
base ユーザーを検索するためのベース。 はい 'ou=people,dc=gitlab,dc=example' または'DC=mydomain,DC=com'
user_filter フォーマット:RFC 4515注意: GitLab はomniauth-ldapのカスタムフィルター構文をサポートしていません。 いいえ '(employeeType=developer)' または'(&(objectclass=user)(|(samaccountname=momo)(samaccountname=toto)))'
lowercase_usernames lowercase_usernames が有効な場合、GitLab はユーザー名を小文字にします。 いいえ ブーリアン

SSL構成設定

設定 説明 必須 使用例
ca_file 内部 CA を使用する必要がある場合など、PEM 形式の CA 証明書を含むファイルへのパスを指定します。 いいえ '/etc/ca.pem'
ssl_version OpenSSLのデフォルトが適切でない場合に、使用するOpenSSLのSSLバージョンを指定します。 いいえ 'TLSv1_1'
ciphers LDAPサーバーとの通信で使用する特定のSSL暗号。 いいえ 'ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2'
cert クライアント証明書 いいえ '-----BEGIN CERTIFICATE----- <REDACTED> -----END CERTIFICATE -----'
key クライアント秘密鍵 いいえ '-----BEGIN PRIVATE KEY----- <REDACTED> -----END PRIVATE KEY -----'

属性コンフィギュレーション設定

GitLab が LDAP ユーザのアカウントを作成する際に使用する LDAP 属性。指定する属性は、文字列としての属性名 ('mail'など) か、順番に試す属性名の配列 (['mail', 'email']など) のいずれかです。ユーザの LDAP サインインは、常に上記のuid で指定した属性になることに注意しましょう。

設定 説明 必須 使用例
username このユーザー名は、ユーザー自身のプロジェクトのパス (gitlab.example.com/username/projectのようなもの) や、イシュー、マージリクエスト、コメント (@usernameのようなもの) で言及するときに使われます。username に指定された属性にメールアドレスが含まれている場合、GitLab ユーザー名はメールアドレスの@より前の部分になります。 いいえ ['uid', 'userid', 'sAMAccountName']
email ユーザーEメールのLDAP属性。 いいえ ['mail', 'email', 'userPrincipalName']
name ユーザー表示名の LDAP 属性。nameで指定された属性でフルネームが見つからなかった場合、first_name およびlast_nameで指定された属性を使用してフルネームが決定されます。 いいえ 'cn' または'displayName'
first_name ユーザーのファーストネームのLDAP属性。 いいえ 'givenName'
last_name ユーザーの姓のLDAP属性。 いいえ 'sn'

LDAP同期設定

設定 説明 必須 使用例
group_base グループの検索に使用されるベース。 いいえ 'ou=groups,dc=gitlab,dc=example'
admin_group GitLab 管理者を含むグループの CN。 注意:cn=administrators や完全な DN ではありません。 いいえ 'administrators'
external_groups 注:cn=interns または完全な DN ではありません。 いいえ ['interns', 'contractors']
sync_ssh_keys ユーザーの公開 SSH キーを含む LDAP 属性。 いいえ 'sshPublicKey' 設定されていない場合は false

LDAPユーザーフィルターの設定

LDAPサーバー上のLDAPユーザーのサブセットにGitLabのすべてのアクセスを制限したい場合、最初のステップは、設定されたbase。 しかし、時にはさらにユーザーをフィルタリングする必要があります。 この場合、LDAPユーザーフィルターを設定することができます。 フィルターはRFC 4515に準拠している必要があります。

オムニバス構成 

gitlab_rails['ldap_servers'] = {
'main' => {
  # snip...
  'user_filter' => '(employeeType=developer)'
  }
}

ソース構成 

production:
  ldap:
    servers:
      main:
        # snip...
        user_filter: '(employeeType=developer)'

Active Directoryグループのネストしたメンバーへのアクセスを制限したい場合は、以下の構文を使用します： 

(memberOf:1.2.840.113556.1.4.1941:=CN=My Group,DC=Example,DC=com)

この “LDAP_MATCHING_RULE_IN_CHAIN “フィルタの詳細については、以下のMicrosoft Search Syntaxドキュメントを参照してください。 ユーザーフィルタのネストされたメンバーのサポートは、グループシンクのネストされたグループのサポートと混同しないでください。

GitLabはOmniAuth LDAPで使われているカスタムフィルタ構文をサポートしていないことに注意してください。

特殊文字のエスケープ

user_filter DNには特殊文字を含めることができます：

  • コンマ： 

     OU=GitLab, Inc,DC=gitlab,DC=com

  • ブラケットの開閉 

     OU=Gitlab (Inc),DC=gitlab,DC=com

    これらの文字は、RFC 4515で文書化されているようにエスケープされなければなりません。

  • カンマは\2Cで区切ります： 

     OU=GitLab\2C Inc,DC=gitlab,DC=com

  • 開き括弧と閉じ括弧は、それぞれ\28 と\29でエスケープします： 

     OU=Gitlab \28Inc\29,DC=gitlab,DC=com

LDAPユーザー名の小文字の有効化

LDAPサーバの中には、設定によっては大文字のユーザ名を返すものがあります。 このため、大文字の名前でリンクやネームスペースを作成するといった混乱したイシューが発生することがあります。

GitLabは、設定オプションlowercase_usernamesを有効にすることで、LDAPサーバーから提供されるユーザー名を自動的に小文字にすることができます。デフォルトでは、この設定オプションはfalse。

オムニバス構成

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

    gitlab_rails['ldap_servers'] = {
'main' => {
  # snip...
  'lowercase_usernames' => true
  }
}

  2. 変更を有効にするために GitLab を再設定します。

ソース構成

  1. config/gitlab.yamlを編集します： 

    production:
  ldap:
    servers:
      main:
        # snip...
        lowercase_usernames: true

  2. 変更を有効にするためにGitLabを再起動します。

LDAPウェブサインインを無効にします。

SAML などの代替手段を使用したい場合に、Web UI で LDAP 認証情報を使用しないようにすると便利です。 これにより、グループの同期に LDAP を使用できるようになると同時に、SAML ID プロバイダがカスタム 2FA などの追加チェックを処理できるようになります。

LDAP ウェブサインインを無効にすると、サインインページにLDAPタブが表示されなくなります。 これは、Git アクセスに LDAP 認証情報を使用することを無効にするものではありません。

オムニバス構成

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

    gitlab_rails['prevent_ldap_sign_in'] = true

  2. 変更を有効にするために GitLab を再設定します。

ソース構成

  1. config/gitlab.yamlを編集します： 

    production:
  ldap:
    prevent_ldap_sign_in: true

  2. 変更を有効にするためにGitLabを再起動します。

暗号化

TLSサーバー認証

simple_tls 、start_tlsの2つの暗号化方式があります。

いずれの暗号化方式でも、verify_certificates: falseを設定すると、LDAP プロトコルのデータが交換される前に LDAP サーバーとの間で TLS 暗号化が確立されますが、LDAP サーバーの SSL 証明書の検証は行われません。

制限事項

TLSクライアント認証

Net::LDAPでは未実施。

匿名LDAP認証を無効にし、シンプル認証またはSASL認証を有効にする必要があります。 LDAPサーバーのTLSクライアント認証設定を必須にすることはできず、クライアントをTLSプロトコルで認証することはできません。

複数のLDAPサーバー

GitLab Enterprise Edition Starterでは、GitLabインスタンスが接続する複数のLDAPサーバーを設定することができます。

別のLDAPサーバーを追加するには

  1. メイン設定の下に設定を複製します。
  2. 追加したLDAPサーバーに合わせて編集します。

このIDはデータベースに保存されるので、GitLabはユーザーがどのLDAPサーバーに属しているかを覚えておくことができます。

Multiple LDAP Servers Sign in

上の画像の例に基づいて、gitlab.rb ： 

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = {
'main' => {
  'label' => 'GitLab AD',
  'host' =>  'ad.example.org',
  'port' => 636,
  ...
  },

'secondary' => {
  'label' => 'GitLab Secondary AD',
  'host' =>  'ad-secondary.example.net',
  'port' => 636,
  ...
  },

'tertiary' => {
  'label' => 'GitLab Tertiary AD',
  'host' =>  'ad-tertiary.example.net',
  'port' => 636,
  ...
  }

}
注：LDAPサーバーはいくつでも設定できますが、各エントリーのlabel セクションは、サインインページに表示されるタブの表示名となるため、必ず一意の命名規則を使用してください。

ユーザー同期

GitLab は一日に一度、GitLab ユーザを LDAP と照合して更新するワーカーを実行します。

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

  • ユーザが LDAP に存在することを確認します。
  • LDAPサーバーがActive Directoryの場合、ユーザーがアクティビティであること（ブロック/無効状態でないこと）を確認します。 これは、LDAP設定でactive_directory: true が設定されている場合にのみ確認されます。
注：Active Directoryでは、ユーザーアカウント制御属性(userAccountControl:1.2.840.113556.1.4.803)のビット2が設定されている場合、ユーザーは無効/ブロックとしてマークされます。詳しくはhttps://ctovswild.com/2009/09/03/bitmask-searches-in-ldap/を参照してください。

上記の条件に失敗した場合、GitLabのldap_blocked 。つまり、サインインやコードのプッシュ/プルができなくなります。

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

  • メールアドレス
  • sync_ssh_keys が設定されている場合は、SSH公開キー。
  • Kerberos が有効な場合は、Kerberos ID。
注：LDAP同期プロセスは、既存のユーザーを更新する一方で、新規ユーザーは最初のサインイン時に作成されます。

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

注意:これらはcronでフォーマットされた値です。これらの値を作成するには、crontabジェネレータを使用します。例えば、http://www.crontabgenerator.com/。

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

以下の構成値を設定することで、LDAP ユーザー同期の時間を手動で構成できます。 以下の例では、LDAP ユーザー同期を 12 時間に 1 回、毎時の先頭に実行するように設定しています。

オムニバス設備

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

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

  2. 変更を有効にするために GitLab を再設定します。

ソースのインストール

  1. config/gitlab.yamlを編集します： 

    cron_jobs:
  ldap_sync_worker_cron:
    "0 */12 * * *"

  2. 変更を有効にするためにGitLabを再起動します。

グループ同期

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

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

group_base の設定は、’organization’ や ‘organizational unit’ のような、GitLab で利用可能な LDAP グループを含む基本的な LDAP ‘コンテナ’ でなければなりません。たとえば、group_base はou=groups,dc=example,dc=comのようになります。設定ファイルでは、次のようになります。

オムニバス構成

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

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

  2. 変更をGitLabに適用します。

ソース構成

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

    production:
  ldap:
    servers:
      main:
        # snip...
        group_base: ou=groups,dc=example,dc=com

  2. 変更を有効にするためにGitLabを再起動します。

グループシンクを利用するには、グループのオーナーやメンテナーは1つ以上のLDAPグループリンクを作成する必要があります。

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

管理者同期

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

注：admin_groupと同時にgroup_base も指定しない限り、管理者は同期されません。また、完全な DN ではなく、管理者グループの CN だけを指定してください。

オムニバス構成

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

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

  2. 変更をGitLabに適用します。

ソース構成

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

    production:
  ldap:
    servers:
      main:
        # snip...
        group_base: ou=groups,dc=example,dc=com
        admin_group: my_admin_group

  2. 変更を有効にするためにGitLabを再起動します。

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

“Lock memberships to LDAP synchronization”（メンバーシップをLDAP同期にロックする）設定により、インスタンス管理者は、グループに新しいメンバーを招待するユーザーの権限をロックすることができます。

有効にすると以下のようになります：

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

これを有効にするには

  1. LDAPの有効化
  2. (管理者) 管理エリア > 設定 > 可視性とアクセス制御に移動します。
  3. メンバーシップをLDAP同期にロックする」チェックボックスが有効になっていることを確認します。

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

注：これらはクーロンフォーマットされた値です。CrontabGeneratorなどでクーロンジェネレータを使ってこれらの値を作成することができます。

デフォルトでは、GitLabは毎正時にグループ同期プロセスを実行します。

重要:複数の同期が同時に実行される可能性があるため、同期プロセスをあまり頻繁に開始しないことをお勧めします。 これは主に、多数のLDAPユーザを持つインストールで懸念されることです。 先に進む前に、LDAPグループ同期ベンチマークのメトリクスを参照して、インストールとの比較を確認してください。

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

オムニバス設備

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

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

  2. 変更を有効にするために GitLab を再設定します。

ソースのインストール

  1. config/gitlab.yamlを編集します： 

    cron_jobs:
  ldap_group_sync_worker_cron:
      "*/30 * * * *"

  2. 変更を有効にするためにGitLabを再起動します。

外部グループ

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

オムニバス構成

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

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

  2. 変更をGitLabに適用します。

ソース構成

  1. config/gitlab.yamlを編集します： 

    production:
  ldap:
    servers:
      main:
        # snip...
        external_groups: ['interns', 'contractors']

  2. 変更を有効にするためにGitLabを再起動します。

グループシンクの技術的詳細

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

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

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

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

  • member
  • submember
  • uniquemember
  • memberof
  • memberuid.

つまり、グループシンクは少なくとも、次のオブジェクトクラスを持つ LDAP グループに対応しています：groupOfNames、posixGroup、groupOfUniqueNames。

また、GitLabはMicrosoft Active Directory、Apple Open Directory、Open LDAP、389 Serverをサポートしています。 他のLDAPサーバーも動作するはずです。

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

注意：ネストされたグループのメンバーシップは、ネストされたグループが設定されたgroup_base内にある場合にのみ解決されます。例えば、GitLab が DNcn=nested_group,ou=special_groups,dc=example,dc=com を持つネストされたグループを見たが、設定された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クエリは最小限に抑えられています。 最後にベンチマークを実行したところ、以下のメトリクスが明らかになりました：

20000人のLDAPユーザー、11000人のLDAPグループ、1000人のGitLabグループがそれぞれ10個のLDAPグループリンクを持つ場合：

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

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

トラブルシューティング

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