WebSurfer's Home

Filter by APML

IUSR は変更可能

by WebSurfer 18. April 2014 17:15

IUSR は固定ではなく変更できるという話です。何を今さらといわれるかもしれませんはが、実は、自分は最近まで知らなかったです。(汗)

匿名ユーザー ID の設定

IUSR とは、先の記事 ASP.NET の ID オブジェクト で書きましたように、匿名アクセスの際に IIS によって使用されるデフォルトの ID です。

これを上の画像のように、特定のユーザーアカウントやアプリケーションプールの ID に変更することができます。詳しい手順は IIS のホームの記事 Anonymous Authentication を見てください。

ASP.NET ベースの Web アプリケーションの場合は、自分が知る限りですが、匿名ユーザー ID の変更が必要になるようなケースはなかったので、IUSR を変更するということは考えもしませんでした。

しかし、PHP アプリケーションを IIS でホストする場合、TexhNet のライブラリ FastCGI を使用して IIS 7 で PHP アプリケーションをホストする の「FastCGI および PHP の構成に関するベスト プラクティス」のセクションに書いてあるように、アプリケーションプール ID を使用するよう匿名ユーザー ID を構成することが推奨されているようです。

それ以外に IUSR を変更することが推奨されているケースがあるかどうかは分かりませんけど、一応変えられるということだけ備忘録として書いておきます。

Tags:

Windows Server

URL Rewrite 2.0 と日本語の問題

by WebSurfer 2. December 2013 17:31

Microsoft が提供している IIS 7.x 用の URL Rewrite 2.0 モジュール を使用しての日本語の書き換えがうまくいかないという話です。

なお、この問題は globalization 要素の requestEncoding 属性を Shift_JIS に設定した場合に限られます。デフォルトの UTF-8 の場合は問題ありません。

URL Rewrite 2.0 による書き換え

例えば、以下のように、日本語を使用した URL を書き換えるケースを考えます。

http://host/dir/あ ⇒ http://host/default.aspx?n=あ

その場合、URL Rewrite 2.0 では URL 書き換えルールは以下のようになります。

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Japanese Query String Test">
          <match url="dir/(.+)$" />
          <action 
            type="Rewrite" 
            url="default.aspx?n={R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

上記で、{R:1} というのは正規表現の後方参照から取得される文字列で、パターン dir/(.+)$ ではカッコで囲った部分になります。例えば、"http://host/dir/xxx" という入力なら {R:1} に該当するのは "xxx" になります。(ちなみに、{R:0} は "dir/xxx" になります)

ブラウザが要求を出す際、先の記事 ブラウザによる URL のエンコーディング で書きましたように、URL を UTF-8 として URL エンコーディングします。

"あ" の UTF-8 でのバイト列は E3 81 82 ですので、"http://host/dir/あ" は "http://host/dir/%E3%81%82" にエンコーディングされてからサーバーに送信されます。

URL Rewrite モジュールでは、"http://host/dir/%E3%81%82" という入力から、正規表現パターン dir/(.+)$ の後方参照として "%E3%81%82" を取得し、それをデコーディングした文字列が {R:1} に渡される仕組みになっています。(ソースコードを見たわけではなく、検証結果での確認ですが)

問題はその際の Encoding の判定です。

requestEncoding 属性が UTF-8(デフォルト)であれば、使用されている Encoding は UTF-8 と判定され、書き換え後の URL は正しく "default.aspx?n=あ" となります。

しかし、requestEncoding 属性が Shift_JIS に設定されていると、"%E3%81%82" の Encoding は Shift_JIS と判定され、書き換え後の URL は "default.aspx.aspx?n=縺・" とクエリ文字列の部分が文字化けしてしまいます。("縺・" は Shift_JIS のバイト列で E3 81 81 45 になります)

requestEncoding 属性が Shift_JIS でこの問題を避ける方法はあるでしょうか?

試しに、"http://host/dir/あ" で "あ" の部分を Shift_JIS の URL エンコード、即ち "http://host/dir/%82%A0" としてブラウザのアドレスバーに入力してみました。

その結果が一番上の画像なのですが、結果は同じように文字化けしてしまい、やっぱりダメでした。

