IDAMのセットアップは少し複雑です。
つまりエンドユーザーのマシンとブラウザーは親ADと1つのネットワークに配置され、Jettyベースのアプリケーションとそれが通信できるAD(ローカルAD)はもう1つのネットワークに配置されます。
2つのADの間には双方向の信頼があります。親ネットワークのブラウザには、信頼済みサイトのローカルドメインがあります。
Jettyサーバーのセットアップは次のとおりです。
問題は:
ただし、親ネットワーク内のブラウザーからサーバーにアクセスすることはできません(これはユーザーが行う方法です)。ブラウザは401unauthを取得しますが、資格情報の入力を求めます。資格情報を入力すると、空白の画面が表示されます。次に、アドレスバーをクリックしてEnterキーを押すと、資格情報がリモートAD用かローカルAD用かによって、次の2つのいずれかが実行されます。
Authorization: Negotiate <60 or so random chars>
)いずれにせよ、それがプロンプトを出しているという事実は間違っています!
これらの症状の説明はありますか?私たちが持っているセットアップは私たちが望むことをすることができますか?
上記の説明が間違っている可能性があるという点で、Jettyサーバーに関して私が言及した構成は、私が行ったように正確である必要があります。詳細をお知らせします。 ADまたは親ネットワークブラウザのいずれかに関する設定は、私の管理下になく、自分で確認するのではなく、設定を報告してきたため、疑わしい可能性があります。
パケットキャプチャが表示されない場合は、HTTP/www.website.comSPNをアプリケーションを実行しているアカウントに登録する必要があると思います。 Microsoftのディレクトリサービスチームには、このトピックに対処する優れたマルチパート投稿が次のURLにあります。
各環境のクライアントからパケットキャプチャ(netmon、wireshark)を実行して、検索されているSPNを特定します。それが決まったら、setspncmdを使用して、アプリケーションを実行しているアカウントに登録します。
FWIW、KerberosはLAN上でのみ機能します。ドメインコントローラーにアクセスできない場所で誰かがアクセスする必要がある場合は、ShibbolethやADFSなどのSSOを検討することをお勧めします。
編集: @ alex-h で述べたように、ブラウザはKerberosを介してサイレント認証するように構成する必要があります。
最後に、これはMicrosoftSharepointの展開に共通する問題です。ユーザーがドメインに対して認証されると、Kerberosを介したSSOがサイレントに実行されることを望んでいます。したがって、上記の回答で問題が解決しない場合は、次のようなフォーラムを確認してみてください。
NTLMが有効になっていないブラウザ(Chrome/Firefox)から1番目を試してください。事前認証が有効になっていることが問題のようであり、双方向の信頼が確立されていない可能性があります。
事前認証については、こちらをご覧ください https://support.Microsoft.com/en-us/kb/2749007 およびこちら https://hc.Apache.org/httpcomponents- client-ga/tutorial/html/authentication.html 。