認証の設定によるアクセス制限

認証の種類

IIS は多数のユーザー認証方法をサポートしています。

ここでは認証方法の代表格である、「匿名認証」、「基本認証」、「Windows 統合認証」の３つの使い方を見て行きましょう。

認証の設定

「認証」の設定は IIS マネージャから設定します。

複数の認証方法がサポートされている

匿名認証

匿名認証は、「認証をしない」という設定です。

インターネット上のどのユーザーからのアクセスも受け付ける場合等は、匿名認証を有効にします。

匿名認証の設定は非常に簡単です。 IIS マネージャにて、匿名認証を選択して 有効にする をクリックすれば OK です。

ちなみに、IIS 7.0 の管理用コマンドである appcmd で設定する場合は次のようにします。

C:\>%systemroot%\system32\inetsrv\appcmd set config 
/section:system.webServer/security/authentication/anonymousAuthentication 
/enabled:true

クイック・スタート・ガイドではなるべく UI から設定を行います。興味のある人は appcmd も調べてみてください。

基本認証

設定方法

ここでは実際に、基本認証による認証ユーザーのみが a.html にアクセス可能なように IIS を設定してみましょう。

a.html は Default Web Site のドキュメントルートに配置します。また、比較のために b.html も作成し、こちらは匿名ユーザーでもアクセス可能にしましょう。

またここでは web.config を用いて認証の設定をします。

web.config は Apache をご存知の方なら、 .htaccess のようなものだと考えていただけばわかりやすいと思います。

web.config は IIS のシステムディレクトリではなく、コンテンツのディレクトリに配置する設定ファイルです。

IIS 7.x の構成ファイルは %SYSTEMROOT%\system32\inetsrv\Config にある、次のファイルです。

administration.config
applicationHost.config
redirection.config

Web サイトやアプリケーションに関する基本的な構成は、applicationHost.config に格納されています。

web.config を用いると applicationHost.config で行った設定を上書きすることができます。

基本認証の設定について web.config で設定の上書きを許可するために、 applicationHost.config の以下の赤でマークした箇所を "Deny" から "Allow" に書き換えます。

...
<sectionGroup name="authentication">
    <section name="anonymousAuthentication" overrideModeDefault="Allow" />
    <section name="basicAuthentication" overrideModeDefault="Allow" />
    <section name="clientCertificatemappingAuthentication" overrideModeDefault="Deny" />
    ...

これによって、web.config で設定を書き換え可能になります。

さて、web.config を作成します。パスは C:\inetpub\wwwroot\web.config です。その内容を次のように記述します。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<location path="a.html">
		<system.webServer>
			<security>
				<authentication>
					<anonymousAuthentication enabled="false"/>
					<basicAuthentication enabled="true"/>
				</authentication>
			</security>
		</system.webServer>
	</location>
</configuration>

location 要素によって、設定を適用するパスを記述します。さらに、匿名アクセスを拒否 (anonymousAuthentication enabled="false") して、基本認証を受け入れます (basicAuthentication enabled="true")。

動作確認

Wfetch を用いて、a.html に対して匿名アクセスを試みます。

すると 401 Unauthorized ステータスが返され、アクセスできませんでした。

基本認証を設定し、user1 の認証情報付きで要求を行ったところ、以下のように 200 OK が返され、a.html にアクセスできました。

また、b.html に対して匿名アクセスを試みたところ、以下のように 200 OK が返され、b.html にアクセスできました。

以上で、確かに a.html には認証が必要であり、b.html は匿名でアクセス可能であることが確認できました。

尚、applicationHost.config にて overrideModeDefault を "Deny" のままであると、以下のようなエラーが発生します。

エラーメッセージ: HTTP エラー 500.19 - Internal Server Error
ページに関連する構成データが無効であるため、要求されたページにアクセスできません。
この構成セクションをこのパスで使用できません。
この問題は、親レベルでセクションがロックされている時に発生します。ロック状態は既定で設定されているか (overrideModeDefault="Deny")、または overrideMode="Deny" もしくは従来の allowOverride="false" を含んだ場所タグによって明示的に設定されます。

基本認証とは？

動作を確認したところで、基本認証とは一体なんなのか理解しておきましょう。

