ローカル管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3
スタンドアロン Content Engine のコ ンテンツ認証および許可の設定
スタンドアロン Content Engine のコンテンツ認証および許可の設定
発行日;2012/02/07 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 10MB) | フィードバック

目次

スタンドアロン Content Engine のコンテンツ認証および許可の設定

コンテンツ要求の認証および許可について

サポートしているコンテンツ認証および許可の方法

パススルー認証を介した Web クライアントの認証

HTTP 要求認証を介した Web クライアントの認証

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

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

HTTP 要求認証の設定

使用上のガイドライン

HTTP要求のRADIUS 認証の設定

HTTP 要求の TACACS+ 認証の設定

HTTP要求のLDAP 認証の設定

HTTP 要求の LDAP 認証の設定例

LDAP データ ベースの構造の概要

LDAP ディレクトリ検索について

LDAP サーバへのユーザ メンバーシップ情報のクエリ方法

LDAP データ ベース内での個人用アカウント情報の検索

LDAP ダイレクト静的グループ用のユーザ アカウント情報の検索

LDAP ネスト静的グループ用のユーザ アカウント情報の検索

HTTP要求の NTLM 認証の設定

HTTP 要求認証のための NTLM 負荷分散

HTTP 要求認証に NTLM サーバを使用する Content Engine の設定

許可ドメイン リスト NTLM HTTP 要求認証のリストの設定

NTLM HTTP 要求認証用の認証方法コントロールの設定

スタンドアロン Content Engines の現在の NTLM 設定を表示

スタンドアロン Content Engines の NTLM 統計情報の表示

スタンドアロン Content Engines でのグループ ベース許可の設定

スタンドアロン Content Engines でのアクセス リストの設定

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

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

Active Directory グループ検索のための Content Engines の設定

Active Directory グループ検索をサポートする Content Engine の設定例

グループ名ベースのアクセス リストの無効化

LDAP Acceptable Use Policy 機能の設定

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

HTTP 要求用エンドツーエンド認証の設定

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

NTLM エンドツーエンド認証

WMT 要求用パススルー認証の設定

スタンドアロン Content Engine のコンテンツ認証および許可の設定

この章では、ACNS 5.3.1 またはそれ以降のソフトウェアを実行するスタンドアロン Content Engine のコンテンツ認証および許可を設定する方法を説明します。コンテンツ認証および許可は、Content Engine を介して提供されるコンテンツへのエンド ユーザ(クライアントのブラウザ)のアクセスを管理します。

もうひとつのタイプの認証および許可であるログイン認証および許可は、Content Engine に管理目的(Content Engine の設定、変更、トラブルシューティング)でログインする管理者に与える特権レベルを管理するよう Content Engine を設定するために使用されます。コンテンツ認証および許可は、ログイン認証および許可とは独立しています。管理用のログイン認証および許可の詳細については、「スタンドアロン Content Engine での管理ログイン認証と許可の設定」参照してください。


) この章では、「HTTP 要求」は、HTTP、FTP-over-HTTP、および HTTPS-over-HTTP 要求を含む HTTP 要求一般を意味します。


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

「コンテンツ要求の認証および許可について」

「HTTP 要求認証の設定」

「スタンドアロン Content Engines でのグループ ベース許可の設定」

「LDAP Acceptable Use Policy 機能の設定」

「HTTP 要求用エンドツーエンド認証の設定」

「WMT 要求用パススルー認証の設定」


) この章で使用される CLI コマンドの構文と使用方法については、『Cisco ACNS Software Command Reference, Release 5.3』を参照してください。コンテンツ認証および許可の情報と、Content Distribution Manager に登録されている Content Engine の説明については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。


コンテンツ要求の認証および許可について

企業が Web アプリケーションのユーザを拡大し、インターネットへのアクセスを従業員に許可すると、次の問題が発生します。

従業員によるインターネット利用の管理方法

オンライン コンテンツへのアクセス制限の方法

これらの問題に対応するために、企業はコンテンツ認証および許可を利用できます。たとえば、オンライン コンテンツへのアクセスを制限する方法として、企業は HTTP 要求認証(コンテンツ認証)を利用できます。HTTP 認証がスタンドアロン Content Engine 上に設定されていると、Content Engine は外部AAA(認証、認可、およびアカウンティング)サーバでパスワード認証をチェックし、ユーザが要求したコンテンツにアクセスが許可されているかどうか決定します(図10-1 を参照)。

図10-1 HTTP 要求認証およびグループ ベースの許可

 


) ACNS 5.x は、一般的に AAA サーバが使用する Lightweight Directory Access Protocol(LDAP)、Microsoft NT LAN Manager(NTLM)、RADIUS および TACACS+ プロトコルをサポートしています。


要求認証および許可は、Content Engine を経由するエンド ユーザの要求すべてと関わります。要求認証および許可では、Content Engine はエンド ユーザを確認します。逆に、エンドツーエンド認証および認証されたオブジェクトのキャッシュは、特定のオブジェクトの認証を処理し、オリジン サーバではなく Content Engine がエンド ユーザを確認します。

要求認証については、ACNS はLDAP、NTLM、TACACS+、および RADIUS をサポートします。要求許可については、ACNS 5.x はグループ ベースのアクセス コントロール リスト(ACL)をサポートします。ACNS 5.2.1 ソフトウェア リリースでは、グループに基づくルールも追加され、グループに基づく許可で利用可能になります。これらの機能により、HTTP 要求をしているエンド ユーザに外部 AAA サーバによる認証と、設定した ACL または Rules Template による許可を要求することができます。

Rules Template 機能は、アクションやパターンまたはパターンのグループによってそれぞれが明確に認識されるルールを設定することを可能にし、スタンドアロン Content Engine は、HTTPS、MMS、RTSP トラフィックを含む HTTP 要求(HTTP トラフィック)をフィルタリングするためにそのルールを利用できます。Content Engine で処理するルールを有効にすると(Content Engine で Rules Template機能を有効にし、Content Engine のルールを設定すると)、Content Engine は受け取るクライアント要求のすべてをチェックし、ルールパターンが要求された内容と合致するか確認します。要求に一致するルール パターンがあると、Content Engine は、指定されたアクション(ポリシー)を使用して、この着信トラフィックを処理します。

ACNS 5.2 ソフトウェアでは、新しい 3 つのルール パターン( groupname username groupname-regex )が追加されました。これら 3 つのルール パターンは、認証済みの NTLM ユーザと LDAP ユーザのグループ名とユーザ名に基づいたアクセス制御ポリシーをサポートします。グループ名に基づくルールは、NTLM や LDAP を介して認証されたユーザに適用されます。ユーザ名に基づくルールは、認証用のユーザ名を含む要求認証方法である、LDAP、NTLM、RADIUSおよび TACACS+ を介して認証されたユーザに適用されます。

たとえば、次の例では rule enable グローバル設定コマンドを使用してContent Engine でルール処理を有効にし「java」という文字列を含む FTP URL(クライアント ブラウザからの FTP 要求)からの、Engineering グループのすべてのエンド ユーザによるダウンロードをブロックする方法を表示しています。

ContentEngine(config)# rule enable
ContentEngine(config)# rule pattern-list 1 group-type and
ContentEngine(config)# rule pattern-list 1 groupname Engineering
ContentEngine(config)# rule pattern-list 1 url-regex java
ContentEngine(config)# rule action block pattern-list 1 protocol ftp
 

) グループ名とユーザ名に基づくルールによる許可は、HTTP 要求認証とグループ ベースの ACL 認証の後に発生します。Rules Template と ACL の設定が競合すると、ACL が優先されます。スタンドアロン Content Engine の Rules Template の設定については、「スタンドアロン Content Engine の Rules Template の設定」 を参照してください。


アクセス コントロールの他の役割には、認証コンテンツのキャッシュがあります。つまり、Webサイトがクライアントにオブジェクトを渡す前にクライアント認証を要求し、そのオブジェクトが Content Engine にキャッシュされている場合は、Content Engine はオブジェクトを他のクライアントに渡す前に認証する必要があります。このようなオブジェクトを、認証済みコンテンツと呼びます。

サポートしているコンテンツ認証および許可の方法

表10-1 で要約されているとおり、コンテンツ認証および許可はさまざまなプロトコルで実行可能です。

 

表10-1 ACNS 5.2.1 またはそれ以降のソフトウェアでサポートされているコンテンツ認証および許可の方法

Method
詳細

HTTP 要求認証

HTTP 要求認証の設定

RADIUS

HTTP要求のRADIUS 認証の設定

TACACS+

HTTP 要求の TACACS+ 認証の設定

LDAP

HTTP要求のLDAP 認証の設定

NTLM

HTTP要求の NTLM 認証の設定

グループ ベースの許可

スタンドアロン Content Engines でのグループ ベース許可の設定

エンドツーエンド認証

HTTP 要求用エンドツーエンド認証の設定

Basic

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

Microsoft NTLM

NTLM エンドツーエンド認証

WMT 要求に対するパススルー認証

WMT 要求用パススルー認証の設定

エンドツーエンド認証は、クライアントとオリジン サーバ間で発生する認証です。パススルー認証は、Content Engine がエンドツーエンド認証を処理する方法です。パススルー認証では、Content Engine は、検査せずにクライアントとオリジン サーバ間の認証要求と応答を通過させます。

スタンドアロン Content Engines は、次の 2 種類のコンテンツ アクセス制御をサポートしています。

「パススルー認証を介した Web クライアントの認証」

「HTTP 要求認証を介した Web クライアントの認証」


) エンド ユーザのオンライン コンテンツへのアクセスを制限するには、URL フィルタ(たとえばローカルフィルタや外部 Websense サーバを通す)を使用する方法、パスワードと URL フィルタを併用する方法などがあります。Content Engine は、認証済みコンテンツやフィルタリングされたコンテンツを認証済みユーザにのみ提供するプロキシ キャッシング エンジンとして設定できます。


パススルー認証を介した Web クライアントの認証

HTTP プロトコルでは、Content Engine から配信されるコンテンツに対する HTTP 要求を発行するエンド ユーザ(Webクライアント)の認証方法は 3 種類あります。

Basic モード

NTLM モード

Microsoft Active Directory (AD)/Kerberos


) 同じように、WMT MMS プロトコルはクライアント認証用に Basic モードと NTLM モードをサポートしています。RTP/RTSP は、クライアント認証で Basic モードをサポートしています。


パススルー認証が使用されるのは、コンテンツが要求元に送られる前に認証が必要な Web サイト(つまり、クライアントがポップアップ ウィンドウでユーザ名とパスワードを入力する必要がある Web サイト)上のコンテンツにクライアントがアクセスを要求するときです。Content Engine は、(プロキシ設定または透過代行受信方法を介した)クライアントと Web サイト間にありますが、このクライアント認証を妨害しないようにします。クライアントと Web サーバ間の認証交換をサポートするため、Content Engine はクライアントと Web サーバ間で認証交換を通過させる(つまり認証交換のトンネルを作る)必要があります。

Web サイトでは、クライアントの IP アドレスを使用してクライアントを認証する場合があります。この方法は古い Web サーバで使用されていますが、クライアント認証で望ましいソリューションではありません。しかし、このような古い Web サイトに対しては、クライアントを認証するために、クライアントと オリジン Web サーバ間に Content Engine が「その場所から離れる」ための脇道が必要となります。このようなケースでは、認証トラフィック バイパスが利用可能です。このトピックに関する詳細は、「スタンドアロン Content Engine での認証トラフィック バイパスの設定」を参照してください。


) クライアント認証を要求するオブジェクトをContent Engine がキャッシュしている場合、認証済みクライアントにのみそのキャッシュされた認証コンテンツを送る必要があります。


HTTP 要求認証を介した Web クライアントの認証

HTTP 要求認証が使用されるのは、Content Engine が外部 AAA サーバと通信しているとき、コンテンツを要求しているユーザを認証するためです。このタイプの認証は、インターネットへのアクセスをクライアントに許可するか禁止する場合に利用されます。たとえば、BigCorp 社がその従業員にはインターネットへのアクセスを制限し、臨時の従業員には Web へのアクセスを許可しない場合です。

このケースでは、Content Engine を BigCorp 社のインターネット ゲートウェイに配置し、この方針を適用します。Content Engine が、Content Engine を介して提供されるコンテンツへアクセスするクライアント要求を受け取った場合、次のようなことが発生します。

1. Content Engine は「認証確認」をクライアントに送信し、クライアントに対してユーザ名およびパスワードの認証情報を入力するように要求します。

2. Content Engine は AAA サーバと通信し、提供された認証情報が有効か決定します。

3. AAA サーバからの応答に基づき、次のようなことが発生します。

a. AAA サーバがユーザを確認すると、Content Engine は要求を通過させます(つまり、クライアントは要求したコンテンツにアクセス可能になります)。

b. AAA サーバがユーザを確認できないと、Content Engine は要求を拒否し、認証失敗メッセージをクライアントに送ります。

ACNS 5.x では、インターネットへのアクセスを許可するグループと禁止するグループを指定することができます。この場合、Content Engine は AAA サーバにクライアントが主張どおりかだけでなく、どのグループに所属しているかたずねます。次に、Content Engine は、AAA サーバからの応答に応じて、適切なアクションを実行します。この種類のアクセス制御は、「HTTP 要求認証」と呼ばれ、Content Engine を介してクライアントがアクセスできるコンテンツを管理します。ACNS 5.x ソフトウェアは、LDAP、NTLM、RADIUS、および TACACS+ プロトコルをサポートし、一般的な AAA サーバで利用することができます( 表10-1 を参照)。

NTLM の場合、HTTP 要求認証は、事前設定された Primary Domain Controller(PDC; プライマリ ドメイン コントローラ)を使用して、ユーザのドメイン、ユーザ名、およびパスワードを認証してから、ユーザからの要求は Content Engine によって処理されます。

ACNS 5.2 ソフトウェアでは、NTLM HTTP 要求認証を Content Engine を通して実行が許可されているドメインのリストを指定する機能が追加されています。

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

Content Engine は、プロキシ モードと透過(WCCP)モードの両方のアクセスに対して、HTTP 要求認証をサポートしています。

プロキシ モードでは、Content Engine はクライアントのユーザ ID(UID)を Content Engine の TACACS+、LDAP および RADIUS 認証方法における認証キャッシュ用鍵として使用します。

他の方法の透過モードおよびNTLM のプロキシ モードでは、Content Engine はクライアント IP アドレスを、Content Engine の認証キャッシュ用鍵として使用します。

HTTP要求認証を透過モードで使用するか、透過モードかプロキシ モードで NTLM を使用する場合には、Content Engine の認証キャッシュがクライアントの IP アドレスであるため、 http authentication cache timeout グローバル設定コマンドでAuthTimeout 間隔 を短く設定することをお勧めします。また、IP アドレスの再割り当てを実行してください。この再割り当てを行わないと、別のユーザが、認証済みのデバイス(PC、 ワークステーションなど)を使用してインターネットにアクセスできてしまいます。AuthTimeout 値を短く設定すると、ユーザが認証済みのデバイスを使用してアクセスする可能性が少なくなります。ACNS 5.2 ソフトウェアでは、絶対タイムアウトを設定するオプションが http authentication cache ttl グローバル設定コマンドで導入されました。絶対タイムアウトはまた、個人が以前に認証されたブラウザを使用してアクセスを取得する可能性を低くするためにも設定できます。詳細は、「再認証の間隔の指定」を参照してください。

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

ある企業の社員が複数の営業所で勤務している場合の例です。この場合、1 台の Content Engine(CE1)をユーザが勤務する特定の営業所に配置し、この CE1 をプロキシ モードに設定できます。もう 1 台のプロキシ モードで動作する Content Engine(CE2)、またはもう 1 台の HTTP 準拠プロキシ装置をアップストリームに配置し、Content Engine またはプロキシ装置の両方に対して、ログイン認証を行う目的で TACACS+、RADIUS、NTLM、または 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 がプロキシ サーバ モードで動作し、HTTP 要求認証用に設定されているときに、次に示されているイベントが発生するのは、次の 2 つの状況のうちいずれかが当てはまる場合です。(1)Content Engine がプロキシ スタイルの要求をクライアントから直接受け取る場合、または(2)Content Engine が WCCP リダイレクト要求を受け取り、アップストリーム プロキシがあるために、Content Engine の http authentication header グローバル設定コマンド オプションが、407(Proxy Authorization Required)に設定されている場合。

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

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

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

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

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

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

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

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

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

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


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


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

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

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

Content Engine が透過モードで動作し、HTTP 要求認証用に設定されているときに、次に示されているイベントが発生するのは、次のいずれかの場合です。(1)Content Engine がリダイレクトされた要求をクライアントから受け取る場合、(2)アップストリーム プロキシがないため、
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 アドレスを Content Engine 認証キャッシュへの鍵として使用します。

HTTP 要求認証の設定

次の認証および許可の方式を 1 つ設定して、スタンドアロン Content Engine 上で HTTP 要求認証を制御できます。

「HTTP要求のRADIUS 認証の設定」

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

「HTTP要求のLDAP 認証の設定」

「HTTP要求の NTLM 認証の設定」


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


使用上のガイドライン

HTTP 要求認証をスタンドアロン Content Engine 上で設定するときは、次の重要事項に従ってください。

Content Engine 上では、一度に 1 つのHTTP 要求認証方式を有効にできます。HTTP 要求認証を Content Engine 上に設定する詳細については、「HTTP 要求認証の設定」を参照してください。

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

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

セキュリティのため、HTTP 要求認証キャッシュ エントリのための絶対 Time To Live(TTL)を指定する機能が ACNS 5.2 ソフトウェアに追加されました。詳細は、「再認証の間隔の指定」を参照してください。

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

追加セキュリティのために、HTTP 要求承認用 NTLM を使用する場合は、 no ntlm basic-auth enable グローバル設定コマンドを使用します。このコマンドは、Content Engine が基本的な認証方法をクライアントに提案したり、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)が追加されました。


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

 

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

NTLM は、HTTP 要求承認用の認証サーバを 8 台まで許可します。サーバ設定の順番は、負荷分散やフェールオーバーの順番を決定します。たとえば、最初に設定されているサーバ(サーバ 1)はプライマリ サーバになり、このサーバに最初に認証要求が送信されます。最後に設定したサーバ(サーバ 8)は、最後のサーバで、Content Engine と連絡しています。

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

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

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

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

ユーザが TACACS+、LDAP、NTLM または RADIUS サーバを介して認証されると、そのユーザ用に Content Engine が生成するすべてのトランザクション ログには、トランザクション ログ フォーマットにユーザ名が設定されている限り(Extended-Squid フォーマットまたはフォーマット ストリングに %u があるカスタム フォーマット)、ユーザ情報が含まれます。

Content Engine がプロキシ モードで動作している場合、ユーザ ID がトランザクション ログに記録されます。Content Engine が透過モードで動作している場合は、代わりにユーザの IP アドレスが記録されます。

transaction-logs sanitize グローバル設定コマンドが指定される場合、ユーザ情報は抑制されます。トランザクション ロギングの詳細は、「スタンドアロン Content Engine のモニタリングとトランザクション」を参照してください。

次の例は、Content Engine CLI を使用して、スタンドアロン Content Engine で HTTP 要求認証を設定する場合です。

次の例では、LDAP サーバ用のホストを設定します。

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

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

ContentEngine(config)# radius-server 172.16.90.121

) HTTP 要求認証をスタンドアロン Content Engine 上に設定する方法の詳細については、「HTTP 要求認証の設定」を参照してください。


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

「HTTP要求のRADIUS 認証の設定」

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

「HTTP要求のLDAP 認証の設定」

「HTTP要求の NTLM 認証の設定」

HTTP要求のRADIUS 認証の設定

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

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


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


スタンドアロン Content Engine 上で、HTTP 要求の RADIUS 認証を設定する手順は、次のとおりです。


ステップ 1 Configure the RADIUS サーバの設定値を Content Engine 上で設定します(「スタンドアロン Content Engine の RADIUS 認証設定」を参照)。

ステップ 2 HTTP 要求に対する RADIUS 認証を Content Engine 上でイネーブルにします。

Content Engine GUI から、 Caching > RADIUS の順に選択し、RADIUS ウィンドウを表示します。 Enable RADIUS On オプション ボタンをクリックして、この Content Engine 上で RADIUS 認証を有効にします。 Update をクリックして設定値を保存します。

Content Engine CLI から radius-server グローバル設定コマンドを使用します。


 

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

次の例では、Content Engine 上で RADIUS クライアントを有効にし、外部 RADIUS サーバを指定しています。次に、RADIUS 鍵を指定し、デフォルトの再送信を受け入れ、RADIUS 認証から、ドメイン名 mydomain.net を除外しています。

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
 

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


設定内容を表示し確認するには、show radius-server と show rule all の EXEC コマンドを使用します。

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 認証を無効にするには、no radius-server enable グローバル設定コマンドを使用します。


HTTP 要求の TACACS+ 認証の設定

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

ContentEngine(config)# tacacs key "tackey"
 

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

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

スタンドアロン Content Engine 上で、HTTP 要求の TACACS+ 認証を設定する手順は、次のとおりです。


ステップ 1 Content Engine が 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+ 鍵を指定します。

ContentEngine(config)# tacacs key key
 

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

ContentEngine(config)# tacacs timeout 15
 

ステップ 4 RADIUS の再試行の回数を指定します。

たとえば、TACACS+ タイムアウトが発生した場合、もう 1 度だけ TACACS+ サーバに再送信を行うように Content Engine を設定します。

ContentEngine(config)# tacacs retransmit 1
 

ステップ 5 TACACS+ パスワード認証用メカニズムを指定します。

たとえば、 ascii キーワードを入力することで、ASCII 平文テキストをメカニズムとして使用します。

ContentEngine(config)# tacacs password ascii
 

ステップ 6 Content Engine 上で TACACS+認証を有効にします。

ContentEngine(config)# tacacs enable
 


 


) TACACS+ 認証設定(たとえば、TACACS+ 鍵の指定)の詳細は、表17-3 を参照してください。tacacs server グローバル設定コマンドの詳細は、『Cisco ACNS Software Command Reference Guide, Release 5.3 』を参照してください。


HTTP要求のLDAP 認証の設定

X.500 プロトコル Directory Access Protocol(DAP)は、多数のディレクトリを実装するには複雑過ぎるという問題に対処するため、ミシガン大学は Lightweight Directory Access Protocol(LDAP)を開発しました。LDAP はディレクトリ サービス プロトコルで、DAP の TCP/IP に基づくバージョンより簡単な仕組みになっていて、情報ディレクトリにアクセスするために利用できます。

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


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


一般的に LDAP クライアント(Content Engine)は LDAP サーバを呼び出し、ユーザ アカウントの有効期限、特権、グループのメンバーシップなどユーザのクレデンシャルを、OpenLDAP 上またはサードパーティ LDAP サーバ上のリモート LDAP ディレクトリから取得します。ACNS ソフトウェア、リリース 5.1 以降では、Content Engine は、Microsoft Active Directory サーバ内にあるリモート Active Directory のユーザ データ ベースで設定されたユーザの認証と許可を行うことができます。

図10-2 では、Content Engine(LDAP クライアント)が他の種類のサーバと連携して動作し、HTTP 要求の LDAP 認証を実行する方法を示しています。

OpenLDAP サーバ(シェアウェア サーバ)

サードパーティ LDAP サーバ(たとえば Sun Microsystems iPlanet サーバ)

Microsoft Active Directory (AD)/Kerberos


図10-2 は、Content Engine がプロキシ モードで動作しているとき、LDAP と共に HTTP 要求認証を実行する方法を示します。Content Engine が透過モードで動作していると、Web クライアントと Content Engine(LDAP クライアント)間にWCCP 対応ルータが存在します。


図10-2 プロキシ モードにおける HTTP 要求の LDAP 認証

 


) ACNS 5.x ソフトウェアは、LDAP Version 2 およびVersion 3 をサポートし、SASL(Secure Authentication and Security Layer)以外のすべての LDAP 機能をサポートします。Content Engine は、暗号化していない単純な認証を使用して LDAP サーバと通信します。将来の拡張においては、SSL(Secure Socket Layer)、SASL、または証明書ベースの認証に基づいてセキュリティ オプションが強化 される予定です。

Active Directory グループ属性は、LDAP Version 3 の拡張です。そのため、Microsoft Active Directory サーバに照会するためには、Content Engine は LDAP Version 3 を使用する必要があります。


表10-2 では、異なるタイプの LDAP サーバ(図10-2 を参照)でサポートされている機能を示しています。「x」は、その機能がサポートされていることを意味します。

 

表10-2 LDAP サーバでサポートされている機能

機能
サードパーティの LDAP サーバ
Open LDAP
サーバ
Microsoft Active Directory サーバ

LDAP Version 2

x

x

 

LDAP Version 3

x

x

x

組織ユニット(ou)

x

x

x

Active Directories(AD)

 

 

x

静的グループ

x

x

x

HTTP 要求の LDAP 認証を設定するときは、次の重要な点に注意してください。

HTTP 要求の LDAP 認証は、Content Engine GUI または CLI を介して設定することができます。

Content Engine GUI から、 Caching > LDAP の順に選択します。表示された LDAP ウィンドウから、 Enable LDAP On オプション ボタンをクリックして LDAP 認証を有効にし、このウィンドウで LDAP 認証を設定します。このトピックの詳細については、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から ldap server グローバル設定コマンドを使用します。

ldap server enable コマンドを使用して、 LDAP 認証を有効にします。

ldap server version ver_num グローバル設定コマンドで、使用する LDAP プロトコル バージョンを指定します。オプションは Version 2 または Version 3 です。次の例では、LDAP Version 3 の指定方法を示します。

ContentEngine(config)# ldap server enableldap server version 3
 

ldap server timeout seconds グローバル設定コマンドを使用して、特定の LDAP サーバへの接続がタイムアウトする前に、Content Engine が応答を待つ秒数を 指定します。デフォルト値は 5 秒です。

ldap server retransmit retries グローバル設定コマンドを使用して、LDAP サーバに接続を試みる回数を指定します。デフォルトは 2 回です。この例では、LDAP 再送回数を 3 回に設定する方法を示します。

ContentEngine(config)# ldap server retransmit 3
 

ldap server userid-attribute useridword コマンドを使用して、ID 属性を指定します。デフォルトでは、uid が指定されています。

ldap server filter filterword グローバル設定コマンドを使用して、データ ベースの検索で利用可能なフィルタ文字列(たとえば、objectclass=user)を指定します。デフォルトはありません。

ldap server base baseword グローバル設定コマンドを使用して、データ ベース検索用のベース認定者名を指定します。このフィールドに、デフォルト値はありません。この例では、データ ベース検索を開始する場所を特定するベース認定者名を指定する方法を示します。

ContentEngine(config)# ldap server base dc=cisco,dc=com
 

ldap server administrative-dn name グローバル設定コマンドを使用して、データ ベース検索用の管理認定者名を指定します。このフィールドに、デフォルト値はありません。

ldap server administrative-passwd passwd グローバル設定コマンドを使用して、データ ベース検索用の管理認定パスワードを指定します。このフィールドに、デフォルト値はありません。

ldap server port port-num グローバル設定コマンドを使用して、LDAP サーバが受信するポート番号を指定します。デフォルト ポート番号は 389 です。

Content Engine が認証に使用する LDAP サーバを指定します。プライマリおよびセカンダリ LDAP サーバを指定できます。

ldap server host { hostname | hostipaddress } primary グローバル設定コマンドを使用して、LDAP サーバをプライマリ サーバに指定します。プライマリ LDAP サーバの IP アドレスまたはホスト名を指定します。

ldap server host { hostname | hostipaddress } secondary グローバル設定コマンドを使用して、LDAP サーバをセカンダリ サーバに指定します。セカンダリ LDAP サーバの IP アドレスまたはホスト名を指定します。

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

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

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


ldap server group グローバル設定コマンドを使用して、LDAP データ ベースからグループ ベースの許可に関するグループ名を取り出します。このコマンドを使用して、データ ベース クエリを実行する LDAP サーバに、認証されたユーザが所属するグループ名を取得するように命令します(たとえば、「Marketing」や「Engineering」など)。Content Engine は、取得したグループ名を使用して、LDAP グループ ベースの許可を実行し、アクセス リストをチェックして、要求されたコンテンツにグループがアクセスできる許可を与えるか拒否するか決定します。


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


表10-3 では、HTTP 要求に対する LDAP 認証のための Content Engine のデフォルト設定を示しています。

 

表10-3 HTTP 要求に対する LDAP 認証用デフォルト設定

機能または設定
デフォルト値

LDAP 認証

無効

許可モード

無効

ベース認定者名

未指定(空のストリング)

データ ベース検索用フィルタ

未指定

LDAP 再送回数

2 回

LDAP サーバ タイムアウト

5 秒

ユーザ ID 属性

uid

グループ属性

組織ユニット(ou)

カスタム属性

アクティブ ディレクトリ(memberOf)

 

有効

無効

無効

静的グループ データ ベース クエリ

グループ属性

グループ メンバ

ネストされたグループ

ネストされたレベル

無効

未指定

未指定

無効

1 レベル

管理識別名

未指定

管理パスワード

未指定

LDAP Version

LDAP Version 2

LDAP ポート

ポート 389

ポリシー リダイレクト 機能

無効

パスワード失効機能

無効

プライマリ LDAP サーバ

未指定

セカンダリ LDAP サーバ

未指定

HTTP 要求の LDAP 認証の設定例

次の例では、Content Engine CLI を使用して、スタンドアロン Content Engine 上で HTTP 要求の LDAP 認証を設定するための、Content Engine CLI の使用方法を示しています。


ステップ 1 Content Engine が HTTP 要求を承認するために使用する LDAP 認証サーバの IP アドレスまたはホスト名を指定します。

ContentEngine(config)# ldap server host 10.1.1.1
 

ステップ 2 必要に応じて、LDAP Version 3 に対して LDAP Version 2 を使用するようにContent Engine を設定します。

図10-2 は、Content Engine 上の LDAP クライアントが OpenLDAP サーバかサードパーティの LDAP サーバへ、LDAP Version 2 または Version 3 の要求を送信できることを示しています。しかし、Content Engine は、Microsoft Active Directory サーバと通信するためには LDAP Version 3 を使用する必要があります。デフォルトでは、Content Engine は LDAP Version 2 を使用します。デフォルト設定を変更するには、 ldap server version 3 グローバル設定コマンドを使用します。

ContentEngine(config)# ldap server version 3
 

ステップ 3 デフォルトでは、HTTP 要求の LDAP 認証は Content Engine 上で無効になっています。次に示すように、Content Engine 上の LDAP 認証を有効にします。

ContentEngine(config)# ldap server enable
 

ステップ 4 検索基準を指定します。

これらの検索基準は、LDAP サーバに渡され、ユーザ データ ベースで検索に使用されます。LDAP サーバは、認証のためのユーザのパスワードを取得します。ユーザが認証されると、LDAP サーバはデータ ベースで要求されたユーザのメンバーシップ情報を検索し、その情報を Content Engine に返します。

検索基準には、グループ属性(たとえば organizationUnit や Active Directory)、ユーザ ID(UID)属性、検索の開始ポイントなどの情報が含まれています。また、データ ベースの範囲を制限するフィルタ(たとえば objectclass=users)を指定することもできます。Content Engine がグループ ベースの許可に設定されている場合は、Content Engine は取得したグループ名を使用して、認証ユーザのためにグループ ベースの許可を実行します。アクセス リストを介したグループ ベースの許可については、「スタンドアロン Content Engines でのグループ ベース許可の設定」を参照してください。

検索基準を指定するには、照会するユーザ データ ベースの構造を知っている必要があります。たとえば、デフォルトでは Content Engine は、組織ユニット( ou )グループ メンバーシップ用のデータ ベースを検索するように、認証サーバに要求します。


) OpenLDAP サーバ、サードパーティ製 LDAP サーバ、Microsoft Active Directory サーバで、組織ユニット グループ メンバーシップ情報を検索することができます。認証サーバが Microsoft Active Directory サーバの場合は、Active Directory グループ メンバーシップだけを検索できます。

組織ユニット オプションおよび Active Directory オプションは、独立したパラメータです。Active Directory グループ メンバーシップだけでなく組織ユニット グループ メンバーシップも Microsoft Active Directory サーバのデータ ベースで検索するように、Content Engine を設定できます。


このデフォルト設定は変更可能です。次の例では、認証のために Microsoft Active Directory サーバで Active Directory グループのメンバーシップのみを照会し、組織ユニット メンバーシップは照会しない Content Engine の設定方法を示しています。

Content Engine(config)# ldap server group active-directory enable
 

次の出力例では、認証ユーザのために Active Directory グループ メンバーシップの検索を Microsoft Active Directory サーバ データ ベースで実行するように、Content Engine が設定された状態を示しています。

ContentEngine# show ldap
LDAP Configuration:
-------------------
LDAP Authentication is enabled
Allow mode: disabled
Base DN: ”DC=cisco,DC=com”
Filter: <none>
Retransmits: 2
Timeout: 5 seconds
UID Attribute: uid
Group Attribute:
organizationUnit: disabled (ou)
Custom Attribute: disabled
Active Directory: enabled (memberOf)
 

) LDAP データ ベースの構造の詳細については、「LDAP データ ベースの構造の概要」 を参照してください。HTTP 要求の LDAP 認証用デフォルト設定パラメータの詳細については、「LDAP データ ベースの構造の概要」 を参照してください。



 

1 人のユーザを認証してから、グループ ベースの許可を実行するように Content Engine を設定することもできます。Content Engine をグループ ベースの許可用に設定すると、Content Engine はアクセス リストをチェックし、認証済みユーザが所属するグループに要求したコンテンツにアクセスを許可するか拒否するかを決定します。この LDAP グループ ベースの許可の決定に基づいて、Content Engine は要求されたコンテンツへのユーザ アクセスを許可または拒否します(図10-1 を参照)。

LDAP グループ ベースの許可を利用するには、Content Engine で次の必須タスクを完了しておく必要があります。

「アクセス リストを使用した LDAP グループ許可の設定例」 で説明しているように、グループ名ベースのアクセス リストをイネーブルおよび設定します。

認証したユーザが所属するグループ名(たとえば「Marketing」や「Engineering」など)を LDAP サーバが取得するように Content Engine を設定します。この情報の取得を要求するように Content Engine を設定するには、照会するデータ ベースの構造を理解している必要があります。このトピックに関する詳細は、次の「LDAP データ ベースの構造の概要」を参照してください。

LDAP データ ベースの構造の概要

Content Engine 上の LDAP クライアントがリモート ユーザ データ ベースに照会するように設定するには、照会するユーザ データ ベースの構造を理解する必要があります。

LDAP データ ベース エントリは、論理的境界および位置的境界を反映する階層型ディレクトリ ツリー内に配置されています。LDAP ディレクトリは次の構造です(図10-3 を参照)。

LDAP ディレクトリ ツリーの最上位ノードは、「ルート」と呼ばれます。

ルートの下には、企業や州、あるいは全国的な組織を表す組織ノード(o)(たとえば、「o=cisco」、「o=texas」および「o=redcross」)があります。

組織ノードの下には、部署のような組織ユニットを表す LDAP グループのノードがあります(たとえば、「ou=Marketing」、「ou=Engineering」)。

ツリーの最下部には、一般人名の個々のノード(たとえば、「cn=Jane Smith」)、文書、およびプリンタなどの共有リソースがあります。

図10-3 LDAP データ ベース構造

 


) 「Hardware Engineers」や「Software Developers」という名前のグループは「Engineering」という名前の親グループの下にネストされているので、このようなグループを「ネストされたグループ」と呼びます。ネストされたグループは LDAP サーバ管理者に対して、系統付けられたグループのメンバシップを定義をするために使用する階層型のグループ関係を作成することを許可します。


LDAP ディレクトリでは、このような情報をテキスト、画像(JPEG)、URL、バイナリ データ、公開鍵証明書として保管できます。

LDAP ユーザ データ ベース エントリ

LDAP ユーザ データ ベース(LDAP ディレクトリ)内のエントリは、認定者名(dn)と呼ばれる名前をもった属性の集合です。エントリの各属性には、タイプ、名前、および 1 つまたは複数の値があります。

属性タイプ:整数、文字列、文字

属性名:属性の名前(たとえば、一般名の「cn」、姓名の名の「givenName」、Eメール アドレスの「mail」)

属性値:属性の値(たとえば、Jane Smith、Jane、jsmith50@cisco.com)

次の例では、OpenLDAP またはサードパーティの LDAP サーバ データ ベース内にある Jane Smith の完全なデータ ベース エントリを示しています。

# Jane Smith, cisco, com
dn: cn=Jane Smith,dc=cisco,dc=com
telephoneNumber: (408) 123-9100
mail: jsmith50@cisco.com
uid: jsmith50
givenName: Jane
sn: Smith
cn: Jane Smith
 

次の例では、Microsoft Active Directory サーバ データ ベース内にある Jane Smith の完全なデータ ベース エントリを示しています。

# Jane Smith, cisco, com
dn: CN=Jane Smith,DC=cisco,DC=com
memberOf: CN=Users,DC=cisco,DC=com
telephoneNumber: (408) 123-9100
mail: jsmith50@cisco.com
uid: jsmith50
givenName: Jane
sn: Smith
cn: Jane Smith
 

LDAP ユーザ データ ベース内のエントリは、認定者名(dn)により参照されます。認定者名はエントリ名を取り、LDAP データ ベース内にある階層ディレクトリ構造内の親エントリの名前を連結して構築されます。たとえば、一般名(cn)が「Jane Smith」で、この個人が「cisco」という名前の組織に所属している場合は、LDAP ディレクトリ エントリの認定者名は次のとおりです。

cn=Jane Smith,dc=cisco,dc=com(OpenLDAP サーバまたはサードパーティ製 LDAP サーバの場合)

CN=Jane Smith,DC=cisco,DC=com(Microsoft Active Directory サーバの場合)

LDAP ディレクトリ内のユーザ グループについて

LDAP ディレクトリには、LDAP グループの一部であるグループ ユーザが含まれています(たとえば、「Marketing」や「Engineering」という名前のグループ)。LDAP グリープはリストであり、名前の集合体です。LDAP グループは groupOfNames の objectclass 属性をもっていて、1 つまたは複数のメンバで構成されています(空のグループは存在しません)。

LDAP データ ベース検索の一部として、認証済みユーザのグループ名を取得するように LDAP サーバに命令できます。Content Engine は、取得したグループ名とグループ ベースのアクセス リストを使用して、LDAP ユーザに対してグループ ベースの許可を実行します。


) LDAP では、objectclass と名付けられた特殊属性を介して、エントリ内のどの属性が要求され許可されるか制御することができます。objectclass 属性の値は、エントリが従うべきスキーマ ルールを決定します。LDAP の詳細については、RFC 1777『Lightweight Directory Access Protocol』を参照してください。


ユーザ データ ベース内の LDAP グループをサポートするには、複数の方法があります。

「LDAP ユーザを組織ユニット内にグループ化」

「LDAP ユーザを静的グループにグループ化」

「Active Directory グループへユーザをグループ化」

データ ベース管理者がデータ ベース内のユーザをグループ化する方法により、データ ベースからメンバーシップ情報を照会するための Content Engine の設定方法が決まります。たとえば、LDAP ディレクトリ クエリを実行する Content Engine を設定するために、CLI を使用する方法については、「LDAP サーバへのユーザ メンバーシップ情報のクエリ方法」 を参照してください。

LDAP Version 3 では、グループは静的、動的、organizationUnit(組織ユニット)として定義することができます。グループはネストすることができます。ACNS 5.1 またはそれ以降のソフトウェアは、静的および organizationUnit グループをサポートし、動的グループはサポートしていません。

LDAP ユーザを組織ユニット内にグループ化

LDAP サーバの管理者が 組織ユニット(たとえば「Marketing」)に基づいて LDAP のユーザをグループ化するときは、管理者は、ユーザを任意のグループに割り当てられますが、グループのネストはできません。組織ユニットは、ネイティブ LDAP グループと同じです。この方法はまた、ネイティブ LDAP グループの設定として引用されます。従来の LDAP Version 3 サーバーは、ユーザ データ ベース内でネイティブ LDAP グループをサポートしています。

デフォルトでは、Content Engine は、組織ユニットのグループ メンバーシップに関して LDAP サーバをクエリするように設定されています。次の例では、「Penny Gold」という LDAP ユーザを「Marketing」という組織ユニットに割り当てるために使用される LDAP データ ベース内のエントリを 2 つ示します。

最初のデータ ベース エントリでは、LDAP サーバ管理者が「Marketing」という組織ユニットのためのグループ ノードを定義します。

dn: cn=Marketing,dc=cisco,dc=com
cn: Marketing
objectclass: groupOfNames
 

2 つ目のデータ ベース エントリでは、管理者は Penny Gold のための個々のノードを定義します。このノードには、Penny Gold のユーザ メンバシップのすべての情報が含まれています。

# Penny Gold, marketing, cisco, com
dn: cn=Penny Gold,ou=Marketing,dc=cisco,dc=com
telephoneNumber: (408) 123-4444
mail: pgold@cisco.com
uid: pgold
givenName: Penny
sn: Gold
cn: Penny Gold
 

Penny Gold の組織ユニット(ou)は「Marketing」として指定されているため、彼女は特定グループのグループ特権を割り当てられます。グループ ベースを許可するように Content Engine を設定し(たとえば、Marketing グループのメンバーが Content Engine を介して提供されるコンテンツにアクセス可能となるアクセス リストを設定し)、Content Engine が Penny Gold を既に認証している場合、彼女は Marketing グループのメンバーであるため、要求したコンテンツにアクセス可能になります。

上記のデータ ベース構造に基づき、次の例では、Penny Gold のようなユーザのユーザ メンバシップ情報をこのデータ ベースで照会するため、Content Engine を設定する方法を示しています。IP アドレスが 172.16.1.1 のサーバ(OpenLDAP サーバまたはサードパーティ製 LDAP サーバ)は、「Marketing」というノードでデータ ベース検索を開始し、ユーザ識別(ユーザ名とユーザ パスワード)を検索して認証されたユーザ名を取得するように指定されています。

ContentEngine(config)# ldap server 172.16.1.1
ContentEngine(config)# ldap server userid-attribute uid
ContentEngine(config)# ldap server organizationUnit enable
ContentEngine(config)# ldap server base “dc=cisco,dc=com”
ContentEngine(config)# ldap server enable
 

organizationUni t オプションがイネーブルであるため、LDAP サーバはデータ ベースにユーザ アカウントの organizationUnit 設定( ou 属性)をクエリします。該当するユーザが複数の組織ユニットに所属している場合は、LDAP サーバはそのユーザが所属するグループ名すべてを含む文字列を返します。Content Engine が LDAP グループ ベース許可用に設定されていると、取得したグループ名とアクセス リストを使用して、認証済みユーザのグループ ベース許可を実行します。

LDAP ユーザを静的グループにグループ化

LDAP サーバ管理者が静的グループを使用して LDAP ユーザをユーザ データ ベース内でグループ化する場合、管理者は静的グループのメンバーを個々に明示的に指定します。LDAP 管理者は、ユーザ許可特権を設定するために、ユーザを LDAP 静的グループに割り当てます。ユーザのインターネットへのアクセスは、静的グループ(たとえば、「Engineering」や「Hardware Engineers」)へ割り当てられた特権に基づいて、許可または拒否されます。

静的グループは、groupOfNames または groupOfUniqueNames のオブジェクト クラス属性を使用して個々のメンバを定義します。これらのオブジェクト クラスには、属性メンバ(groupOfNames)または uniqueMember(groupOfUniqueNames)が必要です。オブジェクト クラス名とメンバ名の属性は、1 対 1 に対応しています。これらの構造オブジェクト クラスを使用する静的グループには、空でない少なくても 1 つのメンバが必要です。

Content Engine LDAP 静的グループの機能により、グループ メンバに対して両方のオブジェクト クラス(groupOfNames および groupOfUniqueNames)をクエリできます。

次の例では、groupOfNames と名付けられたオブジェクト クラスに対して、データ ベースを照会する方法を示しています。

ContentEngine(config)# ldap server group static member-attribute member
ContentEngine(config)# ldap server group static enable
 

次の例では、groupOfUniqueNames と名付けられたオブジェクト クラスに対して、データ ベースを照会する方法を示しています。

ContentEngine(config)# ldap server group static member-attribute uniquemember
ContentEngine(config)# ldap server group static enable

) ACNS 5.x ソフトウェアは、現在 LDAP ユーザ データ ベースの静的グループの照会をサポートしています。静的グループは、OpenLDAP サーバ、サードパーティ LDAP サーバ、および Microsoft Active Directory サーバでサポートされています。


次の例では、LDAP サーバ管理者が LDAP データ ベース内の静的グループを設定する方法を示しています。

1. LDAP サーバ管理者は、LDAP データ ベース内の次のノードを定義します。

「com」と名付けられたルート ノード

「cisco」と名付けられた組織ノード

「Engineering」と名付けられた組織ユニット(ou)のためのノード

Engineering グループの下にネストされた Hardware Engineers グループのためのノード

Engineering グループの下にネストされた Software Developers グループのためのノード

ユーザ名「Jay Doe」のための個人ノード

ユーザ名「Don Smith」のための個人ノード

次の例では、LDAP サーバ管理者がユーザ「Jay Doe」のためのノードを定義する方法を示しています。

# Jay Doe, Engineers, cisco, com
dn: cn=Jay Doe,ou=Engineering,dc=cisco,dc=com
telephoneNumber: (408) 123-8910
mail: jdoe8@cisco.com
uid: jdoe8
givenName: Jay
sn: Doe
cn: Jay Doe

次の例では、LDAP サーバ管理者がユーザ「Don Smith」のためのノードを定義する方法を示しています。

# Don Smith, Engineers, cisco, com
dn: cn=Don Smith,ou=Engineering,dc=cisco,dc=com
telephoneNumber: (408) 123-4567
mail: dsmith7@cisco.com
uid: dsmith7
givenName: Don
sn: Smith
cn: Don Smith
 

2. LDAP サーバ管理者は、特定メンバを静的グループに割り当てます。

次の例では、親グループ「Engineering」の下に 2 つの静的メンバ(「Hardware Engineers」グループと「Software Developers」グループ)があることを、LDAP サーバ管理者が明示的に指定する方法を示します。「Hardware Engineers」と「Software Developers」というグループは、ネストされた静的グループで、親グループの下にネストされています。

dn: cn=Engineering,dc=cisco,dc=com
cn: Engineering
objectclass: groupOfNames
member: cn:Hardware Engineers,dc=cisco,dc=com
member: cn:Software Developers,dc=cisco,dc=com
 

次の例では、LDAP サーバ管理者がユーザ「Jay Doe」と「Don Smith」を「Hardware Engineers」グループに明示的に割り当てる方法を示しています。member 属性が使用されるので、2 つの連結ノード間は一方向リンクです。 member of 属性が使用されると、2 つの連結ノード間に双方向リンクが生成されます。双方向リンクでノードを接続すると、ユーザ メンバーシップ情報のためにデータ ベースの検索が必要になる TCP 要求の数が減ります。

dn: cn=Engineers,dc=cisco,dc=com
cn: Hardware Engineers
object: groupOfNames
member: cn:Jay Doe,ou=Engineering,dc=cisco,dc=com
member: cn:Don Smith,ou=Engineering,dc=cisco,dc=com
 

デフォルトでは、静的グループ クエリとネスト グループ クエリは、Content Engine 上で無効になっています(次の show ldap EXEC コマンドによるサンプル出力の引用が示すとおり)。

ContentEngine# show ldap
LDAP Configuration:
-------------------
Static Groups: disabled
Group Attribute:
Group Member:
Nested Groups: disabled
Nested Level: 1
 

しかし、次の項で説明するとおり、CLI を使用して、スタンドアロン Content Engine 上でこのようなクエリを有効にまたは設定することができます。

「LDAP ダイレクト静的グループ用のユーザ アカウント情報の検索」

「LDAP ネスト静的グループ用のユーザ アカウント情報の検索」

Active Directory グループへユーザをグループ化

Microsoft Active Directory は Windows 2000 サーバ上で動作するソフトウェア アプリケーションです。Active Directory(AD)データ ベースはユーザ データ ベースで、Microsoft Active Directory プログラムを実行する Windows 2000 サーバ上に存在します。

ACNS 5.1 ソフトウェアまたはそれ以降では、Content Engine 上の LDAP クライアントは、Active Directory グループをサポートする LDAP を提供します。Microsoft Active Directory は、LDAP Version 3 のみをサポートしています。デフォルトでは、Content Engine は LDAP Version 2 を使用します。したがって、LDAP Active Directory の機能を Content Engine 上でイネーブルにする前に、Content Engine が LDAP Version 3 を使用するように、 ldap server version 3 グローバル設定コマンドを使用して設定します。

ContentEngine(config)# ldap server version 3
 

LDAP サーバが Active Directory グループのメンバーシップをクエリするように要求します。

ContentEngine(config)# ldap server group active-directory enable
 

) Active Directory グループ属性は、LDAP Version 3 の拡張なので、別にクエリする必要があります。


次の例では、Active Directory データ ベース内のユーザ アカウントからの入力を示しています。

dn: CN=Penny Gold,CN=Users,DC=cisco,DC=local
memberOf: CN=Marketing,DC=cisco,DC=local
 

個々のグループの memberOf 属性およびグループ名は、ユーザのアカウント設定に追加されました。 memberOf 属性は、ネストされたグループ階層をサポートしていません。

LDAP ディレクトリ検索について

LDAP ディレクトリ サービスはグローバル ディレクトリ サービスであり、LDAP クライアント(Content Engines)は、LDAP ディレクトリ内に保管されている情報に、次のようにアクセスできます。

1. Content Engine は指定した LDAP サーバに接続し、LDAP サーバに特定のユーザ メンバーシップ情報についてクエリします(たとえば、ユーザ識別「userid」やユーザ パスワード「userpassword」)。

次の例では、スタンドアロン LDAP サーバにユーザ識別(ユーザ ID およびパスワード)をクエリし、LDAP サーバにユーザが所属する組織ユニット(グループ)の名前を取得させるように、Content Engine を設定する方法を示しています。

ContentEngine(config)# ldap server userid-attribute uid
ContentEngine(config)# ldap server organizationUnit enable
 

Content Engine 管理者は Content Engine 上で検索基準を設定します。このトピックに関する詳細は、「LDAP サーバへのユーザ メンバーシップ情報のクエリ方法」を参照してください。

2. LDAP サーバは、指定された検索基準に合致するエントリをユーザ データ ベース(LDAP ディレクトリ)内で探します。

a. LDAP サーバは、Content Engine 上で organizationUnit オプションが有効になっているか確認します。

organizationUnit オプションが有効になっている場合は、LDAP サーバはデータ ベースにユーザ アカウントの organizationUnit 設定( ou 属性)をクエリします。該当するユーザが複数の組織ユニットに所属している場合は、LDAPサーバはそのユーザが所属するグループ名すべてを含む文字列を返します(たとえば、「Marketing」、「Engineering」)。

organizationUnit オプションが無効になっている場合は、LDAP サーバはクエリを実行しません。

b. LDAP サーバは、Active Directory グループ( memberOf )オプションがイネーブルかチェックします。

memberOf オプションが無効になっている場合は、LDAP サーバ(Microsoft Active Directory サーバ)はクエリを実行しません。

memberOf オプションが有効になっている場合は、LDAP サーバは Microsoft Active Directory サーバのデータ ベースにユーザ アカウントの Active Directory グループ設定をクエリします。Microsoft Active Directory サーバは、ユーザ アカウントの memberOf 属性からグループ名を集め、その情報を Content Engine に返します。


) Active Directory グループ属性は、LDAP Version 3 の拡張なので、別にクエリする必要があります。


c. LDAP サーバは、Content Engine 上でカスタム グループ オプションが有効になっているか確認します。

カスタム グループ オプションが無効になっている場合は、LDAP サーバはクエリを実行しません。

カスタム グループ オプションが有効になっている場合は、LDAP サーバはユーザ アカウントの custom 属性からグループ名を集め、その情報を Content Engine に返します。

d. LDAP サーバは、Content Engine 上で静的グループ オプションが有効になっているか確認します。

静的グループ オプションがデ無効になっている場合は、LDAP サーバはクエリを実行しません。

静的グループ オプションが有効になっている場合は、LDAP サーバはデータ ベースに静的グループ設定をクエリします。サーバはグループ名を集め、この情報を Content Engine に返します。

3. LDAP サーバは、Content Engine からのクエリに応答し、要求された情報か、あるいはそれが見つからないというメッセージを返します。

ユーザが正規のユーザでない場合、HTTP 認証は失敗します。この場合、Content Engine はコンテンツにアクセスするユーザの要求を拒否します。

ユーザが正規のユーザである場合、HTTP 認証は成功します。グループ ベースの許可が Content Engine で有効になっていない場合、Content Engine はこの時点でコンテンツへのユーザ アクセスを許可します。Content Engine がグループ ベースの許可に設定されている場合(たとえば、access-lists 300 enable グローバル設定コマンドを使用してアクセス リストが定義されている場合)、Content Engine は取得したグループ名を使用して、要求されたコンテンツへのアクセスをユーザに許可するか決定します。


) 取得したユーザ メンバーシップ情報は、グループ ベースの許可でのみ使用されます。LDAP ユーザのためのグループ ベースの許可については、「アクセス リストを使用した LDAP グループ許可の設定例」 を参照してください。


LDAP サーバへのユーザ メンバーシップ情報のクエリ方法

ここでは、Content Engine を設定して LDAP ディレクトリ クエリを実行する方法を説明します。

「LDAP データ ベース内での個人用アカウント情報の検索」

「LDAP ダイレクト静的グループ用のユーザ アカウント情報の検索」

「LDAP ネスト静的グループ用のユーザ アカウント情報の検索」


) これらの例では、クエリされる LDAP ディレクトリが 図10-3 で説明されている構造であると想定しています。


LDAP データ ベース内での個人用アカウント情報の検索

次の例では、LDAP データ ベース内で個人(たとえば、Jane Doe)のアカウント情報を検索するため、Content Engine を設定する方法を説明しています。

1. Content Engine がこのデータ ベース検索に使用する LDAP サーバを指定します。

ContentEngine(config)# ldap server 172.16.1.1
 

デフォルトでは、LDAP 認証サーバ用のTCP ポートとしてポート 389 が設定されています。LDAP サーバ用に別のポートを指定するには、 ldap server port port-num コマンドを使用します。有効なポート番号は 1 から 65535 までです。

2. データ ベース検索の開始ポイントとなるベースの認定者名を特定します。

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

3. Content Engine 上で LDAP 認証を有効にします。

ContentEngine(config)# ldap server enable
 

4. 検索基準を指定します。

a. このケースでは、ユーザ ID(ユーザ名とユーザ パスワード)を検索するため、LDAP サーバが要求されます。

ContentEngine(config)# ldap server userid-attribute uid
 

b. Content Engine で organizationUnit オプションをイネーブルにします。これにより、LDAP サーバはユーザ アカウントの ou 属性からグループ名を取得します。

ContentEngine(config)# ldap server organizationUnit enable

LDAP ダイレクト静的グループ用のユーザ アカウント情報の検索

次の例では、指定した LDAP サーバがダイレクト(非ネスト)静的グループのデータ ベース クエリを実行するように、Content Engine を設定する方法を説明しています。このタイプのクエリは、ダイレクト静的グループ(親の静的グループ)に割り当てられたユーザの HTTP 要求認証を、Content Engine が実行できるようにします。

この例では、LDAP データ ベースで、「Engineering」というダイレクト静的グループのユーザ アカウント情報をクエリします。

1. Content Engine がこのデータ ベース検索に使用する LDAP サーバを指定します。

ContentEngine(config)# ldap server 172.16.1.1
 

2. クエリするグループ属性を指定します。

この例では、LDAP サーバは静的グループ設定を一般名が「cn」であるグループ属性で検索します。

ContentEngine(config)# ldap server group static group-attribute cn
 

3. クエリするグループ メンバ属性を指定します。

この例では、LDAP サーバは静的グループ設定を「member」というグループ メンバ属性で検索します。

ContentEngine(config)# ldap server group static member-attribute member
 

4. データ ベース検索の開始ポイントとなるベースの認定者名を特定します。

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

5. Content Engine 上で LDAP 認証を有効にします。

ContentEngine(config)# ldap server enable
 

6. LDAP ユーザ データ ベースの静的グループ クエリを有効にします。

ContentEngine(config)# ldap server group static enable

LDAP ネスト静的グループ用のユーザ アカウント情報の検索

次の例では、指定した LDAP サーバがネストされた静的グループのデータ ベース クエリを実行するように、Content Engine を設定する方法について説明しています。このケースでは、「Engineering」という親グループにネストされている静的グループのユーザ アカウント情報がLDAP ディレクトリで検索されます。

1. Content Engine がこのデータ ベース検索に使用する LDAP サーバを指定します。

ContentEngine(config)# ldap server 172.16.1.1
 

2. LDAP ディレクトリで検索する静的グループのネスト レベルを指定します。

デフォルトでは、LDAP サーバはLDAP ディレクトリを検索の開始ポイントから 1 レベル下まで検索します。このケースでは、「Hardware Engineers」と「Software Developers」の 2 つのネストされた静的グループが、検索の開始ポイント(組織ノード名は「cisco」)から 2 レベル下でネストされています。この例では LDAP サーバが 2 レベル下まで検索するようにしています。

ContentEngine(config)# ldap server group static nested level 2
 

3. クエリするグループ属性を指定します。

次の例では、LDAP サーバはネストされた静的グループ設定を一般名が「cn」であるグループ属性で検索しています。

ContentEngine(config)# ldap server group static group-attribute cn
 

4. クエリするグループ メンバ属性を指定します。

次の例では、LDAP サーバは静的グループ設定を「member」というグループ メンバ属性で検索します。

ContentEngine(config)# ldap server group static member-attribute member
 

5. データ ベース検索の開始ポイントとなるベースの認定者名を特定します。

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

6. Content Engine 上で LDAP 認証を有効にします。

ContentEngine(config)# ldap server enable
 

7. LDAP データ ベースのネストされた静的グループ クエリを有効にします。

ContentEngine(config)# ldap server group static nested enable

HTTP要求の NTLM 認証の設定

Windows NT LAN Manager(NTLM)は、Microsoftのブラウザ(Internet Explorer)、プロキシ、Web サーバ(IIS)で使用されている認証プロトコルです。NTLM プロトコルは要求‐応答ベースのプロトコルであり、インターネットへのユーザ アクセスを認証したり、ブロックしたりするために使用できます。NTLM 要求認証で NTLM を使用する主な利点は、NTLM は認証要求を発行するサーバにパスワードを暗号形式で送信することです。

一般的には、企業はインターネット サイトに保存している情報に対して、NTLM を使用してアクセス制御しています。また企業は、ユーザ名とパスワードをエンド ユーザに対して要求せずに、インターネットの閲覧を保護したいと考えています。NTLM は、この認証方式を Microsoft Internet Explorer やドメイン コントローラ(DC)を介して提供します。Content Engines は、どちらのモデルもサポートするために NTLM HTTP 要求認証をサポートしています。クライアント(Web ブラウザ)は、Content Engine で NTLM HTTP 要求認証を実行し、Content Engine(HTTP プロキシ サーバ)を使用して、要求したコンテンツへアクセスしようと試みます。

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

ACNS 5.2.1 ソフトウェア リリースでは、NTLM HTTP 要求認証に関して次の点が強化されています。

HTTP 要求認証用に 8 台までの NTLM サーバをサポート:負荷を分散させるため、HTTP 要求認証用の NTLM サーバを 8 つまで使用できるように、Content Engine を設定する機能。ACNS 5.1.x およびそれ以前のソフトウェアは、フェールオーバーのみをサポートしていました。詳細は、「HTTP 要求認証のための NTLM 負荷分散」を参照してください。

Active Directory グループ検索用に 8 台までの Global Catalog サーバをサポート:Active Directory 検索用の Global Catalog サーバを 8 台まで使用できるように Content Engine を設定する機能。「Active Directory グループ検索のための Content Engines の設定」を参照してください。


) サーバ設定の順番は、負荷分散やフェールオーバーの順番を決定します。たとえばフェールオーバーが有効な場合、最初に設定されているサーバ(サーバ 1)はプライマリ サーバになり、このサーバに最初に認証要求が送信されます。最後に設定したサーバ(サーバ 8)は、最後のサーバで、Content Engine と連絡しています。負荷分散が有効になっている場合は、最初の要求だけが最初に設定したサーバ(サーバ 1)に送信され、その後は他のサーバでラウンド ロビンが使用されます(たとえば、2 番目の要求がサーバ 2 に送られ、3 番目の要求はサーバ 3に送られます)。


Active Directory グループ検索機能の変更:LDAP クエリは、LDAP クエリが失敗しない限り、認証を行うために割り当てられている同じ Active Directory サーバへ送信されます。LDAP クエリが失敗すると、Content Engine は認証要求を次に設定されているサーバへ送信します(Content Engine は 1 つのサーバにだけ実行します)。

NTLM ネスト グループ検索機能がイネーブルの場合、 ldap-search-server host グローバル設定コマンドを設定する必要はありません。Content Engine は、設定された NTLM サーバの IP アドレスを自動的に使用して、LDAP クエリを送信します。

NTLM サーバ用の新しいscheme コマンド オプション:scheme オプションが ntlm server と、ntlm server ad-group-search gc-server のグローバル設定コマンドに追加されました。このオプションは、設定した NTLM や Global Catalog サーバで利用できる方式(負荷分散やフェールオーバー)の指定を可能にします。デフォルト方式はフェールオーバーです。HTTP 要求承認用の NTLM サーバの方式を指定するには、ntlm server scheme グローバル設定コマンドを使用します。2 番目の例で示すとおり、Active Directory グループ検索用の Global Catalog サーバの方式を変更するには、ntlm server ad-group-search gc-server scheme グローバル設定コマンドを使用します。

ContentEngine(config)# ntlm server ?
ad-group-search Active Directory group search options
connection-retry Maximum attempts to connect to server
connection-timeout Time to wait connecting to server (second
domain Specify Domain name
enable Enable NTLM Authentication
host Host options
scheme Scheme to use for the host list
ContentEngine(config)# ntlm server ad-group-search gc-server ?
host Specify global catalog server address
port Specify global catalog server port, default 3268
scheme Scheme to use for the host list
 

ポーリング スレッド:設定した NTLM または Global Catalog サーバのうちの 1 つが故障と認識されると、Content Engine が受信した要求を送信しないように、負荷分散ファームまたはフェールオーバー ファームから削除されます。Content Engine は定期的にデッド サーバをポーリングします(30 秒毎)。Content Engine がサーバからの応答を受け取ると、負荷分散ファームまたはフェールオーバー ファームにサーバを戻します。

NTLM 用の認証方法制御:Content Engine がNTLM 認証ヘッダーと一緒に基本認証応答ヘッダーを送信することを有効または無効にする機能。詳細は、「NTLM HTTP 要求認証用の認証方法コントロールの設定」を参照してください。

デフォルト NTLM ドメインがない場合のサポート:クライアントが要求認証クレデンシャルでドメイン名を提供せず、Content Engine にもデフォルト ドメインが設定されていない場合、クライアントに認証エラーが返されます。あらかじめ用意されているエラー ページで、エラーの理由を示すテキストがクライアントに送信されます。この機能は、「ドメインなしの設定」機能とも呼ばれます。


) ドメインなしの設定機能は、NTLMをサポートしていないブラウザ(たとえば、Netscape 7.1 以前のブラウザ[Netscape 7.2 以降は NTLM をサポート])でのみサポートされます。Netscape ブラウザでは、Content Engine が NTLM のデフォルト ドメインを設定していない場合は、ユーザがドメインを指定する必要があります。指定しないと、エラーメッセージが表示されます。Netscape ブラウザでは、ドメインはユーザ名の一部として 「domain\username」の形式でのみ提供されます。NTLM をサポートしている Internet Explorer などのブラウザでは、ドメイン名は認証クレデンシャルに常にあり、ユーザがクレデンシャルを指定するように要求される場合および、ドメインがユーザをデスクトップにログインさせる場合に起動します。


設定可能ドメインのリスト:Content Engine でNTLM HTTP 要求認証を実行できるドメインのリストを指定する機能。詳細は、「許可ドメイン リスト NTLM HTTP 要求認証のリストの設定」を参照してください。

transaction-logs log-window-domain グローバル設定コマンドを使用して、Content Engine がユーザ名とドメイン名をトランザクション ログに送信するように設定します。NTLM 認証に使用する Windows ドメイン名は、トランザクション ログのユーザ名フィールドに表示されます。ユーザ名は「domain\username」の形式で表示され、拡張 Squid-style または %u フォーマット トークンを使ったカスタム形式内にあるのユーザ名を含むフォーマットで表示されます。

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

ドメイン外のクライアントが Netscape 7.1 以前のブラウザを使用している場合、ダイアログボックスが表示され最初の認証要求で、ユーザ名とパスワードの入力をクライアントに要求します。クライアントの認証が成功したら、エントリがキャッシュ内に置かれ、認証キャッシュのエントリが無効になるまで、再認証要求は行われません。

HTTP 要求認証のための NTLM 負荷分散

ACNS 4.x ソフトウェアから 5.1 ソフトウェアでは、HTTP 要求認証用に 1 つのプライマリ ドメイン コントローラと、フェールオーバー用のセカンダリ ドメイン コントローラを設定する必要があります。しかし、大規模なネットワークでは、たとえ Content Engine の認証キャッシュがドメイン コントローラへの負荷を軽減できたとしても、大量のトラフィックが Content Engine を通過すると、1 つのドメイン コントローラでは、すべてのエンド ユーザからの認証クエリを処理できなくなる場合があります。

この問題に対処するために、ACNS 5.2 ソフトウェアではドメイン コントロール間の負荷分散が追加されました。ACNS 5.2.1 ソフトウェアまたはそれ以降では、負荷分散とフェールオーバー用にサーバを 8 台まで設定できる機能が追加されました。サーバ設定の順番は、負荷分散およびフェールオーバーの順番を決定します。

負荷分散が方式として選択されると、要求はドメインとコントローラ間をラウンドロビンします。たとえば、n 個のサーバ(ドメイン コントローラ)がある場合、最初の要求はサーバ 1 に行き、2 番目の要求はサーバ 2 へ行き、n 番目の要求はサーバ nへ、(n+1)番目の要求はサーバ 1 に送信されます。サーバ 1 に障害が起こると、Content Engine は、要求を次に設定されている利用可能なサーバーへ送信します(この場合はサーバ 2)。しかし、次の利用可能サーバへのフェールオーバーは 1 回だけ発生します。たとえば、要求 1 の処理中にサーバ 2 がダウンしても、要求 1 は再度フェールオーバーしません。

負荷分散が有効になっていて、サーバ情報が実行時に変更されると、サーバに影響することなく実行時にその変更が反映されます。設定済みの NTLM や Global Catalog サーバの設定値は、show ntlm EXEC コマンドで参照できます。サーバを通過した要求の総数についての統計情報は、show statistics ntlm EXEC コマンドで集計され表示できます。各ドメイン コントローラを通過した要求についての統計情報は、show statistics ntlm EXEC コマンドで集計され表示できます。


) Active Directory のネスト グループ検索が有効になっている場合、同じドメインのサーバのみサポートされます。Active Directory のネスト グループ検索がイネーブルでない場合、複数ドメイン内のサーバが信頼できる関係であればサポートされます。


HTTP 要求認証に NTLM サーバを使用する Content Engine の設定

Content Engine の GUI または CLI を使用して、スタンドアロン Content Engine が HTTP 要求認証に対して外部 NTLM サーバを使用するように設定できます。

ACNS 5.1.x またはそれ以前のソフトウェアでは、ntlm server host グローバル設定コマンドの primary および secondary オプションを使用してプライマリ NTLM サーバとセカンダリ NTLM サーバを明示的に指定できます。

ContentEngine(config)# ntlm server host 172.16.10.10 primary
ContentEngine(config)# ntlm server host 172.16.10.12 secondary
 

ACNS 5.2.1 およびそれ以降のソフトウェアでは、HTTP 要求認証用に NTLM サーバを 8 台まで使用するように Content Engine を設定できます。サーバ設定の順番は、負荷分散やフェールオーバーの順番で決定します。たとえば、フェールオーバーが有効になっている場合は、最初に設定したサーバ(IP アドレスが 172.16.10.10 のサーバ 1)が「プライマリ」サーバで、すべての要求を最初のサーバに送ります。最後に設定したサーバ(IP アドレスが 172.16.10.14 のサーバ 3)は、最後のサーバで、Content Engine と連絡しています。負荷分散が有効になっている場合は、最初の要求だけが最初に設定したサーバ(サーバ 1)に送信され、その後は他のサーバでラウンドロビンが使用されます(たとえば、2 番目の要求がサーバ 2 に送られ、3 番目の要求はサーバ 3に送られます)。

ContentEngine(config)# ntlm server host 172.16.10.10
ContentEngine(config)# ntlm server host 172.16.10.12
ContentEngine(config)# ntlm server host 172.16.10.14
 

) ACNS 5.2 ソフトウェアでは 8 台までのサーバがサポートされたため、ntlm server host primary オプションと ntlm server host secondary オプションは削除されました。ACNS 5.2.1 ソフトウェア リリースでは、ntlm server host scheme load-balanced オプションが追加されました。


Content Engine GUI または CLI を使用して、Content Engine が HTTP 要求認証に対して 8 台までの NTLM サーバを使用するように設定できます。

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

Content Engine CLI から ntlm server グローバル設定コマンドを使用します。

次の例では、Content Engine CLI を使用して、スタンドアロン Content Engine が HTTP 認証要求を負荷分散させるために使用できる最大のサーバ数(8 台の NTLM サーバ)を設定する方法を説明しています。


ステップ 1 ntlm server host グローバル設定コマンドを使用して、HTTP 要求認証用に Content Engine が使用する各 NTLM サーバのホスト名と IP アドレスを指定します。設定された NTLM サーバのリストは、「ホスト リスト」と呼ばれます。

次の例では、8 台の NTLM サーバで構成されるホスト リストを使用するようにContent Engine を設定しています。

ContentEngine(config)# ntlm server host 172.16.10.10
ContentEngine(config)# ntlm server host 172.16.10.12
ContentEngine(config)# ntlm server host 172.16.10.14
ContentEngine(config)# ntlm server host 172.16.10.16
ContentEngine(config)# ntlm server host 172.16.10.18
ContentEngine(config)# ntlm server host 172.16.10.20
ContentEngine(config)# ntlm server host 172.16.10.22
ContentEngine(config)# ntlm server host 172.16.10.24
 

ステップ 2 Content Engine が、設定された NTLM サーバのうちの 1 台への接続を試行する回数を指定します。

次の例では、この値は 3 に設定されています。

ContentEngine(config)# ntlm server connection-retry 3
 

デフォルトは 2 回です。有効な値は、1 ~ 3 です。指定した回数を超えると、Content Engine は NTLM へ接続を試みることを中止し、ホスト リストで次に設定されているサーバへ接続を開始します。

ステップ 3 Content Engine が接続しようとした NTLM サーバからの応答を待機する時間を設定します。

次の例では、このタイムアウトは 10 秒に設定されています。

ContentEngine(config)# ntlm server connection-timeout 10
 

これは、正常に接続できるまでのタイムアウトです。指定された時間を超えると、Content Engine はこの接続をやめて、指定された回数( ntlm server connection-retry グローバル設定コマンドで指定された再試行回数)に到達するまで、Content Engine は次のサーバではなく、同じサーバへ接続を試みます。デフォルトは 5 秒です。有効な値は 1 ~ 20 秒です。

 

ステップ 4 設定した NTLM サーバをフェールオーバーか負荷分散のどちらに使用するか指定します。

ContentEngine(config)# ntlm server scheme ?
fail-over Fail-over between hosts
load-balanced Round-robin load balancing between hosts
 

デフォルトでは、設定したサーバはフェールオーバーに使用されます。次の例では、デフォルトを変更し、負荷分散用に設定したサーバを使用するように Content Engine を設定しています。

ContentEngine(config)# ntlm server scheme load-balanced
 

負荷分散が有効になっている場合は、最初の要求は最初に設定されたサーバへ送られ、設定されている残りのサーバではラウンドロビンが使用されます。逆に、フェールオーバーが有効になっている場合は、Content Engine はすべての要求を最初に設定されたサーバへ送信します。

ステップ 5 Content Engine 上で NTLM 認証を有効にします。

ContentEngine(config)# ntlm server enable
 

ステップ 6 Content Engine 上に NTLM 設定を表示します。

ContentEngine# show ntlm
 

コマンドの出力をチェックし、表示された NTLM 設定が指定した設定(たとえば、指定した NTLM サーバがリストにあるか、負荷分散は指定されているか)を反映しているか確認してください。show ntlm EXEC コマンドの出力例については、「スタンドアロン Content Engines の現在の NTLM 設定を表示」を参照してください。


 

許可ドメイン リスト NTLM HTTP 要求認証のリストの設定

ACNS 5.1.x ソフトウェアでは、エンド ユーザが再度認証される Windows NT ドメイン名を指定する必要があります。これは、デフォルト NTLM ドメイン名と呼ばれています。たとえば、次のコマンドは、ユーザが認証されるためには「cisco.com」というドメインに対する認証が必要であることを指定していました。

ContentEngine(config)# ntlm server domain-name cisco.com
 

ACNS 5.2.1 ソフトウェアまたはそれ以降では、デフォルト ドメインの名前を指定する必要はありません。クライアントが要求認証クレデンシャルでドメイン名を提供せず、Content Engine でデフォルト ドメインが設定されていない(つまり、ntlm server domain グローバル設定コマンドが使用されていない)場合は、認証エラー メッセージがクライアントに返されます。あらかじめ用意されているエラー ページで、エラーの理由を示すテキストがクライアントに送信されます。

ACNS 5.2.1 ソフトウェアまたはそれ以降では、Content Engine で NTLM HTTP 要求認証の実行が許可されるドメインのリストを指定できます。この機能により、追加セキュリティが提供され、Content Engine で NTLM HTTP 要求認証を実行するドメインを制限することが可能です。この機能は、「許可ドメイン機能」と呼ばれています。この機能が Content Engine 上でイネーブルで、提供されたドメイン クレデンシャルが許可ドメイン リスト内のドメインのいずれとも一致しない場合、HTTP 要求認証は失敗し、エラーメッセージがクライアントに送られます。

許可ドメイン機能をサポートするため、次の Content Engine CLI コマンドが ACNS 5.2 ソフトウェアに追加されました。

ntlm allow-domain enable :Content Engine上の許可ドメイン リスト機能を有効にします。デフォルトでは、許可ドメイン機能は無効になっています。

no ntlm allow-domain enable :Content Engine上の許可ドメイン リスト機能を無効にします。

ntlm allow-domain domain domain-name :Content Engine で NTLM HTTP 要求認証の実行が許可されているドメイン名を定義します。ドメイン リスト は32 個までのドメイン名を含むことができます。

許可ドメインリスト機能が有効になっている場合は、この機能は次のようになります。

クライアントのドメイン クレデンシャルが、設定されたドメイン リストにあるドメインのいずれかと一致した場合、Content Engine はコンテンツ要求のためのNTLM HTTP 要求認証を実行します。指定されたドメインが許可ドメインリスト内にあるかチェックする時は、大文字小文字を区別して比較されます。

クライアントのドメイン クレデンシャルが、設定されたドメイン リストにあるドメインのいずれとも一致しない場合、あるいは許可ドメイン リストに設定されたドメインがない場合、Content Engine はこのコンテンツ要求を拒否し、クライアントに 407 か 401 の認証エラー メッセージを送信します。407 または 401 認証メッセージは、エラーの理由を示すテキストをあらかじめ用意しています。

NTLM HTTP 要求認証用の認証方法コントロールの設定

デフォルトでは、Content Engine は常に基本認証応答ヘッダーを NTLM 認証ヘッダーと一緒にクライアント ブラウザに送信します。このデフォルトの対応では、クライアントのブラウザが Netscape ブラウザのように NTLM プロトコルをサポートしていなくても、Content Engine で認証されます(Internet Explorer は NTLM プロトコルをサポートしています)。

基本認証ではユーザのクレデンシャル情報を平文形式で送信するため、NTLM 認証よりも安全でありません。そのため、セキュリティの観点から、認証応答ヘッダーを NTLM 認証ヘッダーと一緒に送信しないように Content Engine を設定することもできます。

ACNS 5.2.1 ソフトウェアまたはそれ以降では、NTLM HTTP 要求認証用の認証方法コントロールを設定することができます。認証方法コントロール機能では、Content Engine が基本認証応答ヘッダーを NTLM 認証ヘッダーと一緒に送信することを有効にも無効にもできます。この機能をサポートするため、次の Content Engine CLI コマンドが ACNS 5.2.1 ソフトウェア リリースに追加されました。

ntlm basic-auth enable :Content Engine は、クライアントのブラウザに基本認証応答ヘッダーを NTLM 認証ヘッダーと一緒に送信します。

no ntlm basic-auth enable :Content Engine は、クライアントのブラウザに基本認証応答ヘッダーを NTLM 認証ヘッダーと一緒に送信しないか、要求で許可しません。

基本認証は NTLMよりも安全でないため、クライアントと Content Engine 間でNTLM HTTP 要求認証のための基本認証方法を使用できないようにするには、スタンドアロン Content Engine 上でNTLM 基本認証機能を無効にします。

スタンドアロン Content Engine でNTLM 基本認証機能を無効にするには、 no ntlm basic-auth enable グローバル設定コマンドを入力してください。

Content Engine が基本認証ヘッダーをクライアントに送信しないように設定されていて、クライアントは NTLM 認証(たとえば、Netscape ブラウザは基本認証だけをサポート)をサポートしていない場合は、クライアントは HTTP 要求を継続できません。クライアント ブラウザの対応は、ブラウザの設定によって異なります。ブラウザによっては、一定時間要求を試みる場合もあります。

スタンドアロン Content Engines の現在の NTLM 設定を表示

Content Engine が使用する NTLM サーバや Global Catalog サーバの個々の情報を表示するには、 show ntlm EXEC コマンドを入力します。

ContentEngine# show ntlm
NTLM parameters:
NTLM Hosts:
172.16.10.10
172.16.10.12
172.16.10.14
172.16.10.16
172.16.10.18
172.16.10.20
172.16.10.22
172.16.10.24
scheme: Load-balanced
State: 有効
Basic Auth: 有効
Default domain: cnbu1.local
Connection Timeout: 10
Connection Retries: 3
Allow Domains: 無効
Allow Domains List:
None
AD group search is enabled
Enumeration User:
Username: administrator
Password: ****
Domain: abc1.local
LDAP Port:389
Global Catalog Servers:
172.16.10.32 , Domain: abc1.local
172.16.10.38 , Domain: abc2.local
Scheme: Load-balanced
Port: 3268
User objectclass: user
Username attribute: sAMAccountName
Groupname attribute: cn
Membership attribute: memberOf
 

スタンドアロン Content Engines の NTLM 統計情報の表示

認証および拒否された要求の数、設定された個々の NTLM サーバや Global Catalog サーバの統計情報の詳細など、NTLM 統計情報を表示するには、show statistics ntlm EXEC コマンドを使用します。

スタンドアロン Content Engines でのグループ ベース許可の設定

要求許可に関して、ACNS 5.x ソフトウェアは、LDAP および NTLM ユーザ用にグループ ベースのアクセス コントロール リストをサポートしています。ACNS ソフトウェア リリース 5.1 より前のリリースでは、グループ名ベースのアクセス コントロール リストはサポートされていましたが、静的グループはサポートされていませんでした。このグループ名ベースのアクセス リストの機能は、グループ ベースの許可と呼ばれます。デフォルトでは、アクセス リスト機能は Content Engine で無効になっています。グループ情報が確認および適用されるのは、アクセス リスト機能が Content Engine 上で有効になっている場合のみです。


) ACNS 5.2.1 ソフトウェア リリースでは、グループ ベースのルールも追加され、グループ ベースの許可で利用可能になります。グループ ベースのルールの詳細については、「スタンドアロン Content Engine の Rules Template の設定」 を参照してください。


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

スタンドアロン Content Engines でのアクセス リストの設定

グループ ベースの許可用のアクセス リストを使用するようにスタンドアロン Content Engine を設定する手順は、次のとおりです。


ステップ 1 access-lists 300 グローバル設定コマンドを使用して、あるグループが スタンドアロン Content Engine を使用してインターネットにアクセスするのを許可、または拒否します。

次の例では、 access-lists 300 permit groupname グローバル設定コマンドを使用して、Marketing や Engineering など組織ユニットに基づく基本ストリング cisco 内のあるグループにアクセスを許可する方法を示しています。Marketing や Engineering グループ内のユーザ全員にはグループ アクセスが許可されます。 access-lists 300 deny groupname any グローバル設定コマンドにより、どのグループにも属さないユーザはアクセスを拒否されます。

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

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

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

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


) Content Engine GUI から、System > Access Lists の順に選択し、表示された Access Lists ウィンドウを使用して、アクセス リストのエントリを定義します。Access Lists ウィンドウの使用方法の詳細については、ウィンドウ内にある HELP ボタンをクリックしてください。


ステップ 2 グループ名ベースのアクセス リスト機能を Content Engine 上で有効にします。

ContentEngine(config)# access-lists enable
 

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



 

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

ACNS のリリース 5.1 より前のリリースでも、グループ名ベースのアクセス リストはサポートされていましたが、静的グループはサポートされていませんでした。Content Engine のグループ許可サポートと Microsoft Active Directory データ ベースを確実に相互運用できるようにするために、ACNS 5.1 ソフトウェアまたはそれ以降では、静的グループのための LDAP グループ ベースの認証をサポートしています。

このシナリオでは、インターネットへのグループ アクセスは次のユーザに許可されます。

企業名が「cisco」の「Marketing」組織ユニットに所属するユーザ全員。

企業名が「cisco」の「Engineering」組織ユニットに所属している「Hardware Engineers」グループに所属するユーザ以外のユーザ全員。「Hardware Engineers」というネストされたグループのメンバは、明示的にアクセスを拒否されているグループに所属しているのでアクセスを拒否されます。


) このシナリオでは、LDAP ディレクトリは図10-3で表示している構造であると想定しています。


このシナリオでは、次に示すとおり、LDAP 管理者は「Engineering」グループを 「Hardware Engineers」および「Software Developers」の親グループとして LDAP ディレクトリ内で定義したと想定しています。

dn: cn=Engineering,dc=cisco,dc=com
cn: Engineering
objectclass: groupOfNames
member: cn:Hardware Engineers,dc=cisco,dc=com
member: cn:Software Developers,dc=cisco,dc=com
 
dn: cd=Hardware Engineers,dc=cisco,dc=com
cn: Hardware Engineers
object: groupOfNames
member: cn=Jay Doe,ou=Engineering,dc=cisco,dc=com
member: cn=Don Smith,ou=Engineering,dc=cisco,dc=com
 
dn: cn=Software Developers,cd=cisco,cd=com
cn: Software Developers
objectclass: groupOfNames
member: cn=John Gold,ou=Engineering,dc=cisco,dc=com
member: cn=John Smith,ou=Engineering,dc=cisco,dc=com
 

LDAP グループ ベースの許可用にスタンドアロン Content Engine を設定する手順は、次のとおりです。


ステップ 1 LDAP サーバへのアクセスを有効にします。LDAP サーバのホスト名か IP アドレスを入力します。

次の例では、LDAP サーバの IP アドレスを使用しています。

ContentEngine(config)# ldap server host 10.1.1.1
 

ステップ 2 ディレクトリ検索の開始ポイントとなるベースの認定者名(dn)を指定します。この例では、文字列の「cisco」と「com」をディレクトリ検索に使用しています。

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

ステップ 3 Content Engine 上で LDAP 認証を有効にします。

ContentEngine(config)# ldap server enable
 

ステップ 4 access-lists 300 groupname グローバル設定コマンドを使用して、Content Engine が提供するコンテンツへアクセスを許可または拒否されるグループを定義します。

次の例では、「Hardware Engineering」というネストされた静的グループのメンバ以外のすべてのユーザにグループ アクセスを許可しています。

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

ステップ 5 Content Engine 上のグループ名ベースのアクセス リストを有効にします。

ContentEngine(config)# access-lists enable
 


 

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

次の例では、アクセス リストでの NTLM グループ許可を設定するために Content Engine CLI を使用する方法を示しています。この例では、NTLM グループ アクセスは、会社名が「cisco」の「Engineering」と「Marketing」グループに許可されています。

スタンドアロン Content Engine 上で、アクセス リストでのスタンドアロン NTLM グループ許可を設定する手順は、次のとおりです。


ステップ 1 NTLM サーバへのアクセスを有効にします ntlm server host グローバル設定コマンドを使用して、NTLM サーバのホスト名か IP address のいずれかを入力します。


) ACNS 5.2.1 ソフトウェアまたはそれ以降では、HTTP 要求認証用に NTLM サーバを 8 台まで設定できます。


次の例では、3 台の NTLM サーバを設定しています。

ContentEngine(config)# ntlm server host 172.16.10.10
ContentEngine(config)# ntlm server host 172.16.10.12
ContentEngine(config)# ntlm server host 172.16.10.14
 

サーバ設定の順番は、負荷分散やフェールオーバーの順番を決定します。フェールオーバーが有効になっている場合、Content Engine はその要求のすべてを最初に設定されたサーバへ送信します(IP アドレスが 172.16.101.0 のサーバ 1)。逆に、負荷分散が有効になっている場合、最初の要求だけがサーバ 1 に送信され、その後は他のサーバでラウンドロビンが使用されます(たとえば、2 番目の要求がサーバ 2[IP アドレスが 172.16.10.12 のサーバ] に送られ、3 番目の要求はサーバ 3[IP アドレスが 172.16.10.14 のサーバ]に送られます)。

ステップ 2 負荷分散用に設定された NTLM サーバのリストを使用するように Content Engine を設定します。デフォルト方式はフェールオーバーです。

ContentEngine(config)# ntlm server scheme load-balanced
 

ステップ 3 (オプション)デフォルト ドメインを指定します。

ContentEngine(config)# ntlm server domain cisco.com
 

ACNS 5.1.x ソフトウェアでは、デフォルト ドメインを指定する必要があります。ACNS 5.2.1 ソフトウェアまたはそれ以降では、デフォルト ドメインを指定する必要はありません。クライアントが要求認証クレデンシャルでドメイン名を提供せず、Content Engine でデフォルト ドメインが設定されていない(ntlm server domain グローバル設定コマンドが使用されていない)場合は、認証エラー メッセージがクライアントに返されます。あらかじめ用意されているエラー ページで、エラーの理由を示すテキストがクライアントに送信されます。

ACNS 5.2.1 ソフトウェアまたはそれ以降では、Content Engine 上で NTLM HTTP 要求認証の実行が許可されるドメインのリストを指定できます。詳細は、「許可ドメイン リスト NTLM HTTP 要求認証のリストの設定」を参照してください。

ステップ 4 Content Engine 上で NTLM 認証を有効にします。

ContentEngine(config)# ntlm server enable
 

ステップ 5 access-lists 300 permit groupname グローバル設定コマンドを使用して、Marketing や Engineering のような組織単位で、基本文字列 cisco 内のグループにアクセスを許可します。

次の例では、Marketing と Engineering のすべてのユーザにグループ アクセスが許可されます。 access-lists 300 deny groupname any グローバル設定コマンドにより、これらのどのグループにも属さないユーザはアクセスを拒否されます。

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

ステップ 6 Content Engine 上のグループ名ベースのアクセス リストを有効にします。

ContentEngine(config)# access-lists enable
 


 

Active Directory グループ検索のための Content Engines の設定

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

ACNS 5.1 ソフトウェアまたはそれ以降では、LDAP 再帰サーチを使用してネストされたグループ名を取得でき、ネストされたグループ用に設定したアクセス リストすべてを適用できます。Active Directory サーバでネストされたグループを使用すると、親グループに設定したポリシーは自動的にサブグループのメンバに適用されます。


) Active Directory には、universal、global、domain local の 3 種類のグループがあります。


再帰クエリを実行し、グループ名の完全なリストでプライマリ ドメイン コントローラをクエリするには、列挙ユーザのクレデンシャルが提供される必要があります。列挙ユーザは Content Engine で定義されたアカウントで、Content Engine が Active Directory サーバで検索を実行できます。列挙ユーザは、ディレクトリ全体で、読み取り権限が必要です。

ACNS 5.1.x ソフトウェアでは、グループ名ベースのアクセス リストは、Active Directory のグループ検索をトリガーするだけの機能でした。ACNS 5.2.1 ソフトウェアまたはそれ以降では、次の追加機能が Active Directory グループ検索をトリガーすることができます。

グループ ベースのルールが Rules Template で設定されている場合(「スタンドアロン Content Engine の Rules Template の設定」を参照)

ICAP が認証グループ ヘッダーを付加するように設定されている場合(「スタンドアロン Content Engine の ICAP サービスの設定」を参照)

SmartFilter 製品が Content Engine 上で有効になっている場合(「SmartFilter ソフトウェアを使用した URL フィルタリングの設定」を参照)

ACNS 5.1.x ソフトウェアでは、Active Directory グループ検索用にプライマリとセカンダリ Global Catalog サーバを明示的に指定する必要がありました。プライマリ Global Catalog サーバに接続できない場合、Content Engine はセカンダリ Global Catalog サーバへ接続を試みていました。

ACNS 5.1.x ソフトウェアでは、Active Directory グループ検索用にプライマリとセカンダリを明示的に指定してグループ情報を取得していました。プライマリとセカンダリ サーバを明示的に指定するには、primary と secondary のキーワード付きで、ntlm server ad-group-search ldap-search-server host グローバル設定コマンドを使用していました。次に例を示します。

ContentEngine(config)# ntlm server host 172.16.10.10 primary
ContentEngine(config)# ntlm server host 172.16.10.12 secondary
 

しかし、Active Directory の場合は、ドメイン コントローラが NTLM と LDAP の双方をサポートするので、Active Directory のグループ検索用にプライマリとセカンダリのサーバを設定する必要がありません。ACNS 5.1.x ソフトウェアでは、次の 2 つの Content Engine CLI コマンドが同じタスクを実行(つまり、同じ Active Directory のドメイン コントローラを設定)していました。

ntlm server host

ntlm server ad-group-search ldap-search-server host

そのため ntlm server ad-group-search ldap-search-server host グローバル設定コマンドは、ACNS 5.2.1 ソフトウェア リリースから削除されました。下位互換性はサポートされています。この削除された Content Engine CLI コマンドをもつ ACNS 5.1.x ソフトウェアで実行される設定は受け入れられますが、バック エンドでは無視されます。

ACNS 5.2.1 ソフトウェアまたはそれ以降では、Active Directory のネストされたグループ検索機能がイネーブルな場合に、ntlm server host グローバル設定コマンドを使用して設定された Active Directory ドメイン コントローラ(ホスト)は、認証と許可の両方に使用されます。

ACNS 5.2.1 ソフトウェアまたはそれ以降では、Active Directory 検索用に Global Catalog サーバを 8 台まで設定できます(ACNS 5.2.1 ソフトウェア リリースでは、 ntlm server ad-group-search gc-server host primary オプションと ntlm server ad-group-search gc-server host secondary オプションは削除されました)。サーバ設定の順番は、負荷分散やフェールオーバーの順番を決定します。フェールオーバーが有効になっている場合、Content Engine は Active Directory 検索要求のすべてを最初に設定された Global Catalog サーバ(サーバ 1)に送信します。逆に、負荷分散が有効になっている場合は、最初の要求だけがサーバ 1 に送信され、その後はラウンドロビンが使用されます(たとえば、2 番目の要求がサーバ 2 に送られ、3 番目の要求はサーバ 3 に送られます)。

Content Engine が Active Directory グループ検索で使用する Global Catalog サーバを設定するには、ntlm server ad-group-search gc-server グローバル設定コマンドを使用します。たとえば、ntlm server ad-group-search gc-server host host-IP-address または hostname コマンドを使って、Content Engine が Active Directory のグループ検索で使用する Global Catalog サーバの IP アドレスやホスト名を指定します。

ntlm server ad-group-search gc-server host domain domain-name グローバル設定コマンドを使って、設定した Global Catalog サーバ用のホスト ドメイン名(たとえば、「abc1.local」)を指定します。次の例では、Content Engine が、「abc1.local」というホスト ドメイン名をもつ Global Catalog サーバを使用するように設定しています。

ContentEngine(config)# ntlm server ad-group-search gc-server host 10.77.157.213 domain abc1.local
 

ACNS 5.2.1 ソフトウェアまたはそれ以降では、ntlm server ad-group-search グローバル設定コマンドの ldap-search-port オプションを使用してグループ情報を取得する LDAP ポートを指定できます。デフォルトではポート 389 です。このオプションは、設定されたすべての Active Directory ドメイン コントローラに対して、LDAP 検索サーバ ポートを設定します。


ldap-search-port オプションは、ACNS 5.1.x ソフトウェアの ldap-search-server port オプションに代わるオプションです。


ACNS 5.2.1 ソフトウェアまたはそれ以降では、ntlm server ad-group-search gc-server グローバル設定コマンドの scheme オプションを使用して、設定した Global Catalog サーバを負荷分散とフェールオーバーのいずれに使用するかを指定できます。

ContentEngine(config)# ntlm server ad-group-search gc-server ?
host Specify global catalog server address
port Specify global catalog server port, default 3268
scheme Scheme to use for the host list
 

ACNS 5.2.1 ソフトウェアまたはそれ以降では、NTLM 負荷分散機能がサポートされ、ドメイン間の認証がより一般的な配置シナリオになりました。ACNS 5.3.1 ソフトウェア リリースでは、LDAP 照会機能のサポートが追加されました。

LDAP 照会機能のサポートにより、設定された Active Directory ドメイン コントローラとは違うけれども信頼できるドメインに所属しているユーザの認証情報を ACNS ソフトウェアで取得することができます。Active Directory ドメイン コントローラが、自身のドメインではないが信頼できるドメインに所属しているユーザの LDAP クエリを受信した場合、Content Engine へ LDAP 照会 URL が返信されます。LDAP 照会機能が Content Engine 上で有効になっている場合、Content Engine は照会 URL 内の参照されたサーバの情報を取得し、そのサーバに接続してユーザの認証情報を要求します。

LDAP 照会機能のサポートにより、次のことが可能になります。

Active Directory の信頼できるドメイン ユーザ認証のサポート

NTLM のネストされたグループ検索のための LDAP 照会のサポート

LDAP ネスティング照会レベルの設定が可能

NTLM 負荷分散用の複数のドメインから Active Directory ドメイン コントローラが設定可能


) NTLM 負荷バランス用の複数のドメインから Active Directory ドメイン コントローラの設定を可能にするには、複数のドメインが信頼できる関係にあることが必要です。異なった信頼できないドメインからの複数のドメイン コントローラが設定されている場合、認証と許可は正確に実行できません。


LDAP 照会機能をサポートするために、 ntlm server ad-group-search ldap-referral グローバル設定コマンドが、ACNS 5.3.1 ソフトウェア リリースに追加されました。

ContentEngine(config)# ntlm server ad-group-search ldap-referral ?
enable Enable ldap referral. (Default is Disabled)
limit Maximum depth of nested referral to follow
 

デフォルトでは、LDAP 照会機能は Content Engine 上で無効になっています。この機能を有効にするには、 ntlm server ad-group-search ldap-referral enable グローバル設定コマンドを入力します。LDAP 照会機能を Content Engine で有効にした後、 ntlm server ad-group-search ldap-referral enable グローバル設定コマンドを入力して、この機能をそれ以降また無効にできます。

NTLM のネストされたグループ検索のための照会制限を指定するには、 ntlm server ad-group-search ldap-referral コマンドの ldap-referral limit option を使用します。デフォルトでは、NTLM のネストされたグループ検索のために 5 件のネストされた照会が許可されます。有効な値は 1 ~ 10 です。

第 1 レベルの検索結果に目的とする結果(Content Engine が検索していた結果)が含まれていたとしても、Active Directory サーバは複数のネストされた照会 URL を返そうとします。それによって Active Directory サーバに対して更なる不必要なラウンド トリップが発生します。したがって、ディレクトリ構造により最初の数レベルでの検索応答が目的の検索結果を含むことが確実な場合、照会制限の数字をより小さくすることができます。

たとえば、第 1 レベルの検索応答に検索結果が含まれる場合、実行を目的として照会制限を 1 に設定できます。照会制限を 1 に設定することによって、Content Engine は正しいドメイン コントローラ(ドメイン コントローラ A)と接続するため 1 つの照会 URL にのみ従い、ドメイン コントローラ A の検索結果とともに発生したさらなる不必要な照会 URL には従いません。

次の例では、NTLM のネストされたグループ検索のために許可されたネストされた照会を 5 つではなく 1 つ指定する方法を示します。

ContentEngine(config)# ntlm server ad-group-search ldap-referral limit 1
 

スタンドアロン Content Engines 上で現在の NTLM パラメータ設定を表示する場合は、 show ntlm EXEC コマンドを入力します。コマンド出力には、現在の照会制限(たとえば、コマンド出力「LDAP referral chasing limit: 8」)に加えて、LDAP 照会機能が有効になっているか(たとえば、コマンド出力「LDAP referral chasing:Enabled」)というような情報も含まれます。

Active Directory グループ検索をサポートする Content Engine の設定例

次の例では、Content Engine が Active Directory グループ検索をサポートするように設定するntlm server ad-group-search グローバル設定コマンドの使い方を示しています。この例では、Content Engine がActive Directory グループ検索のために 10.77.157.213 の IP アドレスをもつ Global Catalog サーバを使用するように設定されています。Global Catalog サーバのホスト ドメイン名は abc1.local です。負荷分散が方式として指定されています(デフォルト方式はフェールオーバーです)。ポート 111 は、グループ情報を取得のため LDAP ポートとして指定されます。Active Directory のグループ検索パラメータ設定後、ntlm server ad-group-search enable グローバル設定コマンドを使用して、スタンドアロン Content Engine 上で Active Directory グループ検索機能を有効にします。

ContentEngine(config)# ntlm server ad-group-search enum-user username administrator
ContentEngine(config)# ntlm server ad-group-search enum-user password ***
ContentEngine(config)# ntlm server ad-group-search enum-user domain abc1.local
ContentEngine(config)# ntlm server ad-group-search gc-server host 10.77.157.213 domain abc1.local
ContentEngine(config)# ntlm server ad-group-search gc-server host 10.77.157.214 domain abc1.local
ContentEngine(config)# ntlm server ad-group-search gc-server scheme load-balanced
ContentEngine(config)# ntlm server ad-group-search ldap-search-port 111
ContentEngine(config)# ntlm server ad-group-search enable
ContentEngine(config)# ntlm server ad-group-search ldap-referral limit 1
ContentEngine(config)# ntlm server ad-group-search ldap-referral enable
 

Active Directory 検索グループを有効にすると、アクセスリンクを正しいドメイン名で設定する必要があります。グループ名は、次のようになります。

DNS domain name \ group name

次の例では、アクセス リストを使用して、Active Directory 検索グループをイネーブルにしています。

ContentEngine(config)# access-lists 300 permit groupname mydomain.local\univ11_sec
ContentEngine(config)# access-lists 300 deny groupname any
ContentEngine(config)# access-lists enable
 

LDAP クエリは、LDAP クエリが失敗しない限り、認証の実行に割り当てられた同じ Active Directory サーバへ送られます。LDAP クエリが失敗すると、許可要求は次に設定されているサーバへフェールオーバーします。Active Directory サーバ上の NTLM サービスまたは LDAP サービスにアクセスできない場合は、Content Engine はActive Directory が機能していないと判断します。

グループ名ベースのアクセス リストの無効化

Content Engine 上にあるグループ名ベースのアクセス リスト機能は、次のとおり、設定したアクセス リンクを失うことなく、ディセーブルにすることができます。

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

Content Engine CLI から no access-lists グローバル設定コマンドを使用します。

LDAP Acceptable Use Policy 機能の設定

ACNS 5.1.1 ソフトウェアおよびそれ以降は、LDAP Acceptable Use Policy 機能をサポートしています。ユーザがブラウザ セッションを開始すると、Content Engine は特定の LDAP 属性の照会を行って、ユーザが「Acceptable Use Policy」(AUP)を表示し、それに同意したかどうかを判別します。ユーザがポリシーを承諾しない場合、Content Engine はユーザをAUPのある内部 Web ページにリダイレクトします。ユーザが Content Engine を介してコンテンツをブラウズするには、AUP を読んで同意する必要があります。ユーザがポリシーに同意したら、Content Engine は LDAP 属性を設定します。その属性により、ユーザはプロキシ サーバ(Content Engine)を介してブラウズを行う、完全なアクセスが許可されます。

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

AUPを有効にするには、 ldap server policy-redirect enable グローバル設定コマンドを入力します。ユーザが、ポリシーを表示し、それに同意するためにリダイレクトされる URL を指定するには、 ldap server policy-redirect redirect-url url グローバル設定コマンドを使用します。ユーザが同意したバージョンをクエリする LDAP 属性を定義するには、 ldap server policy-redirect attribute attribute コマンドを使用します。

スタンドアロン Content Engine 上で AUP を設定する手順は、次のとおりです。


ステップ 1 Content Engine 上で AUP を有効にします。

ContentEngine(config)# ldap server policy-redirect enable
 

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

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

 

ステップ 3 ユーザが同意した AUP のバージョンを判別するために Content Engine がクエリする LDAP 属性を指定します。

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

ステップ 4 Content Engine 上での AUP の現行バージョンを指定します。これはグローバル値で、すべてのユーザが AUP のバージョンに同意するかどうか決定できるように、全ユーザが閲覧できます。

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


 

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

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

HTTP 要求用エンドツーエンド認証の設定

エンドツーエンド認証は、クライアントとオリジン サーバ間で発生する認証です。HTTP プロトコルでは、HTTP 要求を発行した Web クライアントを認証する 3 つの方法があります。

基本モード

NTLM モード

Microsoft Active Directory (AD)/Kerberos


) WMT MMS プロトコルはクライアント認証用に Basic モードと NTLM モードをサポートしています。RTP/RTSP は、クライアント認証で Basic モードをサポートしています。


ACNS 5.2.1 ソフトウェアまたはそれ以降は、パススルー認証でのクライアントを認証する 3 モード(基本、NTLM、および Active Directory/Kerberos)すべてをサポートしています(「パススルー認証を介した Web クライアントの認証」を参照)。

NTLM 方法を使用するエンドツーエンド NTLM 認証には、パススルー サービス、および NTLM 認証を必要とする Web オブジェクトのキャッシングが含まれます。

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

ACNS ソフトウェアは、NTLM 認証ヘッダーを除去して、Microsoft IIS サーバに対する基本認証確認へフォールバックできるようにします。基本認証は、NTLM ベースの認証を要求している Microsoft IIS Web サーバに対して、入力されたユーザ ID をブラウザが認証できるようにするためのものです。

NTLM は Microsoft 独自のもので、文書化されていません。NTLM ヘッダーを除去すると、ブラウザは、基本認証方式にフォールバックできます。Microsoft IIS サーバが引き続き基本認証を受け入れるように設定されている場合、IIS 認証クレデンシャルは、Content Engine を通過できますが、セキュリティが低下します。基本認証ではユーザのクレデンシャル情報を平文形式で送信するため、NTLM 認証よりも安全でありません。

NTLM ヘッダーを除去するようにスタンドアロン Content Engine を設定するには、 http authenticate-strip-ntlm グローバル設定コマンドを入力します。

基本エンドツーエンド認証サポートには、Content Engine を設定して、基本認証方法で認証される Web オブジェクトをキャッシュする機能があります。デフォルトでは、Content Engine はこのようなオブジェクトをキャッシュしません。しかし、 http cache-authenticated basic グローバル設定コマンドを入力して、基本認証方法で認証される Web オブジェクトをキャッシュするように、Content Engine を設定できます。

NTLM エンドツーエンド認証

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

NTLM パススルー サービス

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

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

Content Engine は、NTLM 認証を要求するオブジェクトをキャッシュするように設定できます。サーバは、「no-store」フラグが付いた応答オブジェクトをキャッシュに保存しないようにします。このフラグがない場合、オブジェクトはキャッシュに保存されます。Content Engine が、目的の NTLM サーバにすでに接続されているクライアントからコンテンツの要求を受信する場合、Content Engine は、キャッシュを検索します。

キャッシュ ミスの場合は、要求はオリジン サーバに転送されます。その後、応答オブジェクトはクライアントに送信され、コピーがキャッシュに保存されます。

キャッシュ ヒットの場合には、Content Engine は、このクライアントとサーバ間に保護された接続があるかどうかをチェックします。オブジェクトが NTLM 認証を必要とし、クライアントとサーバ間に仮想の永続的接続がセットアップされていない場合、Content Engine は、クライアントとサーバ間の保護された接続を確立し、要求をサーバに転送します。クライアントとサーバ間の仮想の永続的接続がある場合、if-modified-since(IMS)メッセージがサーバに送信され、オブジェクトの妥当性、およびこのオブジェクトに対するユーザのアクセス権を確認します。その後、キャッシュに保存されたコピーがクライアントに送信されます。

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

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

WMT 要求用パススルー認証の設定

エンドツーエンド認証は、クライアントとオリジン サーバ間で発生する認証です。パススルー認証は、Content Engine がエンドツーエンド認証を処理する方法です。パススルー認証では、Content Engine は検査せずに認証要求とクライアントとオリジン サーバ間の応答を通過させます。

ACNS 5.2.1 ソフトウェア リリースでは、WMT MMS 要求のパススルー認証サポートが追加されました。ACNS 5.3.1 ソフトウェア リリースでは、Windows Media 9 からの WMT RTSP 要求のパススルー認証サポートが追加されました。このサポートにより、Content Engine はクライアントとオリジン サーバ間に仮想接続を確立し、オリジン サーバでクライアントを認証可能になりました。Content Engine はパススルーを行ったり、プロキシ認証サーバとして機能することはありません。そのため、プロキシ サーバ認証は WMT 要求をサポートしません。


) プロキシ サーバ認証は、HTTP 要求をサポートします。HTTP 要求では、Content Engine はプロキシ認証サーバとして機能し、クライアント自体を認証します。


プロキシ モードでは、Windows Media 9 サーバは、WMT 要求のパススルー認証のため、2 つの認証メカニズムをサポートします。

匿名認証

ネットワーク認証

プラグイン(NTLM または Kerberos)認証をネゴシエートする

プラグイン認証を要約する