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

目次

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

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

エンドツーエンドおよびパススルー認証について

Content Engine での NTLM サポートについて

NTLM サポートについて

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

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

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

NTLM エンドツーエンド認証

HTTP 要求の要求認証の設定

HTTP 要求のコンテンツ アクセスの制御

パススルー認証による Web クライアントの認証

HTTP 要求認証による Web クライアントの認証

HTTP 要求の要求認証を設定する場合の注意事項

スタンドアロン Content Engine での認証サービスの設定

RADIUS 認証サービスの設定

TACACS+ 認証サービスの設定

LDAP 認証サービスの設定

LDAP 認証サービスの設定例

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

スタンドアロン Content Engine での LDAP キャッシュの設定

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

NTLM 認証サービスの設定

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

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

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

NTLM HTTP 要求認証用の認証方法制御の設定

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

HTTP 要求のグループベース許可の設定

スタンドアロン Content Engine でのグループベース アクセス リストの設定

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

グループ名ベースのアクセス リストのディセーブル化

LDAP AUP 機能の設定

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

非透過 FTP ネイティブ要求の要求認証の設定

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

この章では、ACNS 5.4.1 以降のソフトウェア リリースが稼働しているスタンドアロン Content Engine にコンテンツ認証および許可を設定する方法を説明します。コンテンツ認証および許可は、Content Engine を介して配信される要求済みコンテンツにエンド ユーザ(HTTP 要求を発行したクライアント ブラウザや、非透過 FTP[ファイル転送プロトコル]ネイティブ要求を発行した FTP クライアントなど)がアクセスできるかどうかを制御します。


) ACNS 5.2.1 以降のソフトウェア リリースでは、HTTP 要求認証がサポートされています。この章では、HTTP 要求は、HTTP、FTP-over-HTTP、および HTTPS-over-HTTP 要求を含む HTTP 要求一般を意味します。ACNS 5.4.1 以降のソフトウェア リリースでは、非透過 FTP ネイティブ要求のプロキシ認証も使用できます。


この章の内容は、次のとおりです。

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

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

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

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

「スタンドアロン Content Engine での認証サービスの設定」

「LDAP AUP 機能の設定」

「非透過 FTP ネイティブ要求の要求認証の設定」


) この章で使用する CLI(コマンドライン インターフェイス)コマンドの構文および使用方法については、『Cisco ACNS Software Command Reference』Release 5.4 を参照してください。Content Distribution Manager に登録されている Content Engine にコンテンツの認証、許可、およびアカウンティングを設定する方法については、『Cisco ACNS Software Configuration Guide for Centrally Managed Deployments』Release 5.4 を参照してください。


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

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

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

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

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

これらの問題に対応するために、企業はコンテンツ認証および許可を利用できます。 表10-1 で要約されているとおり、コンテンツ認証および許可はさまざまなプロトコルで実行可能です。

 

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

方法
詳細

WMT 要求用パススルー認証

「WMT 要求用パススルー認証の設定」を参照してください。

HTTP 要求用エンドツーエンド認証

「HTTP 要求用エンドツーエンド認証の設定」を参照してください。

基本

「基本エンドツーエンド認証」を参照してください。

Microsoft NTLM

「NTLM エンドツーエンド認証」を参照してください。

HTTP 要求の要求認証

「HTTP 要求の要求認証の設定」を参照してください。

RADIUS

「RADIUS 認証サービスの設定」を参照してください。

TACACS+

「TACACS+ 認証サービスの設定」を参照してください。

LDAP

「LDAP 認証サービスの設定」を参照してください。

NTLM

「NTLM 認証サービスの設定」を参照してください。

HTTP 要求のグループベース許可

「HTTP 要求のグループベース許可の設定」を参照してください。

非透過 FTP ネイティブ要求の要求認証

「非透過 FTP ネイティブ要求の要求認証の設定」を参照してください。

RADIUS

「RADIUS 認証サービスの設定」を参照してください。

TACACS+

「TACACS+ 認証サービスの設定」を参照してください。

LDAP

「LDAP 認証サービスの設定」を参照してください。

NTLM

「NTLM 認証サービスの設定」を参照してください。

ACNS 5.2.1 以降のソフトウェア リリースでは、HTTP 要求認証がサポートされています( HTTP 要求 は、HTTP、FTP-over-HTTP、および HTTPS-over-HTTP 要求を含む HTTP 要求一般を意味します)。詳細は、「HTTP 要求の要求認証の設定」を参照してください。

ACNS 5.4.1 以降のソフトウェア リリースでは、非透過 FTP ネイティブ要求のプロキシ認証も使用できます。この機能を使用すると、FTP プロキシとして動作する Content Engine で、Reflection X クライアントや UNIX コマンドライン プログラムなどの FTP クライアントからの非透過 FTP ネイティブ要求を認証することができます。詳細は、「非透過 FTP ネイティブ要求の要求認証の設定」を参照してください。


) ACNS 5.4.1 以降のソフトウェア リリースでは、IP Access Control List(ACL; アクセス制御リスト)を使用して、スタンドアロン Content Engine で稼働しているネイティブ FTP プロキシ サービスへのアクセスを制御することができます。詳細は、「IP ACL による ネイティブ FTP アクセスのコントロール」を参照してください。


HTTP 要求および非透過 FTP ネイティブ要求の RADIUS、TACACS+、Microsoft NT LAN Manager(NTLM)、または LDAP 認証をイネーブル化して設定する場合は、同じプロセスを使用します(たとえば、Content Engine に RADIUS サーバを設定して、Content Engine で RADIUS 認証をイネーブルにすることができます)。ただし、FTP ネイティブ キャッシング サポートには次の制限があります。

FTP 要求プロキシ ルールについては未サポート

URL フィルタリング方式(good リスト、bad リスト、N2H2、Websense および SmartFilter)についてはすべて未サポート

上記の 2 つの制限は、HTTP キャッシング サポートには適用されません。

エンドツーエンドおよびパススルー認証について

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

Content Engine での NTLM サポートについて

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

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

スタンドアロン Content Engine 上での NTLM サポートには、次の 4 つのサポートが含まれます。(1)NTLM エンドツーエンド認証サポート、(2)NHTTP 要求の NTLM 認証、(3)許可用 NTLM グループ情報クエリー、および(4)NTLM で保護されたオブジェクトの事前ロードに関する NTLM サポートです。ACNS 5.x ソフトウェアを実行しているスタンドアロン Content Engine の NTLM サポート タイプの概要については、 表10-2 を参照してください。

 

表10-2 Content Engine での NTLM サポートの概要

NTLM サポート タイプ
説明

HTTP 要求の NTLM 認証

ACNS 5.3.x 以前のリリースでは、HTTP 要求認証のために NTLMv1 のみがサポートされています(NTLMv1 は単に「NTLM」ともいいます)。

ACNS 5.4.1 以降のソフトウェア リリースでは、HTTP 要求認証のために NTLMv1 および NTLMv2 がサポートされています

詳細は、「NTLM 認証サービスの設定」を参照してください。

認証用の NTLM グループ情報クエリー

ACNS 5.x ソフトウェア リリースでは、認証用 NTLM グループ情報クエリーのために NTLMv1 および NTLMv2 がサポートされています。

詳細については、「HTTP 要求のグループベース許可の設定」を参照してください。

NTML エンドツーエンド認証

ACNS 5.x ソフトウェア リリースでは、NTLM エンドツーエンド認証のために NTLMv1 および NTLMv2 がサポートされています。

詳細は、「NTLM エンドツーエンド認証」を参照してください。

NTLM で保護されたオブジェクトの事前ロードに関する NTLM サポート

ACNS 5.1.1 以降のソフトウェア リリースでは、スタンドアロン Content Engine にNTLM で認証されたオブジェクトを事前ロードするための NTLMv1 サポートを使用できます。ACNS 5.4.1 ソフトウェア リリースでは、NTLM で認証されたオブジェクトの事前ロードに関する NTLMv2 サポートが追加されています。

詳細については、「スタンドアロン Content Engine の事前コンテンツ ロードの設定」を参照してください。

ACNS 5.4.1 ソフトウェア リリースに追加された ntlm version グローバル コンフィギュレーション コマンドには、コマンド オプションが 2 つあります。NTLMv1 を再イネーブルにするための version 1 オプションと、スタンドアロン Content Engine で NTLMv2 をイネーブルにするための version 2 オプションです。 version 1 コマンド オプションがデフォルト オプションです。

ACNS 5.4.1 ソフトウェア リリースでは、Content Distribution Manager に登録されている Content Engine に、NTLM で保護されたコンテンツを取得および配信するための NTLMv2 サポートも追加されています。Content Distribution Manager に登録されている Content Engine の設定方法ついては、『 Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4 を参照してください。

NTLM サポートについて

ACNS 5.4.1 以降のソフトウェア リリースでは、HTTP 要求認証のために NTLMv1 および NTLMv2 がサポートされています。ACNS 5.3.x 以前のソフトウェア リリースでは、NTLM HTTP 要求認証(つまり、HTTP プロトコルを介した要求に対する NTLM 要求認証)のために NTLMv1 のみがサポートされています。

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

NTLMv2 は NTLMv1 を継承しています。NTLMv2 は NTLMv1 よりもセキュリティが向上するように設計されています。要求の暗号化に使用されるパスワード ハッシュ作成アルゴリズムは、NTLMv1 よりも NTLMv2 の方が複雑です。NTLMv2 で暗号化された応答には、再生攻撃を防止するためのタイムスタンプを含めることもできます。

ACNS 5.4.1 ソフトウェア リリースでは、NTLMv2 をサポートするように強化されています。ACNS 5.3.x ソフトウェア以前のリリースでは、クライアントが NTLMv2 の使用を試みると、クライアント認証に失敗します。

ブラウザとサーバ(またはプロキシ)間では、NTLMv2 がネゴシエートされません。Windows ベース クライアントおよびサーバ上で NTLMv2 をイネーブルにするには、クライアントおよびサーバのレジストリ変数を変更します。クライアントへの HTTP 応答が、サーバ(またはプロキシ)に認証が必要であることを示している場合、NTLM が許可されていれば、クライアントはクライアント設定に基づいて別の NTLM 応答を生成します。

NTLMv1 が設定されているクライアントにサーバ要求が着信すると、クライアントは NTLMv1 応答を生成します。

NTLMv2 が設定されているクライアントにサーバ要求が着信すると、クライアントは NTLMv2 応答を生成します。

NTLM 対応ブラウザのパススルー認証サポート

Content Engine で ACNS 5.4.1 以降のソフトウェア リリースが稼働していて、クライアント ブラウザに NTLMv2 が設定されている場合は、パススルー認証と NTLM HTTP 要求認証が両方ともサポートされます。

パススルー認証で、次のプロセスが発生します。

1. Content Engine からクライアント ブラウザに NTLM 要求が着信すると、クライアント ブラウザは NTLMv2 応答を生成して、Content Engine に送信します。

2. Content Engine はパススルー認証を実行し、Content Engine への認証要求を送信したドメイン コントローラに NTLMv2 応答を転送します。

3. Content Engine はドメイン コントローラの決定に従って、要求されたコンテンツへのクライアント アクセスを許可または拒否します。

NTLM HTTP 要求認証では、ドメイン コントローラでユーザが検証されると、Content Engine はクライアントのユーザ名およびドメイン名に関する情報を認証キャッシュに保存します。したがって、これ以降に同じ IP アドレスから送信される要求は確認されません。

NTLM 非対応ブラウザの基本認証のサポート

NTLM 非対応ブラウザ(NTLMv1 または NTLMv2 をサポートしていないブラウザ)を使用している場合、次の条件がすべて満たされていれば、Content Engine は NTLMv2 のみを使用してドメイン コントローラと通信します。

NTLMv2 を使用するように Content Engine が設定されている場合( ntlm server host グローバル コンフィギュレーション コマンドに v2 コマンド オプションを指定した場合)

Content Engine が ACNS 5.4.1 以降のソフトウェア リリースをを実行している場合

Content Engine で基本認証がイネーブルな場合( no ntlm basic-auth enable グローバル コンフィギュレーション コマンドを入力して Content Engine での基本認証をディセーブルにしていない場合)

このような状況で、クライアント ブラウザが Content Engine から、クライアント認証が必要であることを示す HTTP 応答を受信すると、クライアント ブラウザは NTLM 認証でなく基本認証を実行します。クライアント ブラウザはクリア テキスト形式のユーザ証明書を、ネットワークを介して Content Engine に送信します。Content Engine はドメイン コントローラからの身元確認を要求し、パスワードを使用して NTLMv2 応答を生成し、ドメイン コントローラに送信して検証します。


) クライアント ブラウザは Content Engine にクリア テキスト形式のパスワードを送信しますが、Content Engine はこのクリア テキスト パスワードをネットワーク経由でドメイン コントローラに転送しません。


要求認証のための NTLM v2 サポートについて

NTLMv2 機能をイネーブルにしないかぎり、要求認証プロセス中に設定された 8 つの NTLM サーバとそれぞれ通信する場合、Content Engine はデフォルトで NTLMv2 でなく NTLMv1 を使用します。

ACNS 5.4.1 ソフトウェア リリースでは、HTTP 要求の要求認証に関する NTMLv2 サポートが追加されています。クライアントとサーバ間では NTLMv2 がネゴシエートされないので(この機能はクライアントとサーバの Windows レジストリを変更して、クライアントとサーバで別々に設定されます)、Content Engine が NTLMv2 をサポートするようにパラメータを指定する必要はありません。ただし、設定済みの NTLM サーバのいずれか( ntlm server host グローバル コンフィギュレーション コマンドを使用して host list に追加された NTLM サーバの 1 つ)と通信する場合に Content Engine が NTLMv2 をサポートするように設定する場合は、Content Engine で ntlm version 2 グローバル コンフィギュレーション コマンドを入力する必要があります。

ContentEngine(config)# ntlm version 2
 

ACNS 5.4.1 ソフトウェア リリースに追加された ntlm version グローバル コンフィギュレーション コマンドには、コマンド オプションが 2 つあります。NTLMv1 を再イネーブルにするための version 1 オプションと、スタンドアロン Content Engine で NTLMv2 をイネーブルにするための version 2 オプションです。 version 1 オプションがデフォルト オプションです。

設定された NTLM サーバのいずれかと通信する際に Content Engine が NTLMv2 を使用するように指定することは、非常に重要です。これは、特に基本認証の場合、Content Engine は実際に NTLMv2 応答を生成し、NTLM サーバと直接通信しているためです。


) Microsoft Windows クライアントのデフォルト動作では LM および NTLM 応答を送信します。Microsoft Windows サーバはデフォルトでこれらの応答を受け入れます。Microsoft Windows クライアントまたはサーバのデフォルト動作を変更する場合、たとえば、クライアントおよびサーバが LM や NTLM 応答でなく NTLMv2 応答を送受信するように設定する場合などは(NTLM バージョン 1 を単に NTLM という場合もあります)、Windows レジストリを変更する必要があります。

たとえば、Windows 9.x システムでは
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibility 変数を、
Windows NT および 2000 システムでは
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel 変数を変更する必要があります。Microsoft Windows クライアント レジストリまたは Windows サーバ レジストリ サーバを変更する方法については、Microsoft Windows のマニュアルを参照してください。



) ドメイン コントローラがセキュリティのために NTLMv2 のみを使用するように設定されている場合は、Content Engine で ntlm version 2 コマンドを入力して、NTLMv2 を使用するように Content Engine を設定します。


スタンドアロン Content Engine に NTLM サーバ リストを設定する方法については、「NTLM 認証サービスの設定」を参照してください。

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

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


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


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

匿名認証

ネットワーク認証

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

プラグイン認証を要約

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

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

Basic モード

NTLM モード

Microsoft Active Directory(AD)/Kerberos


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


ACNS 5.2.1 以降のソフトウェア リリースは、パススルー認証でクライアントを認証する 3 モード(Basic、NTLM、および Active Directory/Kerberos)すべてをサポートしています。

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 グローバル コンフィギュレーション コマンドを入力します。

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

NTLM エンドツーエンド認証

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

NTLM パススルー サービス

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

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

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

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

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


) エンド ツー エンド NTLM 認証では、NTLM バージョン 1(NTLMv1)とバージョン 2(NTLMv2)の両方がサポートされています。


次の例では、エンドツーエンド 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.
 

HTTP 要求の要求認証の設定

オンライン コンテンツへのアクセスを制限する方法として、企業は HTTP 要求認証(コンテンツ認証)を利用できます。HTTP 認証がスタンドアロン Content Engine に設定されていると、Content Engine は外部 Authentication, Authorization, Accounting(AAA; 認証、許可、アカウンティング)サーバでユーザ パスワード認証をチェックし、ユーザが要求したコンテンツにアクセスが許可されているかどうかを判断します(図10-1 を参照)。

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

 


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


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

HTTP 要求のコンテンツ アクセスの制御

要求認証については、ACNS は LDAP、NTLM、TACACS+、および RADIUS をサポートします。要求許可については、ACNS 5.x ソフトウェアはグループ ベースのアクセス リストをサポートします。ACNS 5.2.1 フトウェア リリースでは、グループベースのルールも追加され、グループベースの許可に使用することができます。これらの機能により、HTTP 要求を行っているエンド ユーザに、外部 AAA サーバによる認証と、設定したアクセス リストまたは 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 要求認証とグループベース アクセス リストによる許可のあとに発生します。Rules Template 内の設定とグループベース アクセス リストが一致した場合は、アクセス リストが優先されます。スタンドアロン Content Engine の Rules Template の設定については、第 13 章「スタンドアロン Content Engine の Rules Template の設定」を参照してください。


アクセス制御の他の役割には、認証コンテンツのキャッシュがあります。つまり、Web サイトがクライアントにオブジェクトを渡す前にクライアント認証を要求した場合、そのオブジェクトが Content Engine にキャッシュされていれば、Content Engine はオブジェクトを他のクライアントに渡す前にクライアントも認証する必要があります。このタイプのオブジェクトを 認証済みコンテンツ といいます。

スタンドアロン Content Engine は HTTP 要求に関して次の種類のコンテンツ アクセス制御をサポートしています。

「パススルー認証による Web クライアントの認証」

「HTTP 要求認証による Web クライアントの認証」

「スタンドアロン Content Engine でのグループベース アクセス リストの設定」

パススルー認証による Web クライアントの認証

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

Basic モード

NTLM モード

Microsoft Active Directory(AD)/Kerberos


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


パススルー認証を使用するのは、クライアント認証が必要な(つまり、クライアントがポップアップ ログイン ウィンドウでユーザ名とパスワードを入力する必要がある)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 ソフトウェアは、AAA サーバで一般的に使用されている LDAP、NTLM、RADIUS、および TACACS+ プロトコルをサポートします( 表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 はクライアントの UID(ユーザ ID)を 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)をユーザが勤務する特定の営業所に配置し、プロキシ モードに設定できます。もう 1 台のプロキシ モードで作動する Content Engine(CE2)、またはもう 1 台の HTTP 準拠プロキシ装置をアップストリームに配置し、Content Engine またはプロキシ装置の両方に対して、ログイン認証を行う目的で TACACS+、RADIUS、NTLM、または LDAP のサーバを利用できます。


) ダウンストリームの Content Engine で http append proxy-auth-header グローバル コンフィギュレーション コマンドを設定する必要があります。これは、アップストリームの 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 アドレスを探します。

プロキシ チェーン内に 2 つのレベルの Content Engine が存在する場合(クライアントに最も近い Content Engine の CE1 が最初のレベル、CE2 が 2 番めのレベル)に、CE1 と CE2 の両方に http append x-forwarded-for-header multiple-ip-address グローバル コンフィギュレーション コマンドを設定すると、次のようになります。

1. クライアントから要求を受信した CE1 は、X-Forwarded-for ヘッダーにデフォルト クライアントの IP アドレスを追加して、CE2 に要求を転送します。たとえば、クライアントの IP アドレスが 10.1.1.20 の場合、X-Forwarded-For ヘッダーは「X-Forwarded-for: 10.1.1.20」になります。

2. CE1 から要求を受信した CE2 は、X-Forwarded-for ヘッダーに CE1 の IP アドレスを追加します。したがって、X-Forwarded-For ヘッダーにはクライアントの IP アドレス(ヘッダー内にすでに存在)と、CE1 の IP アドレスが、カンマで区切られて含まれています。たとえば、CE1 の IP アドレスが 10.40.1.40 の場合、X-Forwarded-For ヘッダーは「X-Forwarded-for: 10.1.1.20, 10.40.1.40」になります。

ACNS 5.4.1 以降のソフトウェア リリースでは、X-Forwarded-For ヘッダーに複数の IP アドレスを格納できます。X-Forwarded-for ヘッダーに複数の IP アドレス を追加できるようにするには、 http append x-forwarded-for-header multiple-ip-address グローバル コンフィギュレーション コマンドを入力します。このコマンドが指定してある場合に、CE1 から CE2 に X-Forwarded-For ヘッダーを含む要求が着信すると、CE1の IP アドレスが X-Forwarded-For ヘッダー内の既存クライアントの 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 認証キャッシュへのキーとして使用します。

ACNS 5.4.1 以降のソフトウェア リリースでは、X-Forwarded-For ヘッダーに複数の IP アドレスを格納できます。

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

「RADIUS 認証サービスの設定」

「TACACS+ 認証サービスの設定」

「LDAP 認証サービスの設定」

「NTLM 認証サービスの設定」


) Content Engine の NTLM サポートには、3 つのサポートが含まれます。NTLM エンドツーエンド認証サポート、HTTP 要求の NTLM 認証、および許可用 NTLM グループ情報クエリーです。ACNS 5.x ソフトウェアを実行しているスタンドアロン Content Engine の NTLM サポート タイプの概要については、表10-2 を参照してください。


HTTP 要求の要求認証を設定する場合の注意事項

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

Content Engine 上では、一度に 1 つの要求認証方式をイネーブルにできます。

認証キャッシュに、すべての認証済みユーザを同時に保存するための容量が不足している場合、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 コマンドを使用します。

ACNS5.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 グローバル コンフィギュレーション コマンドが指定されている場合、ユーザ情報は抑制されます。トランザクション ロギングの詳細は、 第 21 章「スタンドアロン 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
 

スタンドアロン Content Engine での認証サービスの設定

スタンドアロン Content Engine に認証サービスを設定する方法については、次の項を参照してください。

「RADIUS 認証サービスの設定」

「TACACS+ 認証サービスの設定」

「LDAP 認証サービスの設定」

「NTLM 認証サービスの設定」

RADIUS 認証サービスの設定

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

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

ACNS 5.4.1 以降のソフトウェア リリースでは、非透過 FTP ネイティブ要求の RADIUS 認証がサポートされています。HTTP 要求および非透過 FTP ネイティブ要求の RADIUS 認証をイネーブル化したり、設定する場合も、同じプロセスを使用します。ただし、FTP ネイティブ キャッシング サポートには次の制限があります。

FTP 要求プロキシ ルールについては未サポート

URL フィルタリング方式(good リスト、bad リスト、N2H2、Websense および SmartFilter)についてはすべて未サポート


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


次に、スタンドアロン Content Engine に HTTP 要求の RADIUS 認証を設定する例を示します。


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

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

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 グローバル コンフィギュレーション コマンドを使用します。


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 をサポートしていません。

ACNS 5.4.1 以降のソフトウェア リリースでは、非透過 FTP ネイティブ要求の RADIUS 認証がサポートされています。HTTP 要求および非透過 FTP ネイティブ要求の RADIUS 認証をイネーブル化したり、設定したりする場合も、同じプロセスを使用します。ただし、FTP ネイティブ キャッシング サポートには次の制限があります。

FTP 要求プロキシ ルールについては未サポート

URL フィルタリング方式(good リスト、bad リスト、N2H2、Websense および SmartFilter)についてはすべて未サポート

次に、スタンドアロン Content Engine に HTTP 要求の TACACS+ 認証を設定する例を示します。


ステップ 1 TACACS+ サーバを 1 台以上使用するように Content Engine を設定します。

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 TACACS+ の再試行の回数を指定します。

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

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.4 を参照してください。


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)サーバ


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


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

 


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

Active Directory グループ属性は LDAP バージョン 3 の拡張です。そのため、Microsoft Active Directory サーバにこの情報をクエリーするためには、Content Engine は LDAP バージョン3 を使用する必要があります。


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

 

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

機能
サードパーティ製 LDAP サーバ
OpenLDAP サーバ
Microsoft Active Directory サーバ

LDAP バージョン 2

x

x

 

LDAP バージョン 3

x

x

x

組織ユニット(ou)

x

x

x

Active Directories(AD)

 

 

x

Static グループ

x

x

x

ACNS 5.4.1 以降のソフトウェア リリースでは、非透過 FTP ネイティブ要求の LDAP 認証がサポートされています。HTTP 要求および非透過 FTP ネイティブ要求の LDAP 認証をイネーブル化したり、設定したりする場合も、同じプロセスを使用します。ただし、FTP ネイティブ キャッシング サポートには次の制限があります。

FTP 要求プロキシ ルールについては未サポート

URL フィルタリング方式(good リスト、bad リスト、N2H2、Websense および SmartFilter)についてはすべて未サポート

HTTP 要求および非透過 FTP ネイティブ要求の LDAP 認証を設定する場合は、次に示す重要事項に留意してください。

HTTP 要求および非透過 FTP ネイティブ要求の LDAP 認証は、Content Engine GUI または CLI を通して設定することができます。

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

Content Engine CLI から ldap server グローバル コンフィギュレーション コマンドを使用します。

LDAP 認証をイネーブルにするには、 ldap server enable コマンドを使用します。

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

ContentEngine(config)# ldap server enable ldap server version 3
 

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

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

ContentEngine(config)# ldap server retransmit 3
 

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

データベース検索に使用するフィルタ文字列(objectclass=user など)を指定するには、 ldap server filter filterword グローバル コンフィギュレーション コマンドを使用します。デフォルトはありません。

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

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

データベース検索用の管理識別名を指定するには、 ldap server administrative-dn name グローバル コンフィギュレーション コマンドを使用します。このフィールドに、デフォルト値はありません。

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

LDAP サーバが待ち受けるポート番号を指定するには、 ldap server port port-num グローバル コンフィギュレーション コマンドを使用します。デフォルト ポート番号は 389 です。

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

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

LDAP サーバをセカンダリ サーバとして指定するには、 ldap server host { hostname | hostipaddress } secondary グローバル コンフィギュレーション コマンドを使用します。セカンダリ 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 データベースからグループベースの許可に関するグループ名を取り出すには、 ldap server group グローバル コンフィギュレーション コマンドを使用します。このコマンドを使用して、データベース クエリーを実行する LDAP サーバに、認証されたユーザが所属するグループ名を取得するように命令します(Marketing や Engineeringなど)。Content Engine は、取得したグループ名を使用して、LDAP グループベースの許可を実行し、アクセス リストをチェックして、要求されたコンテンツにグループがアクセスできる許可を与えるか拒否するかを決定します。


) ACNS 5.1 以降のソフトウェア リリースは、LDAP Version 2 および Version 3 をサポートし、SASL 以外のすべての LDAP 機能をサポートします。


表10-4 は、HTTP 要求の LDAP 認証用の Content Engine のデフォルト設定を示しています。

 

表10-4 HTTP 要求の LDAP 認証用のデフォルト設定

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

LDAP 認証

ディセーブル

許可モード

ディセーブル

ベース識別名

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

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

未指定

LDAP 再送回数

2 回

LDAP サーバ タイムアウト

5 秒

ユーザ ID 属性

uid

グループ属性

組織ユニット(ou)

カスタム属性

Active Directory(memberOf)

 

イネーブル

ディセーブル

ディセーブル

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

グループ属性

グループ メンバー

ネストされたグループ

ネストされたレベル

ディセーブル

未指定

未指定

ディセーブル

1 レベル

管理識別名

未指定

管理パスワード

未指定

LDAP バージョン

LDAP バージョン 2

LDAP ポート

ポート 389

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

ディセーブル

パスワード失効機能

ディセーブル

プライマリ LDAP サーバ

未指定

セカンダリ LDAP サーバ

未指定

LDAP 認証サービスの設定例

次に、Content Engine CLI を使用して、スタンドアロン Content Engine に HTTP 要求および非透過 FTP ネイティブ要求の LDAP 認証を設定する例を示します。


ステップ 1 Content Engine が HTTP 要求および非透過 FTP ネイティブ要求を認証するために使用する LDAP 認証サーバの IP アドレスまたはホスト名を指定します。

ContentEngine(config)# ldap server host 10.1.1.1
 

ステップ 2 必要に応じて、LDAP バージョン 3 または LDAP バージョン 2(デフォルト)を使用するように Content Engine を設定します。

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

ContentEngine(config)# ldap server version 3
 

ステップ 3 デフォルトでは、HTTP 要求の LDAP 認証および非透過 FTP ネイティブ要求は Content Engine 上でディセーブルです。次に示すように、Content Engine 上の LDAP 認証をイネーブルにします。

ContentEngine(config)# ldap server enable
 

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

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

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

検索基準を指定するには、クエリーするユーザ データベースの構造を知っている必要があります。たとえば、デフォルトでは 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
 

次の出力例は、Microsoft Active Directory サーバ データベースで、認証済みユーザの Active Directory グループ メンバーシップ(memberOf)を検索するように、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 データベースの構造の概要」を参照してください。



 

1 人のユーザを正常に認証してから、HTTP 要求に対してグループベースの許可を実行するように 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、電子メール アドレスを表す 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 ディレクトリ エントリの識別名は次のとおりです。

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

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

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

LDAP ディレクトリには、LDAP グループの一部を形成するユーザ グループを格納できます(グループ Marketing や Engineering など)。LDAP グリープはリストであり、名前の集合です。LDAP グループは objectclass 属性 groupOfNames を持っていて、1 つまたは複数のメンバーで構成されています(空のグループは存在しません)。

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


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


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

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

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

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

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

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

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

LDAP サーバの管理者が組織ユニット(Marketing など)に基づいて LDAP ユーザをグループ化する場合、ユーザを任意のグループに割り当てることはできますが、グループをネストすることはできません。組織ユニットは、ネイティブ LDAP グループと同じです。この方法はまた、ネイティブ LDAP グループの設定として引用されます。従来の LDAP バージョン 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 として指定されているため、Penny Gold にはこの特定グループのグループ権限が割り当てられます。グループベースの許可用に Content Engine を設定し(たとえば、Content Engine を通して提供されるコンテンツへのアクセスを Marketing グループのメンバーに許可するアクセス リストを設定し)、Content Engine が Penny Gold をすでに認証している場合、このユーザは Marketing グループのメンバーであるため、要求したコンテンツにアクセス可能になります。

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

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 サーバ管理者は、特定メンバーを静的グループに割り当てます。

次に、LDAP サーバ管理者が、親グループ Engineering が静的メンバーを 2 つ(Hardware Engineers および Software Developers)持つよう明示的に指定する方法を示します。グループ 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 つの連結ノード間の 1 方向リンクです。 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 バージョン 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 Engine)は、LDAP ディレクトリ内に保管されている情報に、次のようにアクセスできます。

1. Content Engine は指定した LDAP サーバに接続し、LDAP サーバに特定のユーザ メンバーシップ情報についてクエリーします(ユーザ ID [userid] やユーザ パスワード [userpassword] など)。

次の例は、スタンドアロン LDAP サーバにユーザ ID(ユーザ 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 バージョン 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 グループ許可の設定例」を参照してください。


スタンドアロン Content Engine での LDAP キャッシュの設定

ACNS 5.4.1 ソフトウェア リリースでは、ネストされたグループ検索のための LDAP メモリ キャッシュ サポートが追加されました。Content Engine はこの機能を使用して、ネストされたグループの検索結果を LDAP キャッシュにローカルに保存できます。この新機能をサポートするため、 ntlm server ad-group-search グローバル コンフィギュレーション コマンドに mem-cache オプションが追加されました。

スタンドアロン Content Engine で LDAP キャッシュをイネーブル化したり、設定するには、 ntlm server ad-group-search mem-cache グローバル コンフィギュレーション コマンドを使用します。

ContentEngine(config)# ntlm server ad-group-search mem-cache ?
enable Enable ldap in-memory cache.(Default is Enabled)
max-ttl Maximum amount of time from creation an entry is valid in the ldap
in-memory cache
size Maximum size of ldap in-memory cache to allocate in KBytes.
 

) LDAP キャッシュは Content Engine 上にあるため、「LDAP インメモリ キャッシュ」と呼ばれることがあります。「AD」は Active Directory の略語です。


Content Engine では LDAP メモリ キャッシュがデフォルトでイネーブルです。キャッシュ サイズは 128 KB、最大 TTL(max-ttl)は 480 分に設定されています。キャッシュ サイズの有効値は 128 ~ 10,240 KB です。最大 TTL の有効値は 1 ~ 1440 分です。

LDAP メモリ キャッシュ機能をディセーブルにするには、 no ntlm server ad-group-search mem-cache グローバル コンフィギュレーション コマンドを入力します。

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

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

「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 サーバはグループ属性が cu(一般名)の静的グループ設定を検索します。

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 Engin を設定する方法を説明します。このケースでは、Engineering という親グループにネストされている静的グループのユーザ アカウント情報が LDAP ディレクトリで検索されます。

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

ContentEngine(config)# ldap server 172.16.1.1
 

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

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

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

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

この例では、LDAP サーバはグループ属性が cu(一般名)のネストされた静的グループ設定を検索します。

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
 

NTLM 認証サービスの設定

ACNS 5.4.1 ソフトウェア リリースでは、非透過 FTP ネイティブ要求の NTLM 認容のサポートが追加されました。

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 Engine の設定」を参照してください。


) サーバを設定する順番によって、負荷分散やフェールオーバーの順番が決まります。たとえば、フェールオーバーがイネーブルの場合、最初に設定したサーバ(サーバ 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 サーバで利用できる方式(負荷分散やフェールオーバー)の指定を可能にします。デフォルト スキームはフェールオーバーです。NTLM サーバの HTTP 要求認証方式を指定するには、ntlm server scheme グローバル コンフィギュレーション コマンドを使用します。2 番めの例で示すとおり、Global Catalog サーバの Active Directory グループ検索方式を変更するには、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 形式のユーザ名の一部として指定する必要があります。Internet Explorer など NTLM をサポートするブラウザは、証明書を指定するように要求されたユーザから送信される認証証明書、あるいはデスクトップへのユーザ ログインに使用されたドメインから送信される認証証明書に、ドメイン名を必ず追加します。


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

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

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

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

ACNS 5.3.x 以前のソフトウェア リリースでは、NTLM HTTP 要求認証(つまり、HTTP プロトコルを介した要求に対する NTLM 要求認証)のために NTLMv1 がサポートされていますACNS 5.4.1 以降のソフトウェア リリースでは、HTTP 要求認証のために NTLMv1 および NTLMv2 がサポートされていますこのトピックに関する詳細は、「Content Engine での NTLM サポートについて」を参照してください。

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

ACNS 4.x ~ 5.1.x のソフトウェア リリースでは、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 を使用して、HTTP 要求認証に対して外部 NTLM サーバを使用するようにスタンドアロン Content Engine を設定できます。

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 を使用して、HTTP 要求認証に対して 8 台までの NTLM サーバを使用するように Content Engine を設定できます。

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

Content Engine CLI から ntlm server グローバル コンフィギュレーション コマンドを使用します。

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


ステップ 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 設定された NTLM サーバと通信する場合に、Content Engine が要求認証に NTLMv2 を使用するかどうかを指定します。

デフォルトでは、Content Engine は LM または NTLMv1 を使用します。ACNS 5.4.1 ソフトウェア リリースでは、HTTP 要求の要求認証に関する NTMLv2 サポートが追加されています。デフォルトでは、要求認証に関する NTLMv2 機能は Content Engine でディセーブルであり、NTLMv1 が使用されます。次の例では、設定された NTLM サーバととの要求認証に NTLMv2 を使用するように Content Engine が設定されています。

ContentEngine(config)# ntlm version 2
 

このトピックに関する詳細は、「要求認証のための NTLM v2 サポートについて」を参照してください。

ステップ 3 Content Engine が設定済み NTLM サーバの 1 つとの接続を試みる最大回数を指定します。

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

ContentEngine(config)# ntlm server connection-retry 3
 

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

ステップ 4 Content Engine が接続試行中の NTLM サーバからの応答を待機する時間を指定します。

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

ContentEngine(config)# ntlm server connection-timeout 10
 

これは、1 回の接続試行に対するタイムアウトです。指定された秒数を超えると、Content Engine はこの試行での接続をあきらめ、指定された回数( ntlm server connection-retry グローバル コンフィギュレーション コマンドで指定されたリトライ回数)に到達するまで、Content Engine は次のサーバではなく、同じサーバへ接続を試みます。デフォルトは 5秒です。有効な値は 1 ~ 20 秒です。

ステップ 5 設定された 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 はすべての要求を最初に設定されたサーバへ送信します。

ステップ 6 (任意)ACNS 5.4.1 以降のソフトウェア リリースが稼働している Content Engine に LDAP キャッシュを設定するには、 ntlm server ad-group-search mem-cache グローバル コンフィギュレーション コマンドを使用します。

Content Engine では LDAP キャッシュがデフォルトでイネーブルです。キャッシュ サイズは 128 KB、最大 TTL(max-ttl)は 480 分に設定されています。Content Engine は LDAP キャッシュを使用して、ネストされたグループ検索の結果を格納します。

次の例では、LDAP キャッシュの最大サイズは 140 KB に設定されています。

ContentEngine(config)# ntlm server ad-group-search mem-cache size 140
Warning: This config destroys and recreates the memcache with new size
 

詳細は、「スタンドアロン Content Engine での LDAP キャッシュの設定」を参照してください。

ステップ 7 Content Engine 上で NTLM 認証をイネーブルにします。

ContentEngine(config)# ntlm server enable
 

ステップ 8 Content Engine の NTLM 設定を表示します。

ContentEngine# show ntlm
 

コマンドの出力をチェックし、表示された NTLM 設定が指定した設定を反映しているか(たとえば、指定した NTLM サーバがリストにあるか、負荷分散は指定されているか)確認してください。show ntlm EXEC コマンド出力例については、「スタンドアロン Content Engine の現在の 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(HTTP プロキシ サーバ)は常に基本認証応答ヘッダーを 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 Engine の現在の NTLM 設定を表示

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

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

HTTP 要求のグループベース許可の設定

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


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


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

スタンドアロン Content Engine でのグループベース アクセス リストの設定

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


ステップ 1 access-lists 300 グローバル コンフィギュレーション コマンドを使用して、スタンドアロン Content Engine を使用したインターネット アクセスを特定のグループに対して許可または拒否します。

次の例は、アクセス リストを使用し、Marketing や Engineering などの組織ユニットに基づいて、基本ストリング cisco 内のグループへのアクセスを許可する方法を示しています。そのために、 access-lists 300 permit groupname グローバル コンフィギュレーション コマンドを使用します。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 組織ユニットに属するすべてのユーザ

組織ユニット Engineering に属するすべてユーザのうち、Hardware Engineers グループに属さないユーザ。ネストされたグループ Hardware Engineers のメンバーは、明示的にアクセスが拒否されたグループに属しているため、アクセスが拒否されます。


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


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

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 アドレスを入力します。


) 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 番めの要求が Server 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 Engine の設定

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 以降のソフトウェア リリースでは、次の追加機能によって HTTP 要求に関する Active Directory グループ検索をトリガーできます。

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

ICAP が認証グループ ヘッダーを付加するように設定されている場合( 第 12 章「スタンドアロン 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 ドメイン コントローラ(ホスト)は、認証と許可の両方に使用されます。

ACNS5.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 グローバル コンフィギュレーション コマンドを使用します。たとえば、Content Engine が Active Directory グループ検索に使用する Global Catalog サーバの IP アドレスまたはホスト名を指定するには、ntlm server ad-group-search gc-server host host-IP-address or hostname コマンドを使用します。

設定された Global Catalog サーバのホスト ドメイン名(「abc1.local」など)を指定するには、ntlm server ad-group-search gc-server host domain domain-name グローバル コンフィギュレーション コマンドを使用します。次の例では、abc1.local というホスト ドメイン名をもつ Global Catalog サーバを使用するように、Content Engine を設定します。

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 を戻します。Content Engine で LDAP 参照機能がイネーブルな場合、Content Engine は参照 URL 内の参照サーバに関する情報を取得し、サーバに問い合わせてユーザの許可情報を要求します。

LDAP 参照機能サポートには、次の機能があります。

Active Directory で信頼されるドメインのユーザ許可のサポート

NTLM ネスト グループ検索の LDAP 参照のサポート

LDAP ネスト参照レベルの設定機能

NTLM 負荷分散のために複数のドメインに Active Directory ドメイン コントローラを設定する機能


) 複数のドメインに Active Directory ドメイン コントローラを設定するには、複数のドメインに信頼関係が確立されている必要があります。信頼できない複数のドメインに複数のドメイン コントローラを設定しても、認証および許可は正しく実行されません。


ACNS 5.3.1 以降のソフトウェア リリースでは、 ntlm server ad-group-search ldap-referral グローバル コンフィギュレーション コマンドを使用して、LDAP 参照機能を設定できます。

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 グローバル コンフィギュレーション コマンドを入力します。Content Engine で LDAP 参照機能をイネーブルにするには、 no ntlm server ad-group-search ldap-referral enable コマンドを入力して、あとでディセーブルにします。

NTLM ネスト グループ検索の参照制限を指定するには、 ntlm server ad-group-search ldap-referral コマンドの ldap-referral limit オプションを使用します。NTLM ネスト グループ検索では、デフォルトで参照を 5 つネストすることができます。有効値は 1 ~ 10 です。

最初のレベルの検索で目的の結果(Content Engine の検索結果)が得られることがありますが、通常、Active Directory サーバはネストされた参照 URL を複数返すため、Active Directory サーバへの不要なラウンドトリップが追加で発生します。したがって、ディレクトリ構造上、最初の数レベルの検索応答に目的の検索結果が含まれていることが分かっている場合は、参照制限の値を小さくすることができます。

たとえば、検索結果が最初のレベルの検索応答に含まれる場合は、参照制限を 1 に設定して、パフォーマンスを高めることができます。参照制限を 1 に設定すると、Content Engine は 1 つの参照 URL だけを使用して、正しいドメイン コントローラ(Domain Controller A)に問い合わせます。検索結果とともに Domain Controller A から生成されるその他の不要な参照 URL は使用しません。

次に、NTLM ネスト グループ検索でネストできる参照数を 5 でなく、1 に指定する例を示します。

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

ACNS 5.4.1 ソフトウェア リリースでは、ネスト グループ検索結果を Content Engine の LDAP キャッシュにローカルにキャッシングするサポート機能が追加されました。この新機能をサポートするため、 ntlm server ad-group-search グローバル コンフィギュレーション コマンドに mem-cache オプションが追加されました。

ContentEngine(config)# ntlm server ad-group-search mem-cache ?
enable Enable ldap in-memory cache.(Default is Enabled)
max-ttl Maximum amount of time from creation an entry is valid in the ldap
in-memory cache
size Maximum size of ldap in-memory cache to allocate in KBytes.
 

) Content Engine では LDAP メモリ キャッシュがデフォルトでイネーブルです。キャッシュ サイズは 128 KB、最大 TTL は 480 分に設定されています。


Content Engine に現在設定されている NTLM パラメータを表示するには、 show ntlm EXEC コマンドを入力します。コマンド出力には、LDAP 参照機能がイネーブルであるかどうかの情報(コマンド出力の [AD LDAP referral chasing:Enabled] 表示など)、および現在の参照制限(コマンド出力の [AD LDAP referral chasing limit:8] 表示など)が含まれます。ACNS 5.4.1 以降のソフトウェア リリースでは、コマンド出力に Content Engine のローカル LDAP キャッシュに関する設定情報も含まれています(たとえば、LDAP キャッシュ、および最大キャッシュ サイズやオブジェクトをキャッシュに格納する最大時間[最大 TTL [max-ttl] 値]がイネーブルな場合)。

Active Directory グループ検索および LDAP キャッシングをサポートするための Content Engine の設定例

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

デフォルトでは、NTLM LDAP メモリキャッシュ機能は Content Engine でイネーブルです。 ntlm server ad-group-search mem-cache max-ttl グローバル コンフィギュレーション コマンドを使用して、LDAP キャッシュ内のオブジェクトの最大 TTL を 400 分(デフォルトは 480分)に設定します。次に、 ntlm server ad-group-search mem-cache size グローバル コンフィギュレーション コマンドを使用して、Content Engine の LDAP キャッシュの最大サイズを 140 KB(デフォルトは 128 KB)に変更します。

Active Directory グループ検索パラメータおよび LDAP キャッシュを設定したら、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 mem-cache max-ttl 400
Warning: This config destroys and recreates the memcache with new ttl
ContentEngine(config)# ntlm server ad-group-search mem-cache size 140
Warning: This config destroys and recreates the memcache with new size
ContentEngine(config)# ntlm server ad-group-search mem-cache enable
ContentEngine(config)# ntlm server ad-group-search enable
ContentEngine(config)# ntlm server ad-group-search ldap-referral limit 1
 

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 AUP 機能の設定

ACNS 5.1.1 以降のソフトウェア リリースでは、LDAP Acceptable Use Policy(AUP)機能がサポートされています。ユーザがブラウザ セッションを開始すると、Content Engine は特定の LDAP 属性を照会して、ユーザが 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)# ldap server policy-redirect attribute aup-attribute
 

ステップ 4 Content Engine 上での AUP の現行バージョンを指定します。これはグローバル値です。すべてのユーザが表示にこの値を使用して、AUP のバージョンに同意済みであるかどうかを判別できるます。

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


 

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

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

非透過 FTP ネイティブ要求の要求認証の設定

ACNS 5.4.1 ソフトウェア リリースでは、非透過 FTP ネイティブ要求のプロキシ認証(Content Engine での要求認証)が追加されました。要求認証および許可が設定されている場合、Content Engine は Content Engine に要求を送信するエンド ユーザ(たとえば、Reflection X クライアント、WS-FTP クライアント、UNIX または DOS コマンドライン FTP プログラムなどの FTP クライアント)を確認します。逆に、エンドツーエンド認証および許可されたオブジェクトのキャッシュは、特定のオブジェクトの認証を処理し、Content Engine でなくオリジン サーバがエンド ユーザを確認します。

ACNS 5.4.1 ソフトウェア リリースでは、非透過 FTP ネイティブ要求のプロキシ認証をサポートするために、 ftp-native proxy コンフィギュレーション コマンドに authentication オプションが追加されました。

ContentEngine(config)# ftp-native proxy ?
active-mode Configuration of active mode for native ftp proxy
authentication Configuration for proxy authentication of proxy-mode requests
incoming Configuration for incoming proxy-mode requests
ContentEngine(config)# ftp-native proxy authentication ?
enable If an authentication service is configured then use it for
authenticating proxy-mode ftp-native requests.
 

デフォルトでは、FTP ネイティブ プロキシ認証機能はディセーブルです。FTP ネイティブ プロキシ認証機能をイネーブルにする手順は、次のとおりです。

ContentEngine(config)# ftp-native proxy authentication enable
 

) FTP プロトコルは本来セキュアでないため、認証証明書がネットワークからスニッフィングされて、セキュアなチャネル(HTTP の場合など)を介して提供されたユーザ証明書が公開されることがあります。


ACNS 5.4.1 ソフトウェア リリースでは、非透過 FTP ネイティブ要求のプロキシ認証(Content Engine での要求認証)が追加されました。要求認証および許可が設定されている場合、Content Engine は Content Engine に要求を送信するエンド ユーザ(たとえば、Reflection X クライアント、WS-FTP クライアント、UNIX または DOS コマンドライン FTP プログラムなどの FTP クライアント)を確認します。逆に、エンドツーエンド認証および許可されたオブジェクトのキャッシュは、特定のオブジェクトの認証を処理し、Content Engine でなくオリジン サーバがエンド ユーザを確認します。

ACNS 5.4.1 ソフトウェア リリースでは、非透過 FTP ネイティブ要求のプロキシ認証をサポートするために、 ftp-native proxy コンフィギュレーション コマンドに authentication オプションが追加されました。

ContentEngine(config)# ftp-native proxy ?
active-mode Configuration of active mode for native ftp proxy
authentication Configuration for proxy authentication of proxy-mode requests
incoming Configuration for incoming proxy-mode requests
ContentEngine(config)# ftp-native proxy authentication ?
enable If an authentication service is configured then use it for
authenticating proxy-mode ftp-native requests.
 

デフォルトでは、FTP ネイティブ プロキシ認証機能はディセーブルです。FTP ネイティブ プロキシ認証機能をイネーブルにする手順は、次のとおりです。

ContentEngine(config)# ftp-native proxy authentication enable
 

) FTP プロトコルは本来セキュアでないため、認証証明書がネットワークからスニッフィングされて、セキュアなチャネル(HTTP の場合など)を介して提供されたユーザ証明書が公開されることがあります。


プロキシ認証サポートがイネーブルな場合、非透過モードでは、FTP クライアントから FTP プロキシ(FTP クライアントの FTP プロキシとして機能する Content Engine)、プロキシ ユーザ名(任意)、プロキシ パスワード、およびオリジン FTP サーバのホスト名を提供する必要があります。

FTP クライアントおよびプロキシに非透過プロキシおよびプロキシ認証が設定されている場合、FTP クライアント(TCP)は FTP プロキシ(Content Engine)と接続し、FTP コマンドを発行して、次のいずれかの方法でプロキシ認証を行います。

FTP プロキシ認証方法 1

クライアントは FTP USER コマンドを使用して、オリジン FTP サーバのサーバ ユーザ名およびホスト名を指定します。

USER proxy-username
PASS proxy-password
USER server-username@server-hostname.company.com
PASS server-password
 

FTP プロキシ認証方法 2

クライアントは FTP SITE コマンドを使用して、オリジン FTP サーバのホスト名を指定します。

USER proxy-username
PASS proxy-password
SITE server-hostname.company.com
USER server-username
PASS server-password
 

次に、Content Engine で TACACS+ プロキシ認証がイネーブルである場合の FTP クライアント セッションの例を示します。この例では、FTP クライアントは FTP プロキシ認証方法 2 を使用します(たとえば、FTP クライアントは FTP SITE コマンドを入力して、オリジン FTP サーバのホスト名を指定します)。

shell# ftp ñd 2.9.192.11 8021
Connected to 2.9.192.11
220 Welcome to FTP-proxy. Login to the proxy using username and password.
Name (2.9.192.11:tuser): tuser
---> USER tuser
331 Password required for tuser.
Password:
---> PASS XXXX
220-Welcome to FTP-proxy.
220-Login to origin server using the 'USER username@server-hostname' command, or
220 Login to origin server using the 'SITE server-hostname' followed by the 'USER username' command.
ftp> site host.abccorp.com
---> SITE host.abccorp.com
220 via2.abccorp.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.
ftp> user anonymous
---> USER anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
---> PASS XXXX
230 Guest login ok, access restrictions apply.
ftp> quit
 

Content Engine に次のトランザクション ロギング フォーマットの 1 つが設定されている場合は、特定のクライアントでプロキシ認証に成功すると、FTP プロキシ認証プロセス中にそのクライアントから提供されたユーザ名がトランザクション ログに記録されます。

拡張 Squid ロギング

カスタム ロギング


) カスタム トランザクション ロギング フォーマットの場合は、transaction-logs format custom コマンドを設定するときに、%u フォーマット指定子を追加する必要があります。


FTP クライアントのプロキシ認証に失敗すると、システム ログに認証障害が記録されます。Content Engine 管理者はシステム ログを調べて、このような認証障害をモニタすることができます。スタンドアロン Content Engine 上でトランザクション ロギングをイネーブル化して、設定する方法については、「トランザクション ロギングのイネーブル化」を参照してください。

スタンドアロン Content Engine 上に非透過 FTP ネイティブ要求の要求認証を設定するときは、次の重要事項に従ってください。

デフォルトでは、Content Engine 上で FTP ネイティブ プロキシ認証機能はディセーブルです。FTP プロトコルは本来セキュアでないため、認証証明書がネットワークからスニッフィングされて、セキュアなチャネル(HTTP の場合など)を介して提供されたユーザ証明書が公開されることがあります。ACNS 5.4.1 以降のソフトウェア リリースで、FTP ネイティブ プロキシ認証機能をイネーブルにする手順は、次のとおりです。

ContentEngine(config)# ftp-native proxy authentication enable
 

ftp-native proxy authentication enable コマンドを入力したにもかかわらず、Content Engine で認証サービス(RADIUS、TACACS+、NTLM、または LDAP)が設定されていない場合は、警告メッセージが表示されます。このメッセージは、Content Engine 上で FTP プロキシ認証機能をイネーブルにする前に、Content Engine に認証サービスを設定する必要があることを示しています。

非透過 FTP ネイティブ要求の要求認証のために、ACNS は認証サービスとして TACACS+、RADIUS、NTLM、および LDAP をサポートしています。FTP ネイティブ要求の送信元である FTP クライアントがプロキシ認証のために Content Engine でクエリーされるかどうかは、着信 FTP ネイティブ要求を受信する Content Engine 上でサポート対象認証サービスの 1 つ(RADIUS、TACACS+、NTLM、または LDAP)がイネーブル化されているかどうかによって決まります。

ACNS 5.4.1 以降のソフトウェア リリースでは、HTTP 要求と非透過 FTP ネイティブ要求の認証サービスのイネーブル化および設定に、同じプロセスを使用することができます(たとえば、HTTP 要求と非透過 FTP ネイティブ要求の認証サービスとして RADIUS をイネーブル化し、設定する場合に、同じプロセスを使用します)。ただし、FTP ネイティブ キャッシング サポートには次の制限があります。

FTP 要求プロキシ ルールについては未サポート

URL フィルタリング方式(good リスト、bad リスト、N2H2、Websense および SmartFilter)についてはすべて未サポート

スタンドアロン Content Engine 上で要求認証を制御するように認証サービスを設定する方法については、次のセクションを参照してください。

「RADIUS 認証サービスの設定」

「TACACS+ 認証サービスの設定」

「LDAP 認証サービスの設定」

「NTLM 認証サービスの設定」

ACNS 5.4.1 以降のソフトウェア リリースでは、IP ACL を使用して、Content Engine で稼働中のネイティブ FTP プロキシ サービスへのアクセスを制御することができます。詳細は、「FTP ネイティブ要求の IP ACL サポートの概要」を参照してください。

ACNS 5.4.1 以降のソフトウェア リリースでは、 ftp-native custom-message グローバル コンフィギュレーション コマンドを使用して、Content Engine が着信プロキシ モード接続に応答して FTP クライアントに送信するカスタマイズ済み応答メッセージを設定することができます。

ContentEngine# ftp-native custom-message ?
download Download the custom message file specified by the URL to the CE
reset Revert to default message and delete the local file on the CE
upload Upload the custom message file to the specified host, directory and
filename using the FTP protocol
 

ftp-native custom-message EXEC コマンドを使用して、次のカスタム メッセージを含むファイルを作成、アップロード、およびダウンロードすることができます。

カスタム ウェルカム メッセージ ― FTP クライアントからのプロキシ モード接続を受け入れる場合

カスタム エラー メッセージ ― 着信 FTP ネイティブ要求に関して Content Engine に設定された IP ACL に基づいて、FTP クライアントがアクセスを拒否される場合

このトピックの詳細は、「FTP ネイティブ要求に対する FTP プロキシ応答用のカスタム メッセージの作成」を参照してください。