3件のコメント

Windows Server 2012でのDHCPを利用したNAPの構築方法 part3 SCCM(WSUS)連携

このエントリはシリーズになっています。他のエントリも合わせて参照してください。

 

前回はDHCPを利用したNAP環境を構築しました。今回はセキュリティ更新プログラムの更新の動作をSCCM上のWSUSと連携させて行なってみました。実際にはソフトウェア更新部分にはSCCMサーバーを利用しており、大部分はWSUSでも同じです。途中うまく行かず試行錯誤しておりますが、そのまま記録しておきました。

前提条件は以下です。

・SCCMが構成されていること

・SCCMでソフトウェア更新ポイントが構成されていること

・クライアントにSCCMクライアントがインストールされている(されるように構成されている)こと

まずNPSサーバー上でのポリシーの設定を行います。

clip_image001

clip_image002

重要及びそれ以上の更新プログラムが存在しており、インストールされていない場合には検疫されるように設定しました。

設定後にクライアント側でどのように認識されているのかはnetshコマンドで確認できます。

netsh nap client show state

 

クライアントの状態:
—————————————————-
名前                   = Network Access Protection Client
説明                   = Microsoft Network Access Protection Client
プロトコルのバージョン = 1.0
状態                   = 有効
制限の状態             = 制限なし
トラブルシューティングの URL
=
制限の開始時刻         =
拡張状態               =
グループ ポリシー      = 構成済み
強制クライアントの状態:
—————————————————-
ID                     = 79617
名前                   = DHCP 検疫強制クライアント
説明                   = DHCP ベースの強制を NAP に提供します。
バージョン             = 1.0
ベンダー名               = Microsoft Corporation
登録日                 =
初期化済み             = はい
ID                     = 79619
名前                   = IPsec 証明書利用者
説明                   = IPsec ベースの強制をネットワーク アクセス保護に提供します。
バージョン             = 1.0
ベンダー名               = Microsoft Corporation
登録日                 =
初期化済み             = いいえ
ID                     = 79621
名前                   = RD ゲートウェイ検疫強制クライアント
説明                   = NAP 用に RD ゲートウェイを強制します
バージョン             = 1.0
ベンダー名               = Microsoft Corporation
登録日                 =
初期化済み             = いいえ
ID                     = 79623
名前                   = EAP 検疫強制クライアント
説明                   = ネットワーク アクセス保護の強制を 802.1X や VPN テクノロジで使用される EAP 認証ネットワーク接続に提供します。
バージョン             = 1.0
ベンダー名               = Microsoft Corporation
登録日                 =
初期化済み             = いいえ
System Health Agent (SHA) の状態:
—————————————————-
ID                     = 79744
名前                   = Windows セキュリティ正常性エージェント
説明                   = Windows セキュリティ正常性エージェントは、コンピューターのセキュリティ設定を監視します。
バージョン             = 1.0
ベンダー名               = Microsoft Corporation
登録日                 =
初期化済み             = はい
エラーのカテゴリ       = なし
修復の状態             = 成功
修復の割合             = 0
修正のメッセージ       = (3237937214) – Windows セキュリティ正常性エージェントは、このコンピューターのセキュリティ状態の更新を終了しました。
確認の結果             = (0x00000000) –
(0x00000000) –
(0x00000000) –
(0x00000000) –
(0x00000000) –
(0x00000000) –
(0x00000000) –
(0x00000000) –
修復の結果             =
OK

上記結果は成功になっていたが、Windows FireWallを手動で設定変更すると設定が改めて確認され、検疫されました。

clip_image003

■SCCMクライアントのインストール

テストで用意したクライアントはインストール直後でまだSCCMクライアントがインストールされていませんでしたので、まずはSCCMクライアントをインストールします。(※もちろん本来は事前にインストールされておいてしかるべきです。)

clip_image004

しかし、インストールできませんでした。

クライアント側のインストールログ(c:\Windows\ccmsetup\Logs\ccmsetup.log)を確認した所ADにアクセスできないので失敗している模様です。検疫中でDCへのアクセスを許可していないので当然ですね。

clip_image005

検疫ネットワークを構成した際には、セットアップは検疫ネットワーク外で行うなどの対処が必要ですね。ここでは一時的に制限を解除してクライアントのインストールを完了しました。

インストール後、SCCMが動作しだすと以下のように検疫された上で強制的に更新ソフトウェアがインストールされ再起動を促されました。

clip_image006

この後再起動後を実施しましたが、再起動後も検疫されたままの状態です。

clip_image007

clip_image008

clip_image009

clip_image010

どうやら、きちんとSCCM(WSUS)のソフトウェア更新機能が動作していないようです。

確認の為に更新プログラムの確認を手動で行いました。

clip_image011

clip_image012

結果、エラーコード 8024402Cで失敗してしまいました。これはきちんとWSUSと通信できていないようです。WSUSとの通信を確認します。

ポリシー上、アクセスするのは以下のアドレスです。

clip_image013

clip_image014

telnetで8530ポートへの接続を確認した所、そもそもTCPでコネクションが貼れない状態でした。

サーバー側できちんと8530ポートで待ち受けているのかを確認します。

clip_image015

これはきちんと待ち受けが出来ています。

再度クライアント側で確認した所

telnet stcsccm1 8530

というコマンド入力ではきちんと接続が行えました。つまり、DNSでの名前解決に失敗している状態でした。

現在の設定では検疫されている状態で修復サーバーとしてSCCMサーバーのみを設定しているため、ActiveDirectoryへのログオンやDNSの名前解決等もまともに行えず修復動作にも支障をきたしてしまっている状態です。名前解決ができるようにする方法はいくつかありますが、とりあえずDCへのアクセスは許可する方針にしました。

clip_image016

修復サーバーグループは1つのポリシーで1つしか選択できないため、同一のグループにsccmサーバーとdcを記述しました。この状態でクライアントを再起動しました。

clip_image017

きちんとDCへのホストルートが追加されました。

その後はきちんと検疫~更新プログラムの適用動作が行われました。

clip_image018

ユーザーにはこのように通知されます。自分からクリックしたことで表示されていますのでこのレベルではNAPにより検疫されていることに気が付かないユーザーも出てしまいそうですね。

clip_image019

アクションセンター経由で確認した所、きちんと更新中のステータスになっていました。

その後、特になにも表示されずに通常通りアクセス可能な状態になりました。特に何も通知されないのはやはりちょっと気になります。

clip_image020

未適用の更新プログラムは存在しない状態にきちんとなっています。

しかし、検疫されなくなった後でも、裏で更新プログラムが適用され続けています。ネットワーク復帰のタイミングはこれでいいのでしょうか?ちょっと疑問が残る所ではありますが、更新プログラムの適用に長い時間がかかるケースもあるでしょうからこのタイミングでもいいのかもしれません。

clip_image021

clip_image022

適用完了後、再起動を促されました。

ひと通りうまく動いているようです。

子供3人。家族優先。都内SIer勤務。Windows系中心のインフラよりの何でも屋。脱原発。 Microsoft MVP for Cloud and Datacenter Management.

3件のコメント

  1. ゲストさん。質問ありがとうございます!

    SCCMもパッチ適用にはWSUS自体を使います。そういう意味でパッチ適用にはADは必要ありません。

    本文の中で色々と試行錯誤してしまっておりますが、ADとの通信を許可したのはDNSのため、つまり名前解決を成功させるためです。この部分だけ予めコントロールしておけばADとの通信も許可せずにパッチ適用を完了させられるはずです。

    具体的には検疫ネットワーク用のDNSを用意しておくか、WSUS(SCCM)サーバーのホスト名に関してはhostsに記載しておくなどの対応になると思います。

  2. 検疫されたPCへSCCMを使用してパッチを強制配布する場合は、検疫されたPCは、ADに接続できていなくても問題ない?(除外サーバーリストにいれない)ということでしょうか?AD認証が必要ないなら、NAPは、面白いかもということで質問させていただきました。WSUSは、ADは不要というのは、知っているのですが、SCCMは、よくわからないので、教えていただければ幸いです。

コメントを残す

メールアドレスが公開されることはありません。