社内でのネットワークアクセス保護（NAP）の展開が完了したと思ったら、あなたよりずっと偉い誰かがポリシーの例外を要求してくる…。これは断るわけにはいきません。あるいは、ネットワークに非NAP 対応マシンが何台かあり、それらのマシンをポリシーから簡単に除外できる方法が必要な場合もあります。時にはベンダーが社内に来て、午後の間ずっとネットワークアクセスを必要とするかもしれません（NAPについては本連載の「第5回 ネットワークアクセス保護（NAP）」を参照してください）。

　いずれにせよ、ポリシーの例外の管理は、NAP 展開を成功させる上で重要な部分を占めています。NAP はRADIUS をベースにして構築されるため、さまざまな属性に基づいて例外ポリシーを作成できます。以下に、よく発生する3 つのシナリオを示します。

　1番目の最も一般的なシナリオは、非NAP 対応コンピュータに関するものです。NAP ポリシーには、マシンがNAP 対応かどうかに関する条件文を含めることができます。これは、NAP 対応のマシンには正常性を徹底する一方で、NAP 対応ではないマシンのアクセスも許可できる便利な方法です。たとえば、このポリシーは次のように表すことができます。

  1. 正常なフルアクセス：「コンピュータの正常性が“正常”と一致する、かつ、コンピュータがNAP 対応である」場合にアクセスを許可する。

  2. 正常ではない制限付きアクセス：「コンピュータの正常性が“正常ではない”と一致する、かつ、コンピュータがNAP 対応である」場合に検疫する。

  3. 非NAP 対応フルアクセス：「コンピュータがNAP 対応ではない」場合にアクセスを許可する。
　ネットワークポリシーサーバー（NPS）では順次ルールが処理されるため、NAP 対応のマシンは最初の2 つのルールのいずれかと照らして判定され、NAP に対応していないマシンは3 つ目のルールに該当することになります。この例外方法は、NAP 展開が完了したときの既存マシンとの相互運用性が保持される有用な方法です。

　2 番目のシナリオは、ポリシーから除外したいNAP 対応マシンに関するものです。この場合、NAP 対応属性を使用しても役には立ちません。なぜなら、マシンは、前の例で示した最初の2 つのポリシーの一方と一致するからです。ここでは、NAP 機能に基づいて除外するのではなく、グループのメンバーシップに基づいて除外するポリシーを作成します。このグループにはユーザーおよびマシンアカウントを含めることができ、その2 つを組み合わせた複雑なルールを作成できます（たとえば、ユーザーがDOMAIN\Finance Users に存在し、マシンがDOMAIN\Finance Workstations に存在する場合に許可する、など）。

　除外が許可されるようにグループベースのポリシーと一致させる必要があるため、前述の例では、このポリシーを最初に示しておく方がいいでしょう。グループベースのポリシーが最初に示されていないと、元の2 つの正常性によるポリシーで一致が起こり、除外がトリガされなくなります。

　3 番目の例は、少しの間だけ社内に来てネットワークアクセスを必要とするベンダーに関するものです。この場合、コンピュータにもユーザーにも、ルールを作成するためのグループのメンバーシップがありません。NAP 展開が完了した場合、または積極的な実施スタンスをとっている場合、「非NAP 対応」ルールは存在しない可能性があります。このようなとき、短期的なユーザーを除外する簡単な方法は、MAC アドレスによる方法です。

　この場合は、コーリングステーションID というRADIUS クライアントプロパティを使用する新しいルールを作成します。このルールとは、「MAC アドレスによる除外： コーリングステーションIDが‘0015B7A6F653’と一致する場合にアクセスを許可する」というもので、ルールが適切に並んでいれば、ビジターの接続試行は最初にこのルールと一致し、MAC アドレスに基づいたネットワークアクセスが可能になります。