Apache サーバーを Kerberize し、作成されたサーバー プリンシパルが Active Directory にサインオンできるようにしようとしています。オンラインで利用できる多数のチュートリアルの 1 つに従いましたが、問題なく動作するようです。私はプロジェクトの Linux 側におり、企業の IT 部門は Windows 側にいます。
IT部門からサービスアカウントとサービスプリンシパルが提供されました。この例では、HTTP/[メールアドレス]彼らは、AD サーバー上で ktpass.exe というツールを実行することを含む、上記のプリンシパルのキータブ ファイルを私に提供しました。
AD/KDC の KVNO とキータブ ファイルが一致することを確認しました。すべて正常です。
ホスト名には適切な DNS A レコードがあり、IP には適切な PTR レコードがあります。両方のサーバーは時刻同期されています。
次のように、発行されたキータブ ファイルを使用して、上記のサービス プリンシパルのチケットを AD/KDC に要求できます。
kinit -k -t http.keytab HTTP/[email protected]
これはうまくいきます。チケットを取得し、このチケットを使用して AD/LDAP ディレクトリのクエリなどを行うことができます。キータブは、この演習の目的の一部であるシングル サインオン Apache サイトの実行にも最適です。
30分が経過します。
上記の kinit コマンドを使用してログオンしようとすると、次のメッセージが表示されて失敗します。
Client not found in Kerberos database
AD サーバー上でプリンシパルが削除された場合と同様に、サービス プリンシパルとして認証できません。
さて、少なくとも私にとっては奇妙なことになってきます。
要求に応じて、AD 管理者は ktpass.exe ツールを再度実行し、サービス用の新しいキータブ ファイルを作成します。サーバー上の KVNO (キー バージョン番号) が増加し、Apache テスト サーバーが Kerberos シングル サインオンの検証を停止します。これは、現在の構成では想定どおりです。私たち全員が驚いたのは、kinit コマンドが再び機能したことです。さらに 30 分を稼いだ後、再び機能しなくなりました。
弊社の IT 部門は困惑しており、これは AD サーバー自体の問題ではないかと推測しています。私は設定の問題だと考えていますが、IT 部門によると、設定のどこにも 30 分制限はないそうです。
私はフォローしましたhttp://www.grolmsnet.de/kerbtut/(セクション 7 を参照) ただし、この方法は私が見つけたすべてのドキュメントで同じであるようです。サービス プリンシパルの時間制限に関する参照は見つかりませんでした。
編集: これはレプリケーションの問題のようです。レプリケーション プロセスでエラーは報告されませんが、サービス アカウントの SPN 値が「HTTP/[メールアドレス]" に "[メールアドレス]" 30分後。
答え1
皆さん、ご意見をありがとうございました。Microsoft の協力を得て、AD 側での認証プロセスのデバッグを手伝ってもらいました。すべては想定どおりに機能しましたが、30 分後に失敗しました。
リモートデバッグセッション中に、参加者の1人がサービスアカウントのUPN/SPNが突然リセットされたことに気付きました。HTTP/[メールアドレス]に[メールアドレス]AD レプリケーションのデバッグを含め、徹底的に調査した結果、原因がわかりました。
誰かが定期的に（またはおそらくイベントによって、ktpass.exeの実行からちょうど30分後に）実行されるスクリプトを作成し、UPN/PSNを次のように更新しました。「クラウド接続を確保する」これを行う理由に関する補足情報はありません。
スクリプトは、既存のUPN/SPN値を許可するように変更されました。メールアドレス、問題を効果的に解決します。
次のような問題をデバッグするためのヒント:
- 認証に参加するすべての人が同じ暗号化タイプをサポートしていることを確認します。DES は時代遅れで安全ではないため使用しないでください。
- サービスアカウントでAES-128とAES-256暗号化を有効にしてください
- サービスアカウントでDESを有効にすると、「このアカウントには DES のみを使用してください」AES暗号化を有効にした場合でも、UF_USE_DES_KEY_ONLY詳細についてはこちらをご覧ください。
- UPN/SPN 値が正しいこと、発行されたキータブ ファイルの値と一致していることを確認します (つまり、LDAP ルックアップを通じて)
- キータブファイル内のKVNO（キーバージョン番号）がサーバー上のものと一致することを確認してください。
- サーバーとクライアント間のトラフィックを検査する（tcpdump や WireShark を使用）
- AD側での認証のデバッグを有効にする - ログを検査する
- AD側でのレプリケーションのデバッグを有効にする - ログを検査する
改めて、ご意見をいただきありがとうございます。
答え2
私も、Achim Grolms のチュートリアルから Kerberos を学びました。これはmod_auth_kerb本当に優れたドキュメントです。
このkeytabファイルはパスワード認証のみを置き換えます。パスワードはファイル内にエンコードされ、これらのバイトは KDC による認証チャレンジで使用されます。サービス アカウントのパスワードを変更すると、キータブ認証が無効になり、kvno 番号も増加します。
サービス アカウント SPN が使用可能であることを確認するために、サービス アカウント パスワードを使用して認証することがよくあります。
kinit HTTP/[email protected]
失敗した場合は、サービス アカウントが無効になっていないことを確認するために、基本認証を試してください。
kinit account
認証に失敗した場合は、アカウントを削除し、別のログイン名で新しいアカウントを作成してトラブルを回避してください。
別のソフトウェア (たとえば、同じ SPN に対して生成された古いキータブを持つ別のシステム) がこのサービス アカウントで認証を試み、無効なパスワードのためにアカウントを無効にする可能性が高くなります。
Kerberos SSO を設定する場合、操作が速すぎると Active Directory に不整合が生じる可能性があります。構成プロセスで行き詰まったときの一般的なガイドラインは、次の手順に従うことです。
- テストおよび本番システムの「古い」または「失敗した」サービス アカウントを削除します。
kvno構成しようとしているSPNがレルム内に存在しないことを確認してくださいsetspn -X複数のアカウントで競合するSPNがないことを確認してください- システムごとに、単一の完全修飾SPN専用のサービスアカウントを1つ作成し、新しいログイン名を設定します。
- サービスアカウントのパスワード変更とパスワードの有効期限切れを防ぐ
- DC同期までしばらくお待ちください
ktpassキータブを生成するときにオプションとしてパスワードを設定する- FQDN SPNとエイリアスを確認する
setspn -l account
DC 上でサービス アカウントを構成するためのコマンドのセットを次に示します。
ktpass -princ HTTP/[email protected] -mapuser [email protected]
-crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL
-pass long!$longp2ass3word -out c:\temp\http-mysite-mycorp-com.keytab
setspn -a HTTP/mysite mysiteAccount
setspn -l mysiteAccount
MMC と、管理コマンド ラインでキータブを生成するための ktpass の実行との間で、異なる DC での操作が速すぎると、DC の同期によって、説明されているような予期しない結果が発生する可能性があります。そのため、アカウントの作成とktpass追加のsetspnコマンドの間にしばらく待機しましょう。
すべてが正しく動作するかどうかを確認するために Linux 上で実行するコマンドは次のとおりです。
kinit [email protected]
kinit HTTP/[email protected]
kinit -k -t http-mysite-mycorp-com.keytab HTTP/[email protected]
kvno HTTP/mysite.mycorp.com
kvno HTTP/mysite