標準の IIS サーバーに展開されるカスタムのコンパイル済み .net 4.0 dll ライブラリを開発しました。このライブラリは、ベンダーが作成したアプリケーションである Spotfire Web Player によって使用されます。このアプリケーションは、IIS サーバー上の独自のアプリケーション プールで実行されます。プラグインは、Web 要求を介してデータを取得する目的で、Tomcat を実行している別のサーバーに接続します。この要求を行うために、プラグインは、ネゴシエート セキュリティを使用して認証トークンを生成し、それを base64 文字列に変換して、パス スルー認証を容易にするために他のサーバーに渡します。IIS のアプリケーション レベルでは、Spotfire Web Player アプリケーションは Windows 認証を使用するように構成されており、さらに Windows 認証のプロバイダーでは、ネゴシエートを指定しています。Kerberos が唯一の認証方法であり、詳細設定でカーネル モード認証を無効にする (NTLM を削除するときに必要)。これは、NTLM ダブル ホップの制限を克服するために行われたものであり、これが問題である可能性があると考えられていました。アプリケーション プールは、標準の .net 4.0 統合パイプライン プールであり、システムの NetworkService アカウントで実行されます。
セキュリティの問題または IIS 構成が適切な認証方法に干渉していることを示すいくつかのシナリオを次に示します。
障害シナリオ (ダブル ホップ)
状態
• サーバーは上記のように実行されており、リモートまたは対話的にログインしているユーザーはいません。
アクション
• リモート ラップトップのユーザーが Internet Explorer ブラウザを開き、プラグインを利用するドキュメントを開こうとします。
結果
• 認証失敗の結果。
機能シナリオ (シングル ホップ)
状態
• サーバーは、リモート デスクトップ経由でログインした管理者によって上記のように実行されています。
アクション• 管理者はサーバー セッションで Internet Explorer
を開き、プラグインを利用するドキュメントを開くことに進みます
。管理者の資格情報が Zema サーバーに正常に渡され、認証されました。
機能シナリオ (ダブル ホップ)の
状態
• サーバーは上記のように実行されており、管理者はリモート デスクトップ経由でログインしており、管理者はプラグインを利用して認証に成功したドキュメントを (リモート デスクトップの IE 経由で) 正常に開いています。
アクション
• ラップトップから chrome または IE の他の標準ユーザーが、プラグインを使用するドキュメントを開こうとします。
結果
• すべてのユーザーが認証されます。ドキュメントが最初にサーバー自体で開かれた後でのみ。
機能シナリオ (シングル ホップ)の
状態
• 上記の IIS サーバーとは異なり、このプラグインは、ユーザーのローカル ラップトップで実行されるクライアント側の .net アプリケーションでも利用できます。このデスクトップ アプリケーション (Spotfire アナリスト ソフトウェア) で使用されるものとまったく同じ DLL ライブラリが IIS で使用されます。
アクション
• ユーザーは、プラグインを使用するラップトップでドキュメントを開きます。
結果
• このシナリオでは、ユーザーのラップトップはプラグインを実行し、認証トークンを生成して、Zema サーバーに直接送信します。IIS サーバーはまったく写っていません。このシナリオでは、常に認証が成功します。
ありがとう！