LDAP 동기화

요약

GitLab에서 작동하도록 LDAP를 구성한 경우, GitLab은 사용자와 그룹을 자동으로 동기화할 수 있습니다. LDAP 동기화는 LDAP 신원이 할당된 기존 GitLab 사용자의 사용자 및 그룹 정보를 업데이트합니다.

GitLab에서 작동하도록 LDAP를 구성한 경우, GitLab은 사용자와 그룹을 자동으로 동기화할 수 있습니다.

LDAP 동기화는 LDAP 신원이 할당된 기존 GitLab 사용자의 사용자 및 그룹 정보를 업데이트합니다. LDAP를 통해 새로운 GitLab 사용자를 생성하지는 않습니다.

동기화가 발생하는 시간을 변경할 수 있습니다.

속도 제한이 있는 LDAP 서버#

일부 LDAP 서버에는 속도 제한이 구성되어 있습니다.

GitLab은 다음 경우에 LDAP 서버에 한 번씩 쿼리합니다:

예약된 사용자 동기화 프로세스 중 각 사용자.
예약된 그룹 동기화 프로세스 중 각 그룹.

경우에 따라 LDAP 서버에 대한 더 많은 쿼리가 발생할 수 있습니다. 예를 들어 그룹 동기화 쿼리가 memberuid 속성을 반환하는 경우.

LDAP 서버에 속도 제한이 구성되어 있고 그 한도에 도달하는 경우:

사용자 동기화 프로세스 중에는 LDAP 서버가 오류 코드로 응답하고 GitLab이 해당 사용자를 차단합니다.
그룹 동기화 프로세스 중에는 LDAP 서버가 오류 코드로 응답하고 GitLab이 해당 사용자의 그룹 멤버십을 제거합니다.

원치 않는 사용자 차단 및 그룹 멤버십 제거를 방지하기 위해 LDAP 동기화를 구성할 때 LDAP 서버의 속도 제한을 고려해야 합니다.

사용자 동기화#

히스토리

LDAP 사용자 프로필 이름 동기화 방지 기능이 GitLab 15.11에서 도입되었습니다.

GitLab은 하루에 한 번 워커를 실행하여 LDAP에 대해 GitLab 사용자를 확인하고 업데이트합니다.

이 프로세스는 다음 접근 확인을 수행합니다:

사용자가 여전히 LDAP에 있는지 확인합니다.
LDAP 서버가 Active Directory인 경우, 사용자가 활성 상태인지 확인합니다(차단/비활성화 상태 아님). 이 확인은 LDAP 구성에서 active_directory: true가 설정된 경우에만 수행됩니다.

Active Directory에서 사용자 계정 제어 속성(userAccountControl:1.2.840.113556.1.4.803)에 비트 2가 설정된 경우 사용자가 비활성화/차단으로 표시됩니다.

자세한 내용은 LDAP의 비트마스크 검색을 참조하세요.

이 프로세스는 다음 사용자 정보도 업데이트합니다:

이름. 동기화 문제로 인해, 사용자가 프로필 이름을 변경하지 못하도록 방지가 활성화되어 있거나 sync_name이 false로 설정된 경우 name은 동기화되지 않습니다.
이메일 주소.
sync_ssh_keys가 설정된 경우 SSH 공개 키.
Kerberos가 활성화된 경우 Kerberos 신원.

Note

LDAP 서버에 속도 제한이 있는 경우, 사용자 동기화 프로세스 중에 해당 한도에 도달할 수 있습니다. 자세한 내용은 속도 제한 문서를 확인하세요.

LDAP 사용자 프로필 이름 동기화#

기본적으로 GitLab은 LDAP 사용자의 프로필 이름 필드를 동기화합니다.