ブラウザからサーバーに送信される URL は "http://host/dir/%82%A0" となりますが(Fiddler2 で確認)、サーバーが受信して URL Rewrite モジュールに渡す時に "%82%A0" が "%E3%81%82" になってしまうようです。(上の画像の X-Original-URL 参照)

というわけで、Microsoft の IIS 7.x 用 URL Rewrite 2.0 モジュールを使う際は、requestEncoding 属性を UTF-8(デフォルト)に限定した方がよさそうです。

UTF-8 なら "http://host/dir/%82%A0" という Shift_JIS で URL エンコーディングされた URL も正しく "default.aspx?n=あ" に書き換えられます。

参考までに検証に使った aspx ページ(0024-QueryString.aspx)を以下に載せておきます。

<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
    
  protected void Page_Load(object sender, EventArgs e)
  {
    Encoding enc = Request.ContentEncoding;
        
    Label1.Text = "Request.ContentEncoding.EncodingName: " + 
        enc.EncodingName;
              
    Label2.Text = "X-Original-URL: ";
    string[] values = 
        Request.Headers.GetValues("X-Original-URL");
    if (values != null)
    {
      string url = values[0];
      Label2.Text = Label2.Text + url;
      Label2.Text = Label2.Text + " (Url-decoded: " +
            HttpUtility.UrlDecode(url, enc) + ")";
    }

    Label3.Text = "Request.RawUrl: " + Request.RawUrl;
    Label4.Text = "Request.Url.OriginalString: " + 
        Request.Url.OriginalString;

    string queryString = Request.QueryString["n"];
    Label5.Text = 
        "Request.QueryString[\"n\"]: " + queryString;
                
    if (queryString != null)
    {
      string s = " (byte array: ";
      byte[] b = enc.GetBytes(queryString);
      for (int i = 0; i < b.Length; i++)
      {
        s = s + String.Format("[{0:X2}]", b[i]);
      }
      Label5.Text = Label5.Text + s + ")";
    }
  }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
  <title></title>
</head>
<body>
  <form id="form1" runat="server">
  <div>
    <asp:Label ID="Label1" runat="server"></asp:Label>
    <br />
    <asp:Label ID="Label2" runat="server"></asp:Label>
    <br />
    <asp:Label ID="Label3" runat="server"></asp:Label>
    <br />
    <asp:Label ID="Label4" runat="server"></asp:Label>
    <br />
    <asp:Label ID="Label5" runat="server"></asp:Label>
  </div>
  </form>
</body>
</html>

Tags: ,

Windows Server

Active Directory 証明書サービス

by WebSurfer 5. February 2012 15:04

自己署名入り証明書(いわゆる、オレオレ証明書)でないサーバー証明書と、CA 証明書を Active Directory 証明書サービスを利用して発行してインストールし、接続時に警告を出さないで SSL 通信を行う方法の紹介です。

サーバーは Windows Server 2008 で、Active Directory ドメインサービスと Web サーバー (IIS) は同一サーバーにインストールし、そこに Active Directory 証明書サービス (AD CS) をエンタープライズ CA としてインストールしてあるという環境です。

(注 1)証明書を発行するサーバーと Web サーバーは別でも問題ないですが、ドメインコントローラーでないサーバーではスタンドアロン CA しかインストールできないかもしれません。(ドメインコントローラーでなくても、ドメイン環境下のサーバーであればいいのかもしれませんが、未確認です)

(注 2)AD CS をインストールする際、「役割サービスの追加」メニューで[証明機関]に加えて[証明機関 Web 登録]も追加してください。前者はデフォルトで選択されていますが、後者はユーザーが手動で選択する(チェックマークを入れる)必要があります。それをしないと、以下の 7 以降の手順でブラウザから Certsrv にアクセスしてサーバー証明書を入手することができません。

エンタープライズ CA をインストールすると、CA 証明書は自動的にそのサーバーの「信頼されたルート証明機関」と「中間証明機関」の両方にインストールされます。

さらに、クライアント PC からドメインユーザーアカウントにログオンすると、クライアント PC にも自動的に CA 証明書が「信頼されたルート証明機関」と「中間証明機関」の両方にインストールされます。

したがって、ドメイン環境下であれば、Web サーバーにサーバー証明書をインストールするだけで、接続時に警告を出さない SSL 通信を行うことが可能になります。

サーバー証明書を取得する方法は、Microsoft TechNet の HTTPS メッセージング用のサーバー証明書を取得する に詳しく書いてありますが、以下にその要点を書きます。(TechNet の日本語の記事はリンク切れになってしまいました。クリックすると英語の Obtain Server Certificates for HTTPS Messaging に飛んでしまいます)

  1. まず、CSR(Certificate Signing Request: サーバー証明書を申請・取得するために認証局へ提出する署名リクエスト)を作成します。必ずサーバー証明書をインストールする Web サーバーで作業してください。
  2. IIS マネージャーを起動し、IIS セクションの「サーバー証明書」をダブルクリックします。
  3. 「操作」セクションの「証明書の要求の作成」をクリックし、「証明書の要求」ウィザードを起動します。
  4. 「識別名プロパティ」画面でディスティングイッシュネーム(一般名など 6 項目の情報)を登録し、「次へ」ボタンをクリックします。一般名(コモンネーム)は SSL 接続の際の URL と一致させる必要があるので注意してください。
IIS マネージャーでディスティングイッシュネームの登録
  1. 次の画面の「暗号化サービス プロバイダ」ドロップダウンリストで「Microsoft RSA Schannel Cryptographic Provide」を選択し、「ビット長」ドロップダウンリストでこれから生成する公開鍵の鍵長(2048 または 1024)を選択して「次へ」をクリックします。
  2. 次の画面で、CSR を保存するフォルダ、ファイル名を入力する画面が表示されるので、任意のフォルダ、ファイル名を指定して「終了」ボタンをクリックします。これで下の画像のような CSR が作成されます(保存場所を覚えておいて下さい)。手順 2 から 6 は、Symantec(旧 Verisign)のサイト新規・追加の手続きからリングが張ってあるCSR生成手順が参考になると思います。
CSR(Certificate Signing Request) を作成
  1. 次はサーバー証明書の作成・入手です。AD CS をインストールすると(その際[証明機関]に加えて[証明機関 Web 登録]の追加も必要なので注意)、そのサーバーに IIS もインストールされ、Default Web Site 下に CertSrv という仮想ディレクトリが作成されているはずです。そこにアクセスしてサーバー証明書をダウンロードします。
  2. サーバー証明書をインストールする Web サーバーで IE を起動し、手順 7 に述べた CertSrv にアクセスします。
IE で CertSrv にアクセス
  1. IE に表示された CertSrv の画面で、「証明書を要求する」⇒「証明書の要求の詳細設定」⇒「Base 64 エンコード CMC または PKCS #10 ファイルを使用して証明書の要求を送信するか、または Base 64 エンコード PKCS #7 ファイルを使用して更新の要求を送信する。」の順にクリックして画面遷移していきます。
  2. 手順 6 で取得した CSR を開き、そのファイルの内容を「証明書の要求または更新要求の送信」ページの「保存された要求:」ボックスにコピー&ペーストします。「証明書テンプレート:」のドロップダウンリストで「Web サーバー」を選択し、「追加属性」を指定して「送信」ボタンをクリックします。
サーバー証明書の要求
  1. IE に「証明書は発行されました」ページが表示されるので、「証明書のダウンロード」をクリックし、Web サーバーの任意のフォルダに証明書を保存します。デフォルトで certnew.cer というファイル名になるはずです。
  2. 次に、サーバー証明書の Web サーバーへのインストールを行います。手順 2 と同様に、Web サーバーで IIS マネージャーを起動し、IIS セクションの「サーバー証明書」をダブルクリックします。
  3. 「操作」セクションの「証明書の要求の完了」をクリックし、「証明書の要求を完了する」ウィザードを起動します。
IIS マネージャーで証明書の要求の完了
  1. 参照 ([...]) ボタンをクリックして手順 11 でダウンロードした証明書ファイルを検索して証明書のパスを入力し、さらに「フレンドリ名」ボックスに証明書の任意のフレンドリ名を入力して「OK」ボタンをクリックします。
  2. このとき "この証明書ファイルに関連付けられた証明書の要求が見つかりません。要求を作成したコンピュータで、証明書の要求を完了する必要があります。" というエラーメッセージが表示されることがあります。その場合でも、インストールが完了していることがありますので、IIS マネージャーの画面に戻り、F5 キーを押して最新の情報を確認してください。
  3. 成功すると「サーバー証明書」セクション(IIS マネージャー画面の真ん中)に新しいサーバー証明書が追加されているはずです。
  4. 最後に SSL 接続のバインドへの追加です。IIS マネージャーで SSLを有効にするサイトを選択して「操作」セクションの「バインド」をクリックし、表示された「サイト バインド」ダイアログボックスの「追加」ボタンをクリックします。
  5. 「サイト バインドの追加」ダイアログ ボックスの、「種類」ドロップダウンリストで「https」を選択し、「SSL 証明書」ドロップダウンリストで手順 14 でインストールした証明書を選択します。
  6. 「OK」をクリックすると IIS の設定は完了です。その後、ファイアウォールの穴あけも忘れないようにしましょう。
IIS マネージャーでサイトバインドの追加

Active Directory を利用したドメイン環境であれば、クライアントの PC にも CA 証明書は自動的にインストールされるので、以上の手順までで接続時に警告を出さないで SSL 通信を行うことができます。

クライアントの PC がドメイン環境にない場合、CA 証明書は手動でダウンロードしてインストールします。その手順は次の通りです。(注:イントラネット外から CertSrv にアクセスしてダウンロードできるかどうかは未確認です)

  1. クライアントの PC から、手順 8 で述べた CertSrv サイト http://サーバー名/CerSrv/ にアクセスし、CA 証明書をダウンロードできます。Windows 認証のログインダイアログが出てくるので Administrator 権限でログインします(ドメインユーザー権限でもいいかもしれませんが未確認です)。
Administrator 権限で CertSrv にログイン
  1. 手順 8 と同じ画面が表示されるので、そこで「CA 証明書、証明書チェーン、または CRL のダウンロード」をクリックします。
  2. 「CA 証明書、証明書チェーン、または CRL のダウンロード」画面が表示されるので、「CA 証明書のダウンロード」をクリックします。うまくいけば、ダウンロードフォルダに certnew.cer という名前の CA 証明書ファイルがダウンロードされているはずです。
CA 証明書のダウンロード
  1. 手順 22 でダウンロードした CA 証明書ファイルをダブルクリックして、「信頼されたルート証明機関」にインストールします。デフォルトでは「中間証明機関」にインストールされてしまうことがありましたので注意してください。
  2. その後で、手順 18 でサーバー証明書を設定したサイトに https としてアクセスすると、以下の画像のように警告なしで接続されます。証明書も有効になっています。
クライアント PC の IE から https で接続した画面

以上、AD CS がエンタープライズ CA としてインストールされている場合の手順です。スタンドアロン CA の場合は少々面倒で、サーバー証明書を発行する前に、手動で CA 証明書を AD CS のサーバーにインストールしなければなりません。次のような手順になります。

  1. CertSrv サイトからダウンロードした CA 証明書をダブルクリックして、「信頼されたルート証明機関」にインストールする。
  2. 手順 25 でインストールした証明書を certmgr でエクスポートする。
  3. mmc + 証明書スナップインを起動する。このとき、「このスナップインで管理する証明書」を[コンピュータアカウント]に設定する。
  4. 手順 26 でエクスポートした証明書を、手順 27 で起動した mmc + 証明書スナップインで、「信頼されたルート証明機関」と「中間証明機関」にイン���ートする。(「信頼されたルート証明機関」だけでよいかもしれませんが未確認です)

これをしないと、サーバー証明書の発行だけでなく、証明書サービス自体もうまく動きません。"xxxx-xxxx-CAのための CA 証明書 0 のチェーンを作成できませんでした。証明書チェーンは処理されましたが、信頼プロバイダが信頼していないルート証明書で強制終了しました。 0x800b0109 (-2146762487)。" というエラーになります。

さらに、サーバー証明書を発行するとき、ダウンロードにはならず一旦保留されてしまうので、AD CS をインストールしたサーバーで、手動で mmc + 証明書スナップインを利用して証明書を発行しなければなりません。

Tags:

Windows Server

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。ブログ2はそれ以外の日々の出来事などのトピックスになっています。

Calendar

<<  December 2025  >>
MoTuWeThFrSaSu
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar