まず、ここでまだ混乱している場合は、謝罪してください。Kerberos認証は、Java devの複雑な問題です。
それで、私は次のシナリオを持っています:
アクセスにkerberos
事前認証を使用し、サブセクションにLDAP
プロファイル認証を使用する一連のウェブアプリ
AWS
にWindows Server
があり、必要なすべてのグループのメンバーである管理者ユーザーのフォレスト(通常、EXAMPLE.COM)があります。関連するすべてのポートが開いていてアクセス可能であり、Spring LDAP
を使用してユーザー名で検索すると、正常に機能します
私が働いている会社には独自のADがあり、私のPCはこのADに属しているので、技術的には2つのADを処理していますが、CORP ADにアクセスできません。ただし、AWS
のWindows Server AD
に、同じユーザー名、パスワード、必要なすべてのグループのメンバーを持つユーザーを追加しましたJFI
これをテストするためにローカルPCでアプリを起動すると問題が発生します。この post で述べたようにFirefoxを設定しましたが、ブラウザ(localhost:port)経由でアプリにアクセスしようとすると、Negotiate
ヘッダーに認証用のチケットが含まれません
ここで役立つコードがあるかどうかわからないが、スニペットを共有したり、それが役立つ場合はチャットを開始したりする
KerberosやWindowsドメインについて誤解しているようです。
まず、ブラウザはKerberosチケットを生成しません。ドメインコントローラは生成します。ほとんどの場合、ブラウザはローカルセキュリティ機関(LSASS)に要求します。 Kerberosを機能させるには、認証と信頼がAD環境でどのように機能するかを理解する必要があります。
ローカルADのユーザーは、クラウドADのユーザーとは完全に別であり、彼らは互いにまったく関係がありません。過去に同じユーザー/パスを使用してWindowsマシン間で認証できたという事実は、Kerberosでは機能しないレガシーなものです。
クロスドメインKerberos認証の場合、Active Directoryの信頼を確立する必要があります。これが一方向の信頼か双方向の信頼かは、すべてのアプリケーションでどのユーザーがどのリソースにアクセスしているかによって異なります。それを整理するには、ADチームに相談する必要があります。信頼構成はドメイン全体に適用されます。
Negotiateヘッダーがないことは、Kerberosがまだ始まっていないことを示唆しています。そのためには、クライアントがリモートホストのサービスプリンシパル名(SPN)を構築および検証できる必要があります。それが行われると、認証のためにリモートホストに渡すサービスチケットを要求できます。
SPNはKerberos機能であるため、独自のドメイン/レルムまたは信頼するドメイン/レルムの一部ではないホストのSPNを検証することは不可能です。 信頼が設定されると、SPN検証はシームレスになります(1)DNSが適切に設定され、(2)サーバーがActive Directoryで公開された正しいSPNを持っている場合。