이 동기화를 방지하려면 sync_name을 false로 설정할 수 있습니다.

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-compose.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:
```
docker compose up -d
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

차단된 사용자#

다음 중 하나에 해당하면 사용자가 차단됩니다:

접근 확인이 실패하여 GitLab에서 해당 사용자가 ldap_blocked 상태로 설정된 경우.
해당 사용자가 로그인할 때 LDAP 서버를 사용할 수 없는 경우.

사용자가 차단되면 해당 사용자는 로그인하거나 코드를 push 또는 pull할 수 없습니다.

차단된 사용자는 다음 모든 조건이 충족되는 경우 LDAP로 로그인할 때 차단이 해제됩니다:

모든 접근 확인 조건이 충족됩니다.
사용자가 로그인할 때 LDAP 서버를 사용할 수 있습니다.

LDAP 사용자 동기화가 실행될 때 LDAP 서버를 사용할 수 없으면 모든 사용자가 차단됩니다.

Note

LDAP 사용자 동기화가 실행될 때 LDAP 서버를 사용할 수 없어 모든 사용자가 차단된 경우, 이후의 LDAP 사용자 동기화는 해당 사용자를 자동으로 차단 해제하지 않습니다.

그룹 동기화#

LDAP가 memberof 속성을 지원하는 경우, 사용자가 처음 로그인할 때 GitLab은 해당 사용자가 멤버여야 하는 그룹에 대한 동기화를 트리거합니다. 이렇게 하면 그룹 및 프로젝트에 대한 접근이 허용되는 시간당 동기화를 기다릴 필요가 없습니다.

그룹 동기화 프로세스는 매시간 정각에 실행되며, 그룹 CN 기반의 LDAP 동기화가 작동하려면 LDAP 구성에서 group_base가 설정되어야 합니다. 이를 통해 GitLab 그룹 멤버십이 LDAP 그룹 멤버를 기반으로 자동으로 업데이트됩니다.

group_base 구성은 GitLab에서 사용할 수 있어야 하는 LDAP 그룹을 포함하는 기본 LDAP '컨테이너'(예: '조직' 또는 '조직 단위')여야 합니다. 예를 들어, group_base는 ou=groups,dc=example,dc=com일 수 있습니다. 구성 파일에서는 다음과 같이 표시됩니다.

Note

LDAP 서버에 속도 제한이 있는 경우, 그룹 동기화 프로세스 중에 해당 한도에 도달할 수 있습니다. 자세한 내용은 속도 제한 문서를 확인하세요.

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-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
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

그룹 동기화를 활용하려면 그룹 Owner 또는 Maintainer 권한을 가진 사용자가 하나 이상의 LDAP 그룹 링크를 만들어야 합니다.

Note

LDAP 서버와 GitLab 인스턴스 사이에 연결 문제가 자주 발생하는 경우, 그룹 동기화 워커 간격을 기본값인 1시간보다 크게 설정하여 GitLab이 LDAP 그룹 동기화를 수행하는 빈도를 줄여 보세요.

그룹 링크 추가#

CN 및 필터를 사용하여 그룹 링크를 추가하는 방법에 대한 정보는 GitLab 그룹 문서를 참조하세요.

LDAP 그룹에 관리자 역할 할당#

그룹 동기화의 확장으로, 전역 GitLab 관리자를 자동으로 관리할 수 있습니다. admin_group의 그룹 CN을 지정하면 LDAP 그룹의 모든 멤버에게 관리자 권한이 부여됩니다. 구성은 다음과 같습니다.

Note

admin_group과 함께 group_base도 지정되지 않으면 관리자가 동기화되지 않습니다. 또한 admin_group의 전체 DN이 아닌 CN만 지정하세요. 또한 LDAP 사용자에게 admin 권한이 있지만 admin_group 그룹의 멤버가 아닌 경우, 동기화 시 GitLab은 해당 사용자의 admin 권한을 취소합니다.

/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 값을 내보냅니다:

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-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
```

/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을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

LDAP 그룹에 커스텀 관리자 역할 할당#

외부 LDAP 그룹에서 동기화된 모든 사용자에게 커스텀 관리자 역할을 할당할 수 있습니다. 이 옵션은 SAML 그룹에는 사용할 수 없습니다.

사용자가 서로 다른 커스텀 역할이 할당된 여러 LDAP 그룹에 속한 경우, GitLab은 가장 먼저 연결된 LDAP 그룹과 연관된 역할을 할당합니다.

Note

동기화를 구성한 후 커스텀 관리자 역할을 가진 LDAP 사용자가 LDAP 그룹에서 제거되면, 다음 동기화가 실행될 때까지 커스텀 역할이 제거되지 않습니다.

사전 요구 사항:

인스턴스와 통합된 LDAP 서버.
관리자 접근 권한.

LDAP CN으로 할당

LDAP CN을 사용하여 커스텀 관리자 역할을 할당하려면:

