Windows Server 2008 と Vista におけるNAP検証

演習環境として、Windows Server 2008 と Vista SP1 があり、NAPの検証を同僚が行いましたのでその結果をUPしておきます。

NAP正常性ポリシーの制御の検証

NAP正常性ポリシーの設定が不適切だった場合、準拠でも非準拠でもないクライアントが存在する。そのような場合、どういった制御になるのかDHCP NAPで検証した。

■テスト１
SHV・・・F/Wが有効であること
正常性ポリシー
・Compliant・・・すべてにパス
・NonCompliant・・１つ以上にパス
※これは、すべて失敗のクライアントは準拠でも非準拠でもなくなる設定。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効
→制限なしのIPアドレスもらえる
F/W無効
→IPアドレスもらえない。APIPAのアドレスになる。
（すべて失敗のクライアントなので、準拠でも非準拠でもなくなるため、
IPアドレスがもらえない。予想どおり。）

■テスト２
SHV・・・F/Wが有効であること
正常性ポリシー
・Compliant・・・すべてにパス
・NonCompliant・・すべてにパス
※これは、わざと準拠と非準拠を同条件にした設定。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効
→制限なしのIPアドレス
F/W無効
→IPアドレスもらえない。APIPAのアドレスになる。

この結果は、ネットワークポリシーの順序で変わる。
ネットワークポリシー
NonCompliant-Restrictedが一番上、次がCompliant-FULLの順だと。

⇒クライアント側で
F/W有効
→制限ありのIPアドレス
F/W無効
→IPアドレスもらえない。APIPAのアドレスになる。

■テスト３
SHV・・・F/Wが有効であること
ウイルス対策ソフトが有効であること
正常性ポリシー
・Compliant・・・すべてにパス
・NonCompliant・・１つ以上にパス
※これは、すべて失敗のクライアントは準拠でも非準拠でもなくなる設定。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効　＆　ウイルス対策なし
→IPアドレスもらえない。APIPAのアドレスになる。
（これはヘン。F/W：パス　＆　ウイルス：失敗だから、「１つ以上に
パス」に合致する。それなのに制限ありのIPアドレスがもらえない。）
F/W無効　＆　ウイルス対策なし
→IPアドレスもらえない。APIPAのアドレスになる。
（こちらは予想どおり）

■テスト４
SHV・・・F/Wが有効であること
ウイルス対策ソフトが有効であること
正常性ポリシー
・Compliant・・・すべてにパス
・NonCompliant・・すべてに失敗
※これは、部分的にパスのクライアントは準拠でも非準拠でもなくなる設定。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効　＆　ウイルス対策なし
→制限ありのIPアドレス
（これもヘン。F/W：パス　＆　ウイルス：失敗だから、「すべてに失敗」
ではないのに、制限ありのIPアドレスがもらえてしまう。）
F/W無効　＆　ウイルス対策なし
→制限ありのIPアドレス
（こちらは予想どおり）

■テスト５
SHV・・・F/Wが有効であること
ウイルス対策ソフトが有効であること
正常性ポリシー
・Compliant・・・１つ以上にパス
・NonCompliant・・すべてに失敗
※これは、矛盾する設定ではない。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効　＆　ウイルス対策なし
→制限ありのIPアドレス
（やはりヘン。F/W：パス　＆　ウイルス：失敗だから、「１つ以上に
パス」に合致する。それなのに制限なしにならない。）
F/W無効　＆　ウイルス対策なし
→制限ありのIPアドレス
（こちらは「すべてに失敗」に合致するから、予想どおり）

まとめ

正常性ポリシーの設定が悪く、準拠でも非準拠でもないクライアントができてしまうと、それらは制限付きどころか、通信そのものができない。
問題は、「一部のチェックに失敗」しているだけのクライアントを「すべてに失敗」で把握してしまっていることだ。NAPでは「一部のチェックに失敗」のクライアントの制御に問題があると考えられる。

ただし最新のOSやサービスパックを使用しての検証ではないので現状では解決しているか不明