認証および承認

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

エンドユーザークレデンシャルの取得の概要


サーバータイプ/レルム	認証方式	サポートされるネットワークプロトコル	注記
Active Directory	Kerberos NTLMSSP 基本	HTTP、HTTPS ネイティブ FTP、FTP over HTTP SOCKS（基本認証）	Kerberos は標準モードでのみサポートされます。クラウドコネクタモードではサポートされません。
LDAP	基本	HTTP、HTTPS ネイティブ FTP、FTP over HTTP SOCKS	—

認証タスクの概要


ステップ	タスク	関連項目および手順へのリンク
1	認証レルムを作成する。	Active Directory 認証レルムの作成（NTLMSSP および基本） LDAP 認証レルムの作成
2	グローバル認証を設定する。	グローバル認証の設定
3	外部認証を設定する。外部 LDAP または RADIUS サーバーからユーザーを認証できます。	外部認証
4	（任意）追加の認証レルムを作成して順序を決定する。使用する予定の各認証プロトコルとスキームの組み合わせに対して、少なくとも 1 つの認証レルムを作成する。	認証シーケンスの作成
5	（任意）クレデンシャルの暗号化を設定する。	クレデンシャル暗号化の設定
6	認証要件に基づいてユーザーとクライアントソフトウェアを分類する識別プロファイルを作成する。	ユーザーおよびクライアントソフトウェアの分類
7	識別プロファイルの作成対象となったユーザーとユーザーグループからの Web 要求を管理するポリシーを作成する。	ポリシーによる Web 要求の管理：ベストプラクティス

認証に関するベストプラクティス

できる限り少数の Active Directory レルムを作成します。多数の Active Directory レルムを作成すると、認証で追加のメモリが必要になります。
NTLMSSP を使用する場合は、 Secure Web Appliance またはアップストリームプロキシサーバを使用してユーザを認証します（両方は使用できません）。（ Secure Web Applianceを推奨）
Kerberos を使用する場合は、 Secure Web Applianceを使用して認証します。
最適なパフォーマンスを得るには、1 つのレルムを使用して同じサブネット上のクライアントを認証します。
一部のユーザーエージェントには、通常の動作に悪影響を及ぼすマシンクレデンシャルや認証失敗の問題があることが判明されています。これらのユーザーエージェントとの認証をバイパスする必要があります。問題のあるユーザーエージェントの認証のバイパスを参照してください。
クライアントをアクティブに認証することは、リソースを大量に消費するタスクです。認証サロゲートを使用すると、認証が完了した後、設定された期間（デフォルトは 3600 秒）、[グローバル認証（Global Authentication）] > [サロゲートタイムアウト（Surrogate Timeout）] で構成可能な認証されたユーザーを記憶することにより、認証パフォーマンスを向上させることができます。アクティブな認証イベントの数を制限するために、可能な場合は常に IP サロゲートを使用する必要があります。

Active Directory/Kerberos


明示的な転送	透過、IP ベースのキャッシング	透過、Cookie ベースのキャッシング
利点： NTLM と比べた場合、パフォーマンスと相互運用性が向上ドメインに参加している Windows クライアントと非 Windows クライアントの両方と連携すべてのブラウザ、および他のほとんどのアプリケーションでサポートされている RFC ベース最小限のオーバーヘッド（再認証は必要ありません） HTTPS（CONNECT）要求で使用できるパスフレーズが認証サーバーに送信されないため、より安全であるホストや IP アドレスではなく、接続が認証されるクライアントアプリケーションが Secure Web Applianceを信頼するように設定されている場合に、Active Directory 環境で真のシングルサインオンを実現	利点： NTLM と比べた場合、パフォーマンスと相互運用性が向上ドメインに参加している Windows クライアントと非 Windows クライアントの両方と連携すべての主要ブラウザで使用できる認証をサポートしていないユーザーエージェントを使用する場合、ユーザーはサポートされるブラウザで最初に認証されるだけでよいオーバーヘッドが比較的低いユーザーが以前に HTTP 要求で認証されている場合は、HTTPS 要求で使用できる	利点： NTLM と比べた場合、パフォーマンスと相互運用性が向上ドメインに参加している Windows クライアントと非 Windows クライアントの両方と連携すべての主要ブラウザで使用できる認証が、ホストや IP アドレスではなく、ユーザーに関連付けられる欠点： Cookie はドメイン固有であるため、新規の各 Web ドメインで認証プロセス全体が必要 Cookie をイネーブルにする必要がある HTTPS 要求で使用できない

Active Directory/基本


明示的な転送	透過、IP ベースのキャッシング	透過、Cookie ベースのキャッシング
利点：すべてのブラウザ、および他のほとんどのアプリケーションでサポートされている RFC ベース最小限のオーバーヘッド HTTPS（CONNECT）要求で使用できるパスフレーズが認証サーバーに送信されないため、より安全であるホストや IP アドレスではなく、接続が認証されるクライアントアプリケーションが Secure Web Applianceを信頼するように設定されている場合に、Active Directory 環境で真のシングルサインオンを実現欠点：すべての要求でパスフレーズがクリアテキスト（Base64）として送信されるシングルサインオンなし中程度のオーバーヘッド：新規の接続ごとに再認証が必要主に Windows および主要ブラウザでのみサポート	利点：すべての主要ブラウザで使用できる認証をサポートしていないユーザーエージェントを使用する場合、ユーザーはサポートされるブラウザで最初に認証されるだけでよいオーバーヘッドが比較的低いユーザーが以前に HTTP 要求で認証されている場合は、HTTPS 要求で使用できる欠点：認証クレデンシャルが、ユーザーではなく、IP アドレスに関連付けられる（Citrix および RDP 環境では使用できず、ユーザーが IP アドレスを変更した場合も使用できない）シングルサインオンなしパスフレーズがクリアテキスト（Base64）として送信される	利点：すべての主要ブラウザで使用できる認証が、ホストや IP アドレスではなく、ユーザーに関連付けられる欠点： Cookie はドメイン固有であるため、新規の各 Web ドメインで認証プロセス全体が必要 Cookie をイネーブルにする必要がある HTTPS 要求で使用できないシングルサインオンなしパスフレーズがクリアテキスト（Base64）として送信される

Active Directory/NTLMSSP


明示的な転送	透過
利点：パスフレーズが認証サーバーに送信されないため、より安全であるホストや IP アドレスではなく、接続が認証されるクライアントアプリケーションが Secure Web Applianceを信頼するように設定されている場合に、Active Directory 環境で真のシングルサインオンを実現欠点：中程度のオーバーヘッド：新規の接続ごとに再認証が必要主に Windows および主要ブラウザでのみサポート	利点：より柔軟性が高い透過 NTLMSSP 認証は透過基本認証と似ています。ただし、Web プロキシはクライアントとの通信に、基本的なクリアテキストのユーザー名とパスフレーズではなく、チャレンジ/レスポンス認証を使用します。透過 NTLM 認証を使用する利点と欠点は、透過基本認証を使用する場合と同様です。ただし、透過 NTLM 認証には、パスフレーズが認証サーバーに送信されないというさらなる利点があり、クライアントアプリケーションが Secure Web Applianceを信頼するように設定されている場合はシングルサインオンを実現できます。

LDAP/基本


明示的な転送	透過
利点： RFC ベース NTLM よりも多くのブラウザをサポート最小限のオーバーヘッド HTTPS（CONNECT）要求で使用できる欠点：シングルサインオンなしすべての要求でパスフレーズがクリアテキスト（Base64）として送信される回避策：認証の失敗	利点：明示的な転送よりも柔軟。 NTLM よりも多くのブラウザをサポート認証をサポートしていないユーザーエージェントを使用する場合、ユーザーはサポートされるブラウザで最初に認証されるだけでよいオーバーヘッドが比較的低いユーザーが以前に HTTP 要求で認証されている場合は、HTTPS 要求で使用できる欠点：シングルサインオンなしパスフレーズがクリアテキスト（Base64）として送信される認証クレデンシャルが、ユーザーではなく、IP アドレスに関連付けられる（Citrix および RDP 環境では使用できず、ユーザーが IP アドレスを変更した場合も使用できない）回避策：認証の失敗

ユーザーの透過的識別

従来、ユーザーの識別および認証では、ユーザーにユーザー名とパスフレーズの入力を求めていました。ユーザーが入力したクレデンシャルは認証サーバーによって認証され、その後、Web プロキシが、認証されたユーザー名に基づいてトランザクションに適切なポリシーを適用します。

しかし、 Secure Web Applianceは、ユーザを透過的に認証するように設定することができます。つまり、エンドユーザにクレデンシャルを要求しません。透過的な識別では、別の信頼できるソースによってユーザーが認証済みであると想定し、そのソースから取得したクレデンシャルを使用してユーザーを認証して、適切なポリシーを適用します。

ユーザーを透過的に識別して以下を実行する場合があります。

ユーザーがネットワーク上のプロキシの存在を意識しないように、シングルサインオン環境を構築する。
エンドユーザーに認証プロンプトを表示できないクライアントアプリケーションからのトランザクションに、認証ベースのポリシーを適用する。

ユーザーの透過的識別は、Web プロキシがユーザー名を取得して識別プロファイルを割り当てる方法にのみ影響を与えます。ユーザー名を取得して識別プロファイルを割り当てた後、Web プロキシは、識別プロファイルの割り当て方法に関係なく、通常どおり他のすべてのポリシーを適用します。

透過認証が失敗した場合、トランザクションを処理する方法を設定できます。ユーザーにゲストアクセスを許可するか、またはユーザーに認証プロンプトを表示することができます。

透過的ユーザー ID の失敗によりエンドユーザーに認証プロンプトが表示され、ユーザーが無効なクレデンシャルにより認証に失敗した場合、ユーザーのゲストアクセスを許可するかどうかを選択できます。

（注）

再認証をイネーブルにしたが、URL フィルタリングによってトランザクションがブロックされている場合、エンドユーザー通知ページが表示され、別のユーザーとしてログインするオプションが提供されます。ユーザーがリンクをクリックすると、認証を求めるプロンプトが表示されます。詳細については、認証の失敗：異なるクレデンシャルによる再認証の許可を参照してください。

透過的ユーザー識別について

透過的ユーザー識別は以下の方式で使用できます。

[ISEによってユーザーを透過的に識別（Transparently identify users with ISE）]：Identity Services Engine（ISE）サービスまたは Passive Identity Connector（ISE-PIC）サービスがイネーブルの場合に使用可能（[ネットワーク（Network）] > [Identity Services Engine]）。これらのトランザクションの場合、ユーザー名と関連するセキュリティグループタグは Identity Services Engine サーバーから取得されます。ISE-PIC を使用している場合は、ユーザー名と関連する ISE セキュリティグループが取得されます。ISE/ISE-PIC サービスを統合するためのタスクを参照してください。
[ASA によってユーザーを透過的に識別（Transparently identify users with ASA）]：ユーザーは、Cisco 適応型セキュリティアプライアンスから受信した現在の IP アドレス対ユーザー名のマッピングによって識別されます（リモートユーザーのみ）。このオプションは、AnyConnect Secure Mobility がイネーブルになっており、ASA と統合されている場合に使用できます。ユーザ名は ASA から取得され、関連するディレクトリグループは Secure Web Applianceで指定された認証レルムまたはシーケンスから取得されます。リモートユーザーを参照してください。
[認証レルムによってユーザーを透過的に識別（Transparently identify users with authentication realms）]：このオプションは、1 つ以上の認証レルムが、以下のいずれかの認証サーバーを使用して透過的識別をサポートするように設定されている場合に使用できます。
- Active Directory：NTLM または Kerberos 認証レルムを作成し、透過的ユーザー識別をイネーブルにします。また、Cisco Context Directory Agent などの Active Directory エージェントを個別に展開する必要があります。詳細については、Active Directory による透過的ユーザー識別を参照してください。
- LDAP：eDirectory として設定した LDAP 認証レルムを作成し、透過的ユーザー識別をイネーブルにします。詳細については、LDAP による透過的ユーザー識別を参照してください。

AsyncOS for Web は eDirectory または Active Directory エージェントと定期的に通信して、認証されたユーザー名と現在の IP アドレスを照合するマッピングを保守します。

Active Directory による透過的ユーザー識別

Active Directory は、 Secure Web Applianceなどの他のシステムから簡単に照会できる形式でユーザログイン情報を記録しません。Cisco Context Directory Agent（CDA）などの Active Directory エージェントは、認証済みユーザーの情報を Active Directory セキュリティイベントログで照会する必要があります。

AsyncOS for Web は Active Directory エージェントと通信して、IP アドレス対ユーザー名のマッピングのローカルコピーを保守します。AsyncOS for Web は IP アドレスをユーザー名に関連付ける必要がある場合、最初にマッピングのローカルコピーをチェックします。一致が見つからない場合、Active Directory エージェントに照会して一致するものを見つけます。

Active Directory エージェントのインストールと設定については、以下の「 Secure Web Applianceに情報を提供する Active Directory エージェントの設定」を参照してください。

Active Directory を使用してユーザーを透過的に識別する場合は、以下を考慮してください。

Active Directory による透過的ユーザー識別は、NTLM または Kerberos 認証スキームでのみ機能します。Active Directory インスタンスに対応する LDAP 認証レルムでは使用できません。
透過的ユーザー ID は Active Directory エージェントがサポートする Active Directory のバージョンで動作します。
高可用性を実現するために、別のマシンに Active Directory エージェントの 2 番目のインスタンスをインストールできます。その場合、各 Active Directory エージェントは、他方のエージェントとは別個に、独自の IP アドレス対ユーザー名マッピングを保持します。AsyncOS for Web は、プライマリエージェントに対する ping の試行が 3 回失敗した後にバックアップとして Active Directory エージェントを使用します。
Active Directory エージェントは、 Secure Web Applianceと通信する際にオンデマンドモードを使用します。
Active Directory エージェントは、 Secure Web Appliance にユーザのログアウト情報をプッシュします。ただし、ユーザーのログアウト情報が Active Directory セキュリティログに記録されないことがあります。これは、クライアントマシンがクラッシュしたり、ユーザーがログアウトせずにマシンをシャットダウンした場合に発生します。ユーザーのログアウト情報がセキュリティログにないと、Active Directory エージェントは、IP アドレスがそのユーザーに割り当てられていないことをアプライアンスに通知できません。これを回避するために、Active Directory エージェントからのアップデートがない場合に AsyncOS が IP アドレス対ユーザーのマッピングをキャッシュしておく時間の長さを定義できます。詳細については、CLI を使用した透過的ユーザー識別の詳細設定を参照してください。
Active Directory エージェントは、ユーザー名の一意性を確保するために、特定の IP アドレスからログインする各ユーザーの sAMAccountName を記録します。
クライアントマシンが Active Directory サーバに提供するクライアントの IP アドレスと Secure Web Applianceは同一である必要があります。
AsyncOS for Web はユーザーが属する上位の親グループだけを検索します。ネストされたグループは検索しません。

Secure Web Applianceに情報を提供する Active Directory エージェントの設定

AsyncOS for Web OS は、Active Directory から直接クライアントの IP アドレスを取得できないので、Active Directory エージェントから IP アドレス対ユーザー名のマッピング情報を取得する必要があります。

Secure Web Appliance にアクセスでき、表示されるすべての Windows ドメインコントローラと通信できるネットワーク上のマシンに、Active Directory エージェントをインストールします。最高のパフォーマンスを実現するために、このエージェントは Secure Web Appliance に物理的にできるだけ近いところに配置する必要があります。小規模なネットワーク環境では、Active Directory サーバーに直接 Active Directory エージェントをインストールすることもできます。

（注）

Secure Web Applianceとの通信に使用される Active Directory エージェントのインスタンスは、シスコの適応型セキュリティアプライアンスやその他の Secure Web Applianceなど、他のアプライアンスもサポートできます。

Cisco Context Directory Agent の取得、インストール、および設定

Cisco Context Directory Agent のダウンロード、インストール、および設定に関する詳細については、http://www.cisco.com/en/US/docs/security/ibf/cda_10/Install_Config_guide/cda10.html を参照してください。

（注）

Secure Web Appliance と Active Directory エージェントは、RADIUS プロトコルを使用して相互に通信します。アプライアンスとエージェントは、ユーザーのパスフレーズを難読化するために同じ共有秘密キーを使用して設定する必要があります。その他のユーザー属性は難読化されません。

LDAP による透過的ユーザー識別

AsyncOS for Web は、Lightweight Directory Access Protocol（LDAP）レルムとして設定されている eDirectory サーバーと通信し、IP アドレス対ユーザー名のマッピングを保守できます。eDirectory クライアントを介してログインする場合、ユーザーは eDirectory サーバーに対して認証されます。認証に成功すると、ログインしたユーザーの属性（NetworkAddress）としてクライアントの IP アドレスが eDirectory サーバーに記録されます。

LDAP（eDirectory）を使用してユーザーを透過的に識別する場合は、以下を考慮してください。

eDirectory クライアントを各クライアントワークステーションにインストールし、エンドユーザーがそれを使用して eDirectory サーバーによる認証を受けるようにする必要があります。
eDirectory クライアントのログインで使用する LDAP ツリーは、認証レルムに設定されている LDAP ツリーと同一である必要があります。
eDirectory クライアントが複数の LDAP ツリーを使用する場合は、ツリーごとに認証レルムを作成し、各 LDAP 認証レルムを使用する認証シーケンスを作成します。
eDirectory として LDAP 認証レルムを設定する場合は、クエリークレデンシャルのバインド DN を指定する必要があります。
eDirectory サーバーは、ユーザーのログイン時にユーザーオブジェクトの NetworkAddress 属性を更新するように設定する必要があります。
AsyncOS for Web はユーザーが属する上位の親グループだけを検索します。ネストされたグループは検索しません。
eDirectory ユーザーの NetworkAddress 属性を使用して、ユーザーの最新のログイン IP アドレスを特定できます。

透過的ユーザー識別のルールとガイドライン

任意の認証サーバーで透過的ユーザー ID を使用する場合は、以下のルールとガイドラインを考慮してください。

DHCP を使用してクライアントマシンに IP アドレスを割り当てる場合は、 Secure Web Appliance 上の IP アドレス対ユーザ名のマッピングが DHCP リースよりも頻繁に更新されるようにします。tuiconfig CLI コマンドを使用して、マッピングの更新間隔を更新します。詳細については、CLI を使用した透過的ユーザー識別の詳細設定を参照してください。
IP アドレス対ユーザ名のマッピングが Secure Web Appliance上で更新される前に、ユーザがマシンからログアウトし、別のユーザが同じマシンにログインした場合、Web プロキシは前のユーザをクライアントとして記録します。
透過的ユーザー識別に失敗した場合に Web プロキシがトランザクションを処理する方法を設定できます。ユーザーにゲストアクセスを許可するか、または認証プロンプトをエンドユーザーに強制的に表示することができます。
透過的ユーザー ID の失敗によりユーザーに認証プロンプトが表示され、ユーザーが無効なクレデンシャルにより認証に失敗した場合、ユーザーのゲストアクセスを許可するかどうかを選択できます。
割り当てられた識別プロファイルが、ユーザーが存在する複数のレルムを含む認証シーケンスを使用している場合、AsyncOS for Web はシーケンスで示される順序でレルムからユーザーグループを取得します。
ユーザーを透過的に識別するように識別プロファイルを設定する場合、認証サロゲートは IP アドレスでなければなりません。別のサロゲートタイプを選択することはできません。
ユーザーの詳細なトランザクションを表示すると、透過的に識別されたユーザーが [Web トラッキング（Web Tracking）] ページに表示されます。
%m および x-auth-mechanism カスタムフィールドを使用して、透過的に識別されたユーザーをアクセスログと WC3 ログに記録することができます。SSO_TUI のログエントリは、ユーザー名が、透過的ユーザー識別により認証されたユーザー名をクライアント IP アドレスと照合することによって取得されたことを示しています。（同様に、SSO_ASA の値は、ユーザーがリモートユーザーであり、ユーザー名が AnyConnect Secure Mobility を使用して Cisco ASA から取得されたことを示しています）。

透過的ユーザー識別の設定

透過的なユーザーの識別と認証の設定については、エンドユーザークレデンシャルの取得の概要に詳しく記載されています。基本的な手順は以下のとおりです。

認証レルムを作成して、順序付けます。
識別プロファイルを作成し、ユーザーおよびクライアントソフトウェアを分類します。
識別されたユーザーとユーザーグループからの Web 要求を管理するポリシーを作成します。

CLI を使用した透過的ユーザー識別の詳細設定

AsyncOS for Web は以下の TUI 関連の CLI コマンドを備えています。

tuiconfig：透過的ユーザー識別に関連する詳細設定を設定します。バッチモードを使用して、複数のパラメータを同時に設定できます。
- Configure mapping timeout for Active Directory agent：AD エージェントからのアップデートがない場合に、AD エージェントによって取得された IP アドレスに対して、IP アドレス対ユーザーのマッピングをキャッシュしておく時間の長さ（分単位）。
- Configure proxy cache timeout for Active Directory agent：プロキシ固有の IP アドレス対ユーザーのマッピングをキャッシュしておく時間の長さ（秒単位）。有効な値は 5～1200 秒です。デフォルト値および推奨値は 120 秒です。より低い値を指定すると、プロキシのパフォーマンスに悪影響を及ぼします。
- Configure mapping timeout for Novell eDirectory：サーバーからのアップデートがない場合に、eDirectory サーバーから取得された IP アドレスに対して、IP アドレス対ユーザーのマッピングをキャッシュしておく時間の長さ（秒単位）。
- Configure query wait time for Active Directory agent：Active Directory エージェントからの応答を待機する時間の長さ（秒単位）。クエリーに要する時間がこのタイムアウト値を上回った場合、透過的ユーザー識別は失敗したと見なされます。これにより、エンドユーザーが体験する認証遅延が限定されます。
- Configure query wait time for Novell eDirectory：eDirectory サーバーからの応答を待機する時間の長さ（秒単位）。クエリーに要する時間がこのタイムアウト値を上回った場合、透過的ユーザー識別は失敗したと見なされます。これにより、エンドユーザーが体験する認証遅延が限定されます。

Active Directory の設定は、透過的ユーザー識別に AD エージェントを使用するすべての AD レルムに適用されます。eDirectory の設定は、透過的ユーザー識別に eDirectory を使用するすべての LDAP レルムに適用されます。

いずれかのパラメータの検証に失敗した場合は、どの値も変更されません。

tuistatus：このコマンドには、以下のような AD 関連のサブコマンドがあります。
- adagentstatus：すべての AD エージェントの現在のステータス、および Windows ドメインコントローラとの接続に関する情報を表示します。
- listlocalmappings： Secure Web Appliance に保存されているすべての IP アドレス対ユーザー名のマッピングを、AD エージェントによって取得された順序で一覧表示します。このコマンドは、エージェントに保存されているエントリや、現在クエリーが進行中のマッピングを一覧表示しません。

シングルサインオンの設定

透過的にクレデンシャルを取得することにより、シングルサインオン環境を実現できます。透過的ユーザー識別は認証レルムの設定項目の 1 つです。

Internet Explorer の場合は、リダイレクトホスト名として、完全修飾ドメイン名ではなく、（ドットを含まない）短縮形のホスト名または NetBIOS 名を必ず使用してください。または、Internet Explorer の [ローカルイントラネット] ゾーンにアプライアンスのホスト名を追加することができます（[ツール] > [インターネットオプション] > [セキュリティ] タブ）。ただし、この操作をすべてのクライアントで実行する必要があります。これに関する詳細については、『How do I properly set up NTLM with SSO (credentials sent transparently)?』を参照してください。

Firefox およびその他の Microsoft 以外のブラウザでは、パラメータ network.negotiate-auth.delegation-uris、network.negotiate-auth.trusted-uris、network.automatic-ntlm-auth.trusted-uris を透過モードのリダイレクトホスト名に設定する必要があります。『Firefox is not sending authentication credentials transparently (SSO)』も参照してください。この記事には、Firefox パラメータの変更に関する一般情報が記載されています。

リダイレクトホスト名については、グローバル認証の設定、または CLI コマンド sethostname を参照してください。

ハイアベイラビリティ展開で Kerberos 認証を行うための Windows Active Directory におけるサービスアカウントの作成

Kerberos 認証でハイアベイラビリティに関する問題が発生している場合は、この手順を使用します。ハイアベイラビリティ展開で Kerberos 認証を使用するときに問題が発生する場所のシナリオは次のとおりです。

ハイアベイラビリティのホスト名の servicePrincipalName は、Active Directory 内の複数のコンピュータアカウントに追加されます。
Kerberos 認証は servicePrincipalName が Active Directory の 1 つのコンピュータアカウントに追加されている場合に機能します。異なるアプライアンスノードでは、ケルベロスサービスチケットの復号化に異なる暗号化文字列が使用されるため、プライマリノードが変更されると高可用性に影響を及ぼす可能性があります。

始める前に

ハイアベイラビリティで Kerberos 認証に使用するユーザー名を選択します。この目的のためだけに使用する新しいユーザー名を作成することをお勧めします。
既存のユーザー名を使用する場合には、次の設定を行います。
- ユーザー名にパスワードがない場合は、パスワードを設定します。
- ユーザーアカウントのプロパティダイアログボックス（[Active Directory ユーザーとコンピュータ（Active Directory users and computers）]）で、次のことを行います。
  
  [ユーザーは次回のログオン時にパスワード変更が必要（User must change password at next logon）] チェックボックスがオフになっていることを確認します。
  
  [パスワードを無期限にする（Password Never Expires）] チェックボックスをオンにします。

手順

ステップ 1

[Active Directory ユーザーとコンピュータ（Active Directory users and computers）] で新しいユーザー名を作成します。

パスワードを指定します。
[ユーザーは次回のログオン時にパスワード変更が必要（User must change password at next logon）] チェックボックスをオフにします。
[パスワードを無期限にする（Password Never Expires）] チェックボックスをオンにします。

ステップ 2

ハイアベイラビリティのホスト名の SPN が、作成または選択した Active Directory ユーザーオブジェクトに関連付けられているかどうかを確認します。SPN には、http/ のプレフィックスが付けられ、その後にアプライアンスのハイアベイラビリティのホスト名が付けられます。クライアントが、ホスト名を解決できることを確認します。

Windows の setspn -q コマンドを使用して、既存の関連付けをクエリーします。

例：setspn -q http/highavail.com

この例では、highavail.com は、アプライアンスのハイアベイラビリティのホスト名です。
クエリの結果に応じて、SPN を削除するか、追加します。

（注）

ケルベロス HA サービスアカウントのパスワードには、文字、数字、スペース、および特殊文字（~ ! @ # % ^ & () _ - {} ' / [] : ; , | + = * ? <>）のみを含めることができます。これらの 3 つの特殊文字 $、`、または " のいずれかがケルベロス HA サービスアカウントのパスワードで使用されている場合、GUI と CLI の両方からの事前認証中にエラーが発生します。ただし、認証はパスワードに使用されるあらゆる種類の文字で成功します。


クエリ結果	操作
「このようなSPNは見つかりませんでした。（No such SPN found.）」	ハイアベイラビリティのホスト名の SPN を Active Directory ユーザーオブジェクトに関連付けます。次のように `setspn -s` コマンドを使用します。 `setspn -s http/highavail.com hausername` この例で、highavail.com はアプライアンスのハイアベイラビリティのホスト名で、hausername は作成または選択したユーザー名です。
「既存のSPNが見つかりました。（Existing SPN found!）」「共通名（CN）は、作成または選択したユーザー名を示しています。（The common name (CN) shows the user name created or chosen.）」「例: CN = hausername（Example: CN = hausername）」	Active Directory でこれ以上の作業は必要ありません。
「既存のSPNが見つかりました。（Existing SPN found!）」「共通名（CN）によって、作成または選択したユーザー名は表示されません。（The common name (CN) does not show the user name created or chosen.）」	SPN を削除します。次のように `setspn -d` コマンドを使用します。 `setspn -d http/highavail.com johndoe` この例で、highavail.com は、アプライアンスのハイアベイラビリティのホスト名で、johndoe は関連付けを解除するユーザー名です。 SPN を追加します。次のように `setspn -s` コマンドを使用します。 `setspn -s http/highavail.com hausername` この例で、highavail.com はアプライアンスのハイアベイラビリティのホスト名で、hausername は作成または選択したユーザー名です。

（注）

関連する Active Directory レルムで keytab 認証が有効になっていることを確認します。Kerberos 認証方式の Active Directory レルムの作成を参照してください。レルムがすでに作成されている場合は、レルムを編集し、keytab 認証を有効にします。

認証レルム

認証レルムによって、認証サーバーに接続するために必要な詳細情報を定義し、クライアントと通信するときに使用する認証方式を指定します。AsyncOS は複数の認証レルムをサポートしています。レルムを認証シーケンスにグループ化することにより、認証要件が異なるユーザーを同じポリシーで管理することができます。

認証フェールオーバー

現在のレルム設定では、プライマリ AD または LDAP が 1 つ、バックアップサーバーが 2 つあります。最初のプライマリサーバーに到達できない場合、クエリーは最初のバックアップサーバーに到達します。最初のバックアップサーバーにも到達できない場合、クエリーは 2 番目のサーバーに到達します。

表 1. IPFW ルールを使用したフェールオーバー時間
フェールオーバー時間	プライマリからセカンダリへのバックアップへのフェールオーバーにかかる時間（秒）
プライマリ AD と Secure Web Applianceの間の接続を切断するまでの時間	75 ～ 80
プライマリ AD と Secure Web Applianceの間の接続を切断し、かつ最初のバックアップと Secure Web Applianceの間の接続も切断するまでの時間	180 ～ 250
プライマリ AD を再起動するまでの時間	42 秒
プライマリ AD の電源がオフになるまでの時間	75 ～ 80
プライマリ AD と最初のバックアップサーバーの電源がオフになるまでの時間	180 ～ 250

複数のサーバーがダウンしている場合は、動作しているドメインコントローラが見つかるまで、 Secure Web Applianceで接続の確立を再試行します。

外部認証
Kerberos 認証方式の Active Directory レルムの作成
Active Directory 認証レルムの作成（NTLMSSP および基本）
LDAP 認証レルムの作成
認証レルムの削除について
グローバル認証の設定

外部認証

外部 LDAP または RADIUS サーバーからユーザーを認証できます。

LDAP サーバーによる外部認証の設定

始める前に

LDAP 認証レルムを作成し、それに 1 つ以上の外部認証クエリーを設定します。LDAP 認証レルムの作成。

手順

ステップ 1

アプライアンスで外部認証を有効にします。

[システム管理（System Administration）] > [ユーザー（Users）] に移動します。
[外部認証（External Authentication）] セクションで [有効（Enable）] をオンにします。

以下のオプションを設定します。


オプション	説明
外部認証を有効にする（Enable External Authentication）	—
認証タイプ（Authentication Type）	[LDAP] を選択します。
外部認証キャッシュタイムアウト（External Authentication Cache Timeout）	再認証のために LDAP サーバーに再接続するまで、AsyncOS が外部認証クレデンシャルを保存する秒数。デフォルトはゼロ（0）です。
LDAP 外部認証クエリー（LDAP External Authentication Query）	LDAP レルムにより設定されたクエリー。
サーバーからの有効なレスポンス待ちタイムアウト（Timeout to wait for valid response from server）	AsyncOS がサーバーからのクエリーに対する応答を待機する秒数。
グループマッピング（Group Mapping）	ディレクトリ内の各グループ名にロールを割り当てます。

ステップ 2

変更を送信し、保存します。

RADIUS 外部認証のイネーブル化

RADIUS を使用した外部認証の有効化を参照してください。

Kerberos 認証方式の Active Directory レルムの作成

始める前に

アプライアンスが（クラウドコネクタモードではなく）標準モードで設定されていることを確認します。
高可用性を設定する場合、手順 9 で指定した [ケルベロス高可用性（Kerberos High Availability）] セクションの [キータブ認証を使用する（Use keytab authentication）] チェックボックスもオンにしてください。

アプライアンスが、ロードバランサなどの HTTP/HTTPS トラフィック分散デバイスの背後にある場合は、Active Directory 内のトラフィック分散デバイスの SPN をユーザーアカウントに関連付けて、[ケルベロス高可用性（Kerberos High Availability）] セクションでそのユーザーアカウントのログイン情報を入力する必要があります。ネットワークトポロジで、トラフィックをリダイレクトする最初のデバイスの SPN を追加する必要があります。たとえば、クライアントデバイスの送信ネットワークトラフィックがトラフィックマネージャ、ロードバランサ、および Secure Web Applianceを通過する場合、トラフィックマネージャの SPN を Active Directory のユーザーアカウントに追加し、このセクションでユーザークレデンシャルを入力する必要があります。これは、トラフィックマネージャがクライアントデバイスのトラフィックを検出する最初のデバイスであるためです。
Active Directory サーバーを準備します。
- 次のサーバーのいずれかに Active Directory をインストールします。Windows Server 2003、2008、2008R2、2012、2016（coeus 11.8、12.0、12.5、14.0、14.5）、または 2019（coeus 14.5 のみ）。
  
  coeus 12.5 用の Active Directory Windows Server 2019 をインストールできます。
- Active Directory サーバーでユーザーを作成します。
  - ドメイン管理者グループまたはアカウントオペレータグループのメンバーであるユーザーを Active Directory サーバー上に作成します。
    
    または
  - 次の権限を持つユーザー名を作成します。
    - Active Directory でのパスワードリセット権限
    - servicePrincipalName への検証済み書き込み
    - アカウント制限事項の書き込み
    - dNShost 名の書き込み
    - servicePrincipalName の書き込み
      
      以上は、アプライアンスをドメインに参加させてアプライアンスが完全機能していることを確認するために、ユーザー名に必要な最小限の Active Directory 権限です。
- クラインアントをドメインに参加させます。サポートされるクライアントは、Windows XP、Windows 10、Mac OS 10.5+ です。
- Windows Resource Kit の kerbtray ツールを使用して、クライアントの Kerberos チケットを確認します（http://www.microsoft.com/en-us/download/details.aspx?id=17657）。
- Mac クライアントでは、[メインメニュー（Main Menu）] > [Keychain Access] で、Ticket Viewer アプリケーションを使用して Kerberos チケットを確認できます。
認証元となる Active Directory ドメインに Secure Web Applianceを参加させるために必要な権限とドメイン情報を取得済みであることを確認します。
Secure Web Applianceの現在の時刻と Active Directory サーバの現在時刻を比較して、その差が Active Directory サーバの [コンピュータクロック同期の最大許容時間（Maximum tolerance for computer clock synchronization）] オプションで指定されている時間を超えていないことを確認します。
Secure Web Applianceがセキュリティ管理アプライアンスで管理されている場合は、異なる Secure Web Appliance上の同名の認証レルムのプロパティが、各アプライアンスで定義されているプロパティと同一になるように設定しておきます。
Secure Web Applianceの設定：
- 明示的モードでは、 Secure Web Applianceのホスト名（sethostname CLI コマンド）をブラウザで設定されているプロキシ名と同じにする必要があります。
- 透過モードでは、 Secure Web Applianceのホスト名をリダイレクトホスト名と同じにする必要があります（グローバル認証の設定を参照）。さらに、Kerberos レルムを作成する前に、 Secure Web Applianceのホスト名とリダイレクトホスト名を設定する必要があります。
新しいレルムを確定すると、レルムの認証プロトコルを変更できなくなるので注意してください。
シングルサインオン（SSO）をクライアントブラウザで設定する必要があります（シングルサインオンの設定を参照）。
ログの使用を簡素化するため、%m のカスタムフィールドのパラメータを使用してアクセスログをカスタマイズします。アクセスログのカスタマイズを参照してください。

（注）

手順

ステップ 1

Cisco Secure Web Applianceの Web インターフェイスで、[ネットワーク（Network）] > [認証（Authentication）] を選択します。

ステップ 2

[レルムを追加（Add Realm）] をクリックします。

ステップ 3

英数字とスペース文字だけを使用して、認証レルムに一意の名前を割り当てます。

ステップ 4

[認証プロトコル（Authentication Protocol）] フィールドで [Active Directory] を選択します。

ステップ 5

Active Directory サーバーの完全修飾ドメイン名または IP アドレスを 3 つまで入力します。

例：ntlm.example.com

IP アドレスが必要なのは、アプライアンスで設定されている DNS サーバーが Active Directory サーバーのホスト名を解決できない場合だけです。

レルムに複数の認証サーバーを設定した場合、アプライアンスは、そのレルム内のトランザクションの認証に失敗するまでに最大 3 つの認証サーバーで認証を試みます。

ステップ 6

アプライアンスをドメインに参加させます。

Active Directory アカウントを設定します。

設定

説明

Active Directory ドメイン（Active Directory Domain）

Active Directory サーバーのドメイン名。DNS ドメインまたはレルムとも呼ばれます。

NetBIOSドメイン名（NetBIOS domain name）

ネットワークで NetBIOS を使用する場合は、ドメイン名を入力します。

ヒント

このオプションを使用できない場合は、setntlmsecuritymode CLI コマンドを使用して、NTLM セキュリティモードが [ドメイン（domain）] に設定されていることを確認します。

コンピュータアカウント（Computer Account）

ドメイン上のコンピュータを一意的に識別する Active Directory コンピュータアカウント（別名「マシン信頼アカウント」）が作成される、Active Directory ドメイン内の場所を指定します。

Active Directory 環境で、コンピュータオブジェクトが一定の間隔で自動的に削除される場合は、自動削除から保護されているコンテナ内にコンピュータアカウントの場所を指定します。

信頼できるドメインルックアップの有効化

レルムの信頼できるドメインルックアップの動作を制御するために、[信頼できるドメインのルックアップを有効にする（Enable Trusted Domain Lookup）] オプションが [Active Directory アカウント（Active Directory Account）] セクション（[ネットワーク（Network）] > [認証（Authentication）] > [レルムの追加（Add Realm）]）に追加されました。

このオプションは、デフォルトでは有効になっています。

[ドメインに参加（Join Domain）] をクリックします。

（注）

すでに参加しているドメインに参加しようとすると（同じクレデンシャルを使用している場合でも）、Active Directory が新しいキーセットをこの Secure Web Applianceを含むすべてのクライアントに送信するため、既存の接続は閉じます。影響を受けるクライアントは、ログオフしてから再度ログインする必要があります。

（注）

AWS に展開された Secure Web Applianceのホスト名は一意である必要があります。一意のホスト名を作成するには、ホスト名の最初の文字列を変更する必要があります。

たとえば、「mgmt」が最初の文字列としてホスト名に追加されている場合、「mgmt<wsa_hostname>」として変更できます。

Active Directory 上のアカウントにログインクレデンシャル（ユーザー名およびパスフレーズ）を指定し、[アカウントの作成（Create Account）] をクリックします。

ステップ 7

（任意）透過的ユーザー識別を設定します。


設定	説明
Active Directoryを使用して透過ユーザー識別を有効にする（Enable Transparent User Identification using Active Directory agent）	プライマリ Context Directory エージェントがインストールされているマシンのサーバー名と、それにアクセスするために使用する共有秘密の両方を入力します。（任意）バックアップ Context Directory エージェントがインストールされているマシンのサーバー名とその共有秘密を入力します。

ステップ 8

ネットワークセキュリティを設定します。


設定	説明
クライアントの署名が必須（Client Signing Required）	クライアントの署名を要求するように Active Directory サーバーが設定されている場合は、このオプションを選択します。このオプションを選択すると、以下の場合に SMB 署名が有効になります。アプライアンスが Active Directory に接続するときにデジタル署名を配置する場合。中間者攻撃を防ぐ場合。

ステップ 9

ハイアベイラビリティを使用する場合は、[Kerberosハイアベイラビリティ（Kerberos High Availability）] セクションで [キータブ認証を使用する（Use keytab authentication）] チェックボックスをオンにします。

[ユーザー名（Username）] と [パスワード（Password）] を入力します。

ハイアベイラビリティクラスタの IP アドレスまたはホスト名に対応する SPN に関連付けられている Active Directory ユーザーの名前を入力します。ユーザー名にドメイン名を含めないでください（たとえば、'DOMAIN\johndoe' や 'johndoe@domain' ではなく、「johndoe」と入力します）。ハイアベイラビリティ展開の認証に使用されるサービスアカウントの作成に関する情報については、ハイアベイラビリティ展開で Kerberos 認証を行うための Windows Active Directory におけるサービスアカウントの作成を参照してください。

ハイアベイラビリティクラスタ内のすべてのアプライアンスについて、この手順を繰り返します。

（注）

アプライアンスが、ロードバランサなどの HTTP/HTTPS トラフィック分散デバイスの背後にある場合は、Active Directory 内のトラフィック分散デバイスの SPN をユーザーアカウントに関連付けて、[Kerberosハイアベイラビリティ（Kerberos High Availability）] セクションでそのユーザーアカウントのクレデンシャルを入力する必要があります。ネットワークトポロジで、トラフィックをリダイレクトする最初のデバイスの SPN を追加する必要があります。たとえば、クライアントデバイスの送信ネットワークトラフィックがトラフィックマネージャ、ロードバランサ、および Secure Web Applianceを通過する場合、トラフィックマネージャの SPN を Active Directory のユーザーアカウントに追加し、このセクションでユーザークレデンシャルを入力する必要があります。これは、トラフィックマネージャがクライアントデバイスのトラフィックを検出する最初のデバイスであるためです。

ステップ 10

（任意）[テスト開始（Start Test）] をクリックします。これにより、ユーザーが実際にそれらを使用して認証を受ける前に、入力した設定をテストして正しいかどうかを確認できます。テストの具体的な実行方法については、「複数の NTLM レルムとドメインの使用」を参照してください。

ステップ 11

テスト中に発生した問題をトラブルシューティングします。認証の問題のトラブルシューティングツールを参照してください。

ステップ 12

変更を送信し、保存します。

次のタスク

Kerberos 認証方式を使用する識別プロファイルを作成します。ユーザーおよびクライアントソフトウェアの分類。

Active Directory 認証レルムの作成（NTLMSSP および基本）

Active Directory 認証レルムの作成の前提条件（NTLMSSP および基本）

認証元となる Active Directory ドメインに Secure Web Applianceを参加させるために必要な権限とドメイン情報を取得済みであることを確認します。
NTLM セキュリティモードとして「domain」を使用する場合は、ネストした Active Directory グループのみを使用します。Active Directory グループがネストされていない場合は、デフォルト値の「ads」を使用します。このガイドの「コマンドラインインターフェイス」のトピックで setntlmsecuritymode を参照してください。
Secure Web Applianceの現在の時刻と Active Directory サーバの現在時刻を比較して、その差が Active Directory サーバの [コンピュータクロック同期の最大許容時間（Maximum tolerance for computer clock synchronization）] オプションで指定されている時間を超えていないことを確認します。
Secure Web Applianceがセキュリティ管理アプライアンスで管理されている場合は、異なる Secure Web Appliance上の同名の認証レルムのプロパティが、各アプライアンスで定義されているプロパティと同一になるように設定しておきます。
新しいレルムを確定すると、レルムの認証プロトコルを変更できなくなるので注意してください。
Secure Web Applianceは、信頼できるすべてのドメインのドメインコントローラと、NTLM レルムに設定されたドメインコントローラに接続する必要があります。認証が正しく機能するように、内部ドメインおよび外部ドメインのすべてのドメインコントローラに対して次のポートを開く必要があります。
- LDAP（389 UDP および TCP）
- Microsoft SMB（445 TCP）
- Kerberos（88 TCP）
- エンドポイント解決：ポートマッパー（135 TCP）Net Log-on 固定ポート
NTLMSSP の場合は、クライアントブラウザにシングルサインオン（SSO）を設定できます。シングルサインオンの設定を参照してください。

複数の NTLM レルムとドメインの使用について

以下のルールは、複数の NTLM レルムとドメインを使用する場合に該当します。

最大 10 の NTLM 認証レルムを作成できます。
ある NTLM レルムのクライアント IP アドレスが、別の NTLM レルムのクライアント IP アドレスと重複しないようにする必要があります。
各 NTLM レルムは 1 つの Active Directory ドメインにのみ参加できますが、そのドメインが信頼しているあらゆるドメインのユーザーを認証できます。この信頼は、同じフォレスト内の他のドメインにデフォルトで適用され、少なくとも一方向の信頼が存在しているフォレスト外部のドメインに適用されます。
既存の NTLM レルムが信頼していないドメインのユーザーを認証するには、追加の NTLM レルムを作成します。

Active Directory 認証レルムの作成（NTLMSSP および基本）

始める前に

アプライアンス内の番号の大きなポート（49152 ～ 65535）がファイアウォールでブロックされないことを確認します。これらのポートは、非同期グループルックアップ要求を実行する必要があります。これらのポートをブロックすると、断続的な認証エラーが発生する可能性があります。

手順

ステップ 1

[ネットワーク（Network）] > [認証（Authentication）] を選択します。

ステップ 2

[レルムを追加（Add Realm）] をクリックします。

ステップ 3

英数字とスペース文字だけを使用して、認証レルムに一意の名前を割り当てます。

ステップ 4

[認証プロトコルと方式（Authentication Protocol and Scheme(s)）] フィールドで [Active Directory] を選択します。

ステップ 5

Active Directory サーバーの完全修飾ドメイン名または IP アドレスを 3 つまで入力します。

例：active.example.com

IP アドレスが必要なのは、アプライアンスで設定されている DNS サーバーが Active Directory サーバーのホスト名を解決できない場合だけです。

ステップ 6

アプライアンスをドメインに参加させます。

Active Directory アカウントを設定します。


設定	説明
Active Directory ドメイン（Active Directory Domain）	Active Directory サーバーのドメイン名。DNS ドメインまたはレルムとも呼ばれます。
NetBIOSドメイン名（NetBIOS domain name）	ネットワークで NetBIOS を使用する場合は、ドメイン名を入力します。
コンピュータアカウント（Computer Account）	ドメイン上のコンピュータを一意的に識別する Active Directory コンピュータアカウント（別名「マシン信頼アカウント」）が作成される、Active Directory ドメイン内の場所を指定します。 Active Directory 環境で、コンピュータオブジェクトが一定の間隔で自動的に削除される場合は、自動削除から保護されているコンテナ内にコンピュータアカウントの場所を指定します。
信頼できるドメインルックアップの有効化	レルムの信頼できるドメインルックアップの動作を制御するために、[信頼できるドメインのルックアップを有効にする（Enable Trusted Domain Lookup）] オプションが [Active Directory アカウント（Active Directory Account）] セクション（[ネットワーク（Network）] > [認証（Authentication）] > [レルムの追加（Add Realm）]）に追加されました。このオプションは、デフォルトでは有効になっています。

[ドメインに参加（Join Domain）] をクリックします。

（注）

たとえば、「mgmt」が最初の文字列としてホスト名に追加されている場合、「mgmt<wsa_hostname>」として変更できます。

そのドメインにコンピュータアカウントを作成する権限を持つ、既存の Active Directory ユーザーの sAMAccountName ユーザー名とパスフレーズを入力します。

例：「jazzdoe」（「DOMAIN\jazzdoe」や「jazzdoe@domain」は使用しないでください）。

この情報は、コンピュータアカウントを確立するために一度だけ使用され、保存されません。
[アカウントの作成（Create Account）] をクリックします。

ステップ 7

（任意）透過的認証を設定します。


設定	説明
Active Directoryを使用して透過ユーザー識別を有効にする（Enable Transparent User Identification using Active Directory agent）	プライマリ Context Directory エージェントがインストールされているマシンのサーバー名と、それにアクセスするために使用する共有秘密の両方を入力します。（任意）バックアップ Context Directory エージェントがインストールされているマシンのサーバー名とその共有秘密を入力します。

ステップ 8

ネットワークセキュリティを設定します。


設定	説明
クライアントの署名が必須（Client Signing Required）	クライアントの署名を要求するように Active Directory サーバーが設定されている場合は、このオプションを選択します。このオプションを選択すると、以下の場合に SMB 署名が有効になります。アプライアンスが Active Directory に接続するときにデジタル署名を配置する場合。中間者攻撃を防ぐ場合。

ステップ 9

（任意）[テスト開始（Start Test）] をクリックします。これにより、ユーザーが実際にそれらを使用して認証を受ける前に、入力した設定をテストして正しいかどうかを確認できます。

ステップ 10

変更を送信し、保存します。

LDAP 認証レルムの作成

始める前に

組織の LDAP に関する以下の情報を取得します。
- LDAP のパージョン
- サーバーのアドレス
- LDAP ポート
Secure Web Applianceがセキュリティ管理アプライアンスで管理されている場合は、異なる Secure Web Appliance上の同名の認証レルムのプロパティが、各アプライアンスで定義されているプロパティと同じであることを確認します。

手順

ステップ 1

[ネットワーク（Network）] > [認証（Authentication）] を選択します。

ステップ 2

[レルムを追加（Add Realm）] をクリックします。

ステップ 3

英数字とスペース文字だけを使用して、認証レルムに一意の名前を割り当てます。

ステップ 4

[認証プロトコルと方式（Authentication Protocol and Scheme(s)）] フィールドで [LDAP] を選択します。

ステップ 5

LDAP 認証の設定を入力します。

設定

説明

LDAP のパージョン（LDAP Version）

LDAP のバージョンを選択し、セキュア LDAP を使用するかどうかを選択します。

アプライアンスは、LDAP バージョン 2 および 3 をサポートしています。セキュア LDAP には LDAP バージョン 3 が必要です。

この LDAP サーバーが透過的ユーザー識別で使用する Novell eDirectory をサポートしているかどうかを選択します。

LDAP サーバー（LDAP Server）

LDAP サーバーの IP アドレスまたはホスト名、およびポート番号を入力します。最大 3 つのサーバーを指定できます。

ホスト名は、完全修飾ドメイン名である必要があります。例：ldap.example.com。IP アドレスが必要なのは、アプライアンスで設定されている DNS サーバーが LDAP サーバーのホスト名を解決できない場合のみです。

標準 LDAP のデフォルトのポート番号は 389 です。セキュア LDAP のデフォルトの番号は 636 です。

LDAP サーバーが Active Directory サーバーの場合は、ドメインコントローラのホスト名または IP アドレス、およびポートを入力します。可能な限り、グローバルカタログサーバーの名前を入力し、ポート 3268 を使用します。ただし、グローバルカタログサーバーが物理的に離れた場所にあり、ローカルドメインコントローラのユーザーのみを認証する必要がある場合は、ローカルドメインコントローラを使用することもできます。

注：レルムに複数の認証サーバーを設定した場合、アプライアンスは、そのレルム内のトランザクションの認証に失敗するまでに最大 3 つの認証サーバーで認証を試みます。

AsyncOS バージョン 11.5 以降では、LDAP/NTLM（ドメインコントローラ通信）の送信元インターフェイスを指定できます。[送信元インターフェイスの設定（Set Source Interface）] チェックボックスをオンにし、ドロップダウンから送信元インターフェイスを選択します。

LDAP 持続的接続（LDAP Persistent Connections）

（[詳細設定（Advanced）] セクションの下）

以下の値のいずれかを選択します。

[永続的接続の使用（無制限）（Use persistent connections (unlimited)）]。既存の接続を使用します。使用できる接続がない場合は、新しい接続が開かれます。
[永続的接続の使用（Use persistent connections）]。既存の接続を使用して、指定された数の要求に使用します。最大値に達すると、LDAP サーバーへの新しい接続が確立されます。
[永続的接続を使用しない（Do not use persistent connections）]。必ず、LDAP サーバーへの新しい接続を作成します。

ユーザー認証（User Authentication）

以下のフィールドに値を入力します。

[ベース識別名（ベース DN）（Base Distinguished Name (Base DN)]

LDAP データベースはツリー型のディレクトリ構造になっており、アプライアンスはベース DN を使用して、LDAP ディレクトリツリー内の適切な場所に移動し、検索を開始します。有効なベース DN フィルタ文字列は、object-value 形式の 1 つ以上のコンポーネントから構成されます。たとえば、「dc=companyname, dc=com」のように入力します。

（注）

このリリースにアップグレードした後で、このフィールドが空の場合、LDAP 認証の [テスト開始（Start Test）] を実行できません。

[ユーザー名属性（User Name Attribute）]

以下の値のいずれかを選択します。

[uid]、[cn]、[sAMAccountName]。ユーザー名を指定する、LDAP ディレクトリで一意の ID。
[カスタム（custom）]。「UserAccount」などのカスタム ID。

[ユーザーフィルタクエリー（User Filter Query）]

ユーザーフィルタクエリーは、ユーザーのベース DN を見つける LDAP 検索フィルタです。これは、ユーザーディレクトリがベース DN の下の階層にある場合、またはそのユーザーのベース DN のユーザー固有コンポーネントにログイン名が含まれていない場合に必要です。

以下の値のいずれかを選択します。

[なし（none）]。すべてのユーザーを抽出します。
[カスタム（custom）]。ユーザーの特定のグループを抽出します。

クエリークレデンシャル（Query Credentials）

認証サーバーが匿名クエリーを受け入れるかどうかを選択します。

認証サーバーが匿名クエリーを受け入れる場合は、[サーバーは、匿名の質問に対応します（Server Accepts Anonymous Queries）] を選択します。

認証サーバーが匿名クエリーを受け入れない場合は、[バインド DN を使用（Use Bind DN）] を選択し、以下の情報を入力します。

[バインド DN（Bind DN）]。LDAP ディレクトリの検索を許可された外部 LDAP サーバー上のユーザー。通常、バインド DN はディレクトリ全体の検索を許可されます。
[パスフレーズ（Passphrase）]。[バインド DN（Bind DN）] フィールドに入力したユーザーに関連付けられているパスフレーズ。

以下のテキストは、[バインド DN（Bind DN）] フィールドに入力するユーザーの例を示しています。

cn=administrator,cn=Users,dc=domain,dc=com sAMAccountName=jdoe,cn=Users,dc=domain,dc=com.

LDAP サーバーが Active Directory サーバーの場合は、「DOMAIN\username」の形式でバインド DN ユーザー名を入力することもできます。

ステップ 6

（任意）グループオブジェクトまたはユーザーオブジェクトを介して [グループ認証（Group Authorization）] をイネーブルにし、選択したオプションを設定します。


グループオブジェクト設定	説明
グループオブジェクト内のグループメンバーシップ属性（Group Membership Attribute Within Group Object）	このグループに属するすべてのユーザーをリストする LDAP 属性を選択します。以下の値のいずれかを選択します。 [member] および [uniquemember]。グループメンバを指定する、LDAP ディレクトリで一意の ID。 [カスタム（custom）]。「`UserInGroup`」などのカスタム ID。
グループ名を含む属性（Attribute that Contains the Group Name）	ポリシーグループの設定で使用できるグループ名を指定する LDAP 属性を選択します。以下の値のいずれかを選択します。 [cn]。グループ名を指定する、LDAP ディレクトリで一意の ID。 [カスタム（custom）]。「`FinanceGroup`」などのカスタム ID。
オブジェクトがグループかどうかを判別するクエリ文字列（Query string to determine if object is a group）	LDAP オブジェクトがユーザーグループを表しているかどうかを判別する LDAP 検索フィルタを選択します。以下の値のいずれかを選択します。 objectclass=groupofnames objectclass=groupofuniquenames objectclass=group [カスタム（custom）]。「`objectclass=person`」などのカスタムフィルタ。注：クエリーによって、ポリシーグループで使用できる一連の認証グループが定義されます。


ユーザーオブジェクト設定	説明
ユーザーオプジェクト内のグループメンバーシップ属性（Group Membership Attribute Within User Object）	このユーザーが属するすべてのグループをリストする属性を選択します。以下の値のいずれかを選択します。 [memberOf]。ユーザーメンバを指定する、LDAP ディレクトリで一意の ID。 [カスタム（custom）]。「`UserInGroup`」などのカスタム ID。
グループメンバーシップ属性は DN（Group Membership Attribute is a DN）	グループメンバーシップ属性が、LDAP オブジェクトを参照する識別名（DN）であるかどうかを指定します。Active Directory サーバーの場合は、このオプションをイネーブルにします。これをイネーブルにした場合は、以下の設定を指定する必要があります。
グループ名を含む属性（Attribute that Contains the Group Name）	グループメンバーシップ属性が DN である場合に、ポリシーグループ設定でグループ名として使用できる属性を指定します。以下の値のいずれかを選択します。 [cn]。グループ名を指定する、LDAP ディレクトリで一意の ID。 [カスタム（custom）]。「`FinanceGroup`」などのカスタム ID。
オブジェクトがグループかどうかを判別するクエリ文字列（Query string to determine if object is a group）	LDAP オブジェクトがユーザーグループを表しているかどうかを判別する LDAP 検索フィルタを選択します。以下の値のいずれかを選択します。 objectclass=groupofnames objectclass=groupofuniquenames objectclass=group [カスタム（custom）]。「`objectclass=person`」などのカスタムフィルタ。注：クエリーによって、Web Security Manager ポリシーで使用できる一連の認証グループが定義されます。

ステップ 7

（任意）ユーザーに対する外部 LDAP 認証を設定します。

[外部認証クエリ（External Authentication Query）] を選択します。

ユーザーアカウントを特定します。


ベース DN（Base DN）	検索を開始する LDAP ディレクトリツリー内の適切な場所に移動するためのベース DN。
クエリ文字列	一連の認証グループを返すクエリー。例： `(&(objectClass=posixAccount)(uid={u}))` または `(&(objectClass=user)(sAMAccountName={u}))`
ユーザのフルネームが格納されている属性（Attribute containing the user’s full name）	LDAP 属性（例：displayName、gecos）。

（任意）RFC 2307 アカウント有効期限 LDAP 属性に基づき、有効期限切れのアカウントはログインが拒否されます。

ユーザーのグループ情報を取得するクエリーを入力します。

1 人のユーザーが複数の LDAP グループに属しており、それぞれユーザーロールが異なる場合は、最も限定的なロールのアクセス許可が AsyncOS によってそのユーザーに付与されます。


ベース DN（Base DN）	検索を開始する LDAP ディレクトリツリー内の適切な場所に移動するためのベース DN。
クエリ文字列	`(&(objectClass=posixAccount)(uid={u}))`
ユーザのフルネームが格納されている属性（Attribute containing the user’s full name）	`gecos`

ステップ 8

（注）

変更を送信して確定すると、後でレルムの認証プロトコルを変更できなくなります。

ステップ 9

変更を送信し、保存します。

次のタスク

Kerberos 認証方式を使用する識別プロファイルを作成します。ユーザーおよびクライアントソフトウェアの分類を参照してください。

関連項目

外部認証

複数の NTLM レルムとドメインの使用

以下のルールは、複数の NTLM レルムとドメインを使用する場合に該当します。

最大 10 の NTLM 認証レルムを作成できます。
ある NTLM レルムのクライアント IP アドレスが、別の NTLM レルムのクライアント IP アドレスと重複しないようにする必要があります。
各 NTLM レルムは 1 つの Active Directory ドメインにのみ参加できますが、そのドメインが信頼しているあらゆるドメインのユーザーを認証できます。この信頼は、同じフォレスト内の他のドメインにデフォルトで適用され、少なくとも一方向の信頼が存在しているフォレスト外部のドメインに適用されます。
既存の NTLM レルムが信頼していないドメインのユーザーを認証するには、追加の NTLM レルムを作成します。

認証レルムの削除について

認証レルムを削除すると関連する ID がディセーブルになり、さらに、関連するポリシーからそれらの ID が削除されます。

認証レルムを削除すると、そのレルムがシーケンスから削除されます。

グローバル認証の設定

認証レルムの認証プロトコルとは別途に、グローバル認証の設定項目を設定してすべての認証レルムに設定を適用します。

Web プロキシの展開モードは、設定できるグローバル認証の設定項目に影響します。明示的な転送モードよりも、透過モードで展開されている場合の方がより多くの設定項目を使用できます。

始める前に

以下の概念をよく理解しておいてください。

認証の失敗
認証の失敗：異なるクレデンシャルによる再認証の許可

手順

ステップ 1

[ネットワーク（Network）] > [認証（Authentication）] を選択します。

ステップ 2

[グローバル設定を編集（Edit Global Settings）] をクリックします。

ステップ 3

[グローバル認証設定（Global Authentication Settings）] セクションで、設定を編集します。


設定	説明
認証サーバーが利用できない場合のアクション（Action if Authentication Service Unavailable）	以下の値のいずれかを選択します。 [認証なしでトラフィックの通過を許可（Permit traffic to proceed without authentication）]。処理が、ユーザーが認証されたかのように続行されます。 [認証に失敗した場合にすべてのトラフィックをブロック（Block all traffic if user authentication fails）]。処理が中止され、すべてのトラフィックがブロックされます。
失敗した認証手続き（Failed Authentication Handling）	識別プロファイルポリシーでユーザーにゲストアクセスを許可する場合は、この設定項目により、Web プロキシがユーザーをゲストとして識別してアクセスログに記録する方法を指定します。ユーザーのゲストアクセス許可の詳細については、認証失敗後のゲストアクセスの許可を参照してください。
再認証（Re-authentication）（URLカテゴリまたはユーザーセッションの制限によりエンドユーザーがブロックされた場合に再認証プロンプトをイネーブルにする（Enable Re-Authentication Prompt If End User Blocked by URL Category or User Session Restriction））	制限が厳しい URL フィルタリングポリシーによって、または別の IP アドレスへのログインの制限によってユーザーが Web サイトからブロックされた場合に、ユーザーに再認証を許可します。新しい認証クレデンシャルを入力できるリンクが記載されたブロックページがユーザーに表示されます。より多くのアクセスを許可するクレデンシャルをユーザーが入力すると、要求されたページがブラウザに表示されます。注：この設定は、制限が厳しい URL フィルタリングポリシーまたはユーザーセッションの制限によってブロックされた、認証済みユーザーにのみ適用されます。認証されずに、サブネットによりブロックされたトランザクションには適用されません。詳細については、認証の失敗：異なるクレデンシャルによる再認証の許可を参照してください。
ベーシック認証トークン TTL（Basic Authentication Token TTL）	認証サーバーによって再検証されるまで、ユーザーのクレデンシャルがキャッシュ内に保管される期間を制御します。これには、ユーザー名とパスフレーズ、およびユーザーに関連付けられているディレクトリグループが含まれます。デフォルト値は推奨されている設定です。[サロゲートタイムアウト（Surrogate Timeout）] が設定されており、その値が [ベーシック認証トークン TTL（Basic Authentication Token TTL）] よりも大きい場合は、サロゲートタイムアウトの値が優先され、Web プロキシは、サロゲートタイムアウトの期限が切れた後に認証サーバーに連絡します。

その他の設定可能な認証設定項目は、Web プロキシが展開されているモード（透過モードまたは明示的な転送モード）に応じて異なります。

ステップ 4

Web プロキシが透過モードで展開されている場合は、以下の設定項目を編集します。

設定

説明

クレデンシャルの暗号化（Credential Encryption）

クライアントが暗号化 HTTPS 接続を介して Web プロキシにログインクレデンシャルを送信するかどうかを指定します。

この設定は基本認証方式と NTLMSPP 認証方式の両方に適用されますが、特に基本認証方式の場合に役立ちます。基本認証方式では、ユーザークレデンシャルがプレーンテキストで送信されるからです。

詳細については、認証の失敗を参照してください。

HTTPS リダイレクトポート（HTTPS Redirect Port）

HTTPS 接続を介してユーザー認証要求をリダイレクトする場合に使用する TCP ポートを指定します。

これによって、クライアントが HTTPS による Web プロキシへの接続を開始するポートが指定されます。これは、クレデンシャルの暗号化がイネーブルになっている場合や、アクセスコントロールの使用時にユーザーに認証を求める場合に発生します。

リダイレクトホスト名（Redirect Hostname）

Web プロキシが着信接続をリッスンするネットワークインターフェイスの短いホスト名を入力します。

透過モードで展開されているアプライアンスに認証を設定した場合、Web プロキシは、ユーザーの認証のためにクライアントに送信するリダイレクション URL でこのホスト名を使用します。

以下の値のいずれかを入力できます。

[1 語のホスト名（Single word hostname）]。クライアントと Secure Web Appliance が DNS 解決可能な 1 語のホスト名を入力できます。これにより、クライアントは、ブラウザ側を設定することなく、Internet Explorer で真のシングルサインオンを実現できます。必ず、クライアントと Secure Web Appliance が DNS 解決可能な 1 語のホスト名を入力してください。たとえば、クライアントがドメイン mycompany.com にあり、Web プロキシがリッスンしているインターフェイスの完全なホスト名が proxy.mycompany.com である場合は、このフィールドに「proxy」と入力する必要があります。クライアントはプロキシに対してルックアップを実行し、proxy.mycompany.com を解決できます。
[完全修飾ドメイン名（FQDN）（Fully qualified domain name (FQDN)）]。このフィールドに、FQDN または IP アドレスを入力することもできます。ただし、その場合、Internet Explorer や Firefox ブラウザで真のシングルサインオンを実現するには、入力する FQDN または IP アドレスが、クライアントブラウザのクライアント信頼済みサイトリストに追加されていることを確認する必要があります。デフォルト値は、プロキシトラフィックに使用されるインターフェイスに応じて、M1 または P1 インターフェイスの FQDN です。

クレデンシャルキャッシュオプション:（Credential Cache Options:）

サロゲートタイムアウト（Surrogate Timeout）

クライアントに認証クレデンシャルを再度要求するまでに、Web プロキシが待機する時間を指定します。クレデンシャルを再度要求するまで、Web プロキシはサロゲートに保存された値（IP アドレスまたは Cookie）を使用します。

一般的に、ブラウザなどのユーザーエージェントでは、ユーザーが毎回クレデンシャルを入力する必要がないように、認証クレデンシャルがキャッシュされます。

クレデンシャルキャッシュオプション:（Credential Cache Options:）

クライアント IP アイドルタイムアウト（Client IP Idle Timeout）

IP アドレスを認証サロゲートとして使用する場合は、この設定で、クライアントがアイドル状態のときに、認証クレデンシャルをクライアントに再要求するまで Web プロキシが待機する時間を指定します。

この値がサロゲートタイムアウト値よりも大きい場合、この設定には効力がなく、サロゲートタイムアウトに達した後にクライアントへの認証要求が行われます。

この設定を使用すると、コンピュータの前にいない時間が多いユーザーの脆弱性を低減できます。

ユーザーセッション制限（User Session Restrictions）

認証済みユーザーが複数の IP アドレスから同時にインターネットにアクセスすることを許可するかどうかを指定します。

ユーザーが未認証ユーザーと認証クレデンシャルを共有しないように、1 つのマシンへのアクセスを制限できます。ユーザーが別のマシンでログインできない場合は、エンドユーザー通知ページが表示されます。このページの [再認証（Re-authentication）] 設定を使用し、ユーザーがボタンをクリックして別のユーザー名でログインできるかどうかを指定することもできます。

この設定をイネーブルにする場合は、制限タイムアウト値を入力します。この値によって、別の IP アドレスでマシンにログインできるようになるまでのユーザーの待機時間を指定します。制限タイムアウト値は、サロゲートタイムアウト値よりも大きい値でなければなりません。

authcache CLI コマンドを使用して、認証キャッシュから特定のユーザーやすべてのユーザーを削除できます。

ヘッダーベースの認証（Header Based Authentication）

この設定により、Active Directory のヘッダーベース認証スキームを構成できます。

ヘッダーベース認証のキャッシュ設定：

認証キャッシュはデフォルトで有効になっています。
認証キャッシュのタイムアウトは、サロゲートタイムアウトと同じです。

キャッシュには、ユーザー名とユーザーグループが保存されます。

（注）

ユーザーグループ設定を更新する場合は、認証キャッシュをクリアします。

テキストエンコーディングとして ASCII を使用し、デフォルト設定の [バイナリのエンコーディングなし（No encoding for Binary）] を使用する [標準ヘッダー（Standard Header）] チェックボックスをオンにします。

着信グループヘッダーを考慮するために、[アクセスポリシーの照合に X-Authenticate-Groups ヘッダー/カスタムヘッダーのグループを使用する（Use Groups in X-Authenticate-Groups Header / Custom Header for match Access Policies）] チェックボックスをオンにします。カスタムヘッダー名を設定する場合は、[カスタムヘッダー名（Custom Header Name）] オプションを使用します。

（注）

[アクセスポリシーの照合に X-Authenticate-Groups ヘッダー/カスタムヘッダーのグループを使用する（Use Groups in X-Authenticate-Groups Header / Custom Header for match Access Policies）] チェックボックスをオンにして、X-Authenticated-Groups ヘッダーを入力しない場合は、アクセスポリシーの照合が失敗することがあります。有効になっていない場合は、Active Directory から取得されたグループがアクセスポリシーと照合されます。

出力でヘッダー（ユーザーおよびグループヘッダー）を保持するには、[出力に認証詳細を残す（Retain Authentication Details on Egress）] チェックボックスをオンにします。

詳細設定（Advanced）

クレデンシャルの暗号化またはアクセスコントロールを使用している場合は、アプライアンスがそれに付属しているデジタル証明書とキー（Cisco IronPort Web セキュリティアプライアンスデモ証明書）を使用するか、ここでアップロードするデジタル証明書を使用するかを選択できます。

ステップ 5

Web プロキシが明示的な転送モードで展開されている場合は、以下の設定項目を編集します。

設定

説明

クレデンシャルの暗号化（Credential Encryption）

クライアントが暗号化 HTTPS 接続を介して Web プロキシにログインクレデンシャルを送信するかどうかを指定します。クレデンシャルの暗号化をイネーブルにするには、[HTTPS リダイレクト（セキュアな）（HTTPS Redirect (Secure)）] を選択します。クレデンシャルの暗号化をイネーブルにすると、認証のためにクライアントを Web プロキシにリダイレクトする方法を設定する追加フィールドが表示されます。

詳細については、認証の失敗を参照してください。

HTTPS リダイレクトポート（HTTPS Redirect Port）

HTTPS 接続を介してユーザー認証要求をリダイレクトする場合に使用する TCP ポートを指定します。

リダイレクトホスト名（Redirect Hostname）

Web プロキシが着信接続をリッスンするネットワークインターフェイスの短縮形のホスト名を入力します。

上記の認証モードをイネーブルにすると、Web プロキシは、ユーザーの認証のためにクライアントに送信するリダイレクション URL でこのホスト名を使用します。

以下の値のいずれかを入力できます。

[1 語のホスト名（Single word hostname）]。クライアントと Secure Web Appliance が DNS 解決可能な 1 語のホスト名を入力できます。これにより、クライアントは、ブラウザ側を設定することなく、Internet Explorer で真のシングルサインオンを実現できます。必ず、クライアントと Secure Web Appliance が DNS 解決可能な 1 語のホスト名を入力してください。たとえば、クライアントがドメイン mycompany.com にあり、Web プロキシがリッスンしているインターフェイスの完全なホスト名が proxy.mycompany.com である場合は、このフィールドに「 proxy」と入力する必要があります。クライアントはプロキシに対してルックアップを実行し、proxy.mycompany.com を解決できます。
[完全修飾ドメイン名（FQDN）（Fully qualified domain name (FQDN)）]。このフィールドに、FQDN または IP アドレスを入力することもできます。ただし、その場合、Internet Explorer や Firefox ブラウザで真のシングルサインオンを実現するには、入力する FQDN または IP アドレスが、クライアントブラウザのクライアント信頼済みサイトリストに追加されていることを確認する必要があります。デフォルト値は、プロキシトラフィックに使用されるインターフェイスに応じて、M1 または P1 インターフェイスの FQDN です。

クレデンシャルキャッシュオプション:（Credential Cache Options:）

サロゲートタイムアウト（Surrogate Timeout）

クレデンシャルキャッシュオプション:（Credential Cache Options:）

クライアント IP アイドルタイムアウト（Client IP Idle Timeout）

この設定を使用すると、コンピュータの前にいない時間が多いユーザーの脆弱性を低減できます。

ユーザーセッション制限（User Session Restrictions）

認証済みユーザーが複数の IP アドレスから同時にインターネットにアクセスすることを許可するかどうかを指定します。

authcache CLI コマンドを使用して、認証キャッシュから特定のユーザーやすべてのユーザーを削除できます。

ヘッダーベースの認証（Header Based Authentication）

この設定により、Active Directory のヘッダーベース認証スキームを構成できます。

ヘッダーベース認証のキャッシュ設定：

認証キャッシュはデフォルトで有効になっています。
認証キャッシュのタイムアウトは、サロゲートタイムアウトと同じです。

キャッシュには、ユーザー名とユーザーグループが保存されます。

（注）

ユーザーグループ設定を更新する場合は、認証キャッシュをクリアします。

（注）

詳細設定（Advanced）

デジタル証明書とキーをアップロードするには、[参照（Browse）] をクリックして、ローカルマシン上の必要なファイルに移動します。次に、目的のファイルを選択してから、[ファイルのアップロード（Upload Files）] をクリックします。

ステップ 6

変更を送信し、保存します。

認証シーケンス

認証シーケンスについて
認証シーケンスの作成
認証シーケンスの編集および順序変更
認証シーケンスの削除

認証シーケンスについて

認証シーケンスを使用すると、さまざまな認証サーバーやプロトコルで 1 つの ID によってユーザーを認証できます。認証シーケンスは、プライマリ認証オプションを使用できなくなった場合にバックアップオプションを提供する上でも役立ちます。

認証シーケンスは複数の認証レルムの集合です。使用するレルムには、さまざまな認証サーバーや認証プロトコルを指定できます。認証レルムの詳細については、認証レルムを参照してください。

2 番目の認証レルムを作成すると、[ネットワーク（Network）] > [認証（Authentication）] に、[すべてのレルム（All Realms）] というデフォルトの認証シーケンスを含む [レルムシーケンス（Realm Sequences）] セクションが自動的に表示されます。[すべてのレルム（All Realms）] シーケンスには、ユーザーが定義した各レルムが自動的に含まれます。[すべてのレルム（All Realms）] シーケンス内のレルムの順序は変更できますが、[すべてのレルム（All Realms）] シーケンスを削除したり、そこからレルムを削除することはできません。

複数の NTLM 認証レルムを定義した場合、 Secure Web Applianceは、各シーケンスの 1 つの NTLM 認証レルムだけを NTLMSSP 認証方式で使用します。[すべてのレルム（All Realms）] シーケンスを含め、各シーケンス内から、NTLMSSP で使用する NTLM 認証レルムを選択できます。複数の NTLM レルムで NTLMSSP を使用するには、2 つの認証レルムに対して 1 つの識別プロファイルを設定し、1 つのアイデンティティがすべてのレルムに使用されるようにします。レルム間には相互信頼関係がある必要があります。

認証で使用されるシーケンス内の認証レルムは、以下によって決まります。

使用される認証方式。通常これは、クライアントに入力したクレデンシャルタイプで指定されます。
シーケンス内でのレルムの順序（1 つの NTLMSSP レルムだけを使用できるので、基本レルムのみ）。

ヒント

最適なパフォーマンスを得るには、1 つのレルムを使用して同じサブネット上のクライアントを認証します。

認証シーケンスの作成

始める前に

複数の認証レルムを作成します（認証レルムを参照）。
Secure Web Applianceがセキュリティ管理アプライアンスで管理されている場合は、異なる Secure Web Appliance上の同名の認証レルムのプロパティが、各アプライアンスで定義されているプロパティと同じであることを確認します。
AsyncOS では、レルムを使用して認証を処理する際に、リストの先頭のレルムから順番に使用されることに注意してください。

手順

ステップ 1	[ネットワーク（Network）] > [認証（Authentication）] を選択します。
ステップ 2	[シーケンスを追加（Add Sequence）] をクリックします。
ステップ 3	英数字とスペース文字を使用して、シーケンスの一意の名前を入力します。
ステップ 4	[基本スキームのレルムシーケンス（Realm Sequence for Basic Scheme）] 領域の最初の行で、シーケンスに含める最初の認証レルムを選択します。
ステップ 5	[基本スキームのレルムシーケンス（Realm Sequence for Basic Scheme）] 領域の 2 番目の行で、シーケンスに含める以下のレルムを選択します。
ステップ 6	（任意）基本クレデンシャルを使用する他のレルムを追加するには、[行の追加（Add Row）] をクリックします。
ステップ 7	NTLM レルムを定義したら、[NTLMSSP スキームのレルム（Realm for NTLMSSP Scheme）] フィールドで NTLM レルムを選択します。 Web プロキシは、クライアントが NTLMSSP 認証クレデンシャルを送信するときに、この NTLM レルムを使用します。
ステップ 8	変更を送信し、保存します。

認証シーケンスの編集および順序変更

手順

ステップ 1

[ネットワーク（Network）] > [認証（Authentication）] を選択します。

ステップ 2

編集または順序変更するシーケンスの名前をクリックします。

ステップ 3

レルムを配置するシーケンス内の位置番号に対応する行で、[レルム（Realms）] ドロップダウンリストからレルム名を選択します。

（注）

[すべてのレルム（All Realms）] シーケンスの場合は、レルムの順序のみを変更できます。レルム自体を変更することはできません。[すべてのレルム（All Realms）] シーケンス内のレルムの順序を変更するには、[順序（Order）] 列の矢印をクリックして、該当するレルムの位置を変更します。

ステップ 4

すべてのレルムをリストして順序付けするまで、必要に応じてステップ 3 を繰り返し、各レルム名が 1 つの行にのみ表示されていることを確認します。

ステップ 5

変更を送信し、保存します。

認証シーケンスの削除

始める前に

認証レルムを削除すると関連する ID がディセーブルになり、さらに、関連するポリシーからそれらの ID が削除されるので注意してください。

手順

ステップ 1	[ネットワーク（Network）] > [認証（Authentication）] を選択します。
ステップ 2	シーケンス名に対応するゴミ箱アイコンをクリックします。
ステップ 3	[削除（Delete）] をクリックして、シーケンスを削除することを確定します。
ステップ 4	変更を保存します。

認証の失敗

認証の失敗について
問題のあるユーザーエージェントの認証のバイパス
認証のバイパス
認証サービスが使用できない場合の未認証トラフィックの許可
認証失敗後のゲストアクセスの許可
認証の失敗：異なるクレデンシャルによる再認証の許可

認証の失敗について

以下の理由により認証に失敗したため、ユーザーが Web からブロックされることがあります。

クライアント/ユーザーエージェントの制限。一部のクライアントアプリケーションでは、認証が適切にサポートされないことがあります。認証を必要としない識別プロファイルを設定し、識別プロファイルの基準をそのクライアント（およびアクセスする必要がある URL（任意））に基づかせることで、これらのクライアントの認証をバイパスできます。
認証サービスを使用できない。ネットワークまたはサーバーの問題によって、認証サービスを使用できない場合があります。このような状況が生じた場合に未認証トラフィックを許可することを選択できます。
クレデンシャルが無効である。ユーザーによっては、適切な認証を得るための有効なクレデンシャルを提供できないことがあります（ビジターやクレデンシャルを待っているユーザーなど）。そのようなユーザーに制限付きの Web アクセスを許可するかどうかを選択できます。

問題のあるユーザーエージェントの認証のバイパス

一部のユーザーエージェントには、通常の動作に影響する認証問題があることが判明されています。

以下のユーザーエージェント経由で認証をバイパスする必要があります。

Windows Update エージェント
MICROSOFT_DEVICE_METADATA_RETRIEVAL_CLIENT
Microsoft BITS
SLSSoapClient
Akamai NetSession Interface
Microsoft CryptoAPI
NCSI
MSDW
Gnotify
msde
Google Update

（注）

トラフィックのフィルタリング（URL カテゴリに基づく）とスキャン（McAfee、Webroot）は、引き続き、アクセスポリシー設定に従い、アクセスポリシーによって実行されます。

手順

ステップ 1

指定したユーザーエージェントとの認証をバイパスするように識別プロファイルを設定します。

[Web セキュリティマネージャ（Web Security Manager）] > [識別プロファイル（Identification Profile）] を選択します。
[識別プロファイルの追加（Add Identification Profile）] をクリックします。

情報を入力します。


オプション	値
名前（Name）	ユーザーエージェントの AuthExempt 識別プロファイル。
上に挿入（Insert Above）	処理順序の最初のプロファイルに設定します。
サブネット別メンバの定義（Define Members by Subnet）	ブランクのままにします。
認証ごとにメンバを定義（Define Members by Authentication）	認証は不要です。

[詳細設定（Advanced）] > [ユーザーエージェント（User Agents）] をクリックします。
[選択なし（None Selected）] をクリックします。
[カスタムユーザーエージェント（Custom User Agents）] で、問題のあるユーザーエージェントの文字列を指定します。

ステップ 2

アクセスポリシーの設定

[Web セキュリティマネージャ（Web Security Manager）] > [アクセスポリシー（Access Policies）] を選択します。
[ポリシーを追加（Add Policy）] をクリックします。

情報を入力します。


オプション	値
ポリシー名	ユーザーエージェントの認証免除
上記ポリシーを挿入（Insert Above Policy）	処理順序の最初のポリシーに設定します。
識別プロファイルポリシー（Identification Profile Policy）	ユーザーエージェントの AuthExempt 識別プロファイル。
詳細設定（Advanced）	なし

ステップ 3

変更を送信し、保存します。

認証のバイパス


	手順	詳細情報
1	[詳細設定（Advanced）] プロパティを設定して、影響を受ける Web サイトを含むカスタム URL カテゴリを作成します。	カスタム URL カテゴリの作成および編集
2	以下の特性を持つ識別プロファイルを作成します。認証を必要とする ID が特に配置されている。カスタム URL カテゴリが含まれている。影響を受けるクライアントアプリケーションが含まれている。認証を必要としない。	ユーザーおよびクライアントソフトウェアの分類
3	識別プロファイルのポリシーを作成します。	ポリシーの作成

認証サービスが使用できない場合の未認証トラフィックの許可

（注）

この設定は、認証サービスを使用できない場合にのみ適用されます。恒久的に認証をバイパスするわけではありません。代替の方法については、認証の失敗についてを参照してください。

手順

ステップ 1	[ネットワーク（Network）] > [認証（Authentication）] を選択します。
ステップ 2	[グローバル設定を編集（Edit Global Settings）] をクリックします。
ステップ 3	[認証サーバーが利用できない場合のアクション（Action if Authentication Service Unavailable）] フィールドで、[認証なしでトラフィックの通過を許可（Permit traffic to proceed without authentication）] をクリックします。
ステップ 4	変更を送信し、保存します。

認証失敗後のゲストアクセスの許可

ゲストアクセスを許可するには、以下の手順を実行する必要があります。

ゲストアクセスをサポートする識別プロファイルの定義
ゲストアクセスをサポートしている識別プロファイルのポリシーでの使用
（任意）ゲストユーザーの詳細の記録方法の設定

（注）

識別プロファイルがゲストアクセスを許可しており、その識別プロファイルを使用しているユーザー定義のポリシーがない場合、認証に失敗したユーザーは適切なポリシータイプのグローバルポリシーと照合されます。たとえば、MyIdentificationProfile がゲストアクセスを許可し、MyIdentificationProfile を使用するユーザー定義のアクセスポリシーがない場合、認証に失敗したユーザーはグローバルアクセスポリシーに一致します。ゲストユーザーをグローバルポリシーと照合しない場合は、ゲストユーザーに適用してすべてのアクセスをブロックするポリシーグループを、グローバルポリシーよりも上に作成します。

ゲストアクセスをサポートする識別プロファイルの定義

手順

ステップ 1	[Web セキュリティマネージャ（Web Security Manager）] > [識別プロファイル（Identification Profiles）] を選択します。
ステップ 2	[識別プロファイルの追加（Add Identification Profile）] をクリックして新しい ID を追加するか、使用する既存の ID の名前をクリックします。
ステップ 3	[ゲスト権限をサポート（Support Guest Privileges）] チェックボックスをオンにします。
ステップ 4	変更を送信し、保存します。

ゲストアクセスをサポートしている識別プロファイルのポリシーでの使用

手順

ステップ 1

[Web セキュリティマネージャ（Web Security Manager）] メニューからポリシータイプを選択します。

ステップ 2

ポリシーテーブル内のポリシー名をクリックします。

ステップ 3

[識別プロファイルおよびユーザー（Identification Profiles And Users）] ドロップダウンリストから、[1 つ以上の識別プロファイルを選択（Select One Or More Identification Profiles）] を選択します（まだ選択していない場合）。

ステップ 4

[識別プロファイル（Identification Profile）] 列のドロップダウンリストから、ゲストアクセスをサポートしているプロファイルを選択します。

ステップ 5

[ゲスト（認証に失敗したユーザー）（Guests (Users Failing Authentication)）] オプションボタンをクリックします。

（注）

このオプションを使用できない場合は、選択したプロファイルがゲストアクセスをサポートするように設定されていないことを示しています。ステップ 4 に戻って別のものを選択するか、ゲストアクセスをサポートする識別プロファイルの定義を参照して、新しいポリシーを定義してください。

ステップ 6

変更を送信し、保存します。

ゲストユーザーの詳細の記録方法の設定

手順

ステップ 1

[ネットワーク（Network）] > [認証（Authentication）] を選択します。

ステップ 2

[グローバル設定を編集（Edit Global Settings）] をクリックします。

ステップ 3

[失敗した認証手続き（Failed Authentication Handling）] フィールドで、次に示す [ゲストユーザーのログ方法（Log Guest User By）] のオプションボタンをクリックします。


オプションボタン	説明
IPアドレス	ゲストユーザーのクライアント IP アドレスがアクセスログに記録されます。
エンドユーザーが入力したユーザー名（User Name As Entered By End-User）	最初に認証に失敗したユーザー名がアクセスログに記録されます。

ステップ 4

変更を送信し、保存します。

認証の失敗：異なるクレデンシャルによる再認証の許可

異なるクレデンシャルによる再認証の許可について
異なるクレデンシャルによる再認証の許可

異なるクレデンシャルによる再認証の許可について

前に使用したクレデンシャルが認証に失敗した場合に、ユーザーが別のクレデンシャルを使用して再認証を受けることを許可するには、再認証機能を使用します。ユーザーは正常に認証されますが、アクセスが許可されない限り、Web リソースにはアクセスできません。これは、認証は、検証したクレデンシャルをポリシーに渡すためにユーザーを識別するだけであり、リソースへのユーザーのアクセスを許可（または禁止）するのはポリシーだからです。

再認証を受けるには、ユーザーは正常に認証されている必要があります。

ユーザー定義のエンドユーザー通知ページで再認証機能を使用するには、リダイレクト URL を解析する CGI スクリプトで Reauth_URL パラメータを解析して使用する必要があります。

異なるクレデンシャルによる再認証の許可

手順

ステップ 1	[ネットワーク（Network）] > [認証（Authentication）] を選択します。
ステップ 2	[グローバル設定を編集（Edit Global Settings）] をクリックします。
ステップ 3	[URL カテゴリまたはユーザーセッションの制限によりエンドユーザーがブロックされた場合に再認証プロンプト（Re-Authentication Prompt If End User Blocked by URL Category or User Session Restriction）] チェックボックスをオンにします。
ステップ 4	[送信（Submit）] をクリックします。

識別済みユーザーの追跡

（注）

アプライアンスがクッキーベースの認証サロゲートを使用するように設定されている場合、アプライアンスは HTTP 要求を介した HTTPS および FTP のクライアントからクッキー情報を取得しません。このため、クッキーからユーザー名を取得できません。

明示的要求でサポートされる認証サロゲート


サロゲートタイプ	クレデンシャルの暗号化がディセーブルの場合			クレデンシャルの暗号化がイネーブルの場合
プロトコル：	HTTP	HTTPS および FTP over HTTP	ネイティブ FTP	HTTP	HTTPS および FTP over HTTP	ネイティブ FTP
サロゲートなし	対応	対応	対応	NA	NA	NA
IP ベース	対応	対応	対応	対応	対応	対応
Cookie ベース	対応	対応***	対応***	対応	非対応/対応**	対応***

透過的要求でサポートされる認証サロゲート

（注）

ユーザーおよびクライアントソフトウェアの分類の [認証サロゲート（Authentication Surrogates）] オプションの説明も参照してください。


サロゲートタイプ	クレデンシャルの暗号化がディセーブルの場合			クレデンシャルの暗号化がイネーブルの場合
プロトコル：	HTTP	HTTPS	ネイティブ FTP	HTTP	HTTPS	ネイティブ FTP
サロゲートなし	NA	NA	NA	NA	NA	NA
IP ベース	対応	非対応/対応*	非対応/対応*	対応	非対応/対応*	非対応/対応*
Cookie ベース	対応	非対応/対応**	非対応/対応**	対応	非対応/対応**	非対応/対応**

* クライアントが HTTP サイトに要求を送信し、認証された後に機能します。その前の動作は、トランザクションタイプによって異なります。

ネイティブ FTP トランザクション。トランザクションが認証をバイパスします。
HTTPS トランザクション。トランザクションがドロップされます。ただし、認証を目的とする最初の HTTPS 要求を復号化するように HTTPS プロキシを設定できます。

** Cookie ベースの認証を使用している場合、Web プロキシは、HTTPS、ネイティブ FTP、および FTP over HTTP の各トランザクションに対してユーザーを認証できません。この制限により、すべての HTTPS、ネイティブ FTP、FTP over HTTP の要求が認証をバイパスするため、認証は要求されません。

*** この場合は、Cookie ベースのサロゲートが設定されていても、サロゲートは使用されません。

再認証ユーザーの追跡

再認証の場合、より強力な権限を持つユーザーが認証を求め承認されると、Web プロキシは、設定されている認証サロゲートに応じた期間だけこのユーザーの ID をキャッシュします。

[セッション Cookie（Session cookie）]。特権ユーザーのアイデンティティが、ブラウザを閉じるか、セッションがタイムアウトになるまで使用されます。
[永続的な Cookie（Persistent cookie）]。特権ユーザーのアイデンティティが、サロゲートがタイムアウトするまで使用されます。
[IP アドレス（IP Address）]。特権ユーザーのアイデンティティが、サロゲートがタイムアウトするまで使用されます。
[サロゲートなし（No surrogate）]。デフォルトでは、Web プロキシは新しい接続ごとに認証を要求しますが、再認証がイネーブルの場合は新しい要求ごとに認証を要求します。そのため、NTLMSSP を使用すると認証サーバーの負荷が増大します。ただし、認証アクティビティの増加はユーザーにはわからない場合があります。ほとんどのブラウザでは、ブラウザが閉じられるまで特権ユーザーのクレデンシャルがキャッシュされ、再入力を求めることなく認証が行われるからです。また、Web プロキシが透過モードで展開され、[明示的転送要求に同じサロゲート設定を適用（Apply same surrogate settings to explicit forward requests）] オプションがイネーブルでない場合は、明示的な転送要求に認証サロゲートが使用されず、再認証により負荷が増加します。

（注）

Secure Web Applianceが認証サロゲートに Cookie を使用する場合は、クレデンシャルの暗号化をイネーブルにすることを推奨します。

資格情報

認証クレデンシャルは、ユーザーのブラウザまたは別のクライアントアプリケーションを介してユーザーに認証クレデンシャルの入力を求めることによってユーザーから取得されるか、または別のソースから透過的に取得されます。

セッション中のクレデンシャルの再利用の追跡
認証および承認の失敗
クレデンシャルの形式
基本認証のクレデンシャルの暗号化

セッション中のクレデンシャルの再利用の追跡

セッション中に 1 回ユーザーを認証した後、認証サロゲートを使用すると、新しい要求ごとにユーザーを認証するのでなく、そのセッション全体におけるクレデンシャルの再利用を追跡できます。認証サロゲートは、ユーザーのワークステーションの IP アドレスまたはセッションに割り当てられた Cookie に基づくことができます。

リダイレクトホスト名については、グローバル認証の設定、または CLI コマンド sethostname を参照してください。