セキュリティを考える上でこれは非常に重要です。

基本認証 (Basic Authentication) は、インターネット上で最も広く使われている認証方法で、 RFC 2617 に詳細が既定されています。

おさえておきたいポイントは、「基本認証はユーザー名とパスワードを HTTP ヘッダに暗号化しないで記述する方法である」ということです。

認証情報として、ユーザー名とパスワードをまるまる送信しているので、ネットワークを覗き見されてしまうと、ユーザー名とパスワードが丸ごと盗まれてしまいます。

従ってとても単純な方法で、広く普及しているのですが、セキュリティに注意しないと問題を引き起こしてしまう可能性があるので、十分気をつけてください。

ちなみに、上のテストでも HTTP ヘッダ部分にユーザー名とパスワードが設定されているのに気付きましたか？

次の部分です。

Authorization: Basic dXNlcjE6UGFzc3dvcmQxMjM=

dXNlcjE6UGFzc3dvcmQxMjM= はユーザー名とパスワードのペアを Base64 エンコードしたものです。デコードすると "user1:Password123" という文字が見えてしまいます。

ちなみに、言葉の使い方ですが、パッとみて読めないからといって「暗号化されている」と言わないでくださいね。こういうのは「エンコード (encode) されている」といいます。アルゴリズムさえ知っていれば "解読" できるからです。

一方、「暗号化」 (encryption) というのはアルゴリズムと「キー」があってはじめて解読できる（平文にできる）ものをいいます。

Windows 統合認証

設定方法

こちらも設定方法は基本認証と同様です。基本認証の時に設定した basicAuthentication の代わりに windowsAuthentication を設定します。これにより、Windows 統合認証が有効になります。

基本認証の時と同様に、a.html にのみ認証するよう設定して、ブラウザから a.html を要求します。

すると、確かに次のように認証ダイアログが表示されました。

このダイアログにユーザー名とパスワードを入力すると、確かに a.html にアクセスできました。

Windows 統合認証の確認とその仕組み

さて、このときに本当に Windows 統合認証になっているのか確認してみましょう。

クイック・スタート・ガイド的には、この上までで動作確認できてます。この先は「徹底解説」的に、仕組みについて簡単に説明します。

そのために、Network Monitor を用いてクライアントとサーバーのやり取りを見てみます。

HTTP に着目すると、次のようなやり取りが見られました。

認証に関わる HTTP ヘッダーを抜き出してみましょう。

WWW-Authenticate はサーバーからクライアントへ、Authorization はクライアントからサーバーへ送られています。

#	HTTP ヘッダ	値
3:	WWW-Authenticate:	Negotiate
4:	Authorization:	Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAA AAAAAAAAAAAAGAHEXAAAADw==
5:	WWW-Authenticate:	Negotiate TlRMTVNTUAACAAAAHgAeADgAAAAVgor iNqRpX/SFkAMAAAAAAAAAAJgAmABWAA AABgBxFwAAAA9XAEkATgAtADIAWABXA E4AVABNAFgASwBPAFYASAACAB4AVwBJ AE4ALQAyAFgAVwBOAFQATQBYAEsATwB WAEgAAQAeAFcASQBOAC0AMgBYAFcATg BUAE0AWABLAE8AVgBIAAQAHgBXAEkAT gAtADIAWABXAE4AVABNAFgASwBPAFYA SAADAB4AVwBJAE4ALQAyAFgAVwBOAFQ ATQBYAEsATwBWAEgABwAIAED6qfFfQc kBAAAAAA==
6:	Authorization:	Negotiate TlRMTVNTUAADAAAAGAAYAJIAAAAIAQg BqgAAABoAGgBYAAAACgAKAHIAAAAWAB YAfAAAABAAEACyAQAAFYKI4gYAcRcAA AAPOe5lr+bGpGVHSzz7TDqcWGsAZQBp AHMAdQBrAGUAbwAtAGkAaQBzADcAdQB zAGUAcgAxAEsARQBJAFMAVQBLAEUATw AtAEgAUAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABPErwG9c8+Z1uZoPzJtAZ3 AQEAAAAAAABA+qnxX0HJAW2vYBSfU0T YAAAAAAIAHgBXAEkATgAtADIAWABXAE 4AVABNAFgASwBPAFYASAABAB4AVwBJA E4ALQAyAFgAVwBOAFQATQBYAEsATwBW AEgABAAeAFcASQBOAC0AMgBYAFcATgB UAE0AWABLAE8AVgBIAAMAHgBXAEkATg AtADIAWABXAE4AVABNAFgASwBPAFYAS AAHAAgAQPqp8V9ByQEGAAQAAgAAAAgA MAAwAAAAAAAAAAAAAAAAMAAAQ6jNB+C 8CsmIwGT/M90RPbzxJqM4XZjXJN4Gwg CRDKEAAAAAAAAAAAAAAADexdAdGtJHs bDt5NBsXvfy

