2
このKerberos / ADセットアップは可能ですか？
少し複雑なIDAM設定があります。 つまり、エンドユーザーのマシンとブラウザは親ADのあるネットワークにあり、Jettyベースのアプリケーションとそれが通信できるAD（ローカルAD）は別のネットワークにあります。 2つのADの間には双方向の信頼があります。親ネットワークのブラウザは、信頼済みサイトにローカルドメインを持っています。 Jettyサーバーの設定は次のとおりです。 ローカルADのプリンシパルに対して生成されたキータブファイルを使用する ローカルADで定義されたユーザーの下でWindowsサービスとして実行されている レルム、ドメイン-レルムマッピング、およびkdcは、ローカルADのドメインに対して定義されます それはspnegoを使用します-isInitiatorはfalseに設定されます。doNotPromptはtrueです。storeKeyはtrueです 問題は： テストとして、（すなわちローカルADにリンクされている）、ローカルネットワーク内のブラウザからサーバーにアクセスすると動作します私は、HTTPトラフィックに正しいKerberosのネゴシエーションを見ることができ、Kerberosのデバッグ情報がログに表示され、ユーザーは自動的に署名されています- 。鮮やかさ。 ただし、親ネットワーク内のブラウザーからサーバーにアクセスする（これは、ユーザーが操作する方法です）ことができません。ブラウザは401 unauthを取得しますが、資格情報を要求します。資格情報を入力すると、空白の画面が表示されます。次に、アドレスバーをクリックしてEnterキーを押すと、資格情報がリモートADとローカルADのどちらであるかに応じて、次のいずれかが行われます。 ローカルADの資格情報は、ログに最初からKerberosを使用して正常にログインします（GET要求、401非認証応答、Kerberosヘッダー要求など） リモートADの資格情報がログインしていない（GETリクエスト、401 UNAUTH応答は、何がNTLMヘッダーのようになります。Authorization: Negotiate <60 or so random chars>） いずれにせよ、それが促しているという事実は間違っています！ これらの症状の説明はありますか？私たちが持っているセットアップは私たちが望むことをすることができますか？ 上記の説明については何が間違っている可能性があるかについては、私が行ったように、Jettyサーバーに関して述べた構成はすべて正確である必要があります。詳細をお知らせいたします。ADまたは親ネットワークブラウザーのいずれかに関する構成は疑わしい可能性があります。これは、私の制御下になく、自分で確認するのではなく、報告された構成を持っているためです。