認証ポリシーの動作は、H.323 メッセージ、ローカル ドメインから受信した SIP メッセージ、および非ローカル ドメインからの SIP メッセージによって異なります。

主な認証ポリシー構成オプションとそれに関連する動作は次のとおりです。

• 資格情報の確認: 関連する認証方法を使用して確認します。

  （注）	シナリオによっては、メッセージが検証されない場合があります。以下を参照してください。

• 資格情報をチェックしない: 資格情報を検証せず、メッセージの処理を許可します。

• 認証済みとして扱う: 資格情報を検証せず、メッセージが認証済みであるかのように処理されます。 このオプションは、登録メカニズム内で認証をサポートしていないサードパーティサプライヤーのエンドポイントに対応するために使用できます。

  （注）	シナリオによっては、メッセージは許可されますが、認証されていないものとして扱われます。以下を参照してください。

認証ポリシーは、メッセージを受信するかどうかに基づいて、さまざまなゾーン タイプに対して選択的に構成できます。

• デフォルト ゾーン、ネイバー ゾーン、トラバーサル クライアント ゾーン、トラバーサル サーバ ゾーン、および統合コミュニケーション トラバーサル ゾーンでは、すべて認証ポリシーを構成できます。

• DNS ゾーンと ENUM ゾーンはメッセージを受信しないため、認証ポリシー構成はありません。

ゾーンの 認証ポリシーを編集するには、 [構成] > [ゾーン] > [ゾーン] に移動し、ゾーンの名前をクリックします。 新しいゾーンを作成すると、ポリシーはデフォルトで 資格情報を確認しない ように設定されます。

次の表に示すように、H.323 メッセージと SIP メッセージの動作は異なります。

H.323

SIP

ゾーンレベルでの SIP メッセージの動作は、SIP 認証信頼モード設定 (つまり、Expressway が受信メッセージ内の既存の認証済みインジケータ (P-Asserted Identity ヘッダーと呼ばれる) を信頼するかどうか) と、メッセージがローカルドメイン (Expressway が権限を持つドメイン) から受信されたか、ローカル以外のドメインから受信されたかによって異なります。

認証されたデバイスと認証されていないデバイスからの通話やその他のメッセージの処理方法は、検索ルール、外部ポリシー サービス、および CPL の構成方法によって異なります。

検索ルール

検索ルールを構成するときは、 リクエストは認証される必要がある 属性を使用して、検索ルールが認証された検索リクエストにのみ適用されるか、すべてのリクエストに適用されるかを指定します。

外部ポリシーサービス

外部ポリシー サービスは、通常、Expressway 自体でポリシー ルールを構成するのではなく、外部の集中サービスを通じてポリシー決定が管理される展開で使用されます。 次の領域でポリシー サービスを使用するように Expressway を設定できます。

• 登録ポリシー

• 検索ルール（ダイヤルプラン）

• コールポリシー

• ユーザポリシー（FindMe）

Expressway がポリシー サービスを使用する場合、名前と値のペアのパラメータのセットを使用して、POST メッセージで通話または登録要求に関する情報をサービスに送信します。 これらのパラメータには、リクエストが認証されたソースから送信されたかどうかに関する情報が含まれます。

『Cisco Expressway シリーズ コンフィギュレーション ガイド』ページの『Cisco Expressway 外部ポリシー導入ガイド』を参照してください。

CPL

Expressway でコール ポリシー ルール ジェネレーターを使用している場合、認証されたソースに対してソース マッチングが実行されます。 認証されていないソースとの一致を指定するには、空白のフィールドを使用します。 (ソースが認証されていない場合、その値は信頼できません)。

アップロードされた手動で作成されたローカル CPL を使用して通話ポリシーを管理する場合は、認証された発信元を参照しているか、認証されていない発信元を参照しているかを CPL で明示的に指定することをお勧めします。

• CPL が認証されていない発信元を確認する必要がある場合 (たとえば、認証されていない発信者をチェックする場合)、CPL は認証されていない発信元を使用する必要があります。 (ただし、ユーザが認証されていない場合は、好きなように自分自身を呼ぶことができます。このフィールドは発信者を検証しません。)

• 認証済みのオリジンを確認するには (認証済みまたは "認証済みとして扱う" デバイスでのみ使用可能)、CPL は authenticated-origin を使用する必要があります。

（注）	CPL スクリプトの作成は複雑なため、代わりに外部ポリシー サービスを使用することをお勧めします。

Expressway が デバイス認証 を使用するように設定されている場合、着信 SIP INVITE 要求が認証されます。 その後、Expressway が別の Expressway などの隣接ゾーンに要求を転送すると、その受信システムも要求を認証します。 このシナリオでは、メッセージはすべてのホップで認証される必要があります。

デバイスの認証情報を一度だけ（最初のホップで）認証する必要があるようにこれを単純化し、ネットワーク内の SIP メッセージの数を減らすには、認証信頼モード設定を使用するように近隣ゾーンを設定できます。

これは、ゾーンの認証ポリシーと組み合わせて使用され、そのゾーンから受信した事前認証済みの SIP メッセージが信頼されるかどうか、またその後 Expressway 内で認証済みまたは未認証として扱われるかどうかを制御します。 事前認証された SIP 要求は、 RFC 3326 で定義されている SIP メッセージ ヘッダーの P-Asserted-Identity フィールドの存在によって識別されます。

認証信頼モード の設定は次のとおりです。

• オン: 事前認証されたメッセージは、それ以上のチャレンジなしに信頼され、その後、Expressway 内で認証済みとして扱われます。 認証されていないメッセージは、認証ポリシーが資格情報を確認するに設定されている場合にチャレンジされます。

• オフ: 既存の認証済みインジケーター (P-Asserted-Identity ヘッダー) がメッセージから削除されます。 認証ポリシーが資格情報を確認するに設定されている場合、ローカルドメインからのメッセージはチャレンジされます。

（注）	ネイバー ゾーンが信頼できる SIP サーバのネットワークの一部である場合にのみ、認証信頼を有効にすることをお勧めします。 トラバーサル サーバー ゾーンとトラバーサル クライアント ゾーン間の認証信頼が暗黙的に示されます。

プロビジョニング サーバでは、受信するプロビジョニングまたは電話帳の要求が、Expressway へのエントリ ポイントのゾーンまたはサブゾーンですでに認証されている必要があります。 プロビジョニング サーバは独自の認証チャレンジを行わず、認証されていないメッセージを拒否します。

Expressway は適切なデバイス認証設定で構成されている必要があります。そうでない場合、プロビジョニング関連のメッセージは拒否されます。

• サブスクライブ メッセージの初期プロビジョニング認証は、デフォルト ゾーンの認証ポリシー設定によって制御されます。 (デバイスがまだ登録されていないため、デフォルト ゾーンが使用されます。)

• デフォルト ゾーンおよびトラバーサル クライアント ゾーンの認証ポリシーは、 資格情報を確認する または 認証済みとして扱うのいずれかに設定する必要があります。そうしないと、プロビジョニング要求は失敗します。

いずれの場合も、Expressway はローカル データベースに対して認証チェックを実行します。 これには、Cisco TMS によって提供されるすべての資格情報が含まれます。

プロビジョニング設定全般の詳細については、Cisco TMS Provisioning Extension 導入ガイドを参照してください。

ローカル認証データベースは Expressway システムの一部として含まれており、特別な接続構成は必要ありません。 ユーザ アカウントの認証資格情報を保存するために使用されます。 資格情報の各セットは、 名前 と パスワードで構成されます。

ローカル データベース内の資格情報は、デバイス (SIP)、トラバーサル クライアント、および TURN クライアントの認証に使用できます。

ローカルデータベースに資格情報を追加する

デバイスの資格情報のセットを入力するには:

1. [構成] > [認証] > [デバイス] > [ローカル データベース] に移動し、 [新規] をクリックします。

2. デバイスの資格情報を表す 名前 と パスワード を入力します。

3. [資格情報の作成]をクリックします。

（注）	同じ資格情報を複数のデバイスで使用できます。

Cisco TMS 内で管理される資格情報（デバイスのプロビジョニング用）

Expressway が TMS Provisioning Extension サービスを使用している場合、Users サービスによって提供される資格情報は、手動で設定されたエントリとともに、ローカル認証データベースに保存されます。 ソース 列は、ユーザ アカウント名が TMS によって提供されているか、 ローカル エントリであるかを識別します。 編集できるのは ローカル エントリのみです。

ローカル データベース内に Cisco TMS 資格情報を組み込むということは、Expressway が、Cisco TMS 内で使用されるのと同じ資格情報セットに対してすべてのメッセージ (プロビジョニング要求だけでなく) を認証できることを意味します。

H.350 ディレクトリ認証と組み合わせたローカルデータベース認証

ローカル データベースと H.350 ディレクトリの両方を使用するように Expressway を設定できます。

H.350 ディレクトリが設定されている場合、Expressway は、まずローカル データベースをチェックしてから H.350 ディレクトリをチェックすることで、提示されたダイジェスト クレデンシャルを常に検証しようとします。

Active Directory（直接）認証と組み合わせたローカル データベース認証

Active Directory (直接) 認証が構成され、NTLM プロトコル チャレンジが 自動 に設定されている場合、NTLM をサポートするデバイスに NTLM 認証チャレンジが提供されます。

• 標準のダイジェスト チャレンジに加えて、NTLM チャレンジも提供されます。

• NTLM をサポートするエンドポイントは、ダイジェスト チャレンジよりも NTLM チャレンジに応答し、Expressway はその NTLM 応答の認証を試みます。