ちょっと間が空いてしまいましたが、再開します。

今回は xml ファイルになっているコンフィグレーションを暗号化する方法について触れましょう。ApplicationHost.config を例に行くと、例えば <connectionStrings> を追加します。今まで書いている <system.webServer> 外の指定になります。

あくまでもサンプルですが、こんな感じの記述を追加するとします。

<connectionStrings>
　　<add name="RemoteSqlServer" connectionString="data source=127.0.0.1;Integrated Security=SSPI;Initial Catalog=aspnetdb" providerName="System.Data.SqlClient" />
　　<add name="AccessFileName" connectionString="~\App_Data\ASPNetDB.mdb" providerName="System.Data.OleDb" />
</connectionStrings>

.NETフレームワークのフォルダへ行きます。
%windir%\Microsoft.NET\Framework\version

aspnet_regiis –pe connectionStrings –app /app

/appの仮想ディレクトリにある web.config のセクション暗号化を行う指定がこれになります。

昔、昔 MS Mail とかExchange 4.0、5.0、5.5 の構築支援をしていた人がいました。私です。(^^)　ついでにMAPIなんかにも手を出してましたが。

そんな大昔のことは置いておいて、英語が苦手でない方にお知らせをしておきます。Exchange 12のプレビューという位置づけで米国サイドでウェブキャストシリーズをやるようです。

An Overview of Exchange “12” (Level 200)
Tuesday, March 14, 2006 

Giving the Administrator More Control in Exchange “12” (Level 200)
Wednesday, March 15, 2006

Client Access and Web Services in Exchange “12” (Level 200)
Thursday, March 16, 2006

Message Security and Active Protection in Exchange “12” (Level 200)
Friday, March 17, 2006

興味がおありの方は是非下記のサイトから登録をしてみてください。
http://www.microsoft.com/events/series/tnexchangeserver.mspx

いつも一緒にあれやこれや考えてくれている very （非常に）あるいは unbelievably （異様に？）に忙しいITプロマーケティングチームのみんなと考えた末に ITE のサイトを作っちゃおうかという話になり、ついに実現しました。上部の写真で真ん中に立って体型の大きさをごまかそうとしているのが私です。(^_^;)
※ITE　：ITプロエバンジェリストの略なんです。

サイトはこちら。
http://www.microsoft.com/japan/technet/eva

背景などの詳細は ITプロマーケティングチームブログ で西谷が書いてくれてますので是非こちらも参照いただければと思います。

今はまだそれほど充実してませんが、腹案の実現化 及び イベントがある度にこのサイトを充実させていきます。microsoft.com/japan でコンテンツが割りと少なめな DSI、MOF、SMDS のような戦略的な話などに関してもITEの気持ちと心を込めて最新の情報を掲載していきたいと思っています。

DSI ： Dynamic Systems Initiative
MOF ： Microsoft Operations Framework
SMDS ：Self-Managing Dynamic Systems
※それぞれリンクは英語サイトにつけてます。

是非 ご期待いただきたいですし、「もっとこういう情報無いの？」っていうフィードバックにも柔軟に対応したいと思っています。ITプロマーケティングチームブログ でもここでリンクを貼っているチームメンバーのブログでも、もちろんこのブログでも結構ですので何かあれば遠慮なくコメントつけてください。

よろしくお願いいたします ＆ お待ちしております。
m(_ _)m

今回は 「じゃあ具体的に管理者が applicationHost.config に制限をかけたい場合にどのような方法になるのか」 をご案内したいと思います。今回も含め、かなり具体的なエリアに踏み込んでいくのでもちろん製品版とは微妙な記述や仕様変更がある可能性がある点はご容赦、という前提で続けていきます。。。

まずはじめに、.config ファイル内のルールとして <location></location> というセクションを書くことができる点から行きましょう。 <location> は.configファイル階層上のどこのパスの設定かを指定した上でコンフィグレーションを記述指定するセクションです。

例えば ルートのIIS Serverの設定を記述したい場合、元々の<system.webServer> の設定を変更するのではなく、<location></location>で囲った範囲に指定したい内容を.configファイルの最後の方に書くような方法が想定されています。つまり、applicationHost.config 内でこんな感じになるという意味です。

<system.webServer>
・・・色々な設定
</system.webServer>

・・・その他コンフィグレーション設定

<location path="." allowOverride="false">
  <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication>
          <providers>
            <add value="Negotiate" />
            <add value="NTLM" />
          </providers>
        </windowsAuthentication>
      </authentication>
    </security>
  </system.webServer>
</location>

この記載はつまり、ルートに対して allowOverride を false にすることによって Windows認証のプロバイダー設定を下位の階層で上書きできないようにすることを指定しています。location + allowOverride 以外にも下記のようなものもあります。こちらは locationを使わず、基本的に applicationHost.config の各セクションに直接書くことを想定しています。

●lockAttributes
<windowsAuthentication enabled="true" lockAttributes="enabled">
ご覧の通り、直前の enabled をロックします。

●lockElements
<windowsAuthentication enabled="true" lockElements="providers">
  <providers>
    <add value="Negotiate" />
    <add value="NTLM" />
  </providers>
</windowsAuthentication>
ご覧の通り、 <providers> の element をロックします。

●lockItem
<windowsAuthentication enabled="true" lockItem="true">
これは windowsAuthentication そのものをロックします。

●lockAllElementsExcept
<windowsAuthentication enabled="true" lockAllElementsExcept="providers">
これは文字通り”providers だけロックしない”という指定ですね。

ご覧いただいた通り、.config ファイルの各所にロックをかけられるということになります。これで管理者は変更されたくない箇所については鍵をかけておけます。ただ、見れば見るほど、各サーバーの applicationHost.config は開発プロジェクトなり、組織なりで標準を作っておかないとまたまたアプリ移植性（あるサーバーからあるサーバーへのアプリ移植を指してます。）が悪い環境ができてしまう可能性がありますね。

ということで、実際にIIS7をお使いになることが決定したら構成の共通標準を作る方向で考えましょう。今回はこんな感じで終了。

構成システムがどんな”イメージ”なのかについて Part I でふれました。Part II では管理ツールと構成システムの関係に触れようと思います。

IIS7 ではまったく新しい 横にペインが３つ並んだ最近のMS製品の管理ツールとしては標準的な形をしている Web Server Manager という名称の管理ツールを用意しています。名前に関してはまだ変更があるかもしれませんので最終確定ではありません。

当然構成情報をGUI で設定する場合、このツールを使うわけですが、メタベースがなくなったことによってこのツールでの変更も Part I で登場した.config ファイルに対して行われます。従って、xmlベースの configファイルを直接変更しても、 GUI で変更しても、 あるいはまだこのブログでは書いていない構成管理系の API を使うにしても、はたまた互換性のある WMI などのスクリプトから利用できるテクノロジーを使用しても すべて .config に反映がなされる統一感が実現されています。

もう一つ今回触れておくと、新管理ツールの説明ではよくやるんですが、IIS7からはサーバーに接続するだけでなく サイトレベルやアプリケーションレベルに接続できるようになりました。そうです。ADでOUのどこかの階層以下の管理を組織内で委任できるのと同じように今度はサイト単位あるいはアプリケーション単位で管理を委任することができます。管理者にとっては個別のアプリの環境を委任することができるため、かなり便利になりますし、今後書いていこうと思いますが、当該サーバーの特定設定に関しては委任した先の人が変更（階層構造なので上書きともいう）できないようにすることもできます。このことによって管理者はサーバー全体に影響を及ぼすような操作をされる心配なく委任できますし、逆の視点ではアプリ開発者は自由に自分のアプリを設定することができるようになります。

そして構成システム上はサーバー全体の設定に関しては applicationHost.config をメンテし 、サイト単位であればサイトで指定した仮想ディレクトリのルートにある web.config、アプリケーションの場合も実際のディスク上のパスのルートに web.config を置き、それぞれの階層でメンテナンスできます。そしてその config の中ではASP.NETの設定も入っていれば、IIS 上での稼動設定も入っています。随分すっきりした感じです。ちなみに Web Server Manager での GUI 操作設定もこの階層構造にうまく融合しており、例えばアプリケーション単位の設定を変更するとアプリケーションに割り当てられた web.config  がなければ作成し、あれば変更する動きをします。

ということで Part II では管理ツールと構成システムの関係を中心に、管理の委任にもふれてみました。