오른쪽 상단에서 Admin을 선택합니다.
Settings > Roles and permissions를 선택합니다.
LDAP Synchronization 탭에서 LDAP Server를 선택합니다.
Sync method 필드에서 Group cn을 선택합니다.
Group cn 필드에서 그룹의 CN을 입력하기 시작합니다. 구성된 group_base에서 일치하는 CN이 포함된 드롭다운 목록이 표시됩니다.
드롭다운 목록에서 CN을 선택합니다.
Custom admin role 필드에서 커스텀 관리자 역할을 선택합니다.
Add를 선택합니다.

GitLab이 일치하는 LDAP 사용자에게 역할을 연결하기 시작합니다. 이 프로세스는 완료되는 데 한 시간 이상 걸릴 수 있습니다.

LDAP 필터로 할당

LDAP 필터를 사용하여 커스텀 관리자 역할을 할당하려면:

오른쪽 상단에서 Admin을 선택합니다.
Settings > Roles and permissions를 선택합니다.
LDAP Synchronization 탭에서 LDAP Server를 선택합니다.
Sync method 필드에서 User filter를 선택합니다.
User filter 텍스트 상자에 필터를 입력합니다. 자세한 내용은 LDAP 사용자 필터 설정을 참조하세요.
Custom admin role 필드에서 커스텀 관리자 역할을 선택합니다.
Add를 선택합니다.

GitLab이 일치하는 LDAP 사용자에게 역할을 연결하기 시작합니다. 이 프로세스는 완료되는 데 한 시간 이상 걸릴 수 있습니다.

전역 LDAP 그룹 멤버십 잠금#

GitLab 관리자는 LDAP와 멤버십이 동기화된 하위 그룹에 새 멤버를 초대하는 것을 그룹 멤버가 방지하도록 할 수 있습니다.

전역 그룹 멤버십 잠금은 LDAP 동기화가 구성된 최상위 그룹의 하위 그룹에만 적용됩니다. LDAP 동기화에 구성된 최상위 그룹의 멤버십을 수정할 수 있는 사용자는 없습니다.

전역 그룹 멤버십 잠금이 활성화된 경우:

그룹 또는 하위 그룹을 Code Owner로 설정할 수 없습니다. 자세한 내용은 전역 그룹 멤버십 잠금과의 비호환성을 참조하세요.
관리자만 접근 수준을 포함하여 모든 그룹의 멤버십을 관리할 수 있습니다.
사용자는 프로젝트를 다른 그룹과 공유하거나 그룹에서 만든 프로젝트에 멤버를 초대할 수 없습니다.

전역 그룹 멤버십 잠금을 활성화하려면:

LDAP를 구성합니다.
오른쪽 상단 모서리에서 Admin을 선택합니다.
Settings > General을 선택합니다.
Visibility and access controls를 펼칩니다.
Lock memberships to LDAP synchronization 체크박스가 선택되어 있는지 확인합니다.

LDAP 그룹 동기화 설정 관리 변경#

기본적으로 Owner 권한을 가진 그룹 멤버는 LDAP 그룹 동기화 설정을 관리할 수 있습니다.

GitLab 관리자는 그룹 Owner에서 이 권한을 제거할 수 있습니다:

LDAP를 구성합니다.
오른쪽 상단 모서리에서 Admin을 선택합니다.
Settings > General을 선택합니다.
Visibility and access controls를 펼칩니다.
Allow group owners to manage LDAP-related settings 체크박스가 선택되어 있지 않은지 확인합니다.

Allow group owners to manage LDAP-related settings가 비활성화된 경우:

그룹 Owner는 최상위 그룹 및 하위 그룹에 대한 LDAP 동기화 설정을 변경할 수 없습니다.
인스턴스 관리자는 인스턴스의 모든 그룹에서 LDAP 그룹 동기화 설정을 관리할 수 있습니다.

외부 그룹#

external_groups 설정을 사용하면 이러한 그룹에 속하는 모든 사용자를 외부 사용자로 표시할 수 있습니다. 그룹 멤버십은 LdapGroupSync 백그라운드 작업을 통해 주기적으로 확인됩니다.

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-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
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

그룹을 위한 GitLab Duo 애드온#

duo_add_on_groups 설정은 LDAP를 통해 인증하는 사용자에 대해 GitLab Duo 애드온 시트를 자동으로 관리합니다. 이 기능은 조직이 LDAP 그룹 멤버십을 기반으로 GitLab Duo 시트 할당 프로세스를 간소화하는 데 도움이 됩니다.

GitLab Duo 시트 동기화는 두 가지 방식으로 발생합니다:

