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

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

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

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

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

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

■テスト2
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のアドレスになる。

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

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

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

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

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

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

まとめ

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

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

スポンサーリンク
レクタングル(大)広告
レクタングル(大)広告
  • このエントリーをはてなブックマークに追加

コメントをどうぞ

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください