KRB5KDC_ERR_PREAUTH_REQUIRED とは
ドメイン参加した PC での PC 起動シーケンスやユーザログオンシーケンスでパケットキャプチャを取得すると、デフォルト設定では最初の AS-REQ の後に以下のエラー (キャプチャ赤枠) が表示されます。
ですが、その直後に TCP コネクションが閉じ、別の TCP コネクションを確立し、2回目の AS-REQ の後には AS-REP が返ってきている (キャプチャ緑枠) のが分かります。
結論から言うと、これが表示されているのは健全である証拠です。これは Kerberos の事前認証を求めるパケットです。
アカウントの事前認証 (PREAUTH) が無効の場合、AS-REQ の後に AS-REP にて「TGT (このチケットの中に暗号化されたセッションキーが含まれる)」を受け取れてしまいます。暗号化されているとは言え、受け取ったらオフラインでブルートフォースやハイブリッド攻撃などを行うことが出来てしまうため、セキュアではありません。
事前認証を有効にすることで、TGT を渡す前に認証が行われるため、セキュアです。
事前認証の対象はユーザアカウントだけではなく、コンピュータアカウントも含まれます。つまり、PC 起動シーケンスにおいては「コンピュータアカウント」の事前認証が行われ、その次のユーザログオンシーケンスでは「ユーザアカウント」の事前認証を求めています。
事前認証と AS-REQ と AS-REP の構造
事前認証は ERR_PREAUTH_REQUIRED に含まれる timestamp をアカウントのパスワードハッシュで暗号化し、することで認証を行います。(一定時間を過ぎると無効)
AS-REQ パケットは以下の構造になっています。このパケットは 2 回目の (事前認証情報にあたる [pA-ENC-TIMESTAMP] が含まれる) AS-REQ ですが、1 回目の AS-REQ はこの部分 (青枠) がありません。
続いて、PREAUTH REQUIRED のエラーパケットは以下の通りです。stime が通常の timestamp で、susec はマイクロ sec 単位の timestamp になります。また、etype で暗号化方式候補を示し、salt も示されています。
最後に AS-REP のパケットは以下の通りです。チケットが暗号化されて渡っているのが分かります。
事前認証の無効化
ユーザアカウントにおいて事前認証を無効化する場合は、「AD ユーザーとコンピュータ」管理ツールで対象ユーザアカウントの「アカウント」タブにて「Kerberos 事前認証を必要としない」にチェックを入れます。
ただし、コンピュータアカウントにおける事前認証については、設定変更は出来なそうです。
事前認証失敗の原因
上記のエラーがイベントログに表示された場合、原因としては以下が考えられます。
- (ユーザーアカウントの事前認証の場合) ID パスワードの入力間違い
- (コンピュータアカウントの事前認証の場合) コンピュータアカウントのパスワード不一致 (セキュアチャネル破損と同じで、snapshot 戻しやリストアによるパスワード巻き戻りやコンピュータ名の重複, 等)
- 時刻同期ができていない
- サーバから提示された etype がクライアント側でサポートされていない
最後に
Kerberos 認証の全体については以下を参照ください。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント