Cisco ACNS キャッシング/ストリーミング コンフィギュレーション ガイド
認証および許可の設定
認証および許可の設定
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

認証および許可の設定

さまざまなタイプの認証および許可の概要

ログイン認証と許可の概要

デフォルトのログイン認証と許可の設定

ログイン認証フェールオーバーの概要

ローカル ログイン認証と許可の概要

RADIUS 認証の概要

TACACS+ 認証と許可

HTTP 要求認証の概要

使用上のガイドライン

透過モードの HTTP 要求認証の概要

透過モードでの階層化キャッシングの概要

プロキシ サーバ モードで作動する場合の HTTP 要求認証の概要

ログイン認証および許可の設定

Content Engine に対する認証サーバの設定

Content Engine に対する RADIUS 認証サーバの設定

Content Engine に対する TACACS+ 認証サーバの設定

ログイン認証および許可スキームの指定とイネーブル化

使用上のガイドライン

ローカル ログイン認証および許可のイネーブル化とディセーブル化

RADIUS ログイン認証および許可のイネーブル化とディセーブル化

TACACS+ ログイン認証および許可のイネーブル化とディセーブル化

HTTP 要求認証の設定

使用上のガイドライン

認証キャッシュ サイズの設定

ContentEngine GUI を使用した認証キャッシュ サイズの設定

CLI コマンドを使用した認証キャッシュ サイズの設定

RADIUS HTTP 要求認証の設定

ContentEngine GUI を使用した RADIUS HTTP 認証要求のイネーブル化

CLI コマンドを使用した RADIUS HTTP 要求認証の設定

TACACS+ HTTP 要求認証の設定

NTLM HTTP 要求認証の設定

LDAP HTTP 要求認証の設定

サーバの冗長性

LDAP HTTP 要求認証

セキュリティ オプション

LDAP Active Directory について

トランザクション ロギング

ContentEngine GUI を使用した LDAP HTTP 要求認証の設定

CLI コマンドを使用した LDAP 認証の設定

エンドツーエンド認証の設定

基本エンドツーエンド認証

NTLM エンドツーエンド認証

NTLM エンドツーエンド認証の例

グループ ベースの許可設定

Active Directory の概要

LDAP Accept Use Policy 機能の設定

LDAP パスワード有効期限機能の設定

グループ名ベースのアクセス リストについて

ContentEngine GUI を使用したグループ名ベースのアクセス リスト設定

CLI コマンドを使用したグループ名ベースのアクセス リスト設定

LDAP グループ認証

LDAP ネスト グループの設定

アクセス リストを使用した LDAP グループ許可の設定

NTLM グループ ベースの認証

アクセス リストを使用した NTLM グループ許可の設定

認証および許可の設定

この章では、ローカルに配置されている Content Engine 上でログイン(ユーザ)認証および許可のサポートを設定する方法を説明します。この章ではまた、ローカルに配置されている Content Engine 上で HTTP 要求認証、およびグループ ベースでの認証を設定する方法も説明します。

この章の構成は、次のとおりです。

「さまざまなタイプの認証および許可の概要」

「ログイン認証および許可の設定」

「HTTP 要求認証の設定」

「エンドツーエンド認証の設定」

「グループ ベースの許可設定」


) この章で使用される CLI コマンドの構文と使用方法については、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。


さまざまなタイプの認証および許可の概要

ACNS 5.x ソフトウェアは、外部アクセス サーバ(たとえば、RADIUS または TACACS+ サーバ)を使用するユーザ、および AAA 機能付きローカル アクセス データベースを必要とするユーザに対して、AAA (Authentication, Authorization, and Accounting; 認証、許可、アカウンティング)をサポートします。

認証(または「ログイン」)では、ユーザの身元を確認し、ユーザ ID をユーザの IP アドレスに関連付けます。許可では、ネットワークで認証されたユーザに対する権限を許可または拒否します。アカウンティングでは、ユーザによる認証サービスの使用状況、および認証と許可において発生したすべての拒否状況がログに記録されます。

Content Engine をローカルに配置している ACNS 5.x 環境では、主要な認証および許可のタイプとして次の 2 つがあります。

ログイン(ユーザ)認証および許可。これにより、Content Engine へのログインおよびアクセス権限を管理できます。

このタイプの認証に関する基本的な情報は、「ログイン認証と許可の概要」を参照してください。

HTTP 要求認証。これにより、Content Engine 上の制限されたサービスへのアクセスを管理できます。HTTP 要求認証が発生するのは、ユーザが特権アクセスを必要とするサービス要求を送信するときです。

ACNS 5.1 ソフトウェアのキャッシュ サービスは、TACACS+、Microsoft NT LAN Manager(NTLM)、Lightweight Directory Access Protocol(LDAP)、および RADIUS サーバの HTTP 要求認証をサポートします。このタイプの認証に関する詳細は、「HTTP 要求認証の概要」を参照してください。

表 7-1 では、ACNS 5.1 でサポートされる各種認証方式の要約を示します。

 

表 7-1 ACNS 5.1 でサポートされる認証方式の要約

認証方式
説明
ログインの認証と許可

Local

デフォルトでは、プライマリ認証方式であり、ローカルで設定されているログインおよびパスワードを使用してログイン時に認証が行われます(「ローカル ログイン認証と許可の概要」 を参照)。

RADIUS

「RADIUS 認証の概要」

TACACS+

「TACACS+ 認証と許可」

HTTP 要求認証
 

RADIUS

「RADIUS HTTP 要求認証の設定」

TACACS+

「TACACS+ HTTP 要求認証の設定」

NTLM

「NTLM HTTP 要求認証の設定」

LDAP

「LDAP HTTP 要求認証の設定」

エンドツーエンド認証

NTLM

「NTLM エンドツーエンド認証」

グループ ベースの認証

LDAP

「LDAP グループ認証」

NTLM

「NTLM グループ ベースの認証」

ログイン認証と許可の概要

ACNS 5.x 環境では、ログインおよび設定権限を次の 3 つのデータベース内で維持できます。

Content Engine 上に置かれているローカル データベース

2 つのリモート データベース(TACACS+ データベースおよび RADIUS データベース)

図 7-1 に示すように、ログインおよび設定の権限は、両方とも Content Engine のローカル データベース、またはリモートのサードパーティ データベース(TACACS+ データベースまたは RADIUS データベース)から取得可能です。

図 7-1 認証データベースとローカルに配置されている Content Engine

 


) ACNS 5.1 ソフトウェアは、Content Engine GUI へのセキュアまたはノンセキュアなアクセスをサポートしています(Content Engine GUI へのセキュアなアクセス、またはノンセキュアなアクセスのいずれか一方はサポート可能ですが、セキュアなアクセスとノンセキュアなアクセスは同時にサポートできません)。セキュアな Content Engine GUI がデフォルトです
https://Content_Engine_ip_address:8003)。このトピックに関する詳細は、「Content Engine GUI の操作」を参照してください。


これらの複数の認証と許可の方式を組み合わせて、ローカルに配置される Content Engine に対するアクセスの制御および権限の設定を行うことができます。

ローカル認証および許可

RADIUS 認証および許可

TACACS+ 認証および許可

ローカル認証を他の認証方式で行えるように設定すると、ローカル認証が常に実行されます。それは優先順位のフラグが設定されていないからです。コンソールおよび Telnet 接続では、複数の異なる認証方式を指定できません。

デフォルトのログイン認証と許可の設定

デフォルトでは、Content Engine は、ローカル データベースを使用して、認証および許可の権限を取得するようになっています。フェールオーバーを行うには、何らかの設定が必要です(たとえば、認証サーバが到達不能ため、発生したフェールオーバー)が、デフォルトでは、指定されていません(デフォルトの認証設定については、図 7-2 を参照してください)。

図 7-2 Content Engine Authentication Configuration ウィンドウ

 


authentication グローバル設定コマンドにより、Content Engine へのログインおよび設定のアクセスを決定する認証方式が設定されます。


表 7-2 では、ログイン認証と許可のデフォルト設定を示しています。

 

表 7-2 ログイン認証と許可のデフォルト設定

機能
デフォルト値

ログイン認証

イネーブル

設定認証

イネーブル

認証サーバに到達できないために、発生する認証サーバのフェールオーバー

ディセーブル

TACACS+ ログイン認証(コンソールおよび Telnet)

ディセーブル

TACACS+ 認証(コンソールおよび Telnet)

ディセーブル

TACACS+ キー

未指定

TACACS+ サーバ タイムアウト

5 秒

TACACS+ 再試行の回数

2 回

RADIUS ログイン認証(コンソールおよび Telnet)

ディセーブル

RADIUS 認証(コンソールおよび Telnet)

ディセーブル

RADIUS サーバの IP アドレス

未指定

RADIUS サーバの UDP 許可ポート

ポート 1645

RADIUS キー

未指定

RADIUS サーバの タイムアウト

5 seconds

RADIUS 再試行の回数

2 回

これらのデフォルト値は、Content Engine GUI または CLI を使用して変更できます。「ログイン認証および許可の設定」を参照してください。

ログイン認証フェールオーバーの概要

デフォルトでは、Content Engine がプライマリ認証方式に失敗したときは、必ずセカンダリ認証方式にフェールオーバーします。ACNS ソフトウェア リリース 5.0.5 より前のリリースでは、ログイン認証のフェールオーバー方式を使用するこのデフォルト設定を変更できませんでした。

ACNS ソフトウェア リリース 5.0.5 以降では、このデフォルトの認証フェールオーバー方式を変更できます。ローカルに配置されている Content Engines には、Content Engine GUI( System > Authentication の順に選択し、 Failover due to Server Unreachable ボックスにチェックマークを付けます。)または CLI( authentication fail-over server unreachable グローバル設定コマンドを使用します。)を使用して、failover due to unreachable server オプションをイネーブルにできます。

フェールオーバーが発生するのは、指定した認証サーバに到達できない場合のみです。次の例では、認証サーバに到達できない場合にログイン認証フェールオーバーを行うように設定する方法を示しています。この場合、Content Engine は、ログイン認証サーバに到達できないときに、次の認証方式を照会するだけです。

ContentEngine(config)#authentication fail-over server-unreachable
ContentEngine(config)#
 

ログイン認証のフェールオーバー機能を使用するには、TACACS+ または RADIUS をプライマリ ログイン認証方式として設定し、ローカルをセカンダリ ログイン認証方式として設定する必要があります。

failover due to unreachable server オプションがイネーブルの場合、次の点に注意してください。

Content Engine 上では、2 つのログイン認証スキーム(プライマリおよびセカンダリ スキーム)のみが許可されている。

Content Engine が、プライマリ認証スキームからセカンダリ認証スキームにフェールオーバーするのは、指定された認証サーバに到達できない場合のみ。

たとえば、failover due to server unreachable オプションがイネーブルで、RADUIS がプライマリ ログイン認証スキームとして、ローカルがセカンダリ ログイン認証スキームとして設定されている場合、次のようなことが発生します。

1. Content Engine がログイン要求を受け取ると、Content Engine は RADIUS 認証サーバに照会を行います。

2. RADIUS サーバに到達できる場合、Content Engine はこの RADIUS データベースを使用してユーザを認証します。

3. RADIUS サーバに到達できない場合、Content Engine は、セカンダリ認証スキーム(Content Engine がローカル認証データベースに照会を行う)を実行して、ユーザを認証します。


) この RADIUS サーバに到達できない場合に限り、認証用にローカル データベースに問い合わせます。それ以外の場合(たとえば、RADIUS サーバでの認証に失敗)には、認証用にローカル データベースに問い合わせをしません。


逆に、Failover Due to Server Unreachable オプションがディセーブルの場合、Content Engine は、プライマリ認証データベースでの認証に失敗した理由に関係なく、セカンダリ認証データベースに問い合わせをします。

すべての認証データベースを使用できる場合、これらすべてのデータベースに、選択された優先度順に、およびフェールオーバー理由に基づいて照会をしていきます。フェールオーバーの理由が指定されていない場合、これらすべてのデータベースは、データベースの優先度順に照会します(たとえば、最初にプライマリ(1 次)データベースに照会し、次にセカンダリ(2 次)データベースに、そして最後にターシャリ(3 次)データベースに照会します)。

ローカルおよびリモート データベース(TACACS+ および RADIUS)は、Content Engine GUI または CLI を使用して、イネーブルまたはディセーブルにできます。Content Engine は、すべてのデータベースがディセーブルであるかを確認し、ディセーブルの場合、システムをデフォルトの状態に設定します(このデフォルトの状態については、「デフォルトのログイン認証と許可の設定」を参照してください)。

さまざまなタイプのログイン認証および許可スキームについては、次を参照してください。

「ローカル ログイン認証と許可の概要」

「RADIUS 認証の概要」

「TACACS+ 認証と許可」


) ローカルに配置されている Content Engine 上で、ログイン認証および許可の設定を行う方法については、 「ログイン認証および許可の設定」を参照してください。


ローカル ログイン認証と許可の概要

ローカル認証および許可では、ローカルに設定されているログインとパスワードを使用して、ログイン認証を行います。これらのログインとパスワードは、各 Content Engine に対してローカルです。また、個々のユーザ名にはマップされません。

デフォルトでは、ローカル ログイン認証は最初、イネーブルになっています。ローカル ログイン認証をディセーブルにするのは、他のログイン認証方式を 1 つまたは複数イネーブルにした場合のみです。ただし、ローカル ログイン認証がディセーブルになっているときに、他のログイン認証方式をすべてディセーブルにすると、ローカル ログイン認証は自動的に再度イネーブルになります。

RADIUS 認証の概要

RADIUS とは、クライアント/サーバ認証のことで、ネットワーク アクセス サーバ(NAS)が、ネットワーク装置に接続しようとするユーザの認証に使用する認証アクセス プロトコルです。NAS はクライアントとして機能し、ユーザ情報を 1 台または複数台の RADIUS サーバに送信します。NAS は、1 台または複数台の RADIUS サーバから受信する応答に基づいて、ユーザへのネットワーク アクセスの許可または拒否を行っています。RADIUS は、RADIUS クライアントとサーバ間の転送に User Datagram Protocol(UDP)を使用します。

ユーザはクライアントとサーバ上で RADIUS キーを設定できます。クライアント上でキーを設定する場合、RADIUS サーバ上で設定されているキーと同一にする必要があります。RADIUS クライアントとサーバは、このキーを使用して、送信される RADIUS パケットをすべて暗号化します。RADIUS キーを設定しない場合は、パケットは暗号化されません。キー自体がネットワーク上に送信されることはありません。


) RADIUS プロトコルの機能の詳細は、RFC 2138『Remote Authentication Dial In User Service (RADIUS)』を参照してください。


RADIUS 認証は、デフォルトでディセーブルになっています。RADIUS 認証と他の認証方式を同時にイネーブルにすることができます。また、最初に使用する方式を指定することもできます。RADIUS 認証設定については、「ログイン認証および許可の設定」を参照してください。

TACACS+ 認証と許可

TACACS+ は、ネットワーク装置へのアクセスを制御します。ネットワーク装置と中央データベース間で、ネットワーク アクセス サーバ(NAS; Network Access Server)情報を交換してユーザまたはエンティティの身元を識別しています。TACACS+ は、TACACS(RFC 1492 で指定される User Datagram Protocol(UDP)ベースのアクセス制御プロトコル)の拡張バージョンです。TACACS+ は、TCP を使用して、信頼性の高い配信を行い、TACACS+ サーバとネットワーク装置の TACACS+ デーモン間のトラフィックをすべて暗号化します。

TACACS+ では、固定パスワード、ワンタイム パスワード(使い捨てパスワード)、およびチャレンジ レスポンス認証などのさまざまなタイプの認証が可能です。TACACS+ 認証は、通常、次のような場合に実行されます。

ログイン認証:最初にマシン(たとえば、ローカルに配置されている Content Engine)にログインする場合

HTTP 要求認証:アクセス権が必要なサービス要求を送信する場合

ユーザが、制限されたサービスを要求すると、TACACS+ は MD5 暗号化アルゴリズムを使用してユーザのパスワード情報を暗号化し、TACACS+ パケット ヘッダーを追加します。このヘッダー情報は、送信されているパケット タイプ(たとえば、認証パケット)、パケット シーケンス番号、使用される暗号化タイプ、およびパケットの長さの合計を識別します。次に、TACACS+ プロトコルはパケットを TACACS+ サーバに転送します。

TACACS+ サーバは、認証、許可、およびアカウンティングの機能を備えています。これらのサービスが TACACS+ 機能のすべてです。これらは互いに独立しているため、TACACS+ 設定に応じてサービスの一部またはすべてを使用できます。

TACACS+ サーバがパケットを受信すると、次の操作を実行します。

ユーザ情報を認証し、ログイン認証が正常に行われたか失敗したかをクライアントに通知する。

認証が続行されること、またクライアントが情報を追加する必要があることをクライアントに通知する。このチャレンジ レスポンス プロセスは、ログイン認証が正しく行われるか失敗するまで、繰り返し実行されます。

ユーザはクライアントとサーバ上で TACACS+ キーを設定できます。Content Engine 上でキーを設定する場合、TACACS+ サーバ上で設定されたキーと同一にする必要があります。TACACS+ クライアントとサーバは、このキーを使用して、送信される TACACS+ パケットをすべて暗号化します。TACACS+ キーを設定しない場合は、パケットは暗号化されません。

TACACS+ 認証は、デフォルトでディセーブルになっています。TACACS+ 認証とローカル認証は同時にイネーブルにできます。TACACS+ をログイン認証スキームとして設定する方法は、「ログイン認証および許可の設定」を参照してください。

HTTP 要求認証の概要

ACNS 5.x ソフトウェアは、TACACS+、Microsoft NT LAN Manager(NTLM)、Lightweight Directory Access Protocol(LDAP)、および RADIUS サーバの HTTP 要求認証をサポートしています。NTLM の場合、HTTP 要求認証は、事前設定された Primary Domain Controller(PDC; プライマリ ドメイン コントローラ)を使用して、ユーザのドメイン、ユーザ名、およびパスワードを認証してから、ユーザからの要求を Content Engine が処理します。

図 7-3 では、Content Engine の認証スキームを経由して HTTP 要求が流れるパスを示しています。

図 7-3 HTTP 要求認証

 


) NTLM、TACACS+、LDAP、および RADIUS のサーバの認証方式(それぞれのサーバで別々のユーザ ID とパスワードが必要な場合がある)はすべて、互いに排他的です。すなわち、一度に 1 つの認証方式のみが使用可能です。


使用上のガイドライン

ローカルに配置されている Content Engine 上での HTTP 要求認証に関して、注意すべき点は次のとおりです。

ACNS 5.x ソフトウェアは、グループ名ベースのアクセス リストをサポートしています。この機能を使用すると、どのグループのユーザが、ローカルに配置されている Content Engine がサービスする特定のコンテンツを表示できるかを管理できます。

グループ情報が確認および適用されるのは、アクセス リスト機能がイネーブルの場合のみです。

ユーザがアクセス リストに定義されているどのグループにも属していない場合、デフォルトのポリシーにより、ユーザ アクセスが許可されます。

図 7-4 は、グループ名ベースのアクセス リストの例を示しています。このアクセス リストにより、マーケティング グループのどのユーザもこの特定の Content Engine を介してコンテンツにアクセスすることはできません。

図 7-4 グループ名ベースのアクセス リスト

 


) グループ名ベースのアクセス リストについては、「RADIUS HTTP 要求認証の設定」を参照してください。


Content Engine が TACACS+、NTLM、RADIUS、または LDAP のサーバを介してユーザを認証する場合、その認証の記録が Content Engine RAM(認証キャッシュ)内にローカルに保存されます。認証エントリが保持される限り、それ以降に同じユーザが制限されたインターネット コンテンツにアクセスしても、再認証は必要ありません。

http authentication cache timeout コマンドは、アクティブでないエントリが削除されるまでに認証キャッシュ内に保存される時間を指定します。レコードが削除されると、制限されたインターネット コンテンツへの以降のアクセスはすべて、再認証が必要になります。

HTTP 認証サーバからドメインを除外するには、 rule no-auth domain コマンドを使用します。TACACS+、NTLM、RADIUS、または LDAP の認証が行われるのは、要求されたサイトが指定のパターンと一致しない場合だけです。

Content Engine は、暗号化していない、単純な認証を使用して LDAP 認証サーバと通信します。

Content Engine が TACACS+ 認証サーバと通信する場合、同じ秘密キー(たとえば、tackey)が TACACS+ サーバ、およびこの TACACS+ サーバと通信しようとする各 TACACS+ クライアント(Content Engine、ルータなど)上で設定されている必要があります。

(config)#tacacs key "tackey"
 

TACACS+ サーバはこの共通のクライアント キーを使用して、暗号化、および復号化を行います。TACACS+ 認証サーバに TACACS+ クライアントを登録する必要はありません。

Content Engine が RADIUS 認証サーバと通信を行う場合、RADIUS サーバに RADIUS クライアント(Content Engine)を登録する必要があります。その上で、RADIUS クライアントとサーバはこの秘密キーを使用します。この秘密キーは、RADIUS サーバと RADIUS クライアント(Content Engine)の両方で設定する必要があります。これは、RADIUS クライアントがこの RADIUS キーを使用して、認証パケットの暗号化および復号化を行うためです。

認証サーバは、NTLM、RADIUS、および LDAP に対しては host オプションを、また TACACS+ に対しては server hostname オプションを使用して指定できます。

NTLM では、2 台の認証サーバを指定できます。

LDAP では、2 台の認証サーバを指定できます。

RADIUS では、5 台の認証サーバを指定できます。

TACACS+ では、3 台の認証サーバを指定できます。

これらの追加されたサーバはバックアップ認証サーバとして機能し、プライマリ サーバが使用できないときにのみ、使用されます。Content Engine がどのサーバにも接続できない場合は、認証は行われず、以前に認証されていなかったユーザはアクセスを拒否されます。


) HTTP 認証機能である RADIUS および LDAP は、Cache ソフトウェア 2.x リリースに組み込まれました。それぞれ radius-server コマンドと ldap コマンドを使用します。

ACNS 5.x ソフトウェアでは、radius-server authtimeout オプション、および ldap authcache max-entriesldap authcache auth-timeout オプションが削除され、それぞれ http authentication cache max-entries コマンドと timeout コマンドにより設定できるようになりました。ldap client auth-header オプションが削除され、このオプションは、http authentication header コマンドを使用して設定できます。multi-user-promptオプションが削除され、代わりにhttp avoid-multiple-user- prompts オプションが使用されるようになりました。さらに、radius-server コマンドの exclude オプションも削除されました。radius-server exclude の代わりに、rule no-auth domain コマンドが使用されるようになりました。しかし、multi-user-prompt オプションの代わりに使用できるものはありません。ldap server コマンドには、enableversion のオプションが追加されました。


ユーザが TACACS+、LDAP、NTLM、または RADIUS のサーバを介して認証されると、そのユーザに対して Content Engine が生成したすべてのトランザクション ログにユーザ情報が記録されます。Content Engine がプロキシ モードで動作している場合、ユーザ ID がトランザクション ログに記録されます。Content Engine が透過モードで動作している場合は、代わりにユーザの IP アドレスが記録されます。 transaction-logs sanitize コマンドが開始される場合、ユーザ情報は抑制されます。トランザクション ロギングの詳細は、「モニタリングおよびトラブルシューティング」を参照してください。

HTTP 認証をローカルに配置されている Content Engine 上で設定するための CLI 使用例は、次のとおりです。

次の例では、LDAP サーバ デーモン用のホストが設定されます。

ContentEngine(config)# ldap server host www.someDomain.com port 390
 

次の例では、RADIUS 認証サーバ用のホストが設定されます。

ContentEngine(config)# radius-server 172.16.90.121
 

次の例では、認証キャッシュ内でエントリが有効である時間の長さが設定されます。

ContentEngine(config)# http authentication cache timeout 1000
 

次の例では、Content Engine が、エンド ユーザに認証のためのクレデンシャル情報(ユーザ ID とパスワード)を要求する際に、ヘッダー 407 を使用することを指定します。

ContentEngine(config)# http authentication header 407
ContentEngine(config)# ldap server host www.someDomain.com port 390

) HTTP 要求認証をローカルに配置されている Content Engine 上に設定する詳細については、「HTTP 要求認証の設定」を参照してください。


Content Engine が HTTP 要求認証用に設定されている場合、どのように作動するかについての基本情報は、次を参照してください。

「透過モードの HTTP 要求認証の概要」

「透過モードでの階層化キャッシングの概要」

「プロキシ サーバ モードで作動する場合の HTTP 要求認証の概要」

ローカルに配置されている Content Engine 上でサポートされている各種タイプの HTTP 要求認証方式に関する情報は、次を参照してください。

「RADIUS HTTP 要求認証の設定」

「TACACS+ HTTP 要求認証の設定」

「NTLM HTTP 要求認証の設定」

「LDAP HTTP 要求認証の設定」

透過モードの HTTP 要求認証の概要

Content Engine が透過モードで作動し、HTTP 要求認証用に設定されているときに、次に示されているイベントが発生するのは、次の(a)、(b) のいずれかの場合です。(a) Content Engine がリダイレクトされた要求をクライアントから受け取る場合、(b) アップストリーム プロキシがないため、 http authentication header コマンド パラメータが 401 (Unauthorized) に設定されている場合。

1. Content Engine は認証キャッシュを検索して、ユーザの IP アドレスが以前に認証されているかどうかを確認します。

2. 情報が一致した場合、Content Engine は要求を通常どおり処理します。

3. 最初の段階で情報が一致しない場合、Content Engine は HTTP ヘッダーをチェックし、Authentication ヘッダー内にあるユーザ情報を検索します。

4. ユーザ情報がない場合、Content Engine は401(Unauthorized)メッセージをクライアントに戻します。

5. クライアントは、ユーザ情報を含めた要求を再送します。

6. Content Engine は認証サーバに要求を送信して、このユーザのエントリを検索します。

7. サーバで情報が一致した場合、Content Engine はこの要求を通常どおり処理し、クライアントの IP アドレスを認証キャッシュに保存します。

8. サーバで情報が一致しなかった場合、Content Engine は再度 401(Unauthorized)メッセージをクライアントに戻します。

透過モードでは、Content Engine は、クライアントの IP アドレスを認証データベースへのキーとして使用します。

透過モードでログイン認証を使用している場合は、 http authentication cache timeout コマンドを使用して、AuthTimeout 時間を短く設定することをお勧めします。また、IP アドレスの再割り当てが必要です。この再割り当てを行わないと、別のユーザが、認証済みのデバイス(PC、ワークステーションなど)を使用してインターネットにアクセスできてしまいます。AuthTimeout 値を短く設定すると、ユーザが認証済みのデバイスを使用してアクセスする可能性が少なくなります。Content Engine がプロキシ モードで作動しているときは、ユーザ ID とパスワードを使用してユーザを認証できます。

透過モードでの階層化キャッシングの概要

Content Engine が透過モードで作動しているとき、ユーザの IP アドレスは、認証 キャッシュに対するキーとして使用されます。Content Engine は、必ず最初に X-FORWARDED-For ヘッダを探し、次にソースの IP アドレスを探します。ここで、 http append x-forwarded-for-header コマンドを使用して、CE1 上の append x-forwarded-for ヘッダーを設定して、CE2 が CE1 IP アドレスだけでなく、そのクライアントの IP アドレスも認識できるようにします。

ここでは、CE1 が X-Forwarded-For ヘッダーを作成しない場合(たとえば、CE1 が Cisco Content Engine ではなく、このヘッダーをサポートしない場合)、CE2 での認証は行われません。

アップストリーム プロキシがある透過モードでの、階層化キャッシングと Content Engine

2 台の Content Engine があるトポロジーにおいて、CE1 が透過モードで作動し、CE2 がプロキシ モードで作動しており、すべてのユーザのブラウザが、CE2 をプロキシとして指定している場合を想定します。

ブラウザの要求はプロキシに送信するように設定されているため、HTTP 407 メッセージが、CE1 から各ユーザにクレデンシャル情報を要求するプロンプトとして戻されます。407 メッセージを使用することにより、送信元 IP アドレスに関連する認証問題は回避されます。代わりに、ユーザ名とパスワードが使用されます。

このモードでは、HTTP 401 メッセージを使用するときよりもセキュリティが向上します。Content Engine は、アドレス形式をチェックし、アップストリーム プロキシが存在するかどうかを判別します。アップストリーム プロキシが存在する場合、Content Engine は HTTP 407 メッセージを使用して、透過モードで動作しているときであっても、ユーザに証明情報を要求するプロンプトを送信します。

プロキシ サーバ モードで作動する場合の HTTP 要求認証の概要

Content Engine がプロキシ サーバ モードで作動し、HTTP 要求認証用に設定されているときに、次に示されているイベントが発生するのは、次の 2 つのシナリオのうちいずれかが当てはまる場合です。(a) Content Engine がプロキシ スタイルの要求をクライアントから受け取る場合、または (b) Content Engine が透過的な(WCCP スタイル)要求をクライアントから受け取り、アップストリーム プロキシがあるために、Content Engine の http authentication header コマンド パラメータが、407 (Proxy Authorization Required) に設定されている場合。

1. Content Engine は、クライアント要求の HTTP ヘッダーをチェックし、Proxy-Authorization ヘッダーにあるユーザ情報を検索します。

2. ユーザ情報がない場合、Content Engine は 407 メッセージをクライアントに戻します。

3. クライアントは、ユーザ情報を含めた要求を再送します。

4. Content Engine は、ユーザ ID とパスワードに基づいて認証キャッシュを検索して、クライアントが以前に認証されているかどうかを確認します。

5. 情報が一致した場合、要求は通常どおり処理されます。

6. 情報が一致しなかった場合、Content Engine は認証サーバに要求を送信して、このクライアントのエントリを検索します。

7. サーバ上で情報が一致した場合、Content Engine はこの要求を通常どおり処理し、クライアントのユーザ ID とパスワードを認証キャッシュに保存します。

8. サーバ上で情報が一致しなかった場合、Content Engine は再度 407 メッセージをクライアントに戻します。

プロキシ モードでの階層化キャッシングの概要

ある企業の社員が複数の営業所で勤務している場合の例です。この場合、1 台の Content Engine(CE1)をユーザが勤務する特定の営業所に配置し、CE1 をプロキシ モードに設定できます。もう 1 台のプロキシ モードで作動する Content Engine(CE2)、またはもう 1 台の HTTP 準拠プロキシ装置をアップストリームに配置し、Content Engine またはプロキシ装置の両方に対して、ログイン認証を行う目的で TACACS+、NTLM、RADIUS、または LDAP のサーバを利用できます。


http append proxy-auth-header コマンドが、ダウンストリームの Content Engine 上で設定される必要があります。アップストリームの Content Engine で必要とするプロキシ認証情報が、ダウンストリームの Content Engine によって HTTP 要求から取り除かれないようにするためです。ダウンストリームの Content Engine ごとに、最高 8 個までのアップストリーム IP アドレスを設定できます。


ある営業所のユーザ 1 がインターネットにアクセスし、コンテンツが CE1 のキャッシュに保存されていても、他の営業所のユーザは認証されていない場合、このコンテンツを利用できません。コンテンツを利用するには、その営業所のローカル ユーザは、CE1 で認証される必要があります。

CE1 と CE2 の両方が認証サーバに接続され、ユーザを認証する場合、営業所のユーザ 2 が初めてインターネット コンテンツを要求する際に、CE1 はその要求に応答して、認証失敗の応答(プロキシ モードの場合は HTTP 407、透過モードの場合は HTTP 401)を戻します。ユーザ 2 は、ユーザ ID とパスワードを入力すると、元の要求が証明情報を含めて繰り返されます。CE1 は、ユーザ 2 を認証するために、HTTP 要求認証サーバに問い合わせます。

認証が成功し、キャッシュ ミスが発生すると、このクレデンシャル情報付きの要求は CE2 に転送されます。CE2 もユーザ 2 を認証するために、認証サーバに問い合わせます。認証が成功すると、CE2 はその要求を処理してキャッシュから配信するか、その要求をオリジン サーバに転送します (このクレデンシャルの転送機能は、デフォルトでは設定されていません。証明書を転送する場合は、 http append proxy-auth-header host CE2ipaddress コマンドを使用して、証明書の転送を明示的に設定する必要があります)。

これで、ユーザ 2 の認証情報は、CE1 と CE2 の両方の認証キャッシュに保存されます。CE1 も CE2 も、ユーザ 2 からの以降の要求に対しては、認証サーバに問い合わせる必要がありません。ただし、ユーザ 2 のエントリの有効期限が切れている場合や、エントリが認証キャッシュから削除されている場合を除きます。

ここでは、CE1 と CE2 がユーザの認証に同じ方法を使用していると想定しています。特に、両方の Content Engine は、ユーザのクレデンシャル情報(ユーザ ID とパスワード)が同じ方法でエンコードされていると想定しています。


ヒント 認証がダウンストリームで行われた後、アップストリームの Content Engine で認証を行わない場合は、rule no-auth コマンドを使用して、ダウンストリーム Content Engine の IP アドレスを除外することができます。


ログイン認証および許可の設定

ローカルに配置された Content Engine に対して、ログイン認証および許可を設定する手順は、次のとおりです。

1. Content Engine に対して設定する、ログイン認証要求時に使用されるログイン認証スキーム(たとえば、ローカル データベースをプライマリ ログイン データベースとし、RADIUS 認証サーバをセカンダリ認証サーバとする)を決定します。

2. ログイン認証サーバの設定値を Content Engine 上で設定します(リモート認証データベース リストを使用する場合)。

たとえば、Content Engine がログイン要求の認証に使用するリモート RADIUS サーバ、または TACACS+ サーバの IP アドレスを指定します。このトピックに関する詳細は、次項(「Content Engine に対する認証サーバの設定」)を参照してください。

3. Content Engine がログイン要求の処理に使用するログイン認証の設定スキームを指定します。

ログイン認証スキームを指定します。

ログイン許可スキームを指定します。

ログイン認証サーバのフェールオーバー スキーム(オプション)を指定します。

たとえば、ログイン要求を処理するのに Content Engine がどの認証データベースをチェックするかを指定します。詳細は、「ログイン認証および許可スキームの指定とイネーブル化」を参照してください。


注意 ローカル認証および許可をディセーブルにする場合は、事前に、RADIUS または TACACS+ 認証が正しく設定され動作していることを確認してください。RADIUS または TACACS+ が正しく設定されていない場合、あるいは RADIUS サーバまたは TACACS+ サーバがオンラインになっていない場合に、ローカル認証をディセーブルにすると Content Engine にログインできないことがあります。

ローカル認証がディセーブルになっているときに、他の認証方法をすべてディセーブルにすると、ローカル認証は自動的に再度イネーブルになります。

Content Engine に対する認証サーバの設定

ここでは、ローカルに配置された Content Engine に認証サーバ設定値を指定する方法について説明します。

「Content Engine に対する RADIUS 認証サーバの設定」

「Content Engine に対する TACACS+ 認証サーバの設定」

Content Engine に対する RADIUS 認証サーバの設定

RADIUS 認証のクライアントは、ACNS 5.x ソフトウェアを実行する Content Engine 上に位置します。これらのクライアントは、可能な場合、中央(リモート)の RADIUS サーバに認証要求を送信します。このサーバには、ログイン認証情報とネットワーク サービス アクセス情報が入っています。

RADIUS 認証をローカルに配置された Content Engine で設定するには、一連の RADIUS 認証サーバの設定値を Content Engine 上で設定する必要があります。Content Engine GUI または CLI を使用して、ローカルに配置された Content Engine に対して、この一連の RADIUS 認証サ―バの設定を行うこともできます。

表 7-4 では、これらの設定値について説明しています。

 

表 7-3 ローカルに配置された Content Engine に対する RADIUS 認証設定値

設定値
説明

RADIUS サーバ

Content Engine が RADIUS 認証に使用する RADIUS サーバを指定します。Content Engine で、指定した RADIUS サーバを使用するには、RADIUS サーバの IP アドレスまたはホスト名およびポート情報を入力します。5 つの異なるホストを指定できます。以前の RADIUS の配置には、ポート番号 1645 を使用していましたが、現在の公式な RADIUS 用のポート番号は 1812 です。5 つの異なるポート番号の使用が可能です。

RADIUS キー

RADIUS キーは、RADIUS クライアント(ローカルに配置された Content Engine)と RADIUS サーバ間のすべての通信の暗号化と認証に使用されます。このキーには、最大 15 文字まで指定できます。デフォルトは指定されていません。


ヒント 同一の RADIUS キーが RADIUS サーバ上でイネーブルになっていることを確認してください。

RADIUS タイムアウト時間

Content Engine が、タイムアウトを宣言するまで、指定した RADIUS 認証サーバから応答を待つ秒数。範囲は 1 ~ 20秒です。デフォルト値は 5秒です。

RADIUS 再送信回数

RADIUS タイムアウト時間を超過した場合、Content Engine が接続を RADIUS に再送信する回数。範囲は 1 ~ 3 回です。デフォルト値は 2 回です。

これら RADIUS 認証の設定値を Content Engine 上で設定後、次のタイプの RADIUS 認証を Content Engine 上でイネーブルにできます。

RADIUS ログイン(ユーザ)認証

RADIUS ユーザ認証(認証設定)

RADIUS HTTP 要求認証

RADIUS 認証をログイン(ユーザ)認証または許可、あるいはその両者をイネーブルにする方法についての情報は、「RADIUS ログイン認証および許可のイネーブル化とディセーブル化」を参照してください。

Content Engine GUI を使用した RADIUS 認証の設定

ローカルに配置された Content Engine 上に、Content Engine GUI を使用して RADIUS 認証を設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > RADIUS の順に選択します。RADIUS authentication settings ウィンドウが表示されます(図 7-5 を参照)。

図 7-5 RADIUS Authentication Settings ウィンドウ

 


) RADIUS authentication settings ウィンドウにアクセスするには、System > Authentication の順に選択し、表示された Authentication Configuration ウィンドウ(図 7-2)にある RADIUS リンクをクリックします。


ステップ 2 Enable RADIUS On オプション ボタンをクリックして、この Content Engine 上で RADIUS 認証をイネーブルにします。

ステップ 3 RADIUS authentication settings ウィンドウを使用して、その他の RADIUS 認証の設定値を指定します。フィールドに関する詳細は、 表 7-3 を参照するか、あるいはこのウィンドウの HELP ボタンをクリックします。


 

これで、この Content Engine に対して、「RADIUS ログイン認証および許可のイネーブル化とディセーブル化」で説明されているように、RADIUS のログイン(ユーザ)認証および許可をイネーブルにできます。

CLI コマンドを使用した RADIUS 認証の設定

CLI を使用して RADIUS 認証をローカルに配置された Content Engine 上で設定する手順は、次のとおりです。


ステップ 1 グローバル設定モードから、 radius-server host コマンドを使用して、1 台または複数台の RADIUS サーバを指定します。オプションで、サーバで使用する宛先 UDP ポートを指定します。デフォルトのポートは 1645 です。

ContentEngine(config)# radius-server host ip_addr [auth-port port]
 

次の例は、RADIUS サーバを 172.16.52.3 に指定する方法を示しています。

ContentEngine(configure)# radius-server 172.16.52.3
 

ステップ 2 radius-server key コマンドを使用して、RADIUS キーを Content Engine 上に指定します。

ContentEngine(configure)# radius-server key myradiuskey
 

ステップ 3 radius-server timeou t コマンドを使用して、RADIUS タイムアウト時間を指定します。

たとえば、Content Engine が、10 秒間待機しても RADIUS サーバからの応答を受信しない場合、タイムアウトを宣言します。

ContentEngine(config)# radius-server timeout 10
 

ステップ 4 radius-server retransmit コマンドを使用して、RADIUS 再送信回数を指定します。

たとえば、Content Engine が、RADIUS タイムアウトが発生した場合、3 回 RADIUS サーバに再送信を行うように設定します。

ContentEngine(config)# radius-server retransmit 3

) RADIUS 認証設定(たとえば、RADIUS キー)の詳細は、表 7-3 を参照してください。tacacs サーバ コマンドの詳細は、『Cisco ACNS Software Command Reference Guide, Release 5.1』を参照してください。


次の例では、RADIUS クライアントを Content Engine 上でイネーブルにし、認証用のリモート RADIUS サーバを指定します。さらに RADIUS キーを Content Engine 上で指定し、再送信のデフォルト値を受け入れ、 domain name mydomain.net ドメインを RADIUS 認証から除外しています。設定は、 show radius-server および show rule all コマンドを使用して表示できます。

ContentEngine(config)# radius-server enable
ContentEngine(config)# radius-server host 172.16.90.121
ContentEngine(config)# radius-server key myradiuskey
ContentEngine(config)# rule enable
ContentEngine(config)# rule no-auth domain mydomain.net
 


 

これで、この Content Engine に対して、「RADIUS ログイン認証および許可のイネーブル化とディセーブル化」で説明されているように、RADIUS をログイン(ユーザ)認証および許可の目的でイネーブルにできます。

Content Engine に対する TACACS+ 認証サーバの設定

TACACS+ 認証をローカルに配置された Content Engine に設定するには、一連の TACACS+ 認証の設定値を Content Engine 上で設定する必要があります。Content Engine GUI または CLI を使用して、ローカルに配置された Content Engine に対して、この一連の TACACS+ 認証の設定を行うこともできます。


) TACACS+ サーバが Content Engine 上に設定されていない場合、TACACS+ 認証は実行されません。


表 7-4 では、これらの設定値について説明します。

 

表 7-4 ローカルに配置された Content Engine での TACACS+ 認証設定値

設定値
説明

TACACS+ サーバ

Content Engine が TACACS+ 認証に使用する TACACS+ サーバを指定します。プライマリ TACACS+ サーバを明示的に指定します。明示的に指定されていない場合、Content Engine が独自の判断を行います。プライマリ TACACS+ サーバ 1 台とバックアップ TACACS+ サーバ 2 台を設定できます。TACACS+ は、サービス仕様に基づき、標準のポート番号 49 を通信用に使用します。

TACACS+ キー

Content Engine が TACACS+ サーバとの通信用に使用する秘密キー。TACACS+ キーの最大文字数は、印刷可能 ASCII 文字で 99 文字を超えない数です(タブを含めない)。空白のキー文字列がデフォルトです。キー文字列の先頭のスペースはすべて無視され、中間および最後のスペースは無視されません。キー内にスペースがある場合でも、二重引用符は不要です。二重引用符がキーの一部であるときは、記入されます。デフォルト値はありません。


ヒント 同一の TACACS+ キーが TACACS+ サーバに設定されていることを確認してください。

TACACS+ タイムアウト時間

Content Engine が、タイムアウトを宣言するまで、指定した TACACS+ 認証サーバから応答を待つ秒数。範囲は 1 ~ 20 秒です。デフォルト値は 5秒です。

TACACS+ 再送信回数

TACACS+ タイムアウト時間が超過した場合、Content Engine が自身の接続要求を TACACS+ に再送信する回数。範囲は 1 ~ 3 回です。デフォルト値は 2 回です。

TACACS+ パスワード認証方式

パスワード認証用のメカニズムを指定します。デフォルトでは、PAP プロトコルがパスワード認証用メカニズムとなっています。これ以外のオプションでは、ASCII 平文テキストをパスワード認証メカニズムとして使用するオプションがあります。

これら TACACS+ 認証の設定値を Content Engine 上で設定後、次のタイプの TACACS+ 認証を Content Engine 上でイネーブルにできます。

TACACS+ ログイン(ユーザ)認証

TACACS+ ユーザ認証(認証設定)

TACACS+ HTTP 要求認証

Content Engine GUI を使用した TACACS+ 認証の設定

ローカルに配置された Content Engine 上に、Content Engine GUI を使用して TACACS+ 認証を設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 System > TACACS+ の順に選択します。TACACS+ authentication settings ウィンドウが表示されます(図 7-6 を参照)。

図 7-6 TACACS+ Authentication Settings ウィンドウ

 


) TACACS+ authentication settings ウィンドウにアクセスするには、System > Authentication の順に選択し、表示された Authentication Configuration ウィンドウ(図 7-2)にある TACACS+ リンクをクリックします。


ステップ 2 Enable TACACS Authentication On オプション ボタンをクリックして、この Content Engine 上で TACACS+ HTTP 認証をイネーブルにします。

ステップ 3 TACACS+ ウィンドウを使用して、その他 TACACS+ 認証の設定値を指定します。フィールドでの情報の詳細は、 表 7-3 を参照するか、あるいはこのウィンドウの Help ボタンをクリックします。

これでこの Content Engine に対して、「TACACS+ ログイン認証および許可のイネーブル化とディセーブル化」で説明されているように、TACACS+ をログイン(ユーザ)認証および許可の目的でイネーブルにできます。


 

CLI コマンドを使用した TACACS+ 認証の設定

CLI を使用して TACACS+ 認証をローカルに配置された Content Engine で設定する手順は、次のとおりです。


ステップ 1 グローバル設定モードから、 tacacs server コマンドを使用して、1 台または複数台の TACACS+ サーバを指定します。

ContentEngine(config)# tacacs server ip_addr [primary]
 

次の例では、ある特定の TACACS+ サーバをプライマリ サーバに指定する方法を示しています。

ContentEngine(config)# tacacs server 172.16.50.1 primary
 

次の例では、ある特定の TACACS+ サーバをバックアップ サーバに指定する方法を示しています。この場合、 primary オプションを指定する必要はありません。

ContentEngine(config)# tacacs server 172.16.50.2
 

ステップ 2 tacacs key コマンドを使用して、TACACS+ キーを指定します。

ContentEngine(config)# tacacs key key
 

ステップ 3 tacacs timeout コマンドを使用して、TACACS+ タイムアウト時間を指定します。たとえば、Content Engine が、15 秒間待機しても TACACS+ サーバからの応答を受信しない場合、タイムアウトを宣言するよう設定します。

ContentEngine(config)# tacacs timeout 15
 

ステップ 4 tacacs retransmi t を使用して、TACACS+ 再送信回数を指定します。たとえば、Content Engine が、TACACS+ タイムアウトが発生した場合、もう 1 度 TACACS+ サーバに再送信を行うように設定します。

ContentEngine(config)# tacacs retransmit 1
 

ステップ 5 tacacs password コマンドを使用して、TACACS+ パスワード認証用のメカニズムを指定します。たとえば、 ASCII キーワードを指定することで、このメカニズムを ASCII 平文テキストとして使用します。

ContentEngine(config)# tacacs password ascii

) TACACS+ 認証設定(たとえば、TACACS+ キー)の詳細は、表 7-4 を参照してください。tacacs server コマンドの詳細は、『Cisco ACNS Software Command Reference Guide, Release 5.1』を参照してください。


次の例では、「spearhead」というホスト名を持つ TACACS+ サーバがプライマリ TACACS+ サーバとして設定されており、Content Engine は、その TACACS+ サーバ(「spearhead」という名)と同一のキー( human789 )を使用するように設定されています。この例では、デフォルトのタイムアウト時間、再送信回数、およびパスワード タイプが変更されています。この例はまた、Content Engine 上での現行の TACACS+ 設定を表示するのに、show tacacs コマンドを使用する方法についても示しています。

ContentEngine(config)# tacacs host spearhead primary
ContentEngine(config)# tacacs key human789
ContentEngine(config)# tacacs timeout 10
ContentEngine(config)# tacacs retransmit 5
ContentEngine(config)# tacacs password ascii
ContentEngine(config)# exit
ContentEngine# show tacacs
Login Authentication for Console/Telnet Session: enabled (secondary)
Configuration Authentication for Console/Telnet Session: enabled (secondary)
 
TACACS+ Configuration:
---------------------
TACACS+ Authentication is off
Key = *****
Timeout = 5
Retransmit = 2
Password type: ascii
 
Server Status
---------------------------- ------
10.107.192.148 primary
10.107.192.168
10.77.140.77
 


 

これで、この Content Engine に対して、「TACACS+ ログイン認証および許可のイネーブル化とディセーブル化」で説明されているように、TACACS+ をログイン(ユーザ)認証および許可の目的でイネーブルにできます。

ログイン認証および許可スキームの指定とイネーブル化

この項では、ローカルに配置された Content Engine 上にログイン認証と許可スキーム(認証設定)を定義および変更する方法について説明します。

「ローカル ログイン認証および許可のイネーブル化とディセーブル化」

「RADIUS ログイン認証および許可のイネーブル化とディセーブル化」

「TACACS+ ログイン認証および許可のイネーブル化とディセーブル化」


注意 ローカル認証および許可をディセーブルにする場合は、RADIUS または TACACS+ 認証が正しく設定され動作していることを確認してください。RADIUS または TACACS+ が正しく設定されていない場合、あるいは RADIUS サーバまたは TACACS+ サーバがオンラインになっていない場合に、ローカル認証をディセーブルにすると Content Engine にログインできないことがあります。

使用上のガイドライン

認証設定の方式をローカルに配置された Content Engine に対して定義または変更する場合には、次の点に注意してください。

ユーザ アクセス管理に外部のアクセス サーバを使用するか、または内部(ローカル)の Content Engine ベースの AAA システムを使用するかの選択は、Content Engine GUI または CLI を使用して行うことができます。

次の複数の認証と許可の方式を組み合わせて、ローカルに配置された Content Engine に対するアクセスの制御および権限の設定を行うことができます。

ローカル認証および許可

RADIUS 認証および許可

TACACS+ 認証および許可

デフォルトでは、Content Engine はローカル データベースを使用して認証および許可権限を取得します。ローカル認証を他の認証方式とともに使用可能にし、優先順位のフラグを設定していない場合、ローカル認証が常に実行されます。コンソールおよび Telnet 接続では、複数の異なる認証方式を指定できません。

ログイン認証および許可(設定)オプションを設定するには、グローバル設定モードで authentication コマンドを使用します。

authentication { configuration { local | radius | tacacs } enable [ primary | secondary | tertiary ]} | fail-over server-unreachable | login { local | radius | tacacs } enable [ primary | secondary | tertiary ]}

表 7-5 では、認証のグローバル設定コマンドに関するパラメータについて説明しています。

 

表 7-5 認証 CLI コマンドのパラメータ

パラメータ
説明

configuration

コンフィギュレーション認証(許可)を設定する。

local

認証用のローカル データベースを選択する。

radius

認証用 RADIUS サーバを選択する。

tacacs

認証用 TACACS+ サーバを選択する。

enable

設定およびログイン認証用のデータベースをイネーブルにする。

primary

(オプション)選択した認証データベースをプライマリとして設定する。

secondary

(オプション)選択した認証データベースをセカンダリとして設定する。

tertiary

(オプション)選択した認証データベースをターシャリ(3 次)として設定する。

fail-over server-unreachable

現行の認証サーバが到達不能の場合にのみ、その次の認証サーバに照会する。

login

ログイン認証を設定する。

authentication グローバル設定コマンドは、ローカルに配置された Content Engine へのログインおよび設定のアクセスを決定する、両方の認証方式を設定します。

authentication login コマンドは、ユーザが Content Engine に対する何らかのレベルのアクセス許可をもっているかどうかを判別します。 authentication configuration コマンドにより、ユーザに Content Engine へのアクセス権(設定のアクセス)を与えます。

authentication login local コマンドと authentication configuration local コマンドは、認証と許可にローカル データベースを使用します。

authentication login は、ユーザが Content Engine に対する何らかのレベルのアクセス許可をもっているかどうかを判別するためのログイン認証方式を指定します。

authentication configuration コマンドは、認証済みのユーザに対する権限(Content Engine へのアクセス権限のレベル)を判別します。

authentication login tacacs コマンド、および authentication configuration tacacs コマンドは、 ログイン認証および許可に TACACS+ リモート サーバを使用します。

authentication login tacacs コマンド、および authentication c onfiguration tacacs コマンドは、 ユーザ アクセス レベルの判別に TACACS+ リモート サーバを使用します。

authentication login radius コマンド、および authentication configuration radius コマンドは、 ユーザ アクセス レベルの判別に RADIUS リモート サーバを使用します。

デフォルトでは、ログインおよび設定に対して、ローカル方式がイネーブルになり、TACACS+ と RADIUS の 2 方式はディセーブルになります。TACACS+ と RADIUS がディセーブルのときは、自動的にローカル データベースがイネーブルになります。TACACS+、RADIUS、およびローカル方式を同時にイネーブルにすることができます。 primary オプションは、ログインと設定の際に最初に実行する方式を指定します。 secondary オプションは、最初の方式が失敗した場合に実行する方式を指定します。tertiary オプションは、最初の方式と 2 番目の方式が両方失敗したときに使用する方式を指定します。 authentication login コマンド、または authentication configuration コマンドの方式がすべて primary に設定されている場合、あるいはすべて secondary または tertiary に設定されている場合、ローカルが最初に試行されます。次に TACACS+、その次に RADIUS の順に試行されます。

次の例では、まず、ローカル、TACACS+、および RADIUS の認証と許可をイネーブルにしています。次に、TACACS+ を最初に使用する方式に設定し、ローカルを TACACS+ 方式が失敗したときの第 2 の方式に設定し、最後に RADIUS をローカルと TACACS+ の両方が失敗したときの第 3 の方式に設定しています。

ContentEngine(config)# authentication login tacacs enable primary
ContentEngine(config)# authentication login local enable secondary
ContentEngine(config)# authentication login radius enable tertiary
ContentEngine(config)# authentication configuration tacacs enable primary
ContentEngine(config)# authentication configuration local enable secondary
ContentEngine(config)# authentication configuration radius enable tertiary
 

次は、 show authentication user コマンドの例です。

ContentEngine# show authentication user
Login Authentication: Console/Telnet Session
----------------------------- -----------------------
local enabled (secondary)
radius enabled (tertiary)
tacacs enabled (primary)
 

tacacs グローバル設定コマンドと TACACS+ サーバでは、TACACS+ 認証および許可の方式を使用するように設定する必要があります。TACACS+ サーバの設定に関する詳細は、「Content Engine に対する TACACS+ 認証サーバの設定」を参照してください。TACACS+ を Content Engine 上でイネーブルにする詳細は、「TACACS+ ログイン認証および許可のイネーブル化とディセーブル化」を参照してください。


authentication login radius コマンド、および authentication configuration radius コマンドは、 ユーザ アクセス レベルの判別に RADIUS リモート サーバを使用します。


radius-server グローバル設定コマンドと RADIUS サーバでは、RADIUS 認証と許可の方式を使用するように設定する必要があります。RADIUS サーバの設定に関する詳細は、「Content Engine に対する RADIUS 認証サーバの設定」を参照してください。RADIUS を Content Engine 上でイネーブルにする詳細は、「RADIUS ログイン認証および許可のイネーブル化とディセーブル化」を参照してください。


デフォルトでは、ログインおよび設定に対して、ローカル方式がイネーブルになり、TACACS+ と RADIUS の 2 方式はディセーブルになります。TACACS+ と RADIUS がイネーブルのときは、ローカルの方式が自動的にイネーブルになります。TACACS+、RADIUS、およびローカル方式を同時にイネーブルにすることができます。

認証設定は次に適用されます。

コンソールおよび Telnet 接続

Secure FTP(SFTP)、SSH(SSH Version 1)、および Websense サーバ アクセス。

ローカルに配置された Content Engine へのコンソール接続、および Telnet 接続に対して異なる認証方式を指定できません。

Content Engine(TACACS+ クライアント)上で RADIUS キーまたは TACACS+ キーを設定する場合は、必ず RADIUS サーバまたは TACACS+ サーバで同一のキーを設定してください。

複数の RADIUS サーバまたは TACACS+ サーバを設定する場合は、最初に設定されているサーバがプライマリ サーバになり、このサーバに最初に認証要求が送信されます。セカンダリ サーバおよびターシャリ(3 次)サーバを認証および許可用に指定することもできます。

primary secondary、 または tertiary キーワードを authentication グローバル設定コマンドで使用して、サーバをプライマリ、セカンダリ、ターシャリとして指定できます(「認証設定方式を定義する CLI の例」の例を参照)。

Content Engine GUI からも、サーバをプライマリ、セカンダリ、またはターシャリとして指定できます。 System > Authentication の順に選択し、次に該当するサーバの隣にあるドロップダウン リストから、 Primary、Secondary、または Tertiary を選択します。(図 7-2 を参照)。

primary オプションにより、ログインおよび設定用の試行に対して、第 1 の優先順位と方式が指定されます。

secondary オプションのより、プライマリ方式が失敗した場合に使用する方式が指定されます。

tertiary オプションにより、最初の方式と 2 番目の方式が両方失敗したときに使用する方式が指定されます。

authentication login コマンドまたは authentication configuration コマンドの方式がすべて primary に設定されている場合、あるいはすべて secondary または tertiary に設定されている場合、ローカルが最初に試行されます。次に TACACS+、その次に RADIUS の順に試行されます。 authentication login コマンドまたは authentication configuration コマンドの優先順位が primary、secondary、または tertiary に設定されていない場合、ローカルが最初に試行され、次に TACACS+、その次に RADIUS の順に試行されます。

デフォルトでは、Content Engine はローカル データベースを使用して認証および許可権限を取得します。Content Engine は、すべてのデータベースがディセーブルであるかどうかを確認し、ディセーブルの場合、システムをデフォルトの状態に設定します。(このデフォルト状態に関する情報は、「デフォルトのログイン認証と許可の設定」を参照してください。)

認証は、「ログイン」とも呼ばれ、許可は図 7-2で示されているように、「設定」とも呼ばれます。「認証設定」という用語は、これ以降のこの章全体でログインおよび設定を集合的に呼ぶのに使用されます。


ヒント Content Engine GUI または CLI を使用して、ローカルに配置された Content Engine に認証設定の方式を設定することができます。認証設定の方式を指定した後、選択した認証設定に関係する設定値を定義する必要があります(たとえば、認証ログイン アクセスに対してプライマリ サーバとして使用する Content Engine が必要とする TACACS+ サーバの IP アドレス、またはホスト名を指定します)。


認証設定方式を定義する CLI の例

次の例では、まず、ローカル、TACACS+、および RADIUS の認証と許可をイネーブルにしています。次に、TACACS+ を最初に使用する方式に設定し、ローカルを TACACS+ 方式が失敗したときの第 2 の方式に設定し、最後に RADIUS をローカルと TACACS+ の両方が失敗したときの第 3 の方式に設定しています。

ContentEngine(config)# authentication login tacacs enable primary
ContentEngine(config)# authentication login local enable secondary
ContentEngine(config)# authentication login radius enable tertiary
ContentEngine(config)# authentication configuration tacacs enable primary
ContentEngine(config)# authentication configuration local enable secondary
ContentEngine(config)# authentication configuration radius enable tertiary
 

次は、 show authentication user コマンドの例です。

ContentEngine# show authentication user
Login Authentication: Console/Telnet Session
----------------------------- -----------------------
local enabled (secondary)
radius enabled (tertiary)
tacacs enabled (primary)
 
Configuration Authentication: Console/Telnet Session
----------------------------- -----------------------
local enabled (secondary)
radius enabled (tertiary)
tacacs enabled (primary)
 
 

TACACS+ 認証設定を含む、Content Engine の認証設定を表示するには、 show authentication user コマンドを使用します。たとえば、次のとおりです。

ContentEngine# show authentication user
Login Authentication: Console/Telnet Session
----------------------------- -----------------------
local disabled
radius enabled
tacacs enabled
 
Configuration Authentication: Console/Telnet Session
----------------------------- -----------------------
local disabled
radius enabled (tertiary)
tacacs enabled
ContentEngine#
 

ローカル ログイン認証および許可のイネーブル化とディセーブル化

ローカルに配置された Content Engine 上で認証および許可をイネーブル、またはディセーブルにするために、Content Engine GUI または CLI を使用できます。デフォルトでは、ログイン認証および許可(アクセス中の制御権限)はイネーブルになっています。


注意 ローカル認証および許可をディセーブルにする場合は、事前に、RADIUS または TACACS+ 認証が正しく設定され動作していることを確認してください。RADIUS または TACACS+ が正しく設定されていない場合、あるいは RADIUS サーバまたは TACACS+ サーバがオンラインになっていない場合に、ローカル認証をディセーブルにすると Content Engine にログインできないことがあります。

Content Engine GUI を使用したローカル認証および許可のイネーブル化とディセーブル化

ローカルに配置された Content Engine 上で、ローカル認証および許可を再度イネーブルにする手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 System > Authentication の順に選択します。Authentication Configuration ウィンドウが表示されます。(図 7-7 を参照)。

ステップ 2 ローカル ログイン認証を再度イネーブルにする手順は、次のとおりです。

a. Authentication Configuration ウィンドウの Enable Login の部分で、Local の隣りにある Enable ボックスにチェックマークを付けて、ローカル ログイン認証をイネーブルにします(図 7-7 を参照)。

b. デフォルトでは、ローカル データベースがログイン認証用のプライマリ データベースです。このデフォルト値を変更するには、もう 1 つのオプション(たとえば、 Secondary または Tertiary )を Local の隣りにあるドロップダウン リストから選択します。

図 7-7 ローカルに配置された Content Engine 上でのローカル ログイン認証の再イネーブル化

 

ステップ 3 ローカル ログイン許可を再度イネーブルにする手順は、次のとおりです。

a. Authentication Configuration ウィンドウで Enable Configuration window のところまでスクロールします。

b. Authentication Configuration ウィンドウの Enable Configuration の部分で Local の隣りにある Enable ボックスにチェックマークを入れて、ローカル許可を再度イネ―ブルにします。

c. デフォルトでは、Local データベースは、この Content Engine が許可用に使用するプライマリ データベースです。このデフォルト値を変更するには、もう 1 つのオプション(たとえば、 Secondary または Tertiary )を Local の隣りにあるドロップダウン リストから選択します。

ステップ 4 Update をクリックします。


 


) ローカル データベースをログイン認証データベースとしてディセーブルにするには、Authentication Configuration ウィンドウの Enable Login の部分にある Local の隣りの Enable ボックスのチェックマークを外します。

許可データベースとしてのローカル データベースをディセーブルにするには、Authentication Configuration ウィンドウの Enable Configuration の部分にある Local の隣りの Enable ボックスのチェックマークを外します。


CLI コマンドを使用するローカル認証および許可のイネーブル化とディセーブル化

デフォルトでは、ローカルに配置された Content Engine 上のローカル認証および許可はイネーブルになっています。

ローカルに配置された Content Engine 上で、ローカル認証および許可を再度イネーブルにするために CLI を使用する手順は、次のとおりです。


ステップ 1 グローバル設定モードから、 authentication login local コマンドを使用して、ローカル ログイン認証をイネーブルにします。たとえば、次のとおりです。

ContentEngine(config)# authentication login local enable
 

ステップ 2 グローバル設定モードから、 authentication configuration local コマンドを使用して、ローカル許可(アクセス時の権限制御)をイネーブルにします。たとえば、次のとおりです。

ContentEngine(config)# authentication configuration local enable
 


 


) ローカルに配置された Content Engine 上でローカル認証および許可をディセーブルにするには、no 形式の authentication コマンドを使用します(たとえば、ローカル認証をディセーブルにするのには、no authentication login local enable コマンドを使用します)。


RADIUS ログイン認証および許可のイネーブル化とディセーブル化

デフォルトでは、ローカルに配置された Content Engine 上の RADIUS 認証および許可はディセーブルになっています。RADIUS 認証と他の認証方式は同時にイネーブルにすることができます。最初に使用する方式を指定するには、 primary キーワードを使用します。ローカル認証がディセーブルになっているときに、他の認証方法をすべてディセーブルにすると、ローカル認証は自動的に再度イネーブルになります。

RADIUS と TACACS+ の両方を使用している場合、Content Engine に RADIUS 認証を最初に実行するように強制するには、 primary キーワードまたは Authentication Configuration ウィンドウのドロップダウン リスト( System >Authentication )を使用します。


) RADIUS 認証を Content Engine 上でイネーブルにする前に、少なくとも 1 台の RADIUS サーバを指定します。RADIUS サーバの指定については、「Content Engine に対する RADIUS 認証サーバの設定」を参照してください。


Content Engine GUI を使用した RADIUS のイネーブル化とディセーブル化

ローカルに配置された Content Engine 上で、RADIUS ログイン認証および許可をイネーブルまたはディセーブルにする手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 System > Authentication の順に選択します。Authentication Configuration ウィンドウが表示されます。

ステップ 2 RADIUS ログイン認証をこの Content Engine 上でイネーブルにする手順は、次のとおりです。

a. Authentication Configuration ウィンドウの Enable Login の部分で、 RADIUS の隣りにある Enable ボックスにチェックマークを付けて、RADIUS をログイン認証をイネーブルにします(図 7-8 を参照)。

b. RADIUS ドロップダウン リストを使用して、 RADIUS ログイン データベースが、このローカルに配置された Content Engine のプライマリ、セカンダリ、またはターシャリ認証データベースのいずれかであるかを指定します。

図 7-8 ローカルに配置された Content Engine 上での RADIUS ログイン認証のイネーブル化

 

ステップ 3 RADIUS 許可をこの Content Engine 上でイネーブルにする手順は、次のとおりです。

a. Authentication Configuration ウィンドウをスクロールして、Enable Configuration window を表示します。

b. Authentication Configuration ウィンドウの Enable Configuration の所で、 RADIUS の隣りにある Enable ボックスにチェックマークを付けて、RADIUS(リモート)認証をこの Content Engine 上でイネーブルにします。

c. RADIUS ドロップダウン リストを使用して、この RADIUS 認証データベースがこの Content Engine に対してプライマリ、セカンダリ、またはターシャリの認証データベースのいずれであるかを指定します。

ステップ 4 Update をクリックします。


 


) ログイン認証データベースとしてのリモート RADIUS データベースをディセーブルにするには、Authentication Configuration ウィンドウの Enable Login の部分にある RADIUS の隣りの Enable ボックスのチェックマークを外します。

許可データベースとしてのリモート RADIUS データベースをディセーブルにするには、Authentication Configuration ウィンドウの Enable Configuration 部分にある RADIUS の隣りの Enable ボックスのチェックマークを外します。


CLI コマンドを使用する RADIUS 認証および許可のイネーブル化とディセーブル化

ローカルに配置された Content Engine 上で、RADIUS 認証および許可をイネーブルにするために CLI を使用する手順は、次のとおりです。


ステップ 1 グローバル設定モードから、authentication login radius コマンドを使用して、RADIUS を通常のログイン モードに対してイネーブルにします。

ContentEngine(config)# authentication login radius enable [primary] [secondary] [tertiary]
 

たとえば次のように、Content Engine に RADIUS 認証を最初に実行(TACACS+ 認証を使用する前に実行)するよう強制します。

ContentEngine(config)# authentication login radius enable primary
 

ステップ 2 グローバル設定モードから、authentication configuration radius コマンドを使用して、RADIUS 許可をイネーブルにします。

ContentEngine(config)# authentication configuration radius enable [primary] [secondary] [tertiary]
 

たとえば次のように、Content Engine に RADIUS 許可を最初に実行(TACACS+ 許可を使用する前に実行)するよう強制します。

ContentEngine(config)# authentication configuration radius enable primary
 


 


) ローカルに配置された Content Engine 上で RADIUS 認証および許可をディセーブルにするには、no 形式の authentication コマンドを使用します(たとえば、RADIUS 認証をディセーブルにするのには、no authentication login radius enable コマンドを使用します)。


TACACS+ ログイン認証および許可のイネーブル化とディセーブル化

デフォルトでは、TACACS+ 認証および許可は、ローカルに配置された Content Engine 上でディセーブルになっています。Content Engine の GUI または CLI を使用して、TACACS+ 認証および許可をローカルに配置された Content Engine 上でイネーブルにできます。

RADIUS と TACACS+ の両方を使用している場合、 primary キーワードを使用して Content Engine 上で強制的に TACACS+ 認証を最初に実行できます。


) TACACS+ 認証を Content Engine 上でイネーブルにする前に、少なくとも 1 台の TACACS+ サーバを指定しておきます。TACACS+ サーバの指定については、「RADIUS HTTP 要求認証の設定」を参照してください。


Content Engine GUI を使用した TACACS+ のイネーブル化とディセーブル化

ローカルに配置された Content Engine 上で、TACACS+ 認証および許可をイネーブルにする手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 System > Authentication の順に選択します。Authentication Configuration ウィンドウが表示されます。

ステップ 2 TACACS+ ログイン認証をこの Content Engine 上でイネーブルにする手順は、次のとおりです。

a. Authentication Configuration ウィンドウの Enable Login の部分で、 TACACS+ の隣りにある Enable ボックスにチェックマークを付けて、TACACS+ をログイン認証としてイネーブルにします(図 7-9 を参照)。

b. TACACS+ ドロップダウン リストを使用して、TACACS+ ログイン データベースが、このローカルに配置された Content Engine に対してプライマリ、セカンダリ、またはターシャリ認証データベースのいずれであるかを指定します。

図 7-9 ローカルに配置された Content Engine 上での TACACS+ ログイン認証のイネーブル化

 

ステップ 3 TACACS+ 許可をこの Content Engine 上でイネーブルにする手順は、次のとおりです。

a. Authentication Configuration ウィンドウで Enable Configuration window のところまでスクロールします。

b. Authentication Configuration ウィンドウの Enable Configuration 部分で、 TACACS+ の隣りにある Enable ボックスにチェックを付けて、TACACS+(リモート)認証をこの Content Engine 上でイネーブルにします。

c. TACACS+ ドロップダウン リストを使用して、この TACACS+ 認証データベースがこの Content Engine に対してプライマリ、セカンダリ、またはターシャリ認証データベースのいずれかであるかを指定します。

ステップ 4 Update をクリックします。


 


) ログイン認証データベースとしてのリモート TACACS+ データベースをディセーブルにするには、Authentication Configuration ウィンドウの Enable Login 部分にある TACACS+ の隣りの Enable ボックスのチェックマークを外します。

許可データベースとしてのリモート TACACS+ データベースをディセーブルにするには、Authentication Configuration ウィンドウの Enable Configuration 部分にある TACACS+ の隣りの Enable ボックスのチェックマークを外します。


CLI コマンドを使用する TACACS+ 認証および許可のイネーブル化とディセーブル化

ローカルに配置された Content Engine 上で、TACACS+ 認証および許可をイネーブルにするために CLI を使用する手順は、次のとおりです。


ステップ 1 グローバル設定モードから、authentication login tacacs コマンドを使用して、TACACS+ を通常のログイン モードに対してイネーブルにします。

ContentEngine(config)# authentication login tacacs enable [primary] [secondary] [tertiary]
 

たとえば次のように、Content Engine に TACACS+ 認証を最初に行う(RADIUS 認証を使用する前に実行する)よう強制します。

ContentEngine(config)# authentication login tacacs enable primary
 

ステップ 2 グローバル設定モードから、authentication configuration tacacs コマンドを使用して、TACACS+ 許可をイネーブルにします。

ContentEngine(config)# authentication configuration tacacs enable [primary] [secondary] [tertiary]
 

たとえば次のように、Content Engine に TACACS+ 許可を最初に行う(RADIUS 許可を使用する前に実行する)よう強制します。

ContentEngine(config)# authentication configuration tacacs enable primary
 


 


) ローカルに配置された Content Engine 上で TACACS+ 認証および許可をディセーブルにするには、no 形式の authentication コマンドを使用します(たとえば、TACACS+ 認証をディセーブルにするのには、no authentication login tacacs enable コマンドを使用します)。


HTTP 要求認証の設定

これらの複数の認証と許可の方式のうち 1 つを設定して、ローカルに配置された Content Engine での HTTP 要求認証の管理を行うことができます。

「RADIUS HTTP 要求認証の設定」

「TACACS+ HTTP 要求認証の設定」

「NTLM HTTP 要求認証の設定」

「LDAP HTTP 要求認証の設定」


) Content Engine 上での NTLM サポートには、次の 3 つのサポートが含まれます。(1) NTLM エンド ツー エンド認証サポ―ト、(2) NTLM HTTP 要求認証、および (3) 認証用 NTLM グループ情報クエリーです。HTTP 要求認証では、ACNS 5.x ソフトウェアは NTLM v1 をサポートしています。エンド ツー エンド NTLM 認証では、NTLM v1 と v2 の両方がサポートされています。


使用上のガイドライン

HTTP 要求認証をローカルに配置された Content Engine 上で設定するときは、次のガイドラインに従ってください。

常に 1 つの HTTP 要求認証しかイネーブルにできません。

認証キャッシュに、すべての認証済みユーザを同時に保存するための容量が不足している場合、Content Engine は、まだタイムアウトになっていないエントリのうち、古いエントリから削除します。認証キャッシュのサイズ調整についての情報は、「HTTP 要求認証の設定」を参照してください。

グループ名ベースのアクセス リストを使用して、ある特定の Content Engine によってサービスされるコンテンツに対するグループ許可権限を定義できます。ある特定グループのメンバーには、NTLM または LDAP HTTP 要求認証サーバに対する認証が行われた後、自動的にグループ権限が割り当てれられます。このトピックに関する情報は、「NTLM HTTP 要求認証の設定」、および「LDAP HTTP 要求認証の設定」を参照してください。

LDAP 認証からドメインを除外するには、 rule no-auth domain コマンドを使用します。LDAP、RADIUS、または TACACS+ からの認証要求が発生するのは、要求が指定された no-auth パターンに一致しない場合だけです。


) HTTP 要求認証は、「ログイン認証と許可の概要」で示されるログイン(ユーザ)認証と許可のオプションの影響を受けません。


認証キャッシュ サイズの設定

認証キャッシュに、すべての認証済みユーザを同時に保存するための容量が不足している場合、Content Engine は、まだタイムアウトになっていないエントリのうち古いエントリから削除します。Content Engine のタイムアウト値の範囲は、1 ~ 1440 分(24 時間)です。デフォルトのタイムアウト値は 480 秒です。

各ユーザの最後のインターネット アクセス以後、認証キャッシュからそのユーザのエントリを削除するまでの時間のデフォルト値は、480 分です。最短の時間は 1 分、最大は 1440 分(24 時間)です。この時間が経過すると、Content Engine はアクセス制御サーバに対する再認証を要求します。

LDAP、RADIUS、および TACACS+ をプロキシ リダイレクト モードで使用する場合、認証キャッシュ内に保持されている認証レコードでは、入力されたユーザ名とパスワードがインデックスとして使用されます。LDAP、RADIUS、および TACACS+ を WCCP 対応ルータのリダイレクト モードで使用する場合、認証レコードに付けられるインデックスは、透過モードで要求を送信する Content Engine の IP アドレスになります。

NTLM サーバをプロキシ リダイレクト モード、または WCCP 対応ルータのリダイレクト モードのどちらで使用する場合も、すべての認証レコードのインデックスとして、要求側 Content Engine の IP アドレスが使用されます。

http authentication コマンドには、 header オプションがあります。このオプションを設定すると、認証が失敗した際にクライアントにメッセージを表示できます。 http authentication header 401 (Unauthorized)、または http authentication header 407 (Proxy Authorization Required)を選択できます。デフォルトでは、Content Engine は、着信要求の URL 構文に基づいてキャッシュ ロードを認証します。

認証キャッシュのサイズを、Content Engine GUI または CLI を使用して、ローカルに配置された Content Engine 上で設定できます。

Content Engine GUI を使用した認証キャッシュ サイズの設定

Content Engine の認証キャッシュ サイズの設定を行う手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > Auth. Cache の順に選択します。Authenticated Caching ウィンドウが表示されます(図 7-10 を参照)。

図 7-10 Authenticated Cache ウィンドウ

 

ステップ 2 Max entries フィールドに、この Content Engine 上のキャッシュ内で保持される最大エントリ数を指定します。範囲は 500 ~ 32000 です。デフォルト値は 16000 です。

ステップ 3 Timeout フィールドに、最後のアクセス以降 Content Engine からキャッシュを除去するまでの時間の長さを示す値を入力します。範囲は 1 ~ 1440 分です。デフォルト値は 480 分です。

ステップ 4 Header type ドロップダウン リストを使用します。

401 を選択した場合、許可に失敗したときに 401 不許可ヘッダー メッセージをクライアントに送信できます。

407 を選択した場合、許可に失敗したときに 407 プロキシ許可要求メッセージをクライアントに送信できます。

デフォルトでは、 Based on URL syntax がヘッダー タイプに選択されています。

ステップ 5 Update をクリックして変更を保存します。


 

CLI コマンドを使用した認証キャッシュ サイズの設定

認証キャッシュ サイズのパラメータの設定が必要な場合は、 http authentication cache コマンドを使用してください。認証キャッシュに保存される最大エントリ数は 32,000 です。最小数は 500、デフォルトは 16,000 です。このパラメータの設定が必要な場合は、 http authentication max-entries コマンドを使用してください。

認証キャッシュ パラメータを表示するには、EXEC モードで show http authentication コマンドを使用します。

RADIUS HTTP 要求認証の設定

RADIUS 認証のクライアントは、ACNS 5.x ソフトウェアを実行する Content Engine 上に存在します。これらのクライアントは、可能ならば、中央の RADIUS サーバに認証要求を送信します。このサーバには、ユーザ認証情報とネットワーク サービス アクセス情報が保存されています。

ローカルに配置された Content Engine 上で、RADIUS HTTP 要求認証の設定を行う手順は、次のとおりです。

1. Configure the RADIUS サーバの設定値を Content Engine 上で設定します(「Content Engine に対する RADIUS 認証サーバの設定」を参照)。

2. Content Engine GUI または CLI を使用して、Enable RADIUS HTTP 要求を Content Engine 上でイネーブルにします(次の項を参照)。

「Content Engine GUI を使用した RADIUS HTTP 認証要求のイネーブル化」

Content Engine GUI を使用した RADIUS HTTP 認証要求のイネーブル化

ローカルに配置された Content Engine 上で、RADIUS HTTP 要求認証をイネーブルにする手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > RADIUS の順に選択します。RADIUS ウィンドウが表示されます(図 7-5 を参照)。

ステップ 2 Enable RADIUS On オプション ボタンをクリックして、この Content Engine 上で RADIUS 認証をイネーブルにします。


) RADIUS サーバが、「Content Engine に対する RADIUS 認証サーバの設定」で説明されているとおりに設定されていない場合、RADIUS 認証は実行されません。


ステップ 3 Update をクリックして設定値を保存します。


 

CLI コマンドを使用した RADIUS HTTP 要求認証の設定

RADIUS HTTP 要求認証をローカルに配置された Content Engine 上に設定するために CLI を使用するには、 radius-server コマンドをグローバル設定モードで使用します。RADIUS 認証の設定値をディセーブルにする場合は、このコマンドの no 形式を使用します。 radius-server コマンドの詳細は、『Cisco ACNS Software Command Reference , Release 5.1.』を参照してください。


rule コマンドが RADIUS に関連付けられるのは、radius-server redirect オプションが設定されている場合だけです。


RADIUS 認証のリダイレクション

radius-server コマンドの redirect オプションは、RADIUS サーバを使用する認証要求が失敗すると、認証応答を別の認証サーバにリダイレクトします。

次の例では、RADIUS クライアントをイネーブルにし、RADIUS サーバを指定しています。次に、RADIUS キーを指定し、デフォルトの再試行をイネーブルにしています。さらに、RADIUS 認証から、ドメイン名 mydomain.net を除外しています。設定を表示し確認するには、show radius-server コマンドと show rule all コマンドを使用します。


rule コマンドが RADIUS に関連付けられるのは、radius-server redirect オプションが設定されている場合だけです。


ContentEngine(config)# radius-server enable
ContentEngine(config)# radius-server host 172.16.90.121
ContentEngine(config)# radius-server key myradiuskey
ContentEngine(config)# rule enable
ContentEngine(config)# rule no-auth domain mydomain.net
 
ContentEngine# show radius-server
Radius Configuration:
---------------------
Radius Authentication is on
Timeout = 5
Retransmit = 3
Key = ****
Servers
-------
IP 172.16.90.121 Port = 1645 State: ENABLED
 
ContentEngine# show rule all
Rules Template Configuration
----------------------------
Rule Processing Enabled
rule no-auth domain mydomain.net
 

次の例では、Content Engine 上で RADIUS 認証をディセーブルにします。

ContentEngine(config)# no radius-server enable
 

TACACS+ HTTP 要求認証の設定

TACACS+ データベースは、ユーザが Content Engine にアクセスする前にユーザを確認します。TACACS+ は、米国の国防総省(RFC 1492)を起源とし、非特権モードおよび特権モードのアクセスに対する追加制御方式としてシスコシステムズが使用しています。ACNS 4.1 以降のソフトウェアは、TACACS+ のみをサポートし、TACACS と Extended TACACS をサポートしていません。

HTTP 要求認証のために TACACS+ をイネーブルにするには、 tacacs enable グローバル設定コマンドを使用します。


) HTTP 要求認証は、「ログイン認証と許可の概要」で示されているログイン(ユーザ)認証と許可のオプションの影響を受けません。



ヒント TACACS+ 認証方式をイネーブルにする前に、tacacs server グローバル設定コマンドを使用して TACACS+ サーバを設定しておく必要があります(「CLI コマンドを使用した TACACS+ 認証の設定」を参照)。


Content Engine GUI の User ページ(Content Engine GUI から、 System > Users の順に選択)または user グローバル設定コマンドにより、ローカル データベース内でユーザ名、パスワード、およびアクセス権限の追加、削除、または変更ができます。TACACS+ リモート データベースは、管理ユーザに対する、ログインおよび設定の権限の保存にも使用できます。 tacacs グローバル設定コマンド、または TACACS+ GUI ページでは、リモート データベースへのアクセスに必要なネットワーク パラメータを設定できます。

TACACS+ 認証の設定値をローカルに配置された Content Engine 上で指定する詳細は、「Content Engine に対する TACACS+ 認証サーバの設定」を参照してください。

NTLM HTTP 要求認証の設定

NTLM プロトコルは、インターネットへのユーザ アクセスの認証やブロックに使用できます。ユーザが Windows NT または Windows 2000 のドメインにログインし、ブラウザを始動すると、認証情報はブラウザにより保存され、後にインターネットにアクセスするための NTLM クレデンシャル(証明)として使用されます。ブラウザは、ドメイン名と一緒に NTLM クレデンシャルを ACNS キャッシュに送信します。ACNS キャッシュは、Windows NT ドメイン コントローラに要求を送信して、そのドメインにおけるユーザの有効性をチェックします。ユーザがドメイン内の有効なユーザでない場合、インターネットへのアクセス要求は拒否されます。認証が成功すると、送信元 IP アドレスが Content Engine の認証キャッシュに保存されます。以降、この IP アドレスからの要求に対して、認証キャッシュ エントリの期限が切れるか、クリアされるまで、身元証明が要求されることはありません。

Content Engine の GUI または CLI を使用して、ローカルに配置された Content Engine が HTTP 要求認証に対して NTLM サーバを使用するように設定できます。

ntlm server コマンドを使用すると、NTLM 認証を使用可能にできます。また、NTLM サーバ ドメイン名、および NT プライマリ ドメイン コントローラ(PDC)名、または IP アドレスを設定し、オプションでホスト名またはアドレスをプライマリ、あるいはセカンダリとして設定できます。

次は、NTLM HTTP 要求認証用にローカルに配置された Content Engine を設定するための CLI 使用例です。

ContentEngine(config)# ntlm server domain cisco_abc
ContentEngine(config)# ntlm server host 172.16.10.10 primary
ContentEngine(config)# ntlm server host 172.16.10.12 secondary
ContentEngine(config)# ntlm server enable
 
ContentEngine# show ntlm
NTLM parameters:
Primary: 172.16.10.10
Secondary: 172.16.10.12
State: Enabled
Domain name: cisco_abc
 

Content Engine GUI から、 Caching > NTLM の順に選択して、NTML ウィンドウにアクセスします。(図 7-11 を参照)。NTLM ウィンドウを使用して、NTLM サーバの設定値を Content Engine 上で指定し、 Update をクリックします。 NTLM ウィンドウの各フィールドの詳細については、 Help ボタンをクリックしてください。

図 7-11 NTLM Authentication ウィンドウ

 

NTLM 認証要求を発信する前に、必ず、次の項目を確認してください。

NTLM プライマリ ドメイン コントローラに、NetBIOS で指定されたコンピュータ アカウントと一致する DNS へのエントリがある。

プライマリ ドメイン コントローラは、順方向および逆方向の DNS 解決ができる。

Content Engine 上で設定されているドメイン名が、プライマリ ドメイン コントローラ上のドメインと一致する。

次の例では、server1 は cisco.com ドメイン内にあり、NetBIOS 指定のコンピュータ アカウントと一致する DNS 内にエントリがなければなりません。

ip domain-name cisco.com
ntlm server host server1
 

NTLM 認証の透過性

クライアントが Internet Explorer ブラウザをプロキシ モードで使用しているドメイン内に置かれている場合、認証は「popless」です。すなわち、ユーザには、ユーザ名とパスワードの入力を求めるダイアログ ボックスが表示されません。透過モードで認証が透過的に行われるのは、インターネット オプションのセキュリティ設定値がカスタマイズされていて、その値が、 User Authentication > Logon > Automatic logon with current username and password に設定されている場合だけです。

LDAP HTTP 要求認証の設定

ローカルに配置された Content Engine は、認証のために LDAP サーバを使用して、ユーザのインターネット アクセスを制限できます。LDAP サーバは、X.500 プロトコルの大部分のサービスを、簡易にかつ低オーバーヘッドで提供します。

ACNS 5.x ソフトウェアは、LDAP バージョン 2 およびバージョン 3 をサポートし、SASL(Secure Authentication and Security Layer)以外のすべての LDAP 機能をサポートします。

サーバの冗長性

2 番目の LDAP サーバは、 ldap server host コマンド オプションを使用して指定できます。サーバを追加することにより、認証にバックアップ機能が加わり、スループットが向上します。特に、Content Engine のロード バランシング方式で 2 台のサーバ間で要求を均等に配信する場合に顕著になります。Content Engine が 2 台の LDAP サーバのどちらにも接続できない場合、認証は行われず、新規に認証を試みるユーザはアクセスを拒否されます。

LDAP HTTP 要求認証

Content Engine をローカルに配置している場合、Content Engine を使用して、ユーザが、認証用に LDAP サーバを使用してインターネットにアクセスするのを制限できます。Content Engine は、HTTP 照会を使用して、ユーザからクレデンシャル(ユーザの ID およびパスワード)を入手し、これらを LDAP サーバ データベース内のクレデンシャルと比較します。Content Engine が LDAP サーバを介してユーザを認証すると、その認証の記録が、ローカルの Content Engine RAM(認証キャッシュ)内に保存されます。認証エントリが保管されている限り、その後制限されたインターネット コンテンツに同じユーザがアクセスを試みても、LDAP サーバへの自動照合は行われません。

Content Engine は、プロキシ モードと透過(WCCP)モードの両方のアクセスに対して、LDAP 認証をサポートしています。プロキシ モードでは、Content Engine はクライアントのユーザ ID を認証データベースのキーとして使用し、透過モードでは、Content Engine は、クライアントの IP アドレスを認証データベースのキーとして使用します。Content Engine は、(暗号化していない)単純な認証を使用して LDAP サーバと通信します。


) ACNS 5.x ソフトウェアは、LDAP バージョン 2 およびバージョン 3 をサポートし、Secure Authentication and Security Layer(SASL)以外のすべての LDAP 機能をサポートします。


Content Engine GUI または CLI を使用して、LDAP サーバの設定をローカルに配置された Content Engine 上で行うことができます。

LDAP ユーザ認証を透過モードで使用している場合は、 http authentication cache timeout コマンドを使用して設定する AuthTimeout 間隔を短くすることをお勧めします。また、IP アドレスの再割り当てを実行してください。この再割り当てを行わないと、別のユーザが、認証済みのデバイス(PC、ワークステーションなど)を使用してインターネットにアクセスできてしまいます。AuthTimeout 値を短く設定すると、ユーザが認証済みのデバイスを使用してアクセスする可能性が少なくなります。Content Engine がプロキシ モードで動作しているときは、ユーザ ID とパスワードを使用してユーザを認証します。

セキュリティ オプション

Content Engine は、暗号化していない単純な認証を使用して LDAP サーバと通信します。将来の拡張においては、SSL(Secure Socket Layer)、SASL、または証明書ベースの認証に基づいてセキュリティ オプションが強化される予定です。

LDAP Active Directory について

Active Directory データベースは、Windows 2000 サーバのユーザ データベースです。LDAP プロトコルは認証の目的でこのデータベースを照会します。通常、Content Engineの LDAP クライアントは LDAP サーバのユーザ データベースを照会し、ユーザ アカウントの有効期限、権限、ユーザが所属するグループなどのユーザ証明情報を取得します。

ACNS 5.x ソフトウェアでは、Content Engine の LDAP クライアントは、Windows 2000 サーバ データベース内のリモート Active Directory に設定されているユーザを認証し、許可することができます。

トランザクション ロギング

ユーザが LDAP を介していったん認証されると、Content Engine が生成するそのユーザに対するすべてのトランザクション ログには、ユーザ情報が含まれます。Content Engine がプロキシ モードで動作している場合、ユーザ ID がトランザクション ログに記録されます。Content Engine が透過モードで動作している場合は、代わりにユーザの IP アドレスが記録されます。

transaction-logs sanitize コマンドが開始される場合、ユーザ情報は抑制されます。

Content Engine GUI を使用した LDAP HTTP 要求認証の設定

ローカルに配置された Content Engine で、LDAP HTTP 要求認証の設定を行う手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > LDAP の順に選択します。LDAP ウィンドウが表示されます(図 7-12 を参照)。

図 7-12 LDAP Server Settings ウィンドウ

 

ステップ 2 Enable LDAP On オプション ボタンをクリックして、LDAP 認証設定をイネーブルにします。

ステップ 3 LDAP Version オプション ボタンを使用して、使用する LDAP プロトコルのバージョンを指定します。

ステップ 4 Number of Retransmits フィールドに値を指定します。

ステップ 5 User-id Attribute フィールドに、ユーザ ID 名を入力します。

ステップ 6 Filter フィールドに、LDAP サーバが使用するフィルタ ストリングを入力します。

ステップ 7 Base Distinguished Name フィールドに、LDAP サーバ内の検索用のベース識別名ストリングを入力します。このフィールドに、デフォルト値はありません。

ステップ 8 Administrative DN フィールドに、LDAP データベースの管理識別名を入力します。このフィールドに、デフォルト値はありません。

ステップ 9 Administrative DN Password フィールドに、管理パスワードを入力します。このフィールドに、デフォルト値はありません。

ステップ 10 Content Engine をイネーブルにして、特定の LDAP サーバを使用するには、ホスト情報およびポート情報を入力します。

a. Host フィールドに、LDAP サーバの IP アドレスまたはホスト名を入力します。5 つの異なるホストを指定できます。

b. Port フィールドに、LDAP サーバがリスンするポート番号を入力します。デフォルトの LDAP ポートは 389 です。


) LDAP サーバが設定されていない場合、LDAP 認証は行われません。


ステップ 11 Update をクリックして設定値を保存します。


 

LDAP ウィンドウ内のパラメータおよびそれに対応する CLI コマンドのリストについては、 表 7-6 を参照してください。

.

表 7-6 LDAP サーバの主要パラメータの設定

パラメータ
説明
CLI コマンド

Enable LDAP Servers

LDAP サーバを使用して、HTTP 認証をイネーブルにする。

ldap server enable

LDAP Version

使用する LDAP プロトコルのバージョン。Version 2 または Version 3 のどちらかを選択します。

ldap server version

Time to wait

特定の LDAP サーバへの接続上でタイムアウトが発生する前に、Content Engine が応答を待つ秒数。デフォルト値は 5 秒です。

ldap server time-out

Number of Retransmits

この接続が行われる前に LDAP サーバへの接続が試行される回数。デフォルト値は 2 回です。

ldap server retransmit

User-id Attribute

LDAP サーバ側のユーザ ID 属性の名称。デフォルトのユーザ ID 属性は "uid" です。

ldap server userid-attribute

Filter

LDAP フィルタ ストリング。デフォルト値はありません。

ldap server filter

Base Distinguished Name

LDAP サーバの検索の開始点となるベース識別名。これにより、ドメイン "com" など特定のストリングを対象とした検索が可能です。

ldap server base

Administrative DN

管理識別名。これにより、選択したベース識別名に属する特定のユーザを対象とした検索が可能です。

ldap server administrative-dn

Administrative DN Password

管理識別名のパスワード。

ldap server administrative-passwd

Server Port

LDAP サーバがリスンするポート番号。デフォルト ポート番号は 389 です。

ldap server port

Primary Host

プライマリ LDAP サーバの IP アドレス。

ldap server host

Secondary Host

セカンダリ LDAP サーバの IP アドレス。

ldap server host

ロ―カルに配置された Content Engine 上で LDAP 認証を設定するための CLI の使用に関する情報は、次の項を参照してください。

CLI コマンドを使用した LDAP 認証の設定

LDAP 認証をローカルに配置された Content Engine 上でイネーブルするには、 ldap コマンドを使用します。LDAP 対応 Content Engine は、LDAP サーバを使用してユーザを認証します。Content Engine は、HTTP クエリーを使用して、ユーザの認証情報(ユーザ ID およびパスワード)を取得し、これらを LDAP サーバ内の認証情報と照合します。


) ACNS 5.1 ソフトウェアは、LDAP Version 2 および Version 3 をサポートし、Secure Authentication and Security Layer (SASL) 以外のすべての LDAP 機能をサポートします。