사용자 로그인 시: 사용자가 LDAP를 통해 로그인하면 GitLab은 즉시 해당 사용자의 그룹 멤버십을 확인합니다.
예약된 동기화: GitLab은 사용자 로그인 없이도 시트 할당이 최신 상태로 유지되도록 매일 오전 02:00(서버 시간)에 모든 LDAP 사용자를 자동으로 동기화합니다.

그룹에 대한 애드온 시트 관리를 활성화하려면 GitLab 인스턴스에서 duo_add_on_groups 설정을 구성해야 합니다:

/etc/gitlab/gitlab.rb를 편집합니다:

gitlab_rails['ldap_servers'] = {
  'main' => {
    'duo_add_on_groups' => ['duo_group_1', 'duo_group_2'],
    }
}

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

Helm 값을 내보냅니다:

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml을 편집합니다:

global:
  appConfig:
    ldap:
      servers:
        main:
          duo_add_on_groups: ['duo_group_1', 'duo_group_2']

파일을 저장하고 새 값을 적용합니다:

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

docker-compose.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:
```
docker compose up -d
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

production: &base
  ldap:
    servers:
      main:
        duo_add_on_groups: ['duo_group_1', 'duo_group_2']

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

그룹 동기화 기술적 세부 사항#

이 섹션에서는 어떤 LDAP 쿼리가 실행되고 그룹 동기화에서 어떤 동작을 기대할 수 있는지 설명합니다.

사용자의 LDAP 그룹 멤버십이 변경되면 그룹 접근 수준이 낮아질 수 있습니다. 예를 들어 사용자가 그룹에서 Owner 권한을 가지고 있고 다음 그룹 동기화에서 Developer 권한만 있어야 한다는 것이 밝혀지면, 그 접근이 그에 따라 조정됩니다. 단, 사용자가 그룹의 마지막 Owner인 경우는 예외입니다. 그룹에는 관리 업무를 수행하기 위해 최소한 한 명의 Owner가 필요합니다.

제한된 접근으로 최소 접근 권한 할당#

히스토리

GitLab 18.6에서 bso_minimal_access_fallback이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 18.10에서 기본적으로 활성화되었습니다.

제한된 접근이 활성화되고 사용 가능한 구독 시트가 없는 경우, LDAP 그룹 동기화 중에 사용자에게 최소 접근 권한이 할당됩니다.

자세한 내용은 SAML, SCIM, LDAP를 사용한 프로비저닝 동작을 참조하세요.

지원되는 LDAP 그룹 유형/속성#

GitLab은 멤버 속성을 사용하는 LDAP 그룹을 지원합니다:

member
submember
uniquemember
memberof
memberuid

이는 그룹 동기화가 다음 object 클래스를 가진 LDAP 그룹을 (적어도) 지원함을 의미합니다:

groupOfNames
posixGroup
groupOfUniqueNames

멤버가 언급된 속성 중 하나로 정의된 경우 다른 object 클래스도 작동해야 합니다.

Active Directory는 중첩 그룹을 지원합니다. 구성 파일에서 active_directory: true가 설정된 경우 그룹 동기화는 멤버십을 재귀적으로 해결합니다.

중첩 그룹 멤버십#

중첩 그룹 멤버십은 중첩 그룹이 구성된 group_base에서 발견되는 경우에만 해결됩니다. 예를 들어 GitLab이 DN이 cn=nested_group,ou=special_groups,dc=example,dc=com인 중첩 그룹을 발견했지만 구성된 group_base가 ou=groups,dc=example,dc=com인 경우, cn=nested_group은 무시됩니다.

쿼리#

각 LDAP 그룹은 base group_base와 필터 (cn=<cn_from_group_link>)로 최대 한 번 쿼리됩니다.
LDAP 그룹에 memberuid 속성이 있는 경우, GitLab은 각 사용자의 전체 DN을 얻기 위해 멤버당 다른 LDAP 쿼리를 실행합니다. 이 쿼리는 base base, scope baseObject, 그리고 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가 사용자, 그룹, GitLab Duo 애드온 시트를 동기화하는 시간 및 간격을 변경할 수 있습니다.

사용자의 경우#

기본적으로 GitLab은 서버 시간 01:30 AM에 하루에 한 번 워커를 실행하여 LDAP에 대해 GitLab 사용자를 확인하고 업데이트합니다.

Warning

여러 동기화가 동시에 실행될 수 있으므로 동기화 프로세스를 너무 자주 실행하지 마세요. 대부분의 설치에서는 동기화 일정을 수정할 필요가 없습니다. 자세한 내용은 LDAP 보안 문서를 참조하세요.

cron 형식으로 다음 구성 값을 설정하여 LDAP 사용자 동기화 시간을 수동으로 구성할 수 있습니다. 필요한 경우 crontab 생성기를 사용할 수 있습니다. 아래 예시는 LDAP 사용자 동기화를 매 12시간마다 정각에 한 번 실행하도록 설정하는 방법을 보여줍니다.

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-compose.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:
```
docker compose up -d
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

