GitLabとKerberosの連携のトラブルシューティング

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

KerberosインテグレーションでGitLabを使用する場合、次の問題が発生する可能性があります。

Windows 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サーバー間の接続をテストする

ユーティリティ（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がキータブファイルを使用して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継続的インテグレーション/継続的デリバリーは、Kerberos対応のGitLabインスタンスでは機能しません。

クライアントマシンとKerberosサーバー間の接続不足

これは通常、ブラウザがKerberosサーバーに直接接続できない場合に発生します。サポートされていないメカニズム（IAKERB）にフォールバックします。これは、Kerberosサーバーへの仲介役としてGitLabサーバーを使用しようとします。

このエラーが発生している場合は、クライアントマシンとKerberosサーバーの間に接続があることを確認してください。これは前提条件です。トラフィックはファイアウォールによってブロックされるか、DNSレコードが正しくない可能性があります。

エラー: `GitLab DNS record is a CNAME record`

GitLabがCNAMEレコードで参照されている場合、Kerberosは次のエラーで失敗します。この問題を解決するには、GitLabのDNSレコードがAレコードであることを確認してください。

GitLabインスタンスのホスト名のフォワードDNSレコードとリバースDNSレコードが一致しません

別の失敗モードは、GitLabサーバーのフォワードDNSレコードとリバースDNSレコードが一致しない場合に発生します。多くの場合、Windowsクライアントはこの場合に機能しますが、Linuxクライアントは失敗します。Kerberosレルムを検出する際に、リバースドメインネームシステムを使用します。間違ったレルムを取得すると、通常のKerberosメカニズムが失敗するため、クライアントはIAKERBのネゴシエートを試行することにフォールバックし、以前の認証エラーメッセージが表示されます。

これを修正するには、GitLabサーバーのフォワードドメインネームシステムとリバースドメインネームシステムが一致することを確認してください。たとえば、GitLabにgitlab.example.comとしてアクセスし、IPアドレス10.0.2.2に解決する場合、2.2.0.10.in-addr.arpaはgitlab.example.comのPTRレコードである必要があります。

ブラウザまたはクライアントマシンにKerberosライブラリがありません

最後に、ブラウザまたはクライアントマシンにKerberosサポートがまったくない可能性があります。Kerberosライブラリがインストールされていること、および他のKerberosサービスに対して認証できることを確認してください。

HTTP Basic: クローン作成時にアクセスが拒否されました

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

Git v2.11以降を使用している場合にクローン作成時に上記のエラーが表示される場合は、http.emptyAuth Gitオプションをtrueに設定して、これを修正できます:

git config --global http.emptyAuth true

プロキシHTTPS経由でのKerberosを使用したGitクローン作成

以下に該当する場合は、コメントする必要があります:

http://URLがKRB5 Gitクローン作成でクローンオプションに表示される場合に、https://URLが予期されます。
HTTPSはGitLabインスタンスで終了しませんが、代わりにロードバランサーまたはローカルトラフィックマネージャーによってプロキシされます。

# gitlab_rails['kerberos_https'] = false

こちらも参照してください: Git v2.11リリースノート