Kerberos 통합으로 GitLab 문제 해결
Offering: GitLab Self-Managed
Kerberos 통합이 포함된 GitLab을 사용할 때 다음 문제가 발생할 수 있습니다. Kerberos를 사용하여 GitLab에 로그인하기 위해 Google Chrome을 사용할 때는 전체 사용자 이름을 입력해야 합니다.
Kerberos 통합이 포함된 GitLab을 사용할 때 다음 문제가 발생할 수 있습니다.
Windows AD에 대한 Kerberos 인증으로 Google Chrome 사용#
Kerberos를 사용하여 GitLab에 로그인하기 위해 Google Chrome을 사용할 때는 전체 사용자 이름을 입력해야 합니다. 예를 들어 username@domain.com.
전체 사용자 이름을 입력하지 않으면 로그인이 실패합니다. 로그를 확인하여 이 로그인 실패의 증거로 다음 이벤트 메시지를 확인하세요:
"message":"OmniauthKerberosController: failed to process Negotiate/Kerberos authentication: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested\nUnknown error".
GitLab과 Kerberos 서버 간의 연결 테스트#
kinit 및 klist와 같은 유틸리티를 사용하여 GitLab 서버와 Kerberos 서버 간의 연결을 테스트할 수 있습니다. 설치 방법은 특정 OS에 따라 다릅니다.
klist를 사용하여 keytab 파일에서 사용 가능한 서비스 주체 이름(SPN)과 각 SPN의 암호화 유형을 확인합니다:
klist -ke /etc/http.keytab
Ubuntu 서버에서 출력은 다음과 유사합니다:
Keytab name: FILE:/etc/http.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 HTTP/my.gitlab.domain@MY.REALM (des-cbc-crc)
3 HTTP/my.gitlab.domain@MY.REALM (des-cbc-md5)
3 HTTP/my.gitlab.domain@MY.REALM (arcfour-hmac)
3 HTTP/my.gitlab.domain@MY.REALM (aes256-cts-hmac-sha1-96)
3 HTTP/my.gitlab.domain@MY.REALM (aes128-cts-hmac-sha1-96)
상세 모드에서 kinit를 사용하여 GitLab이 keytab 파일을 사용하여 Kerberos 서버에 연결할 수 있는지 테스트합니다:
KRB5_TRACE=/dev/stdout kinit -kt /etc/http.keytab HTTP/my.gitlab.domain@MY.REALM
이 명령은 인증 프로세스의 자세한 출력을 표시합니다.
지원되지 않는 GSSAPI 메커니즘#
Kerberos SPNEGO 인증을 사용할 때 브라우저는 지원하는 메커니즘 목록을 GitLab에 보낼 것으로 예상됩니다. GitLab이 지원하는 메커니즘이 없으면 인증이 실패하고 로그에 다음과 같은 메시지가 표시됩니다:
OmniauthKerberosController: failed to process Negotiate/Kerberos authentication: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested Unknown error
이 오류 메시지에는 여러 가지 잠재적 원인과 해결책이 있습니다.
전용 포트를 사용하지 않는 Kerberos 통합#
Kerberos 통합이 전용 포트를 사용하도록 구성되지 않은 경우 GitLab CI/CD는 Kerberos 활성화 GitLab 인스턴스와 작동하지 않습니다.
클라이언트 머신과 Kerberos 서버 간의 연결 부족#
이는 브라우저가 Kerberos 서버에 직접 연결할 수 없을 때 일반적으로 발생합니다. GitLab 서버를 Kerberos 서버의 중간자로 사용하려는
IAKERB라는 지원되지 않는 메커니즘으로 대체됩니다.
이 오류가 발생하면 클라이언트 머신과 Kerberos 서버 간의 연결이 있는지 확인하세요 - 이것은 전제 조건입니다! 트래픽이 방화벽에 의해 차단되거나 DNS 레코드가 올바르지 않을 수 있습니다.
GitLab DNS record is a CNAME record 오류#
GitLab이 CNAME 레코드로 참조될 때 Kerberos가 이 오류로 실패합니다.
이 문제를 해결하려면 GitLab의 DNS 레코드가 A 레코드인지 확인합니다.
GitLab 인스턴스 호스트명에 대한 순방향 및 역방향 DNS 레코드 불일치#
GitLab 서버의 순방향 및 역방향 DNS 레코드가 일치하지 않을 때 다른 실패 모드가 발생합니다. 종종 이 경우 Windows 클라이언트는 작동하지만 Linux 클라이언트는 실패합니다. Linux 클라이언트는 Kerberos 영역을 감지하는 동안 역방향 DNS를 사용합니다. 잘못된 영역을 얻으면 일반 Kerberos 메커니즘이 실패하므로 클라이언트가 IAKERB 협상을 시도하여 이전 인증 오류 메시지가 발생합니다.
이를 해결하려면 GitLab 서버의 순방향 및 역방향 DNS가 일치하는지 확인합니다. 예를 들어 gitlab.example.com으로 GitLab에 액세스하고 IP 주소 10.0.2.2로 해결되면 2.2.0.10.in-addr.arpa는 gitlab.example.com에 대한 PTR 레코드여야 합니다.
브라우저 또는 클라이언트 머신에서 Kerberos 라이브러리 누락#
마지막으로 브라우저 또는 클라이언트 머신에 Kerberos 지원이 전혀 없을 수 있습니다. Kerberos 라이브러리가 설치되어 있고 다른 Kerberos 서비스에 인증할 수 있는지 확인합니다.
클론 시 HTTP Basic: Access denied#
remote: HTTP Basic: Access denied
fatal: Authentication failed for ''
Git v2.11 이상을 사용하고 클론 시 이전 오류가 표시되는 경우 http.emptyAuth Git 옵션을 true로 설정하여 해결할 수 있습니다:
git config --global http.emptyAuth true
프록시된 HTTPS를 통한 Kerberos Git 클론#
다음의 경우 아래를 주석 처리해야 합니다:
- KRB5 Git Cloning 옵션에서
https://URL이 예상되는데http://URL이 표시될 때. - HTTPS가 GitLab 인스턴스에서 직접 종료되지 않고 로드 밸런서 또는 로컬 트래픽 매니저에 의해 프록시될 때.
# gitlab_rails['kerberos_https'] = false
참고: Git v2.11 릴리스 노트