그룹의 경우#

기본적으로 GitLab은 매시간 정각에 그룹 동기화 프로세스를 실행합니다. 표시된 값은 cron 형식입니다. 필요한 경우 crontab 생성기를 사용할 수 있습니다.

Warning

여러 동기화가 동시에 실행될 수 있으므로 동기화 프로세스를 너무 자주 시작하지 마세요. 대부분의 설치에서는 동기화 일정을 수정할 필요가 없습니다.

다음 구성 값을 설정하여 LDAP 그룹 동기화 시간을 수동으로 구성할 수 있습니다. 아래 예시는 그룹 동기화를 매 2시간마다 정각에 한 번 실행하도록 설정하는 방법을 보여줍니다.

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-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
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

GitLab Duo 애드온 시트의 경우#

기본적으로 GitLab은 LDAP 그룹 멤버십을 확인하고 GitLab Duo 애드온 시트를 할당하거나 제거하기 위해 서버 시간 02:00 AM에 하루에 한 번 GitLab Duo 애드온 시트 동기화 프로세스를 실행합니다.

Warning

구성 값을 설정하여 LDAP GitLab Duo 애드온 시트 동기화 시간을 수동으로 구성할 수 있습니다. 다음 예시는 동기화를 매 4시간마다 한 번 실행하도록 설정하는 방법을 보여줍니다.

/etc/gitlab/gitlab.rb를 편집합니다:

gitlab_rails['ldap_add_on_seat_sync_worker_cron'] = "0 */4 * * *"

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

Helm 값을 내보냅니다:

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml을 편집합니다:

global:
  appConfig:
    cron_jobs:
      ldap_add_on_seat_sync_worker:
        cron: "0 */4 * * *"

파일을 저장하고 새 값을 적용합니다:

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

docker-compose.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:
```
docker compose up -d
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

production: &base
  ee_cron_jobs:
    ldap_add_on_seat_sync_worker:
      cron: "0 */4 * * *"

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

LDAP 동기화

Tier: Ultimate
Offering: GitLab Self-Managed

원문 보기

번역일: 2026-05-22

요약

GitLab에서 작동하도록 LDAP를 구성한 경우, GitLab은 사용자와 그룹을 자동으로 동기화할 수 있습니다.

LDAP 동기화는 LDAP 신원이 할당된 기존 GitLab 사용자의 사용자 및 그룹 정보를 업데이트합니다. LDAP를 통해 새로운 GitLab 사용자를 생성하지는 않습니다.

동기화가 발생하는 시간을 변경할 수 있습니다.

속도 제한이 있는 LDAP 서버#

일부 LDAP 서버에는 속도 제한이 구성되어 있습니다.

GitLab은 다음 경우에 LDAP 서버에 한 번씩 쿼리합니다:

예약된 사용자 동기화 프로세스 중 각 사용자.
예약된 그룹 동기화 프로세스 중 각 그룹.

경우에 따라 LDAP 서버에 대한 더 많은 쿼리가 발생할 수 있습니다. 예를 들어 그룹 동기화 쿼리가 memberuid 속성을 반환하는 경우.

LDAP 서버에 속도 제한이 구성되어 있고 그 한도에 도달하는 경우:

사용자 동기화 프로세스 중에는 LDAP 서버가 오류 코드로 응답하고 GitLab이 해당 사용자를 차단합니다.
그룹 동기화 프로세스 중에는 LDAP 서버가 오류 코드로 응답하고 GitLab이 해당 사용자의 그룹 멤버십을 제거합니다.

원치 않는 사용자 차단 및 그룹 멤버십 제거를 방지하기 위해 LDAP 동기화를 구성할 때 LDAP 서버의 속도 제한을 고려해야 합니다.

사용자 동기화#

히스토리

LDAP 사용자 프로필 이름 동기화 방지 기능이 GitLab 15.11에서 도입되었습니다.

GitLab은 하루에 한 번 워커를 실행하여 LDAP에 대해 GitLab 사용자를 확인하고 업데이트합니다.

이 프로세스는 다음 접근 확인을 수행합니다:

사용자가 여전히 LDAP에 있는지 확인합니다.
LDAP 서버가 Active Directory인 경우, 사용자가 활성 상태인지 확인합니다(차단/비활성화 상태 아님). 이 확인은 LDAP 구성에서 active_directory: true가 설정된 경우에만 수행됩니다.

Active Directory에서 사용자 계정 제어 속성(userAccountControl:1.2.840.113556.1.4.803)에 비트 2가 설정된 경우 사용자가 비활성화/차단으로 표시됩니다.

자세한 내용은 LDAP의 비트마스크 검색을 참조하세요.

이 프로세스는 다음 사용자 정보도 업데이트합니다:

이름. 동기화 문제로 인해, 사용자가 프로필 이름을 변경하지 못하도록 방지가 활성화되어 있거나 sync_name이 false로 설정된 경우 name은 동기화되지 않습니다.
이메일 주소.
sync_ssh_keys가 설정된 경우 SSH 공개 키.
Kerberos가 활성화된 경우 Kerberos 신원.

Note

LDAP 서버에 속도 제한이 있는 경우, 사용자 동기화 프로세스 중에 해당 한도에 도달할 수 있습니다. 자세한 내용은 속도 제한 문서를 확인하세요.

LDAP 사용자 프로필 이름 동기화#

기본적으로 GitLab은 LDAP 사용자의 프로필 이름 필드를 동기화합니다.

이 동기화를 방지하려면 sync_name을 false로 설정할 수 있습니다.

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-compose.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:
```
docker compose up -d
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

차단된 사용자#

다음 중 하나에 해당하면 사용자가 차단됩니다:

접근 확인이 실패하여 GitLab에서 해당 사용자가 ldap_blocked 상태로 설정된 경우.
해당 사용자가 로그인할 때 LDAP 서버를 사용할 수 없는 경우.

사용자가 차단되면 해당 사용자는 로그인하거나 코드를 push 또는 pull할 수 없습니다.

차단된 사용자는 다음 모든 조건이 충족되는 경우 LDAP로 로그인할 때 차단이 해제됩니다:

모든 접근 확인 조건이 충족됩니다.
사용자가 로그인할 때 LDAP 서버를 사용할 수 있습니다.

LDAP 사용자 동기화가 실행될 때 LDAP 서버를 사용할 수 없으면 모든 사용자가 차단됩니다.

Note

그룹 동기화#

Note

LDAP 서버에 속도 제한이 있는 경우, 그룹 동기화 프로세스 중에 해당 한도에 도달할 수 있습니다. 자세한 내용은 속도 제한 문서를 확인하세요.

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-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
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

그룹 동기화를 활용하려면 그룹 Owner 또는 Maintainer 권한을 가진 사용자가 하나 이상의 LDAP 그룹 링크를 만들어야 합니다.

Note

그룹 링크 추가#

CN 및 필터를 사용하여 그룹 링크를 추가하는 방법에 대한 정보는 GitLab 그룹 문서를 참조하세요.

LDAP 그룹에 관리자 역할 할당#

Note

