＃医者に痛風って言われちゃった...テヘッ
ここ5日間、このささいなトラブルに悩まされていました。おかげでとあるドキュメントの提出期限を大幅に過ごしてしまいました...。大阪の F さん、本当にごめんなさい...。これから即行で手を付けます....。
で、きっと同じ経験を今後される方もいらっしゃると思うので、とりあえずの回避策について投稿しておきたいと思います。
以下のような環境を構築しているとしましょう。
上記のような環境で、オンプレミスの Active Directory ドメインにログオンした状態で Windows Azure 上のアプリケーションにアクセスすると、再びログオンすることなくアプリケーションの画面を表示することができます。なぜならば、ADFS サーバーは既定で統合認証が行えるように構成されているからです。つまり、既に Active Directory ドメインにログオンした状態であれば、ADFSサーバーからセキュリティトークンを発行してもらうために再び認証を受ける必要がありません。結果、オンプレミスとクラウドアプリケーションのシングルサインオン（SSO）が可能です。
しかし、サクッとテスト環境を作って試してみたところ、なぜか以下のようにログオンボックスが表示されることがあります。
もちろん、正しいユーザーIDとパスワードを入力すればアプリケーションにアクセスすることは可能です。ログオンボックスで間違えた情報を入力したり、「キャンセル」をクリックすると以下のメッセージが表示されます。明らかに ADFS が出力していることがわかります。
この問題が発生したということは、Active Directory や ADFS 自体は正しく動作しているにもかかわらず、統合認証（既存のクレデンシャルの引き継ぎ）の部分だけがうまく機能していないということです。
このときに疑うポイントは主に以下の4つです。
ADFS 構築でよく目にするのが 2 番目の SPN の問題です。
しかし、ADFS を スタンドアロンで構成した場合、サービスアカウントとして NetworkService が使用され、SPN も自動構成されるため、この問題には該当しないことが多いはずです。じゃ、1番目や3番目かといえば、「そんな複雑な構成なんかしてないよ！」というのが正直なところかと思います。
そこで疑っていただきたいのが、4番目の「イントラネットゾーン」です。SharePoint をよくご存知のエンジニアの方は、「ゾーン」を意識することが多いと思います（逆に私はあまり使わないので苦手だったりしますが...）。
Internet Explorer では、[セキュリティ]タブに用意された各ゾーンごとに、それぞれのゾーン内のセキュリティ上の動作を定義することができます。[レベルのカスタマイズ]をクリックすると、セキュリティ設定画面が表示され、一番下のほうに[ユーザー認証]に関する設定項目が用意されています。
既定では、「現在のユーザー名とパスワードで自動的にログオンする」がチェックされています。つまり、アクセスしようとしているサイト（今回の場合には ADFS サーバー）がイントラネットゾーンに存在している場合に限って、現在のクレデンシャルを使用したシングルサインオンを有効にする...ということになります。
これを踏まえると、ここで説明しているような「なぜかログオンボックスが表示されてしまう」という現象は、ADFSサーバーがイントラネット上に無いと判断されてしまっていることに起因します。判断しているのは IE です。
でも不満が残りますよね。「明らかにイントラじゃん！」と叫びたいくらいです。
そんな怒りをおさえつつ KB を検索してみると、以下のようなドキュメントが見つかります。
FQDN または IP アドレスを使用すると、イントラネット サイトがインターネット サイトとして識別される http://support.microsoft.com/kb/303650/
うむむむ...なんてことでしょう。私が構築したテスト環境だと、50%程度の確率でこの現象が発生しています...「FQDN が正しくイントラネットとして識別される条件」については調査を継続したいと思います...。
ひとまず、回避策としては IEの「ローカルイントラネット」ゾーンに、ADFS の FQDN を以下のように追記します。
この設定はグループポリシーに組み込むこともできるので、ドメイン配下のすべてのクライアントに自動設定することも可能です。
逆に言えば...複数のユーザーでログオンしなおしてクレームの状態を確かめたり...デモンストレーションのためにログオンしなおす時間があまり取れない場合なんかは、あえてイントラネットゾーンから外しておく...なんてこともできるわけですねぇ。