Content Engine がLDAP サーバを使用してユーザ認証を実行するように設定するには、 ldap server グローバル設定コマンドを使用します。

ldap server { administrative-dn name | administrative-passwd passwd | allow-mode | base baseword | enable | filter filterword | group { active-directory enable | custom uid enable | organizationUnit enable | static { enable | group-attribute gid | member-attribute { custom-member memid | member | uniquemember }| nested { enable | level 1-100 }}} | host { hostname | hostipaddress } [ primary | secondary ] | password-expiry { enable | redirect-url url} | policy-redirect { attribute name | enable | redirect-url url | version-number num} | port port-num | retransmit retries | timeout seconds | userid-attribute useridword | version ver_num }

表 7-7 では、 ldap server グローバル設定コマンドのパラメータについて説明します。

 

表 7-7 ldap server コマンドのパラメータ

パラメータ
説明

server

LDAP サーバ パラメータを設定する。

active-directory-group

Active Directory グループを利用する。

enable

機能をイネーブルにする。

administrative-dn

管理用の独自の名称を設定する。

name

管理識別名。

administrative-passwd

管理用パスワードを設定。

passwd

管理パスワード。

allow-mode

LDAP サーバが使用できないときにユーザへのアクセスを可能にする。

base

LDAP データベース内で行う検索の開始点に対する独自のベース名を設定する。

baseword

ベース値。デフォルト値はありません。

enable

LDAP サーバを使用して、HTTP 要求認証をイネーブルにする。

filter

認証グループに対する LDAP フィルタを設定する。

filterword

LDAP フィルタに対するテキスト。デフォルト値はありません。

group

LDAP グループを設定する。

active-directory

グループ名をユーザ アカウントの memberOf 属性から取得する。

enable

Active Directory グループのメンバーシップをイネーブルにする。

custom

グループ名をユーザ アカウントの custom 属性から取得する。

uid

ユーザ アカウントのカスタム属性名。

enable

カスタマイズされた属性名のグループ メンバーシップ。

organizationUnit

グループ名をユーザ アカウントの ou 属性から取得する。

enable

organizationUnit グループのメンバーシップをイネーブルにする。

static

LDAP 静的グループを設定する。

enable

ユーザのメンバーシップに対して静的グループ クエリーをイネーブルにする。

group-attribute

静的グループ属性の名前。

gid

静的グループ属性の名前(たとえば、cn、gid)。

member-attribute

照会するグループ メンバー属性の名前。

custom-member

静的グループ メンバー属性の名前を設定する。

memid

カスタム静的グループ メンバー属性の名前。

member

静的グループ メンバー属性の名前を設定する。

uniquemember

静的グループ メンバー属性の名前。

nested

ネストされた静的グループの名前を取得する。

enable

ユーザ メンバーシップに対して、ネストされた静的グループ クエリーをイネーブルにする。

level

照会する静的グループのネスト レベル。

1-100

静的グループのネスト レベルを指定する(デフォルトは 1)。

host

ホスト パラメータを設定する。

hostname

LDAP サーバのホスト名。最大 2 基のサーバ名を設定できます。

hostipaddress

LDAP サーバの IP アドレス。

password-expiry

認証パスワードの有効期限を設定する。

enable

認証パスワードの満了に対するサポートをイネーブルにする。

redirect-url

ユーザの失効したパスワードをリセットできる URL を定義する。

url

ユーザ パスワードが失効した場合にリダイレクトする URL。

policy-redirect

ポリシー リダイレクト サポートを設定する。

attribute

ユーザがサイトのポリシーを受け入れたかどうかを判別する LDAP 属性名を定義する。

enable

ポリシー リダイレクト サポートをイネーブルにする。

name

ポリシー バージョンの値が保管されている LDAP 属性名。

redirect-url

Acceptable Usage Policy 承認の場合にリダイレクトする URL を定義する。

url

ユーザが使用ポリシーを受け入れていない場合に、リダイレクトする URL。

version-number

現行のポリシー バージョン番号を定義する。

num

ポリシー バージョン番号(1 ~ 99999999)

primary

(オプション)プライマリ ホストとしてホストを指定する。

secondary

(オプション)セカンダリ ホストとしてホストを指定する。

port

LDAP 認証サーバに対して TCP ポートを設定する。

port-num

LDAP サーバのポート番号を指定する(1~65535)。デフォルトは、389 です。

retransmit

アクティブなサーバに対する送信試行の回数を指定する。

retries

1 つのトランザクションに対する送信試行の回数(1~3)。デフォルトは、2 です。

timeout

LDAP サーバの返答を待つ時間を設定する。

seconds

秒単位の待ち時間(1~20)。デフォルトは 5 秒、最短は 1 秒、最長は 20 秒です。

userid-attribute

LDAP サーバ上にユーザの ID 属性を設定する。

useridword

ユーザ ID 属性に対する値。デフォルトは「uid」です。

version

LDAP バージョン番号を設定する。

ver_num

LDAP バージョン番号(2~3)。デフォルトは、2 です。

LDAP 認証の設定例

次の例では、2 台の LDAP サーバをプライマリとセカンダリの HTTP 要求認証サーバに指定し、その設定を表示する方法を示しています。

ContentEngine(configure)# ldap server 172.16.1.1 primary
ContentEngine(configure)# ldap server 172.16.1.2 secondary
 

次の例では、LDAP タイムアウト時間を指定し、その設定を表示する方法を示しています。

ContentEngine(config)# ldap server timeout 10
 

次の例では、LDAP の再試行の回数を指定し、その設定を表示する方法を示しています。

ContentEngine(config)# ldap server retransmit 3

エンドツーエンド認証の設定

ACNS 5.x ソフトウェアは、基本エンドツーエンド認証、および NTLM エンドツーエンド認証の両方をサポートします。エンドツーエンド NTLM 認証には、パススルー サービス、および NTLM 認証を必要とする Web オブジェクトのキャッシングが含まれます。HTTP 要求認証は、Content Engine でユーザの要求を処理する前に、あらかじめ設定された NTLM ドメイン コントローラを使用して、ユーザのドメイン、ユーザ名、およびパスワードを認証します。NTLM 認証は、Microsoft 環境(たとえば、Microsoft Internet Information Services にアクセスする、Microsoft Internet Explorer のクライアント)でしか機能しません。


) エンドツーエンド NTLM 認証は、WCCP Version 2 透過キャッシングでのみサポートされます。HTTP 要求認証の場合、NTLM 認証が使用されるにもかかわらず、ブラウザが NTLM 認証をサポートしない場合に、ユーザ名とパスワードの情報が、基本認証ヘッダーをもつ平文で Content Engine に渡されます。その後、Content Engine はこの情報を使用して、あらかじめ設定されている Windows NT ドメイン コントローラと照合してユーザを認証します。


基本エンドツーエンド認証

ACNS ソフトウェアは、NTLM 認証ヘッダーを除去して、Microsoft Internet Information Services(IIS)サーバに対する基本認証確認へフォールバックできるようにします。

基本認証は、NTLM ベースの認証を要求している Microsoft IIS Web サーバに対して、入力されたユーザ ID をブラウザが認証できるようにするためのものです。NTLM は Microsoft 社が専有権をもち、文書化されていません。NTLM ヘッダーを除去すると、ブラウザは、基本認証方式にフォールバックできます。IIS が引き続き基本認証を受け入れるように設定されている場合、IIS 認証クレデンシャルは、Content Engine を通過できますが、セキュリティが低下します。NTLM ヘッダー除去機能を使用可能にするには、 http authenticate-strip-ntlm グローバル設定コマンドを使用してください。

NTLM エンドツーエンド認証

2 つのレベルの NTLM エンドツーエンド サポートの要約は、次のとおりです。

NTLM パススルー サービス

NTLM パススルー サービスがサーバ上で設定されている場合、Content Engine は、Content Engine を介した、クライアントとサーバ間の保護された永続的接続をセットアップします。NTLM 認証メッセージは、この仮想の永続的接続を通過します。Content Engine は、この仮想接続上で転送されるいかなるオブジェクトもキャッシュに保存しません。すべてのクライアント要求は、オリジン サーバによって処理されます。

NTLM オブジェクト キャッシング

ACNS 5.x ソフトウェアは、NTLM 認証を必要とするオブジェクトをキャッシングするように設定できます。サーバは、「no-store」フラグが付いた応答オブジェクトをキャッシュに保存しないようにします。このフラグがない場合、オブジェクトはキャッシュに保存されます。Content Engine が、目的の NTLM サーバにすでに接続されているクライアントから要求を受信する場合、ACNS ソフトウェアは、キャッシュを検索します。キャッシュ ミスの場合は、要求はオリジン サーバに転送されます。その後、応答オブジェクトはクライアントに送信され、コピーがキャッシュに保存されます。キャッシュ ヒットの場合には、Content Engine は、このクライアントとサーバ間に保護された接続があるかどうかをチェックします。オブジェクトが NTLM 認証を必要とし、クライアントとサーバ間に仮想の永続的接続がセットアップされていない場合、Content Engine は、クライアントとサーバ間の保護された接続を確立し、要求をサーバに転送します。クライアントとサーバ間の仮想の永続的接続がある場合、if-modified-since(IMS)メッセージがサーバに送信され、オブジェクトの妥当性、およびこのオブジェクトに対するユーザのアクセス権を確認します。その後、キャッシュに保存されたコピーがクライアントに送信されます。

NTLM エンドツーエンド認証の例

次の例では、エンドツーエンド NTLM 認証用に Content Engine を設定します。デフォルトでは、基本認証済みオブジェクト、および NTLM 認証済みオブジェクトは、キャッシュに保存されません。

ContentEngine(config)# no http authenticate-strip-ntlm
ContentEngine(config)# http cache-authenticated ntlm
ContentEngine# show http cache-authenticated ntlm
Basic authenticated objects are not cached.
NTLM authenticated objects are cached.
 

グループ ベースの許可設定

Windows NT ドメインおよび Windows 2000 ドメインでは、管理者はユーザおよび他のリソースを含むセキュリティ原則を体系化するために Windows グループ機能を使用して、グループを作成できます。Active Directory(AD)データベースは、Windows 2000 サーバのユーザ データベースです。このデータベースは、LDAP または NTLM が使用されているときに、認証用に照会されます。

Active Directory の概要

Active Directory(AD)データベースは、Windows 2000 サーバ上のユーザ データベースです。このデータベースは、LDAP または NTLM が使用されているときに、認証のために照会できます。

通常、Content Engine の LDAP クライアントは LDAP サーバのユーザ データベースを照会し、ユーザ アカウントの有効期限、権限、ユーザのグループ メンバーシップなどのユーザ証明情報を取得します。ACNS 5.x ソフトウェアでは、Content Engine の LDAP クライアントは、Windows 2000 サーバ データベース内のリモートの Active Directory に設定されているユーザの認証と許可ができます。

Microsoft Active Directory は、LDAP Version 3 のみをサポートしています。デフォルトでは、Content Engine は LDAP Version 2 を使用します。したがって、LDAP Active Directory の機能を Content Engine 上でイネーブルにする前に、Content Engine が LDAP Version 3 を使用するように、 ldap server version コマンドを使用して設定します。

ContentEngine(config)# ldap server version 3
 

LDAP Active Directory 機能をローカルに配置された Content Engine 上でイネーブルにするには、 ldap server group active-directory-group enable コマンドを使用します。

LDAP Accept Use Policy 機能の設定

ACNS 5.1 には、新しい LDAP Accept Use Policy 機能があります。ユーザがブラウザ セッションを開始すると、Content Engine は特定の LDAP 属性の照会を行って、ユーザが「Acceptable Use Policy」(AUP) を表示し、それに同意したかを判別します。ユーザがこのポリシーに同意しない場合、このユーザは Content Engine によって、内部の Web ページにリダイレクトされます。この Web ページには Acceptable Use Policy があり、ユーザはその内容を読み、それに同意しなくてはなりません。同意後、ユーザは Content Engine を介してのブラウズを許可されます。ユーザがポリシーに同意したら、Content Engine は LDAP 属性を設定します。その属性により、ユーザはプロキシ(Content Engine)を介してブラウズを行う、完全なアクセスが許可されます。

この LDAP 属性は設定可能で、これには、整数値が保持されています。ユーザのデータベースに格納されている値は、ユーザが同意したポリシーのバージョンです。この値は Content engine 内に設定されている現行バージョンと比較されます。これらの値が等しい場合、ユーザはブラウズを行うためのアクセスを与えられますが、これらの値が等しくない場合、ユーザは AUP を読み、同意するための内部の Web ページに誘導するように設定された URL にリダイレクトされます。

Acceptable Use Policy をイネーブルにするには、 ldap server policy-redirect enable コマンドを使用します。ユーザが、ポリシーを表示し、それに同意するためにリダイレクトされる URL を指定するには、 ldap server policy-redirect redirect-url url コマンドを使用します。 ユーザが同意したバージョンを照会する LDAP 属性を定義するには、 ldap server policy-redirect attribute 属性を使用します。

Accept Use Policy 機能をローカルに配置された Content Engine で設定する手順は、次のとおりです。


ステップ 1 Accept Use Policy 機能を Content Engine 上でイネーブルにします。

ContentEngine(config)# ldap server policy-redirect enable
 

ステップ 2 ユーザがポリシーを表示し、同意するためにリダイレクトされる URL を指定します。

ContentEngine(config)# ldap server policy-redirect redirect-url url
 

ステップ 3 ユーザが同意した Accept Use Policy のバージョンを判別するのに Content Engine が照会する LDAP 属性を指定します。

ContentEngine(config)# ldap server policy-redirect attribute aup-attribute
 

ステップ 4 Content Engine 上での Accept Use Policy の現行バージョンを指定します。これはグローバル値で、ユーザ自身がこのバージョンの Accept Use Policy に同意したかどうかを確認するために、すべてのユーザに対して使用されます。

ContentEngine(config)# ldap server policy-redirect value latest-policy-version
 


 

LDAP パスワード有効期限機能の設定

この新しい LDAP パスワード機能により、Content Engine がユーザを Web ページにリダイレクトし、そこでユーザにユーザ名とパスワードの入力を求めるように設定できます。LDAP 認証パスワードの有効期限機能の動作を設定するには、 ldap server password-expiry グローバル設定コマンドを使用します。 ldap server コマンドの詳細は、表 7-6を参照してください。

グループ名ベースのアクセス リストについて

ACNS 5.x ソフトウェアでは、ユーザが、NTLM または LDAP の要求認証サーバに対して認証された後にだけ、管理者はグループ名ベースのアクセス コントロール リストを使用してグループ認証を設定できます。このリストは、グループのメンバーが Content Engine が提供するコンテンツにアクセスする際のグループ権限を設定するために使用されます。この機能を使用すると、特定のグループに属するユーザが Content Engine 上の特定のコンテンツを表示できるかどうかを制御できます。

ある特定グループのメンバーには、NTLM または LDAP HTTP 要求認証サーバに対する認証が行われた後、自動的にグループ権限が割り当てれられます。この許可機能は、アクセスがあるグループにのみ許可されると指定することによって、より細かいアクセス コントロールを提供します。

グループ名ベースのアクセス リストを扱う際は、次のガイドラインに従ってください。

デフォルトでは、この機能は Content Engine 上でディセーブルになっていますが、次の項で説明されているように、Content Engine GUI または CLI を使用してイネーブル化あるいは設定が行えます。

「Content Engine GUI を使用したグループ名ベースのアクセス リスト設定」

「CLI コマンドを使用したグループ名ベースのアクセス リスト設定」

アクセス リストが Content Engine 上でイネーブルになっている場合は、どの設定済みアクセス リストを消去することなく、Content Engine 上でそのアクセス リストをディセーブルにできます。