/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 값을 내보냅니다:

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-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
```

/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을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

LDAP 그룹에 커스텀 관리자 역할 할당#

외부 LDAP 그룹에서 동기화된 모든 사용자에게 커스텀 관리자 역할을 할당할 수 있습니다. 이 옵션은 SAML 그룹에는 사용할 수 없습니다.

사용자가 서로 다른 커스텀 역할이 할당된 여러 LDAP 그룹에 속한 경우, GitLab은 가장 먼저 연결된 LDAP 그룹과 연관된 역할을 할당합니다.

Note

사전 요구 사항:

인스턴스와 통합된 LDAP 서버.
관리자 접근 권한.

LDAP CN으로 할당

LDAP CN을 사용하여 커스텀 관리자 역할을 할당하려면:

오른쪽 상단에서 Admin을 선택합니다.
Settings > Roles and permissions를 선택합니다.
LDAP Synchronization 탭에서 LDAP Server를 선택합니다.
Sync method 필드에서 Group cn을 선택합니다.
Group cn 필드에서 그룹의 CN을 입력하기 시작합니다. 구성된 group_base에서 일치하는 CN이 포함된 드롭다운 목록이 표시됩니다.
드롭다운 목록에서 CN을 선택합니다.
Custom admin role 필드에서 커스텀 관리자 역할을 선택합니다.
Add를 선택합니다.

GitLab이 일치하는 LDAP 사용자에게 역할을 연결하기 시작합니다. 이 프로세스는 완료되는 데 한 시간 이상 걸릴 수 있습니다.

LDAP 필터로 할당

LDAP 필터를 사용하여 커스텀 관리자 역할을 할당하려면:

오른쪽 상단에서 Admin을 선택합니다.
Settings > Roles and permissions를 선택합니다.
LDAP Synchronization 탭에서 LDAP Server를 선택합니다.
Sync method 필드에서 User filter를 선택합니다.
User filter 텍스트 상자에 필터를 입력합니다. 자세한 내용은 LDAP 사용자 필터 설정을 참조하세요.
Custom admin role 필드에서 커스텀 관리자 역할을 선택합니다.
Add를 선택합니다.

GitLab이 일치하는 LDAP 사용자에게 역할을 연결하기 시작합니다. 이 프로세스는 완료되는 데 한 시간 이상 걸릴 수 있습니다.

전역 LDAP 그룹 멤버십 잠금#

GitLab 관리자는 LDAP와 멤버십이 동기화된 하위 그룹에 새 멤버를 초대하는 것을 그룹 멤버가 방지하도록 할 수 있습니다.

전역 그룹 멤버십 잠금이 활성화된 경우:

그룹 또는 하위 그룹을 Code Owner로 설정할 수 없습니다. 자세한 내용은 전역 그룹 멤버십 잠금과의 비호환성을 참조하세요.
관리자만 접근 수준을 포함하여 모든 그룹의 멤버십을 관리할 수 있습니다.
사용자는 프로젝트를 다른 그룹과 공유하거나 그룹에서 만든 프로젝트에 멤버를 초대할 수 없습니다.

전역 그룹 멤버십 잠금을 활성화하려면:

LDAP를 구성합니다.
오른쪽 상단 모서리에서 Admin을 선택합니다.
Settings > General을 선택합니다.
Visibility and access controls를 펼칩니다.
Lock memberships to LDAP synchronization 체크박스가 선택되어 있는지 확인합니다.

LDAP 그룹 동기화 설정 관리 변경#

기본적으로 Owner 권한을 가진 그룹 멤버는 LDAP 그룹 동기화 설정을 관리할 수 있습니다.

GitLab 관리자는 그룹 Owner에서 이 권한을 제거할 수 있습니다:

LDAP를 구성합니다.
오른쪽 상단 모서리에서 Admin을 선택합니다.
Settings > General을 선택합니다.
Visibility and access controls를 펼칩니다.
Allow group owners to manage LDAP-related settings 체크박스가 선택되어 있지 않은지 확인합니다.

Allow group owners to manage LDAP-related settings가 비활성화된 경우:

그룹 Owner는 최상위 그룹 및 하위 그룹에 대한 LDAP 동기화 설정을 변경할 수 없습니다.
인스턴스 관리자는 인스턴스의 모든 그룹에서 LDAP 그룹 동기화 설정을 관리할 수 있습니다.

외부 그룹#

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-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
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

그룹을 위한 GitLab Duo 애드온#

GitLab Duo 시트 동기화는 두 가지 방식으로 발생합니다:

사용자 로그인 시: 사용자가 LDAP를 통해 로그인하면 GitLab은 즉시 해당 사용자의 그룹 멤버십을 확인합니다.
예약된 동기화: GitLab은 사용자 로그인 없이도 시트 할당이 최신 상태로 유지되도록 매일 오전 02:00(서버 시간)에 모든 LDAP 사용자를 자동으로 동기화합니다.

그룹에 대한 애드온 시트 관리를 활성화하려면 GitLab 인스턴스에서 duo_add_on_groups 설정을 구성해야 합니다:

/etc/gitlab/gitlab.rb를 편집합니다:

gitlab_rails['ldap_servers'] = {
  'main' => {
    'duo_add_on_groups' => ['duo_group_1', 'duo_group_2'],
    }
}

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

Helm 값을 내보냅니다:

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml을 편집합니다:

global:
  appConfig:
    ldap:
      servers:
        main:
          duo_add_on_groups: ['duo_group_1', 'duo_group_2']

파일을 저장하고 새 값을 적용합니다:

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

docker-compose.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:
```
docker compose up -d
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

production: &base
  ldap:
    servers:
      main:
        duo_add_on_groups: ['duo_group_1', 'duo_group_2']

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

그룹 동기화 기술적 세부 사항#

이 섹션에서는 어떤 LDAP 쿼리가 실행되고 그룹 동기화에서 어떤 동작을 기대할 수 있는지 설명합니다.

제한된 접근으로 최소 접근 권한 할당#

히스토리

GitLab 18.6에서 bso_minimal_access_fallback이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 18.10에서 기본적으로 활성화되었습니다.

제한된 접근이 활성화되고 사용 가능한 구독 시트가 없는 경우, LDAP 그룹 동기화 중에 사용자에게 최소 접근 권한이 할당됩니다.

자세한 내용은 SAML, SCIM, LDAP를 사용한 프로비저닝 동작을 참조하세요.

지원되는 LDAP 그룹 유형/속성#

GitLab은 멤버 속성을 사용하는 LDAP 그룹을 지원합니다:

member
submember
uniquemember
memberof
memberuid

이는 그룹 동기화가 다음 object 클래스를 가진 LDAP 그룹을 (적어도) 지원함을 의미합니다:

groupOfNames
posixGroup
groupOfUniqueNames

멤버가 언급된 속성 중 하나로 정의된 경우 다른 object 클래스도 작동해야 합니다.

Active Directory는 중첩 그룹을 지원합니다. 구성 파일에서 active_directory: true가 설정된 경우 그룹 동기화는 멤버십을 재귀적으로 해결합니다.

중첩 그룹 멤버십#

쿼리#

각 LDAP 그룹은 base group_base와 필터 (cn=<cn_from_group_link>)로 최대 한 번 쿼리됩니다.
LDAP 그룹에 memberuid 속성이 있는 경우, GitLab은 각 사용자의 전체 DN을 얻기 위해 멤버당 다른 LDAP 쿼리를 실행합니다. 이 쿼리는 base base, scope baseObject, 그리고 user_filter가 설정되어 있는지 여부에 따라 달라지는 필터로 실행됩니다. 필터는 (uid=<uid_from_group>) 또는 user_filter의 결합이 될 수 있습니다.

벤치마크#

20,000명의 LDAP 사용자, 11,000개의 LDAP 그룹, 각 10개의 LDAP 그룹 링크가 있는 1,000개의 GitLab 그룹의 경우:

초기 동기화(GitLab에 기존 멤버 할당 없음)는 1.8시간 소요
이후 동기화(멤버십 확인, 쓰기 없음)는 15분 소요

LDAP 동기화 일정 조정#

LDAP가 사용자, 그룹, GitLab Duo 애드온 시트를 동기화하는 시간 및 간격을 변경할 수 있습니다.

사용자의 경우#

기본적으로 GitLab은 서버 시간 01:30 AM에 하루에 한 번 워커를 실행하여 LDAP에 대해 GitLab 사용자를 확인하고 업데이트합니다.

Warning

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-compose.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:
```
docker compose up -d
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

그룹의 경우#

기본적으로 GitLab은 매시간 정각에 그룹 동기화 프로세스를 실행합니다. 표시된 값은 cron 형식입니다. 필요한 경우 crontab 생성기를 사용할 수 있습니다.

Warning

/etc/gitlab/gitlab.rb를 편집합니다:

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

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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-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
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart

GitLab Duo 애드온 시트의 경우#

Warning

/etc/gitlab/gitlab.rb를 편집합니다:

gitlab_rails['ldap_add_on_seat_sync_worker_cron'] = "0 */4 * * *"

파일을 저장하고 GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

Helm 값을 내보냅니다:

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml을 편집합니다:

global:
  appConfig:
    cron_jobs:
      ldap_add_on_seat_sync_worker:
        cron: "0 */4 * * *"

파일을 저장하고 새 값을 적용합니다:

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

docker-compose.yml을 편집합니다:

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

파일을 저장하고 GitLab을 재시작합니다:
```
docker compose up -d
```

/home/git/gitlab/config/gitlab.yml을 편집합니다:

production: &base
  ee_cron_jobs:
    ldap_add_on_seat_sync_worker:
      cron: "0 */4 * * *"

파일을 저장하고 GitLab을 재시작합니다:

# systemd를 실행하는 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init을 실행하는 시스템의 경우
sudo service gitlab restart