GitLab과 Kerberos 통합의 Troubleshooting


Tier: Free, Premium, Ultimate
Offering: Self-Managed

GitLab과 Kerberos 통합 작업 시 다음 문제가 발생할 수 있습니다.

윈도우즈 AD에서 Kerberos 인증을 사용하여 Google Chrome을 사용하는 경우

Google Chrome을 사용하여 Kerberos로 GitLab에 로그인할 때는 전체 사용자 이름을 입력해야 합니다. 예를 들어, 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 서버 간의 연결 테스트

GitLab 서버와 Kerberos 서버 간의 연결을 테스트하기 위해 kinit 및 klist와 같은 유틸리티를 사용할 수 있습니다. 이들을 설치하는 방법은 특정 OS에 따라 다릅니다.

klist를 사용하여 keytab 파일에 있는 서비스 주체 이름(SP)과 각 SP에 대한 암호화 유형을 확인할 수 있습니다. 

klist -ke /etc/http.keytab

우분투 서버에서의 출력 예시는 다음과 유사할 것입니다. 

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)

GitLab이 keytab 파일을 사용하여 Kerberos 서버에 연결할 수 있는지를 테스트하기 위해 상세 모드의 kinit을 사용할 수 있습니다. 

KRB5_TRACE=/dev/stdout kinit -kt /etc/http.keytab HTTP/my.gitlab.domain@MY.REALM

이 명령은 인증 프로세스의 상세한 출력을 보여줍니다.

지원되지 않는 GSSAPI 메커니즘

Kerberos SPNEGO 인증에서 브라우저는 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 서버 간의 연결 부재

브라우저가 Kerberos 서버에 직접 연락할 수 없는 경우에 나타납니다. 이 경우 브라우저는 <IAKERB>라는 지원되지 않는 메커니즘으로 되돌아갑니다. 이것은 GitLab 서버를 Kerberos 서버에 중계하는 시도입니다.

만약 이 오류가 발생한다면, 클라이언트 기계와 Kerberos 서버 간의 연결이 있는지 확인하십시오. 이것은 사전 조건입니다! 트래픽이 방화벽에 의해 차단될 수도 있고 DNS 레코드가 올바르지 않을 수도 있습니다.

GitLab DNS 레코드가 CNAME 레코드 오류

GitLab이 CNAME 레코드로 참조될 때 Kerberos는 이 오류로 실패합니다. 이 문제를 해결하려면 GitLab의 DNS 레코드가 A 레코드인지 확인하십시오.

GitLab 인스턴스 호스트명에 대한 순방향 및 역방향 DNS 레코드 불일치

GitLab 서버의 순방향 및 역방향 DNS 레코드가 일치하지 않는 경우 또 다른 실패 모드가 발생합니다. Windows 클라이언트는 정상적으로 작동하는 반면 리눅스 클라이언트는 실패합니다. 리눅스 클라이언트는 Kerberos 영역을 검출하는 동안 역방향 DNS를 사용합니다. 올바르지 않은 영역을 받으면 보통의 Kerberos 메커니즘이 실패하기 때문에 클라이언트는 IAKERB를 시도하게 되어 위의 오류 메시지가 발생합니다.

이를 해결하려면 GitLab 서버의 순방향 및 역방향 DNS가 일치하는지 확인하십시오. 예를 들어, gitlab.example.com으로 GitLab에 접근한다면, 2.2.0.10.in-addr.arpa는 gitlab.example.com의 PTR 레코드여야 합니다.

브라우저나 클라이언트 기계에 Kerberos 라이브러리가 없음

마지막으로, 브라우저나 클라이언트 기계에 Kerberos 지원이 없을 수 있습니다. Kerberos 라이브러리가 설치되어 있고 다른 Kerberos 서비스에 인증할 수 있는지 확인하십시오.

클론 시 HTTP 기본: 액세스 거부 

remote: HTTP Basic: Access denied
fatal: Authentication failed for '<KRB5 path>'

클론할 때 위의 오류가 표시되면 Git v2.11 이상을 사용 중이고 다음 설정을 통해 이 문제를 해결할 수 있습니다. 

git config --global http.emptyAuth true

Kerberos를 사용하여 프록시 HTTPS를 통한 Git 클론

다음과 같은 경우에는 다음을 주석 처리해야 합니다.

  • https:// URL이 예상되는데 http:// URL이 KRB5 Git 클론 옵션에서 보일 때
  • HTTPS가 GitLab 인스턴스에서 종료되지 않고 로드 밸런서나 로컬 트래픽 관리자에 의해 프록시되는 경우 
# gitlab_rails['kerberos_https'] = false

참고 자료: