- 概要
- セキュリティ
- git パスワード認証
- 既存の GitLab ユーザーの LDAP サインインの有効化
- GoogleセキュアLDAP
- 構成
- 暗号化
- 複数のLDAPサーバー
- ユーザー同期
- グループ同期
- トラブルシューティング
一般的なLDAPの設定
GitLabはLDAPとインテグレーションし、ユーザー認証をサポートします。
このインテグレーションは、以下を含むほとんどのLDAP準拠のディレクトリサーバーで動作します:
- Microsoft Active Directory
- Appleオープンディレクトリ
- LDAPを開く
- 389 サーバー
GitLab Enterprise Editions(EE) では、グループメンバーシップの同期や複数のLDAPサーバーのサポートなど、インテグレーションが強化されています。
概要
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管理エリアでユーザーを手動でブロックすると、すべてのアクセスを即座にブロックすることができます。
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
に置き換えられました。構成例
オムニバス構成
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
。
オムニバス構成
-
/etc/gitlab/gitlab.rb
を編集します:gitlab_rails['ldap_servers'] = { 'main' => { # snip... 'lowercase_usernames' => true } }
-
変更を有効にするために GitLab を再設定します。
ソース構成
-
config/gitlab.yaml
を編集します:production: ldap: servers: main: # snip... lowercase_usernames: true
-
変更を有効にするためにGitLabを再起動します。
LDAPウェブサインインを無効にします。
SAML などの代替手段を使用したい場合に、Web UI で LDAP 認証情報を使用しないようにすると便利です。 これにより、グループの同期に LDAP を使用できるようになると同時に、SAML ID プロバイダがカスタム 2FA などの追加チェックを処理できるようになります。
LDAP ウェブサインインを無効にすると、サインインページにLDAPタブが表示されなくなります。 これは、Git アクセスに LDAP 認証情報を使用することを無効にするものではありません。
オムニバス構成
-
/etc/gitlab/gitlab.rb
を編集します:gitlab_rails['prevent_ldap_sign_in'] = true
-
変更を有効にするために GitLab を再設定します。
ソース構成
-
config/gitlab.yaml
を編集します:production: ldap: prevent_ldap_sign_in: true
-
変更を有効にするために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サーバーを追加するには
- メイン設定の下に設定を複製します。
- 追加したLDAPサーバーに合わせて編集します。
このIDはデータベースに保存されるので、GitLabはユーザーがどのLDAPサーバーに属しているかを覚えておくことができます。
上の画像の例に基づいて、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,
...
}
}
label
セクションは、サインインページに表示されるタブの表示名となるため、必ず一意の命名規則を使用してください。ユーザー同期
GitLab は一日に一度、GitLab ユーザを LDAP と照合して更新するワーカーを実行します。
プロセスは以下のアクセス・チェックを実行します:
- ユーザが LDAP に存在することを確認します。
- LDAPサーバーがActive Directoryの場合、ユーザーがアクティビティであること(ブロック/無効状態でないこと)を確認します。 これは、LDAP設定で
active_directory: true
が設定されている場合にのみ確認されます。
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ユーザー同期スケジュールの調整
デフォルトでは、GitLabは1日1回、サーバー時間の午前1時30分にワーカーを実行し、GitLabユーザーをLDAPと照合して更新します。
以下の構成値を設定することで、LDAP ユーザー同期の時間を手動で構成できます。 以下の例では、LDAP ユーザー同期を 12 時間に 1 回、毎時の先頭に実行するように設定しています。
オムニバス設備
-
/etc/gitlab/gitlab.rb
を編集します:gitlab_rails['ldap_sync_worker_cron'] = "0 */12 * * *"
-
変更を有効にするために GitLab を再設定します。
ソースのインストール
-
config/gitlab.yaml
を編集します:cron_jobs: ldap_sync_worker_cron: "0 */12 * * *"
-
変更を有効にするために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
のようになります。設定ファイルでは、次のようになります。
オムニバス構成
-
/etc/gitlab/gitlab.rb
を編集します:gitlab_rails['ldap_servers'] = { 'main' => { # snip... 'group_base' => 'ou=groups,dc=example,dc=com', } }
ソース構成
-
/home/git/gitlab/config/gitlab.yml
を編集します:production: ldap: servers: main: # snip... group_base: ou=groups,dc=example,dc=com
-
変更を有効にするためにGitLabを再起動します。
グループシンクを利用するには、グループのオーナーやメンテナーは1つ以上のLDAPグループリンクを作成する必要があります。
グループリンクの追加
CNやフィルタを使ったグループリンクの追加については、GitLabグループのドキュメントを参照してください。
管理者同期
グループ同期の拡張として、GitLabのグローバル管理者を自動的に管理することができます。admin_group
のグループCNを指定すると、LDAPグループのメンバー全員に管理者権限が与えられます。 設定は以下のようになります。
admin_group
と同時にgroup_base
も指定しない限り、管理者は同期されません。また、完全な DN ではなく、管理者グループの CN だけを指定してください。オムニバス構成
-
/etc/gitlab/gitlab.rb
を編集します:gitlab_rails['ldap_servers'] = { 'main' => { # snip... 'group_base' => 'ou=groups,dc=example,dc=com', 'admin_group' => 'my_admin_group', } }
ソース構成
-
/home/git/gitlab/config/gitlab.yml
を編集します:production: ldap: servers: main: # snip... group_base: ou=groups,dc=example,dc=com admin_group: my_admin_group
-
変更を有効にするためにGitLabを再起動します。
グローバルグループメンバーシップロック
“Lock memberships to LDAP synchronization”(メンバーシップをLDAP同期にロックする)設定により、インスタンス管理者は、グループに新しいメンバーを招待するユーザーの権限をロックすることができます。
有効にすると以下のようになります:
- アクセスレベルを含め、グループのメンバーシップを管理できるのは管理者のみです。
- ユーザーは、他のグループとプロジェクトを共有したり、グループで作成されたプロジェクトにメンバーを招待したりすることはできません。
これを有効にするには
- LDAPの有効化
- (管理者) 管理エリア > 設定 > 可視性とアクセス制御に移動します。
- メンバーシップをLDAP同期にロックする」チェックボックスが有効になっていることを確認します。
LDAPグループ同期スケジュールの調整
デフォルトでは、GitLabは毎正時にグループ同期プロセスを実行します。
以下の構成値を設定することで、LDAPグループ同期の時間を手動で構成できます。 以下の例では、グループ同期を2時間に1回、毎正時に実行するように設定しています。
オムニバス設備
-
/etc/gitlab/gitlab.rb
を編集します:gitlab_rails['ldap_group_sync_worker_cron'] = "0 */2 * * * *"
-
変更を有効にするために GitLab を再設定します。
ソースのインストール
-
config/gitlab.yaml
を編集します:cron_jobs: ldap_group_sync_worker_cron: "*/30 * * * *"
-
変更を有効にするためにGitLabを再起動します。
外部グループ
external_groups
設定を使用すると、これらのグループに属するすべてのユーザーを外部ユーザーとしてマークすることができます。グループメンバーシップは、LdapGroupSync
バックグラウンドタスクによって定期的にチェックされます。
オムニバス構成
-
/etc/gitlab/gitlab.rb
を編集します:gitlab_rails['ldap_servers'] = { 'main' => { # snip... 'external_groups' => ['interns', 'contractors'], } }
ソース構成
-
config/gitlab.yaml
を編集します:production: ldap: servers: main: # snip... external_groups: ['interns', 'contractors']
-
変更を有効にするために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のトラブルシューティングについては、管理者ガイドを参照してください。