IEのゾーンと統合認証

今回はInternet Explorerの「ゾーン」と統合認証についての話です。 IEのゾーンとは IEの「ゾーン」とはセキュリティを高めるためにある仕組みで、信頼できるサイトでは、色々なことを許可し、信頼できないサイトでは極力できることを絞る・・・ということを自動的に行ってくれる仕組みです。 IEを立ち上げて、ウインドウ右下の「ゾーン」を確認してみましょう。以下はIE7でYahoo! Japanを表示したところですが、「インターネットゾーン」として認識されています。 このようにインターネット上のサイトは「インターネットゾーン」にあるものとして扱われ、できることを比較的絞った状態になっています。例えば未署名のActiveXコントロールはダウンロードできません。 ゾーンとしては以下の種類があります。 - インターネット - ローカルイントラネット - 信頼済みサイト - 制限つきサイト ぞれぞれのゾーンのレベルのカスタマイズ(できること、できないことを設定すること)は「ツール」→「インターネットオプション」→「セキュリティ」タブから行えます。 IEのシングルサインオン で、このゾーンの設定の中にシングルサインオンの設定があり、ゾーンの判定とあいまってなかなかわかりづらい挙動をしてくれます。今回はそこをお伝えしたいのです。 良くあるのが、Active Directory環境下で - IISでWebサイトを構築していてWindows統合認証に設定しているのに、アクセスするとIDとパスワードを求められてしまう - でも、IDとパスワードを求められないケース(端末、ユーザー)もある という問題です。 これは実は、セキュリティレベルの設定と、ゾーンの判定によって起こされています。 まず重要なのはそれぞれのゾーンにある、「ユーザー認証」の設定です。 規定の状態では、どのゾーンに関しても「イントラネットゾーンでのみ自動的にログオンする」という設定になっています。 なので、 - イントラネットゾーンであればWindows統合認証を使って、ドメインにログオンしているユーザーならそのIDで自動的にWebサイトにログオンする - イントラネットゾーン以外のゾーンではIDとパスワードを聞かれる という挙動になります。 どのサイトがどのゾーンに含まれるのか では、どのサイトがどのゾーンに含まれるのでしょうか?それは以下のようなルールになっています。 - 信頼済みサイト - 明示的にユーザーがアドレスを追加したサイト。 - 制限付きサイト - 明示的にユーザーがアドレスを追加したサイト。 - ローカルイントラネット - 自動判定。 - 明示的にユーザーがアドレスを追加することもできる。 - インターネット - 信頼済みサイト、制限付きサイトに含まれておらず、ローカルイントラネットと、自動判定されなかったサイト。 つまり、ローカルイントラネットの自動判定ロジックが肝になります。 ローカルイントラネットの判定基準 今回の話の一番重要なところです。ローカルイントラネットの判定基準は、規定の状態では - URLに.(ドット)が含まれるかどうか が判断基準になっています。URLに.(ドット)が含まれればそれはローカルイントラネットではなく、URLに.(ドット)が含まれなければそれはローカルイントラネットなのです。 ...

March 12, 2009 · 1 min · 胡田昌彦

「イントラネットに繋がらない」 - ドメインサフィックス&Proxy編

今回は「インターネット」ではなくて、「イントラネット」に繋がらないというケースについて書いてみます。 今、Active Directoryで構成されたWindowsネットワーク(ドメイン名sample.lcoal)があるとして、そこにintraという名前のメンバサーバーがあり、そこでイントラサイトが稼働しているとしましょう。このときのURLは何になるでしょうか? - http://intra/ - http://intra.sample.local/ さて、どちらが正解でしょうか? 正解は、「どちらも正解」です。 「なんだ、それは」と思うかもしれませんが、これがなかなか奥深い話もあったりします。たとえば1のhttp://intra/というアドレスを使っている場合。クライアントの設定によってはつながったりつながらなかったりします。繋がる場合でも、名前解決の方法が異なったりします。ちょっと詳しく見てみましょう。 名前解決の手段は何か? まず、http://intra/というURLですが、実際にはintraというホストのIPアドレスを知らなくてはいけません。最終的にはTCP/IPで接続するわけですから。 名前解決の手段としては様々なものがある、という話は以前しました。 - 参考:[NETBIOS名とホスト名の違い](https://windowsadmin.ebisuda.net/2009/02/10/netbios%e5%90%8d%e3%81%a8%e3%83%9b%e3%82%b9%e3%83%88%e5%90%8d%e3%81%ae%e9%81%95%e3%81%84/) この場合intraを名前解決する方法は以下のパターンがあるわけです。 - hostsファイル(ホスト名) - DNS(ホスト名) - lmhostsファイル(NETBIOS名) - WINS(NETBIOS名) - ブロードキャスト(NETBIOS名) で、厄介なのが2に関してです。 ドメインサフィックス DNSとして考えたときに「intra.」なんていうホスト名はあり得ないわけです。本来は「intra.sample.local」です。なので「intra」を裏で「intra.sample.local」に変更してくれている仕組みが存在するわけです。 マイネットワーク→プロパティ→(対象NIC)→プロパティ→インターネットプロトコル(TCP/IP)→プロパティ→詳細設定→DNSタブ (なんてわかりづらい所にあるんでしょう…) - 「プライマリおよび接続専用のDNSサフィックスを追加する」 - 「プライマリDNSサフィックスの親サフィックスを追加する」 - 「以下のDNSサフィックスを順に追加する」 - 「この接続のDNSサフィックス」 そしてもう一か所あります。 マイコンピュータ→プロパティ→コンピュータ名タブ→変更→詳細 (なんてわかりづらい所にあるんでしょう…) - 「このコンピューターのプライマリDNSサフィックス」 - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」 これらの設定が"仕組み"になります。 勝手にドメインサフィックスが追加される理由 通常は以下のような流れで、勝手に適切なドメインサフィックスが追加されるようになっています。 - Active Directoryに参加する - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」が既定で有効であるため、ドメイン名(sample.local)が「このコンピューターのプライマリDNSサフィックス」として設定される - DNSを使った「intra」の名前解決の際に「プライマリおよび接続専用のDNSサフィックスを追加する」および「プライマリDNSサフィックスの親サフィックスを追加する」が有効であるので「intra.」だけではなくて「intra.sample.local」も検索される うまくいかないケース ここまでの説明が理解できれば、http://intra/ではアクセスできないケースがあることが理解できるのではないかと思います。 具体的なケースを示します。まず前提として以下のケースで、 - hostsファイルに記載されていない - lmhostsファイルに記載されていない - WINSが構成されていない - 対象サーバーと同一サブネットに無い(ブロードキャストでの名前解決はできない) これらすべてに加えて、以下のどれかの条件に当てはまる時です。 ...

March 11, 2009 · 1 min · 胡田昌彦