なんか、ごちゃごちゃっとして、これでは何のことかわかりませんね。

値の Negotiate の後に含まれる文字列は、認証情報を Base64 でエンコードしたデータです。ですから、Base64 デコードしないと読めないのです。

さらに、Base64 デコードしても基本的にバイナリデータですから、人間が読むのには向いていません。

そこで (認証情報が NTLM であろうことを予想して) NTLM データのダンプツールを使って、 Base64 デコードしてさらにデコードされた内容を解釈すると、それぞれの値は次のようになります。

ちなみに、このツール NTLM メッセージダンプツール (dumpntlm) は、私が書いたツールです。ネットワークトレースをテキストファイルで渡された時 (笑) など、パケット解析ツールで太刀打ちできない時にお使いください。

#	HTTP ヘッダ
3:	WWW-Authenticate:
	Negotiate
4:	Authorization:
Negotiate --- Decoded Message --- 0000 4e 54 4c 4d 53 53 50 00:01 00 00 00 97 82 08 e2 NTLMSSP......... 0010 00 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00 ................ 0020 06 00 71 17 00 00 00 0f:00 00 ..q....... Signature: NTLMSSP Indicator: 00000001 NTLM Message Type Flags: Negotiate Unicode Negotiate OEM Request Target Negotiate Sign Negotiate LAN Mangager Key Negotiate NTLM Negotiate Always Sign Negotiate NTLM2 key Negotiate 128 bit encryption Negotiate 56 bit encryption
5:	WWW-Authenticate:
Negotiate --- Decoded Message --- 0000 4e 54 4c 4d 53 53 50 00:02 00 00 00 1e 00 1e 00 NTLMSSP......... 0010 38 00 00 00 15 82 8a e2:36 a4 69 5f f4 85 90 03 8.......6.i_.... 0020 00 00 00 00 00 00 00 00:98 00 98 00 56 00 00 00 ............V... 0030 06 00 71 17 00 00 00 0f:57 00 49 00 4e 00 2d 00 ..q.....W.I.N.-. 0040 32 00 58 00 57 00 4e 00:54 00 4d 00 58 00 4b 00 2.X.W.N.T.M.X.K. 0050 4f 00 56 00 48 00 02 00:1e 00 57 00 49 00 4e 00 O.V.H.....W.I.N. 0060 2d 00 32 00 58 00 57 00:4e 00 54 00 4d 00 58 00 -.2.X.W.N.T.M.X. 0070 4b 00 4f 00 56 00 48 00:01 00 1e 00 57 00 49 00 K.O.V.H.....W.I. 0080 4e 00 2d 00 32 00 58 00:57 00 4e 00 54 00 4d 00 N.-.2.X.W.N.T.M. 0090 58 00 4b 00 4f 00 56 00:48 00 04 00 1e 00 57 00 X.K.O.V.H.....W. 00a0 49 00 4e 00 2d 00 32 00:58 00 57 00 4e 00 54 00 I.N.-.2.X.W.N.T. 00b0 4d 00 58 00 4b 00 4f 00:56 00 48 00 03 00 1e 00 M.X.K.O.V.H..... 00c0 57 00 49 00 4e 00 2d 00:32 00 58 00 57 00 4e 00 W.I.N.-.2.X.W.N. 00d0 54 00 4d 00 58 00 4b 00:4f 00 56 00 48 00 07 00 T.M.X.K.O.V.H... 00e0 08 00 40 fa a9 f1 5f 41:c9 01 00 00 00 00 00 00 ..@..._A........ Signature: NTLMSSP Indicator: 00000002 0000 1e 00 1e 00 38 00 00 00:15 82 8a e2 36 a4 69 5f ....8.......6.i_ 0010 f4 85 90 03 .... TargetName: WIN-2XWNTMXKOVH NTLM Message Type Flags: Negotiate Unicode Request Target Negotiate Sign Negotiate NTLM Negotiate Always Sign Target Type Server Negotiate NTLM2 key Negotiate target Info Negotiate 128 bit encryption Negotiate 56 bit encryption Challenge: 0000 36 a4 69 5f f4 85 90 03: 6.i_.... Context: (no data) Domain name subblock: WIN-2XWNTMXKOVH Server name subblock: WIN-2XWNTMXKOVH DNS domain name subblock: WIN-2XWNTMXKOVH DNS server name subblock: WIN-2XWNTMXKOVH
6:	Authorization:
Negotiate --- Decoded Message --- 0000 4e 54 4c 4d 53 53 50 00:03 00 00 00 18 00 18 00 NTLMSSP......... 0010 92 00 00 00 08 01 08 01:aa 00 00 00 1a 00 1a 00 ................ 0020 58 00 00 00 0a 00 0a 00:72 00 00 00 16 00 16 00 X.......r....... 0030 7c 00 00 00 10 00 10 00:b2 01 00 00 15 82 88 e2 \|............... 0040 06 00 71 17 00 00 00 0f:39 ee 65 af e6 c6 a4 65 ..q.....9.e....e 0050 47 4b 3c fb 4c 3a 9c 58:6b 00 65 00 69 00 73 00 GK<.L:.Xk.e.i.s. 0060 75 00 6b 00 65 00 6f 00:2d 00 69 00 69 00 73 00 u.k.e.o.-.i.i.s. 0070 37 00 75 00 73 00 65 00:72 00 31 00 4b 00 45 00 7.u.s.e.r.1.K.E. 0080 49 00 53 00 55 00 4b 00:45 00 4f 00 2d 00 48 00 I.S.U.K.E.O.-.H. 0090 50 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00 P............... 00a0 00 00 00 00 00 00 00 00:00 00 4f 12 bc 06 f5 cf ..........O..... 00b0 3e 67 5b 99 a0 fc c9 b4:06 77 01 01 00 00 00 00 >g[......w...... 00c0 00 00 40 fa a9 f1 5f 41:c9 01 6d af 60 14 9f 53 ..@..._A..m.`..S 00d0 44 d8 00 00 00 00 02 00:1e 00 57 00 49 00 4e 00 D.........W.I.N. 00e0 2d 00 32 00 58 00 57 00:4e 00 54 00 4d 00 58 00 -.2.X.W.N.T.M.X. 00f0 4b 00 4f 00 56 00 48 00:01 00 1e 00 57 00 49 00 K.O.V.H.....W.I. 0100 4e 00 2d 00 32 00 58 00:57 00 4e 00 54 00 4d 00 N.-.2.X.W.N.T.M. 0110 58 00 4b 00 4f 00 56 00:48 00 04 00 1e 00 57 00 X.K.O.V.H.....W. 0120 49 00 4e 00 2d 00 32 00:58 00 57 00 4e 00 54 00 I.N.-.2.X.W.N.T. 0130 4d 00 58 00 4b 00 4f 00:56 00 48 00 03 00 1e 00 M.X.K.O.V.H..... 0140 57 00 49 00 4e 00 2d 00:32 00 58 00 57 00 4e 00 W.I.N.-.2.X.W.N. 0150 54 00 4d 00 58 00 4b 00:4f 00 56 00 48 00 07 00 T.M.X.K.O.V.H... 0160 08 00 40 fa a9 f1 5f 41:c9 01 06 00 04 00 02 00 ..@..._A........ 0170 00 00 08 00 30 00 30 00:00 00 00 00 00 00 00 00 ....0.0......... 0180 00 00 00 30 00 00 43 a8:cd 07 e0 bc 0a c9 88 c0 ...0..C......... 0190 64 ff 33 dd 11 3d bc f1:26 a3 38 5d 98 d7 24 de d.3..=..&.8]..$. 01a0 06 c2 00 91 0c a1 00 00:00 00 00 00 00 00 00 00 ................ 01b0 00 00 de c5 d0 1d 1a d2:47 b1 b0 ed e4 d0 6c 5e ........G.....l^ 01c0 f7 f2 .. Signature: NTLMSSP Indicator: 00000003 0000 18 00 18 00 92 00 00 00:08 01 08 01 aa 00 00 00 ................ 0010 1a 00 1a 00 58 00 00 00:0a 00 0a 00 72 00 00 00 ....X.......r... 0020 16 00 16 00 7c 00 00 00: ....\|... LMResponse: size: 24 (allocated 24) Offset 00000092 NTLMResponse: size: 264 (allocated 264) Offset 000000AA DomainName: size: 26 (allocated 26) Offset 00000058 UserName: size: 10 (allocated 10) Offset 00000072 WorkstationName: size: 22 (allocated 22) Offset 0000007C LMResponse: 0000 00 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00: ........ NTLMResponse: 0000 4f 12 bc 06 f5 cf 3e 67:5b 99 a0 fc c9 b4 06 77 O.....>g[......w 0010 01 01 00 00 00 00 00 00:40 fa a9 f1 5f 41 c9 01 ........@..._A.. 0020 6d af 60 14 9f 53 44 d8:00 00 00 00 02 00 1e 00 m.`..SD......... 0030 57 00 49 00 4e 00 2d 00:32 00 58 00 57 00 4e 00 W.I.N.-.2.X.W.N. 0040 54 00 4d 00 58 00 4b 00:4f 00 56 00 48 00 01 00 T.M.X.K.O.V.H... 0050 1e 00 57 00 49 00 4e 00:2d 00 32 00 58 00 57 00 ..W.I.N.-.2.X.W. 0060 4e 00 54 00 4d 00 58 00:4b 00 4f 00 56 00 48 00 N.T.M.X.K.O.V.H. 0070 04 00 1e 00 57 00 49 00:4e 00 2d 00 32 00 58 00 ....W.I.N.-.2.X. 0080 57 00 4e 00 54 00 4d 00:58 00 4b 00 4f 00 56 00 W.N.T.M.X.K.O.V. 0090 48 00 03 00 1e 00 57 00:49 00 4e 00 2d 00 32 00 H.....W.I.N.-.2. 00a0 58 00 57 00 4e 00 54 00:4d 00 58 00 4b 00 4f 00 X.W.N.T.M.X.K.O. 00b0 56 00 48 00 07 00 08 00:40 fa a9 f1 5f 41 c9 01 V.H.....@..._A.. 00c0 06 00 04 00 02 00 00 00:08 00 30 00 30 00 00 00 ..........0.0... 00d0 00 00 00 00 00 00 00 00:00 30 00 00 43 a8 cd 07 .........0..C... 00e0 e0 bc 0a c9 88 c0 64 ff:33 dd 11 3d bc f1 26 a3 ......d.3..=..&. 00f0 38 5d 98 d7 24 de 06 c2:00 91 0c a1 00 00 00 00 8]..$........... 0100 00 00 00 00 00 00 00 00: ........ DomainName: keisukeo-iis7 UserName: user1 WorkstationName: KEISUKEO-HP

つまり、WWW-Authenticate ヘッダーと Authorization ヘッダーを用いて、こんな情報をやり取りしたということになります。

もしあなたが、NTLM 認証をサポートする Web サーバーを実装したいと思ったら、 SSPI を用いた NTLM 通信の解説ページを参考にして、 SSPI で作られるブログを WWW-Authenticate ヘッダと Authorization ヘッダに入れて、クライアントとサーバー間でネゴシエートするようにすればよいです。

NTLM 認証は、NTCR (NT Challenge/Response) 認証とも言われています。チャレンジと呼ばれるワンタイムデータをパスワードを用いて、クライアント側、サーバー側でハッシュをつくり、それらをつき合わせて認証する仕組みです。

このため、ネットワーク上にはパスワードが流れることが無く、（またハッシュから元のパスワードが推測しにくいため）比較的安全な方法といわれています。