NPS を RADIUS サーバーとして計画する
ネットワーク ポリシー サーバー (NPS) を リモート認証ダイヤルイン ユーザー サービス (RADIUS) サーバーとして展開すると、NPS は、ローカル ドメインとローカル ドメインを信頼するドメインに対する接続要求の認証、承認、アカウンティングを実行します。 以下の計画のガイドラインを使用すると、RADIUS の展開を簡略化することができます。
以下の計画ガイドラインには、NPS を RADIUS プロキシとして展開する必要のある状況は含まれていません。 NPS を RADIUS プロキシとして展開すると、NPS は、NPS を実行しているサーバーや、リモート ドメイン、信頼されていないドメイン、またはその両方のドメインの他の RADIUS サーバーに接続要求を転送します。
NPS を RADIUS サーバーとしてネットワークに展開する前に、次のガイドラインに従って展開計画を立ててください。
NPS 構成を計画します。
RADIUS クライアントを計画します。
認証方法の使用を計画します。
ネットワーク ポリシーを計画します。
NPS アカウンティングを計画します。
NPS 構成を計画する
NPS をどのドメインのメンバーにするか決定する必要があります。 マルチドメイン環境の場合、メンバーであるドメイン内のユーザー アカウントと、NPS のローカル ドメインを信頼するすべてのドメインの資格情報を NPS で認証することができます。 承認プロセス中に NPS でユーザー アカウントのダイヤルイン プロパティが読み取られるようにするには、各ドメインの RAS および NPS グループに NPS のコンピューター アカウントを追加する必要があります。
NPS のドメイン メンバーシップを決定した後、RADIUS プロトコルを使用して RADIUS クライアント (ネットワーク アクセス サーバーとも呼ばれる) と通信するようにサーバーを構成する必要があります。 また、NPS でイベントログに記録されるイベントの種類を構成したり、サーバーの説明を入力したりすることができます。
主要な手順
NPS 構成の計画には、次の手順を使用することができます。
NPS で RADIUS クライアントから RADIUS メッセージを受信するために使用する RADIUS ポートを決定します。 既定のポートは、RADIUS 認証メッセージの場合は UDP ポート 1812 と 1645、RADIUS アカウンティング メッセージの場合はポート 1813 とポート 1646 です。
複数のネットワーク アダプターを使用して NPS が構成されている場合は、RADIUS トラフィックを許可するアダプターを決定します。
NPS でイベント ログに記録するイベントの種類を決定します。 拒否された認証要求、成功した認証要求、または両タイプの要求をログに記録することができます。
複数の NPS を展開するかどうかを決定します。 RADIUS ベースの認証とアカウンティングにフォールト トレランスを提供するには、少なくとも 2 つの NPS を使用します。 1 つの NPS はプライマリ RADIUS サーバーとして使用され、もう 1 つはバックアップとして使用されます。 各 RADIUS クライアントは、両方の NPS 上で構成されます。 プライマリ NPS が使用できなくなった場合、RADIUS クライアントから別の NPS にアクセス要求メッセージが送信されます。
1 つの NPS 構成を別の NPS にコピーするために使用するスクリプトを計画して、管理オーバーヘッドを節約し、サーバーの誤構成を防ぎます。 NPS には、別の NPS にインポートするために NPS 構成のすべてまたは一部をコピーできる Netsh コマンドがあります。 コマンドは Netsh プロンプトを使用して手動で実行することができます。 ただし、コマンド シーケンスをスクリプトとして保存すれば、サーバー構成を変更する必要が生じた際に、後日スクリプトを実行することができます。
RADIUS クライアントを計画する
RADIUS クライアントは、ワイヤレス アクセス ポイント、仮想プライベート ネットワーク (VPN) サーバー、802.1X 対応スイッチ、およびダイヤルアップ サーバーなどのネットワーク アクセス サーバーです。 Radius サーバーに接続要求メッセージを転送する RADIUS プロキシは、Radius クライアントでもあります。 NPS は、RFC 2865 「リモート認証ダイヤルイン ユーザー サービス (RADIUS)」、RFC 2866 「RADIUS アカウンティング」 で説明されている RADIUS プロトコルに準拠するすべてのネットワーク アクセス サーバーと RADIUS プロキシに対応しています。
重要
クライアント コンピューターなどのアクセス クライアントは RADIUS クライアントではありません。 RADIUS プロトコル対応のネットワーク アクセス サーバーとプロキシ サーバーだけが RADIUS クライアントです。
また、ワイヤレス アクセス ポイントとスイッチの両方が、802.1X 認証に対応している必要があります。 拡張認証プロトコル (EAP) または保護された拡張認証プロトコル (PEAP) を展開する場合は、アクセス ポイントとスイッチで EAP の使用がサポートされている必要があります。
ワイヤレス アクセス ポイントの PPP 接続の基本的な相互運用性をテストするには、アクセス ポイントとアクセス クライアントでパスワード認証プロトコル (PAP) を使用するように構成します。 ネットワーク アクセスに使用する予定のプロトコルをテストするまで、追加の PPP ベースの認証プロトコル (PEAP など) を使用します。
主要な手順
RADIUS クライアントの計画中は、次の手順を使用できます。
NPS で構成する必要があるベンダー固有の属性 (VSA) を文書化します。 ネットワーク アクセス サーバーで VSA が必要な場合は、後で NPS でネットワーク ポリシーを構成するときに使用するできるように VSA 情報をログに記録します。
すべてのデバイスの構成を簡略化できるよう、RADIUS クライアントと NPS の IP アドレスを文書化します。 RADIUS クライアントを展開する際は、RADIUS プロトコルを使用するように構成し、NPS IP アドレスを認証サーバーとして入力する必要があります。 また、RADIUS クライアントと通信するように NPS を構成する場合は、RADIUS クライアントの IP アドレスを NPS スナップインに入力する必要があります。
RADIUS クライアント上と NPS スナップイン内で、構成用の共有シークレットを作成します。 RADIUS クライアントは共有シークレット (パスワード) を使用して構成する必要があります。この共有シークレットは、NPS で RADIUS クライアントを構成する際に NPS スナップインにも入力します。
認証方法の使用を計画する
NPS では、パスワード ベースと証明書ベースの両方の認証方法がサポートされています。 ただし、すべてのネットワーク アクセス サーバーで同じ認証方法がサポートされているわけではありません。 場合によっては、ネットワーク アクセスの種類に基づいて別の認証方法を展開する必要があるケースもあります。
組織のワイヤレス アクセスと VPN アクセスの両方を展開する場合がありますが、アクセスの種類によって異なる認証方法を使用できます。たとえば、VPN 接続には EAP-TLS を使用して、トランスポート層セキュリティを使用する EAP (EAP-TLS) の強力なセキュリティを利用しつつ、802.1X ワイヤレス接続には PEAP-MS-CHAP v2 を使用することができます。
PEAP と Microsoft Challenge ハンドシェイク認証プロトコル バージョン 2 (PEAP-MS-CHAP v2) では、ポータブル コンピューターや他のワイヤレス デバイスで使用するために特別に設計された高速再接続という名前の機能が提供されています。 高速再接続では、ワイヤレス クライアントが同じネットワーク上のワイヤレス アクセス ポイント間を移動することができます。ワイヤレス クライアントが新しいアクセス ポイントとの関連付けを行うたびに認証される必要がありません。 これにより、ワイヤレス ユーザーのエクスペリエンスが向上し、資格情報を再入力することなくアクセス ポイント間を移動できます。 PEAP-MS-CHAP v2 では高速再接続と高いセキュリティが提供されるため、PEAP-MS-CHAP v2 はワイヤレス接続の認証方法として理にかなったな選択肢と言えます。
VPN 接続の場合、証明書ベースの認証方法である EAP-TLS は、自宅やモバイル コンピューターから組織の VPN サーバーにインターネット経由で送信される場合にも、ネットワーク トラフィックを保護する強力なセキュリティを提供します。
証明書ベースの認証方法
証明書ベースの認証方法には、強力なセキュリティを提供するというメリットがある一方で、パスワード ベースの認証方法よりも展開が困難になるというデメリットがあります。
PEAP-MS-CHAP v2 と EAP-TLS はどちらも証明書ベースの認証方法ですが、双方には多くの違いがあり、展開方法も異なります。
EAP-TLS
EAP-TLS では、クライアントとサーバーの双方の認証に証明書が使用され、組織で公開キー基盤 (PKI) を展開する必要があります。 PKI の展開は複雑な場合があり、NPS を RADIUS サーバーとして使用する計画とは別の計画フェーズが必要です。
EAP-TLS の場合、NPS で証明機関 (CA) からのサーバー証明書が登録され、この証明書は証明書ストア内のローカル コンピューターに保存されます。 認証プロセスで、NPS がアクセス クライアントにサーバー証明書を送信して ID を証明することで、サーバー認証が行われます。 アクセス クライアントでは、さまざまな証明書のプロパティが調べられ、証明書が有効でサーバー認証中に使用するのに適切かどうかが判断されます。 送信されたサーバー証明書がサーバー証明書としての最小要件を満たし、アクセス クライアントの信頼する CA から発行されている場合、クライアントによって NPS が正常に認証されます。
同様に、クライアント認証は、認証プロセスでクライアントが NPS にクライアント証明書を送信して ID を証明する際に行われます。 NPS は証明書を調べ、送信されたクライアント証明書がクライアント証明書としての最小要件を満たし、また NPS の信頼する CA から発行されている場合、NPS によってアクセス クライアントが正常に認証されます。
サーバー証明書は NPS 上の証明書ストアに保存される必要があります。ただし、クライアント証明書またはユーザー証明書は、クライアントの証明書ストアか、スマート カードのいずれかに保存することができます。
この認証プロセスを正常に完了するには、すべてのコンピューターについてそのローカル コンピューターと現在のユーザーの[信頼されたルート証明機関]の証明書ストアに、組織の CA 証明書が保存されている必要があります。
PEAP-MS-CHAP v2
PEAP-MS-CHAP v2 では、サーバー認証用に証明書を、ユーザー認証用にパスワード ベースの資格情報が使用されます。 証明書はサーバー認証にのみ使用されます。このため、PEAP-MS-CHAP v2 を使用するために PKI を展開する必要はありません。 PEAP-MS-CHAP v2 を展開する場合は、次の 2 つの方法のいずれかを使用して NPS のサーバー証明書を取得することができます。
Active Directory 証明書サービス (AD CS) をインストールして、NPS に証明書を自動登録する方法。 この方法を使用する場合は、ネットワークに接続しているクライアント コンピューターに CA 証明書も登録して、NPS に発行された証明書を信頼する必要があります。
VeriSign などの公的 CA からサーバー証明書を購入する方法。 この方法を使用する場合は、クライアント コンピューターによって既に信頼されている CA を選択してください。 クライアント コンピューターで CA が信頼されているかどうかを確認するには、クライアント コンピューターで [Microsoft 管理コンソール (MMC) 証明書スナップイン] を開き、ローカル コンピューターと現在のユーザーの [信頼されたルート証明機関] ストアを表示します。 これらの証明書ストアに CA からの証明書がある場合、クライアント コンピューターで CA が信頼されるため、CA から発行されている証明書も信頼されます。
PEAP-MS-CHAP v2 での認証プロセス中に、NPS からサーバー証明書がクライアント コンピューターに送信されると、サーバー認証が行われます。 アクセス クライアントでは、さまざまな証明書のプロパティが調べられ、証明書が有効でサーバー認証中に使用するのに適切かどうかが判断されます。 送信されたサーバー証明書がサーバー証明書としての最小要件を満たし、アクセス クライアントの信頼する CA から発行されている場合、クライアントによって NPS が正常に認証されます。
ユーザー認証は、ユーザーがネットワークに接続しようとしてパスワード ベースの資格情報を入力し、ログオンしようとする際に発生します。 NPS は資格情報を受け取り、認証と承認を実行します。 ユーザーが正常に認証および承認され、クライアント コンピューターで NPS が正常に認証された場合は、接続要求が許可されます。
主要な手順
認証方法の使用の計画には、次の手順を使用できます。
ワイヤレス、VPN、802.1X 対応スイッチ、ダイヤルアップ アクセスなど、提供する予定のネットワーク アクセスの種類を特定します。
アクセスの種類ごとに使用する認証方法を決定します。 認証方法には、強力なセキュリティを提供する証明書ベースのものを使用することをお勧めします。ただし、PKI を展開することが実用的でない場合には、他の認証方法を選択した方が、ネットワークへのニーズをバランス良く満たせるケースもあります。
EAP-TLS を展開する場合は、PKI の展開を計画します。 これには、サーバー証明書とクライアント コンピューターの証明書に使用する証明書テンプレートの計画が含まれます。 また、ドメイン メンバーやドメイン メンバー以外のコンピューターに証明書を登録する方法と、スマートカードを使用するかどうかの決定も含まれます。
PEAP-MS-CHAP v2 を展開する場合は、NPS にサーバー証明書を発行するために AD CS をインストールするかどうか、または VeriSign などの公的 CA からサーバー証明書を購入するかどうかを決定します。
ネットワーク ポリシーを計画する
ネットワークポリシーは、RADIUS クライアントから受信した接続要求が承認済みかどうかを判断するために、NPS で使用されます。 また NPS での承認決定には、ユーザー アカウントのダイヤルイン プロパティが使用されます。
ネットワークポリシーは、NPS スナップインに表示される順序で処理されるため、最も制限の厳しいポリシーをポリシー一覧の最初に配置するように計画します。 NPS では、接続要求ごとに、ポリシーの条件と接続要求のプロパティの照合が試行されます。 一致するものが見つかるまで、各ネットワーク ポリシーが順番に検証されます。 一致するものが見つからない場合には、接続要求が拒否されます。
主要な手順
ネットワーク ポリシーの計画には、次の手順を使用することができます。
最も制限の厳しいポリシーから最も制限の緩いポリシーへと、NPS でのネットワーク ポリシー処理の優先順序を決定します。
ポリシーの状態を決定します。 ポリシーの状態の値には、有効か無効を指定できます。 ポリシーが有効になっている場合、承認中に NPS でポリシーが評価されます。 ポリシーが有効になっていない場合、ポリシーは評価されません。
ポリシーの種類を決定します。 ポリシーの条件が接続要求と一致する場合にアクセスを許可するのか、ポリシーの条件が接続要求と一致する場合にアクセスを拒否するのか、ポリシーの設計方法を決定する必要があります。 たとえば、Windows グループのメンバーによるワイヤレス アクセスを明示的に拒否する場合は、ネットワーク ポリシーを作成する際にグループとワイヤレス接続方法を指定し、ポリシーの種類の設定で [アクセス拒否] を指定します。
NPS で、ポリシーの基になっているグループ メンバーであるユーザー アカウントのダイヤルイン プロパティを無視するかどうかを決定します。 この設定が有効になっていない場合、ネットワークポリシーで構成されている設定が、ユーザー アカウントのダイヤルイン プロパティによって上書きされます。 たとえば、ネットワークポリシーがユーザーへのアクセスを許可するように構成されていても、そのユーザーのユーザー アカウントのダイヤルイン プロパティが [アクセスを拒否する] に設定されている場合、そのユーザーのアクセスは拒否されます。 ただしポリシーの種類の設定で、[ユーザー アカウントのダイヤルイン プロパティを無視する] を有効にすると、このユーザーはネットワークへのアクセスが許可されます。
ポリシーでポリシー ソース設定を使用するかどうかを決定します。 この設定を使用すると、すべてのアクセス要求のソースを簡単に指定することができます。 使用可能なソースは、ターミナル サービス ゲートウェイ (TS ゲートウェイ)、リモート アクセス サーバー (VPN またはダイヤルアップ)、DHCP サーバー、ワイヤレス アクセス ポイント、正常性登録機関サーバーです。 または、ベンダー固有のソースを指定することもできます。
ネットワーク ポリシーが適用されるうえで、一致する必要がある条件を決定します。
ネットワーク ポリシーの条件が接続要求と一致した場合に適用される設定を決定します。
既定のネットワーク ポリシーを使用するか、変更するか、または削除するかを決定します。
NPS アカウンティングを計画します。
NPS では、ユーザー認証やアカウンティング要求などの RADIUS アカウンティングデータを、IAS 形式、データベース互換形式、Microsoft SQL Server ログ記録という3つの形式でログに記録できます。
IAS 形式とデータベース互換形式では、ローカル NPS 上のログファイルがテキスト ファイル形式で作成されます。
SQL Server ログ記録を使用すると、SQL Server 2000 または SQL Server 2005 XML に準拠しているデータベースにログが記録され、RADIUS アカウンティングを拡張して、リレーショナル データベースにログを記録できるという利点を活用することができます。
主要な手順
NPS アカウンティングの計画には、次の手順を使用することができます。
- NPS アカウンティング データをログファイルに保存するか、SQL Server データベースに保存するかを決定します。
ローカル ログ ファイルを使用した NPS アカウンティング
ログ ファイルでのユーザー認証とアカウンティング要求の記録は、主に接続分析と課金の目的に使用されます。また、セキュリティ調査ツールとしても役立ち、攻撃後に悪意のあるユーザーのアクティビティを追跡する方法としても使用できます。
主要な手順
ローカル ログ ファイルを使用した NPS アカウンティングの計画では、次の手順を使用することができます。
NPS ログ ファイルに使用するテキスト ファイル形式を決定します。
ログに記録する情報の種類を選択します。 アカウンティング要求や、認証要求、定期的な状態をログに記録することができます。
ログ ファイルを保存するハードディスクの場所を決定します。
ログ ファイルのバックアップ ソリューションを設計します。 ログ ファイルを保存するハードディスクの場所は、データのバックアップを簡単に行える場所である必要があります。 また、ログ ファイルが保存されているフォルダーのアクセス制御リスト (ACL) を構成して、ハードディスクの場所を保護する必要があります。
新しいログ ファイルを作成する頻度を決定します。 ファイル サイズに基づいてログ ファイルを作成する場合は、新しいログ ファイルが NPS で作成されるまでに許容される最大ファイル サイズを決定します。
ハードディスクの容量が不足している場合に、NPS で古いログファイルを削除するかどうかを決定します。
アカウンティング データを表示し、レポートを生成するために使用するアプリケーションを決定します。
NPS SQL Server のログ
NPS SQL Server のログは、セッション状態に関する情報が必要な場合や、レポートの作成とデータ分析、アカウンティング データの管理を一元化して簡素化するために使用されます。
NPS には、SQL Server ログ記録を使用して、1つ以上のネットワーク アクセス サーバーから受信したユーザー認証とアカウンティング要求を、Microsoft SQL Server デスクトップ エンジン (MSDE 2000) または SQL Server 2000 より後の任意のバージョンの SQL Server を実行しているコンピューター上のデータソースに記録する機能が備わっています。
アカウンティング データは、NPS から XML 形式でデータベースのストアド プロシージャに渡されます。このストアド プロシージャは、構造化照会言語 (SQL) と XML (SQLXML) の両方をサポートしています。 XML に準拠した SQL Server データベースでユーザー認証およびアカウンティング要求を記録することで、複数の NPS で1つのデータソースを使用できるようになります。
主要な手順
NPS SQL Server のログ記録を使用した NPS アカウンティングの計画には、次の手順を実行できます。
自分や組織の別のメンバーが SQL Server 2000 または SQL Server 2005 リレーショナル データベースの開発経験があり、これらの製品を使用して SQL Server データベースを作成、変更、運営、管理する方法を理解しているか判断します。
SQL Server が NPS またはリモートコンピューターのどちらにインストールされているかを判断します。
受信する NPS アカウンティング データを含む XML ファイルを処理するために SQL Server データベースで使用するストアド プロシージャを設計します。
SQL Server データベースのレプリケーション構造とフローを設計します。
アカウンティング データを表示し、レポートを生成するために使用するアプリケーションを決定します。
ネットワーク アクセス サーバーの使用を計画します。このネットワーク アクセス サーバーは、すべてのアカウンティング要求でクラス属性を送信します。 クラス属性は Access-Accept メッセージで RADIUS クライアントに送信され、アカウンティング要求のメッセージを認証セッションと関連付ける場合に便利です。 クラス属性は、ネットワーク アクセス サーバーからアカウンティング要求メッセージとして送信された場合、アカウンティング レコードと認証レコードの照合に使用することができます。 サーバーが受け入れる認証ごとに使用する ID は、属性固有のシリアル番号、サービスの再起動時間、サーバーのアドレスの組み合わせによる一意の ID である必要があります。
中間アカウンティングをサポートするネットワーク アクセス サーバーの使用を計画します。
アカウンティング オンおよびアカウンティング オフのメッセージを送信するネットワーク アクセス サーバーの使用を計画します。
アカウンティング データの格納と転送をサポートするネットワーク アクセス サーバーの使用を計画します。 この機能をサポートするネットワーク アクセス サーバーは、ネットワーク アクセス サーバーが NPS と通信できない場合に、アカウンティング データを格納することができます。 NPS が使用可能になると、ネットワーク アクセス サーバーから格納されているレコードが NPS に転送されます。したがって、この機能を提供しないネットワーク アクセス サーバーよりも信頼性が高いと言えます。
ネットワーク ポリシーで、常に Acct-Interim-Interval 属性を構成するように計画します。 Acct-Interim-Interval 属性では、ネットワーク アクセス サーバーが送信する各中間更新の間隔が秒単位で設定されます。 RFC 2869 によると、Acct-Interim-Interval 属性の値は 60 秒 (1 分) より小さくすることはできません。また、600 秒 (10 分) より小さくしないでください。つまり、600 秒を超える値を使用すると、RADIUS サーバーが受信する更新の頻度が減ります。 詳細については、RFC 2869 を参照してください。
NPS で、定期的な状態のログ記録が有効になっていることを確認します。