設定済みのアクセス リストを消去することなく、アクセス リストをディセーブルにする方法は次のとおりです。

Content Engine GUI から、 System > Access Lists の順に選択します。Access Lists ウィンドウで、Enable access lists Off オプション ボタンをクリックし、次に Update をクリックします。

CLI から、 no access-lists コマンドを使用します。

ローカルに配置された Content Engine 上でグループ名ベースのアクセス リスト オプションをイネーブルにするために、Content Engine の GUI または CLI を使用できます。

access-lists enable グローバル設定コマンドを使用します。

Content Engine GUI から、 System > Access Lists の順に選択し、 Enable access lists On オプション ボタンをクリックします。

グループ名ベースのアクセス リストの定義に、Content Engine GUI または CLI を使用できます。

ローカルに配置された Content Engine を使用したインターネット アクセスを許可または拒否するには、 access-lists 300 コマンドを使用します。詳細は、「CLI コマンドを使用したグループ名ベースのアクセス リスト設定」を参照してください。

Content Engine GUI から、 System > Access Lists の順に選択し、表示された Access Lists ウィンドウを使用して、アクセス リストのエントリを定義します。詳細は、「Content Engine GUI を使用したグループ名ベースのアクセス リスト設定」を参照してください。

グループ名ベースのアクセス リストがサポートされるためには、少なくとも 1 つの認証方式(ローカル、TACACS+、または RADIUS など)がイネーブルになっている必要があります。


) Content Engine 上で最初に実行する認証方式を設定する場合は、ローカル認証方式をお勧めします。


ldap server group コマンドを使用して、LDAP グループを定義します。たとえば、次のタイプの LDAP ユーザ グループを設定できます。

Active directory: active-directory オプションを使用して、ユーザ アカウントの memberOf 属性からグループ名を取得する。

Custom: custom オプションを使用して、ユーザ アカウントのカスタム属性からグループ名を取得する。

Organizational Unit: organizationUnit オプションを使用して、ユーザ アカウントの ou 属性からグループ名を取得する。

Static: static オプションを使用して、LDAP 静的グループを設定する。

たとえば、 ldap server group コマンドを使用して、Content Engine がネストされた静的グループの名前を取得するように設定します。デフォルトでは、Content Engine は 1 つのネスト レベルを照会します。ネスト レベルを 1 ~ 100 までの範囲で指定できます。次の例では、Content Engine が 20 のネスト レベルまで照会するように設定されています。

ContentEngine(config)#ldap server group static nested level 20 enable
 

ntlm server group コマンドを使用して、NTLM グループを定義します。

ACNS 5.1 では、NTLM のネスト グループがサポートされています。

ACNS リリース 5.1 より以前のリリースでは、グループ名ベースのアクセス リストはサポートされていましたが、ネスト グループはサポートされていませんでした。たとえば Content Engine が Active Directory に照会を行う場合は、次のような場合です。

照会(クエリー)によってグローバル グループ名が取得される。

クエリーだけによって直接グループ名が取得される。

たとえば、クエリーが「Engineering」という名前に対するものであった場合、ネスト グループ名は取得できませんでした(たとえば、「Engineering」という名前のグローバル グループ内にある「Development Engineering」、および「System Engineering」などのネスト グループは取得されませんでした)。

Windows ベースのユーザ グループの場合、domain\group の形式でグループ名の前にドメイン名を付加する必要があります。

Windows NT ベースのユーザ グループには、ドメイン NetBIOS 名を使用します。

Windows 2000 ベースのユーザ グループには、ドメイン DNS 名を使用します。

Content Engine GUI を使用したグループ名ベースのアクセス リスト設定

ローカルに配置された Content Engine で、Content Engine GUI を使用して、グループ名ベースのアクセス リストを作成およびイネーブルにする手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 System > Access Lists の順に選択します。Access Lists ウィンドウが表示されます(図 7-4 を参照)。

ステップ 2 Access Lists ウィンドウで、 Enable access lists On オプション ボタンをクリックして、グループ名ベースのアクセス リスト オプションをこの Content Engine 上でイネーブルにします。

ステップ 3 Access Lists ウィンドウを使用して、作成しようとするアクセス リストに必要な情報を指定します。

a. Add an item to Access-list:任意のグループ名(たとえば、 marketing )をテキスト ボックスに入力するか、または Any チェックボックスをクリックして対応するグループ名を設定します。グループ名にはスペースを含めることができます。

b. Group permissions:Group permission オプション ボタンを使用して、グループがこの Content Engine を使用して、インターネットへアクセスするのを許可または拒否します。たとえば、マーケティング グループのどのユーザも Content Engine を使用してコンテンツにアクセスさせないようにするには、 deny オプション ボタンをクリックします。

c. Position of an item in the list:ポジション(正の整数)をテキスト ボックスに入力します。範囲は 1 ~ 4294967294 です。デフォルト値のゼロ (0) がこの項目の末尾に付加されます。負の値は使用できません。


ヒント Access Lists ウィンドウの各フィールドについての詳細は、Access Lists ウィンドウの Help ボタンをクリックします。

ステップ 4 Update をクリックして、グループ名ベースのアクセス リストをこの Content Engine 上で保存します。


 

CLI コマンドを使用したグループ名ベースのアクセス リスト設定

CLI を使用して、グループ名ベースのアクセス リストをローカルに配置された Content Engine 上で管理するには、次の項目に従ってください。

アクセス リストのエントリを設定するには、 access-lists 300 コマンドを使用します。これらのエントリは、どのグループがこの Content Engine を使用したインターネットへのアクセスを許可されるか、あるいは拒否されるかを判別します。

デフォルトでは、グループ名ベースのアクセス リストは、Content Engine 上でディセーブルになっています。これらのアクセス リストをローカルに配置された Content Engine 上でイネーブルにするには、 access-lists enable グローバル設定コマンドを使用します。

このアクセス リスト機能がイネーブルになっている場合、設定済みのアクセス リストを消去することなく、この機能をローカルに配置された Content Engine 上でディセーブルにできます。設定済みのアクセス リストを消去せずにこの機能をディセーブルにするには、 no access-lists コマンドを使用します。

ローカルに配置された Content Engine 上で CLI を使用して、グループ名ベースのアクセス リストをイネーブルにし、表示する手順は、次のとおりです。


ステップ 1 グローバル設定モードから、access-lists 300 permit groupname コマンドを使用して、Content Engine 上でグループ名ベースのアクセス リストに対してエントリを設定します。

たとえば、 access-lists 300 permit groupname コマンドを使用して、ファイナンス、エンジニアリング、またはセールスのような組織単位で、基本文字列 xyz 内のグループにアクセスを許可します。

次の例では、ファイナンス エンジニアリング、およびセールスのすべてのユーザにグループ アクセスが許可されます。 access-lists 300 deny groupname any コマンドにより、これらのどのグループにも属さないユーザはアクセスを拒否されます。

ContentEngine(config)# access-lists 300 permit groupname Finance
ContentEngine(config)# access-lists 300 permit groupname Engineering
ContentEngine(config)# access-lists 300 permit groupname Sales
ContentEngine(config)# access-lists 300 deny groupname any
 

ステップ 2 グループ名ベースのアクセス リスト オプションを Content Engine 上でイネーブルにします。

ContentEngine(config)# access-lists enable
 

ステップ 3 グループ名ベースのアクセス リストに対する統計情報を表示します。

ContentEngine# show statistics access-lists 300
 

ステップ 4 グループ名ベースのアクセス リストに対する統計情報をリセットします。

ContentEngine# clear statistics access-lists 300
 


 

LDAP グループ認証

ACNS ソフトウェア リリース 5.1 より以前のリリースでは、Content Engine は、LDAP グループ ベースでの認証用のグローバル グループをもつローカル グループしかサポートしていませんでした。Content Engine のグループ認証サポートと、Microsoft Active Directory データベースとの相互運用性を確保するために、ACNS 5.1 は、ネスト グループ、特にローカル グループ内での特定のローカル グループをサポートしています。ACNS 5.1 では、LDAP パスワードおよび、ユーザ名とパスワードを求める Web ページへのリダイレクトもサポートされています。

LDAP ネスト グループの設定

LDAP In ACNS 5.1 ソフトウェアでは、LDAP グループ認証に対してネスト グループを定義できます。Content Engine がネストされた静的グループ名を取得するように設定するには、 ldap server group コマンドを使用します。デフォルトでは、Content Engine は 1 つのネスト レベルを照会します。ネスト レベルを 1 ~ 100 までの範囲で指定できます。

次の例では、Content Engine が 20 のネスト レベルまで照会するように設定しています。

ContentEngine(config)#ldap server group static nested level 20 enable
 

ACNS リリース 5.1 より以前のリリースでは、グループ名ベースのアクセス リストはサポートされていましたが、ネスト グループはサポートされていませんでした。たとえば。Content Engine が Active Directory に照会を行うときは、次のような場合です。

クエリーによってグローバル グループ名が取得される。

クエリーだけによって直接グループ名が取得される。

たとえば、クエリーが「Engineering」という名前に対するものであった場合、ネスト グループ名は取得できませんでした(たとえば、「Engineering」という名前のグローバル グループ内にある「Development Engineering」および「System Engineering」などのネスト グループは取得されませんでした)。

LDAP サーバとアクセス コントロール リストを使用してグループ認証と許可を設定する手順は、次のとおりです。このシナリオでは、LDAP グループ アクセスは、XYZ 会社のエンジニアリング、マーケティング、および販売のグループに許可されています。次のパラメータは、エンジニアリング グループのユーザである John Smith に対して、LDAP サーバで設定されています。

# John Smith
dn: cn=John Smith,ou=Engineering,dc=xyz,dc=com
cn: John Smith
sn: Smith
telephoneNumber: 1 408 123 4567
uid: jsmith
userpassword: john123

) マーケティング グループおよびセールス グループのユーザは、似たようなパラメータを使用しているので、各組織単位でも、個々のユーザ単位でも、管理設定値を変更できます。


アクセス リストを使用した LDAP グループ許可の設定

次に、ローカルに配置された Content Engine 上でアクセス リストを使用して、LDAP グループ許可を定義、およびイネーブル化するために CLI を使用するワークフローのサンプルを示します。


ステップ 1 ユーザおよびグループ パラメータを認証サーバ(この場合、LDAP サーバ)上で設定します。

次のパラメータは、エンジニアリング グループのユーザである John Smith に対して、LDAP サーバで設定されています。

# John Smith
dn: cn=John Smith,ou=Engineering,dc=xyz,dc=com
cn: John Smith
sn: Smith
telephoneNumber: 1 408 123 4567
uid: jsmith
userpassword: john123
 

ステップ 2 グローバル設定モードから、LDAP サーバへのアクセスをイネーブルにします。LDAP サーバ用のホスト名あるいは IP アドレスのどちらかを入力します。次の例では、LDAP サーバの IP アドレスが使用されています。

ContentEngine(config)# ldap server host 10.1.1.1
 

ステップ 3 ldap server base コマンドを使用して、LDAP データベース内で検索に対する開始点の基本となる識別名 (dn) を指定します。

次の例では、LDAP サーバで「xyz」と「com」の文字列が検索されます。

ContentEngine(config)# ldap server base “dc=xyz,dc=com”

) Content Engine 上の LDAP サーバ パラメータは、LDAP サーバ上の設定と一致させておく必要があります。たとえば、LDAP サーバ上での識別名は、直前の例では、 dc=xyz、および dc=com でなければなりません。


ステップ 4 ldap server enable コマンドを使用して、LDAP サーバ認証をイネーブルにします。

ContentEngine(config)# ldap server enable
 

ステップ 5 access-lists 300 permit groupname コマンドを使用して、マーケティング、エンジニアリング、またはセールスのような組織単位で、基本文字列 xyz 内のグループに対してアクセスを許可します。

次の例では、エンジニアリング、マーケティング、およびセールスのすべてのユーザにグループ アクセスが許可されます。 access-lists 300 deny groupname any コマンドにより、これらのどのグループにも属さないユーザはアクセスを拒否されます。

ContentEngine(config)# access-lists 300 permit groupname Engineering
ContentEngine(config)# access-lists 300 permit groupname Marketing
ContentEngine(config)# access-lists 300 permit groupname Sales
ContentEngine(config)# access-lists 300 deny groupname any
 

ステップ 6 Content Engine 上で access-lists enable グローバル設定コマンドを使用して、グループ名ベースのアクセス リストの使用をイネーブルにします。

ContentEngine(config)# access-lists enable
 


 

NTLM グループ ベースの認証

ACNS ソフトウェア リリース 5.1 より以前のリリースでは、Content Engine は、NTLM グループ ベースでの認証用のグローバル グループをもつローカル グループしかサポートしていませんでした。Content Engine のNTLM グループ認証サポートと、Microsoft Active Directory データベースとの相互運用性を確保するために、ACNS 5.1 は、ネスト グループ、特にローカル グループ内での特定のローカル グループをサポートしています。

アクセス リストを使用した NTLM グループ許可の設定

NTLM サーバおよびグループ名ベースのアクセス リストを使用して、NTLM グループ許可を設定する手順は、次のとおりです。ここでの設定では、NTLM グループ アクセスは、XYZ 会社のエンジニアリング、マーケティング、およびセールスのグループに許可されています。

この項では、1 台の NTLM サーバとグループ名ベースのアクセス リストを使用して、グループ認証およびグループ許可を設定する方法について説明します。ここでの設定では、LDAP グループ アクセスは、XYZ 会社のエンジニアリング、マーケティング、およびセールスのグループに許可されています。次のパラメータは、エンジニアリング グループのユーザである John Smith に対して、NTLM サーバで設定されています。

# John Doe
dn: cn=John Doe,ou=Engineering,dc=xyz,dc=com
cn: John Doe
sn: Doe
telephoneNumber: 1 408 123 1234
uid: jdoe
userpassword: jdoe123

) マーケティング グループおよびセールス グループのユーザは、似たようなパラメータを使用しているので、各組織単位でも、個々のユーザ単位でも、管理設定値を変更できます。


NTLM サーバとグループ名ベースのアクセス リストを使用して、グループ認証およびグループ許可を設定するために CLI を使用する手順は、次のとおりです。


ステップ 1 グローバル設定モードから、 ntlm server host コマンドを使用して、NTLM サーバへのアクセスをイネーブルにします。NTLM サーバ用のホスト名または IP アドレスのどちらかを入力します。

次の例では、NTLM サーバの IP アドレスが使用されています。

ContentEngine(config)# ntlm server host 10.1.1.1 primary
 

ステップ 2 ntlm server domain コマンドを使用して、この Content Engine に対して NTLM サーバ ドメイン名を設定します。

ContentEngine(config)# ntlm server domain domain
 

ステップ 3 この Content Engine 上で、 ntlm server enable コマンドを使用して NTLM サーバ認証をイネーブルにします。

ContentEngine(config)# ntlm server enable
 

ステップ 4 access-lists 300 permit groupname コマンドを使用して、マーケティング、エンジニアリング、またはセールスのような組織単位で、基本文字列 xyz 内のグループに対してアクセスを許可します。

次の例では、エンジニアリング、マーケティング、および販売のすべてのユーザにグループ アクセスが許可されます。 access-lists 300 deny groupname any コマンドにより、これらのどのグループにも属さないユーザはアクセスを拒否されます。

ContentEngine(config)# access-lists 300 permit groupname Engineering
ContentEngine(config)# access-lists 300 permit groupname Marketing
ContentEngine(config)# access-lists 300 permit groupname Sales
ContentEngine(config)# access-lists 300 deny groupname any
 

ステップ 5 Content Engine 上で access-lists enable グローバル設定コマンドを使用して、グループ名ベースのアクセス リスト使用をイネーブルにします。

ContentEngine(config)# access-lists enable