第65章 ユーザと認証設定の管理
ユーザ管理
この章では、ローカル認証およびリモート認証を可能にする、ＳｏｎｉｃＷＡＬＬセキュリティ装置のユーザ管理機能について説明します。この章は、次のセクションから構成されています。
ユーザ管理の概要
詳細については、次の各セクションを参照してください。
ＳｏｎｉｃＷＡＬＬセキュリティ装置には、ユーザ レベルの認証メカニズムが用意されています。これにより、ユーザがインターネット上の離れた場所からＬＡＮにアクセスできるようにしたり、インターネットへのアクセスを試みるＬＡＮユーザに対して、コンテンツ フィルタ ポリシーを適用またはバイパスすることが可能になります。また、認証されたユーザだけに、ＶＰＮトンネルにアクセスし、暗号化された接続を通してデータを送信することを許可することもできます。ユーザが異なるゾーン （ＷＡＮ、ＶＰＮ、ＷＬＡＮなど） のネットワーク リソースにアクセスしようとすると、そのユーザは直ちにＳｏｎｉｃＷＡＬＬによって認証され、ネットワーク トラフィックはそこで初めてＳｏｎｉｃＷＡＬＬを通過することになります。ユーザがＬＡＮ上のコンピュータにログインしたとしても、ローカル タスクしか実行しなければ、ＳｏｎｉｃＷＡＬＬによる認証は行われません。ユーザ レベル認証は、ローカル ユーザ データベース、ＬＤＡＰ、ＲＡＤＩＵＳを使って実行できるほか、ローカル データベースにＬＤＡＰまたはＲＡＤＩＵＳを組み合わせて実行するることもできます。ＳｏｎｉｃＯＳは、さらに、シングル サイン オン （ＳＳＯ） 機能を備えています。ＳＳＯをＬＤＡＰと組み合わせて使用できます。ＳｏｎｉｃＷＡＬＬ上のローカル データベースは、最大で１,０００ユーザをサポートできます。ユーザ数が１,０００人を超える場合は、認証にＬＤＡＰまたはＲＡＤＩＵＳを使用する必要があります。
ローカル ユーザおよびローカル グループを使った認証
ＳｏｎｉｃＷＡＬＬセキュリティ装置は、ユーザやグループの情報を格納するためのローカル データベースを備えています。このローカル データベースを使ってユーザを認証したり、ネットワークへのアクセスを制御したりするようにＳｏｎｉｃＷＡＬＬを設定できます。この目的において、ネットワークにアクセスするユーザ数が比較的少ない場合は、ＬＤＡＰまたはＲＡＤＩＵＳではなく、ローカル データベースの使用をお勧めします。一度作成してしまえば管理はさほど難しくありませんが、多数のユーザやグループのエントリを作成するには時間がかかります。ユーザ数が多いネットワークでは、ＬＤＡＰサーバまたはＲＡＤＩＵＳサーバを使った認証の方が効率的です。
コンテンツ フィルタ サービス （ＣＦＳ） のポリシーをユーザに適用するには、そのユーザがローカル グループのメンバーであること、および、ＣＦＳポリシーがそのグループに適用されていることが必要です。ＣＦＳを使用する場合、ＬＤＡＰまたはＲＡＤＩＵＳを単独で使用することはできません。ＬＤＡＰまたはＲＡＤＩＵＳに、ローカル認証を組み合わせて使用する必要があります。ＣＦＳポリシーを使用するために認証方式を組み合わせる場合、ローカルのグループ名とＬＤＡＰまたはＲＡＤＩＵＳのグループ名とを完全に一致させる必要があります。「ＬＤＡＰ＋ローカル ユーザ」の認証方式を使用した場合、ＬＤＡＰサーバからＳｏｎｉｃＷＡＬＬ上のローカル データベースにグループをインポートできます。こうすることで、対応するグループを簡単に作成できます。対応するグループを作成すれば、ＣＦＳポリシーを適用できるようになります。
ローカル ユーザとグループ アカウントは、ＳｏｎｉｃＯＳのユーザ インターフェースから作成できます。ユーザを追加できるほか、任意のユーザの設定を編集することも可能です。例えば、次のような設定を編集できます。
･ グループ メンバーシップ － ユーザは１つまたは複数のローカル グループに所属できます。既定では、すべてのユーザがＥｖｅｒｙｏｎｅグループおよびＴｒｕｓｔｅｄ Ｕｓｅｒｓグループに所属します。ユーザからこれらのグループのメンバーシップを削除したり、他のグループのメンバーシップを追加したりできます。
･ ＶＰＮアクセス － このユーザによって開始されたＶＰＮクライアントがアクセス可能なネットワークを設定できます。ＶＰＮアクセスを設定する際は、ネットワークのリストから選択できます。ネットワークは、対応するアドレス グループまたはアドレス オブジェクトの名前で指定します。
補足 ユーザとグループに対するVPNアクセス設定は、ＧＶＣ、ＮｅｔＥｘｔｅｎｄｅｒおよびＳＳＬ ＶＰＮ仮想オフィス ブックマークを使ってネットワーク リソースにアクセスするリモート クライアントの能力に影響します。 ＧＶＣ、ＮｅｔＥｘｔｅｎｄｅｒ、または、仮想オフィスのユーザがネットワーク リソースへアクセスすることを許可するには、ネットワーク アドレス オブジェクトかグループを、「ＶＰＮアクセス」 タブの ”許可” リストに追加する必要があります。
ローカル グループを追加したり編集したりすることもできます。グループでは、次のような設定を編集できます。
･ グループ設定 － 管理者グループに対して、ログイン状況ポップアップ ウィンドウをアクティブにすることなく管理インターフェースへのログインを許可するよう、ＳｏｎｉｃＯＳを設定することができます。
･ グループ メンバー － グループのメンバーとして、ローカル ユーザまたは他のローカル グループを追加できます。
･ ＶＰＮアクセス － グループのＶＰＮアクセスは、ユーザのＶＰＮアクセスと同じ方法で設定できます。このグループのメンバーによって開始されたＶＰＮクライアントがアクセス可能なネットワークを設定できます。ＶＰＮアクセスを設定する際は、ネットワークのリストから選択できます。ネットワークは、対応するアドレス グループまたはアドレス オブジェクトの名前で指定します。
･ ＣＦＳポリシー － グループのメンバーに対して、コンテンツ フィルタ （ＣＦＳ） ポリシーを適用できます。ＣＦＳポリシー設定を利用するには、ＳｏｎｉｃＷＡＬＬでプレミアム コンテンツのフィルタ サービスを利用するためのライセンスが必要です。
ＲＡＤＩＵＳを使った認証
ＲＡＤＩＵＳ （Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ） は、ＳｏｎｉｃＷＡＬＬセキュリティ装置が、ネットワークへのアクセスを試みるユーザを認証するときに使用するプロトコルです。ＲＡＤＩＵＳサーバには、ユーザ情報を格納したデータベースが存在します。ＲＡＤＩＵＳサーバは、ＰＡＰ （パスワード認証プロトコル）、ＣＨＡＰ （チャレンジ ハンドシェーク認証プロトコル）、ＭＳＣＨＡＰ （Ｍｉｃｒｏｓｏｆｔ ＣＨＡＰ）、ＭＳＣＨＡＰｖ２などの認証スキームを使ってユーザの資格情報をチェックします。
ＲＡＤＩＵＳはＬＤＡＰとは大きく異なり、主として安全な認証機能を実現するものですが、ユーザ グループのメンバーシップを渡すのに使用できるさまざまな属性など、エントリごとに非常に多くの属性が用意されています。ＲＡＤＩＵＳでは、数千人規模のユーザ情報を格納できるため、ネットワーク アクセスを必要とするユーザ数が多い場合のユーザ認証として最適です。
ＬＤＡＰ／アクティブ ディレクトリ／イーディレクトリ認証
ＬＤＡＰ （Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ） は、例えばユーザ アカウント、ユーザ グループ、ホスト、サーバといったネットワーク上の要素についての情報を格納および管理するためのディレクトリ サービス構造を定義します。ユーザ アカウント、グループ、権限などを管理するためにＬＤＡＰを使用する標準はいくつか存在します。一部はＬＤＡＰによる管理が可能なマイクロソフト アクティブ ディレクトリのような独自システム、 一部はＬＤＡＰ標準の実装であるサンバのようなオープン規格です。また、ユーザ リポジトリ情報を管理するためのＬＤＡＰ ＡＰＩを提供するノベル イーディレクトリのような独自システムもあります。
ＳｏｎｉｃＯＳでは、ユーザ認証方式として、ＲＡＤＩＵＳとローカル ユーザ データベースに加えて、ＬＤＡＰもサポートしています。また、マイクロソフト アクティブ ディレクトリ （ＡＤ）、およびノベル イーディレクトリのディレクトリ サービスなど多数のスキーマや、あらゆるスキーマとのやりとりを許可する、完全に設定可能なユーザ定義のオプションもサポートしています。
マイクロソフト アクティブ ディレクトリは、ＳｏｎｉｃＷＡＬＬシングル サイン オンおよびＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントとも連携して動作します。詳細については、「シングル サイン オンの概要」 を参照してください。
ＳｏｎｉｃＯＳでサポートされるＬＤＡＰディレクトリ サービス
企業のネットワークで使用される最も一般的なディレクトリ サービスと統合するために、ＳｏｎｉｃＯＳでは、以下のＬＤＡＰスキーマとの統合をサポートしています。
･ マイクロソフト アクティブ ディレクトリ
･ ＲＦＣ２７９８ ＩｎｅｔＯｒｇＰｅｒｓｏｎ
･ ＲＦＣ２３０７ネットワーク インフォメーション サービス
･ サンバＳＭＢ
･ ノベル イーディレクトリ
･ ユーザ定義スキーマ
ＳｏｎｉｃＯＳは、以下のプロトコルが実行されるディレクトリ サービスのサポートを提供します。
･ ＬＤＡＰｖ２ （ＲＦＣ３４９４）
･ ＬＤＡＰｖ３ （ＲＦＣ２２５１～２２５６、ＲＦＣ３３７７）
･ ＬＤＡＰｖ３ ｏｖｅｒ ＴＬＳ （ＲＦＣ２８３０）
･ ＬＤＡＰｖ３ ｗｉｔｈ ＳＴＡＲＴＴＬＳ （ＲＦＣ２８３０）
･ ＬＤＡＰ Ｒｅｆｅｒｒａｌｓ （ＲＦＣ２２５１）
ＬＤＡＰ用語
ＬＤＡＰおよびその変種に関連して使用される用語を以下に示します。
･ スキーマ － スキーマは、ディレクトリに格納することができるデータのタイプやデータの格納方法を定義するルールのセットまたは構造です。データは、“エントリ”の形式で格納されます。
･ アクティブ ディレクトリ （ＡＤ） － マイクロソフトのディレクトリ サービスで、一般的にウィンドウズ ベースのネットワークで使用されます。マイクロソフト アクティブ ディレクトリはＬＤＡＰ互換です。
･ イーディレクトリ － ノベルのディレクトリサービスで、ノベル ネットウェア ベースのネットワークで使用されます。ノベル イーディレクトリは、管理用に使用できるＬＤＡＰゲートウェイを持っています。
･ エントリ － ＬＤＡＰディレクトリに格納されたデータ。エントリは、“属性”／値 （または名前／値） の組で格納されます （属性は“オブジェクト クラス”により定義されます）。例えば、“ｃｎ＝ｊｏｈｎ”の場合、“ｃｎ” （一般名） が属性、“ｊｏｈｎ”が値となります。
･ オブジェクト クラス － オブジェクト クラスは、ＬＤＡＰディレクトリに格納できるエントリのタイプを定義します。例えば、ＡＤで使用されるオブジェクト クラスとして、“ｕｓｅｒ”と“ｇｒｏｕｐ”があります。
･ オブジェクト － ＬＤＡＰ用語では、ディレクトリ内のエントリはオブジェクトと呼ばれます。ＬＤＡＰクライアントのＳｏｎｉｃＯＳ実装の目的上、重要なオブジェクトは、“ユーザ”オブジェクトと“グループ”オブジェクトです。ＬＤＡＰの実装の違いにより、これらのオブジェクト クラスは異なる名前で呼ばれます。例えば、アクティブ ディレクトリでは、ユーザ オブジェクトは“ｕｓｅｒ”、グループ オブジェクトは“ｇｒｏｕｐ”と呼ばれます。また、ＲＦＣ２７９８では、ユーザ オブジェクトは“ｉｎｅｔＯｒｇＰｅｒｓｏｎ”、グループ オブジェクトは“ｇｒｏｕｐＯｆＮａｍｅｓ”と呼ばれます。
･ 属性 － ＬＤＡＰディレクトリ内のオブジェクトに格納されたデータ アイテム。オブジェクトは、必須の属性、または、任意の属性を持つことができます。例えば、“ｄｃ”属性は、“ｄｃＯｂｊｅｃｔ” （ドメイン構成要素） オブジェクトの必須の属性です。
･ ｄｎ － “ｄｉｓｔｉｎｇｕｉｓｈｅｄ ｎａｍｅ （識別名）”。ユーザまたは他のオブジェクトの全体で一意な名前。複数の構成要素から成り、通常は、ｃｎ （ｃｏｍｍｏｎ ｎａｍｅ＝一般名） 構成要素で開始し、２つ以上のｄｃ （ｄｏｍａｉｎ ｃｏｍｐｏｎｅｎｔｓ＝ドメイン構成要素） として指定されたドメインで終了します。例えば、「ｃｎ＝ｊｏｈｎ，ｃｎ＝ｕｓｅｒｓ，ｄｃ＝ｄｏｍａｉｎ，ｄｃ＝ｃｏｍ」と表現されます。
･ ｃｎ － “ｃｏｍｍｏｎ ｎａｍｅ （一般名）”属性は、ＬＤＡＰでは多くのオブジェクト クラスの必須構成要素になっています。
･ ｏｕ － “ｏｒｇａｎｉｚａｔｉｏｎ ｕｎｉｔ （組織単位）”属性は、ほとんどのＬＤＡＰスキーマ実装の必須構成要素です。
･ ｄｃ － “ｄｏｍａｉｎ ｃｏｍｐｏｎｅｎｔ （ドメイン構成要素）”属性は、一般的に識別名のルートで見ることができます。また、多くの場合に必須の属性です。
･ ＴＬＳ － Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ （トランスポート層セキュリティ） は、ＳＳＬ （Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ） のＩＥＴＦで標準化されたバージョンです。ＴＬＳ １.０は、ＳＳＬ ３.０の後継規格です。
ＬＤＡＰスキーマの関連情報
･ マイクロソフト アクティブ ディレクトリ： スキーマ情報については、〈http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/active_directory_schema.asp〉 および 〈http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ldap/ldap/ldap_reference.asp〉 を参照してください。
･ ノベル イーディレクトリ： ＬＤＡＰ統合に関する情報については、〈http://www.novell.com/documentation/edir873/index.html?page=/documentation/edir873/edir873/data/h0000007.html〉 を参照してください。
･ ユーザ定義スキーマ： インストールされているＬＤＡＰシステムのドキュメントを参照してください。ＬＤＡＰに関する一般的な情報については、〈http://rfc.net/rfc1777.html〉 を参照してください。
ワンタイム パスワード
ワンタイム パスワード （ＯＴＰ） は、ユーザ名とパスワードによる標準の資格情報と共にシステム生成のランダムなパスワードも利用する２ファクタ認証方式です。 ユーザが正しい基本ログイン資格情報を提示すると、システムによってワンタイム パスワードが生成され、ユーザの定義済み電子メール アドレスに送信されます。 ユーザは電子メールからワンタイム パスワードを取り出して、それをログイン画面に入力する必要があります。
ワンタイム パスワードはどれも使い捨てです。 ユーザが有効なユーザ名とパスワードの入力に成功するたびに、そのアカウントの既存のワンタイム パスワードが削除されます。 未使用のワンタイム パスワードは、「ユーザ ＞ 設定 ＞ ユーザ セッション設定 」インターフェースで設定されたタイムアウト値に従って失効します。 管理者はローカル ユーザまたはローカル グループ ベースでワンタイム パスワードを有効にすることができます。 ローカル ユーザに関してワンタイム パスワードを設定するには、「ローカル ユーザの追加」 を参照してください。 ローカル グループに関してワンタイム パスワードを設定するには、「ローカル グループの作成」 を参照してください。
ワンタイム パスワードを使用するには、正しく設定されたＳＭＴＰサーバに装置がアクセスできなければなりません。 管理者に対してＯＴＰが有効になっている場合は、正しく設定されたＳＭＴＰサーバへのアクセスがないと、ＯＴＰを必要とするすべてのユーザがログインできるわけではありません。 その場合、管理者がコマンド ライン コンソールを通じてログインして、管理者自身のＯＴＰを無効にする必要があります。具体的には、シリアル コンソールで次のコマンドを入力します （ＳｏｎｉｃＷＡＬＬ ＮＳＡ ３５００装置を使用するものと仮定しています）。
シングル サイン オンの概要
このセクションでは、ＳｏｎｉｃＷＡＬＬ ＳｏｎｉｃＯＳのシングル サイン オン機能の概要を説明します。 このセクションは、次のサブセクションから構成されています。
シングル サイン オンとは
シングル サイン オン （ＳＳＯ） とは、ワークステーションに１回ドメイン ログインするだけで、あるいはウィンドウズ ターミナル サービスまたはＣｉｔｒｉｘサーバを通じて、複数のネットワーク リソースに特権的にアクセスできるようにする透過的なユーザ認証メカニズムです。 ＳｏｎｉｃＷＡＬＬセキュリティ装置は、ＳｏｎｉｃＷＡＬＬシングル サイン オン エージェント （ＳＳＯエージェント） とＳｏｎｉｃＷＡＬＬターミナル サービス エージェント （ＴＳＡ） を使用してＳＳＯ機能を提供し、ユーザのアクティビティを識別します。 ＳｏｎｉｃＷＡＬＬシングル サイン オン エージェント （ＳＳＯエージェント） は、ワークステーションのＩＰアドレスに基づいてユーザ アクティビティを識別します。 ＳｏｎｉｃＷＡＬＬ ＴＳＡは、サーバのＩＰアドレスとユーザ名とドメインの組み合わせによってユーザを識別します。
ＳｏｎｉｃＷＡＬＬ ＳＳＯはまた、ＭａｃおよびＳａｍｂａと共に使用しているＬｉｎｕｘユーザに対しても利用可能です。 さらに、ブラウザＮＴＬＭ認証により、ＳｏｎｉｃＷＡＬＬ ＳＳＯはＳｏｎｉｃＷＡＬＬ ＳＳＯやＳａｍｂａを必要とせずに、ＨＴＴＰトラフィックを送るユーザを認証することが可能です。
ＳｏｎｉｃＷＡＬＬ ＳＳＯの設定は、ＳｏｎｉｃＯＳ管理インターフェースの「ユーザ ＞ 設定」ページで行います。 ＳＳＯは、ログイン認証方式設定とは独立しており、両者を同時に使用してＶＰＮ／Ｌ２ＴＰクライアント ユーザまたは管理者ユーザの認証を行うことができます。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントおよびＴＳＡは、ＳｏｎｉｃＷＡＬＬ ＡＤコネクタおよびＮＤコネクタと互換性のあるプロトコルを使用し、ユーザがいつログアウトしたかを自動的に判別することで不正アクセスを防止します。 ＳｏｎｉｃＷＡＬＬセキュリティ装置は、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントまたはＴＳＡからのデータに基づき、ＬＤＡＰまたはローカル データベースに対してグループのメンバーシップを問い合わせます。 必要に応じて、メンバーシップをファイアウォール ポリシーと照合し、アクセス権を持つユーザを制御します。 また、コンテンツ フィルタおよびアプリケーション制御用のポリシーの選択に使用して、アクセスを許可する対象を制御することができます。 ＳＳＯ経由で認識したユーザ名は、トラフィックのログとユーザおよびアプリケーション フロー監視からのイベントに報告されます。
無動作タイムアウトはＳＳＯにも適用されますが、セッション時間の制限は適用されません。 ログアウトしたユーザから再びトラフィックが送信されると、そのユーザが自動的かつ透過的に再度ログインされます。
ドメインにログインせずに、ワークステーションまたはターミナル サービス／Ｃｉｔｒｉｘサーバに直接ログインしたユーザは、ブラウザＮＴＬＭ認証が有効でＨＴＴＰトラフィックを送信しない限り認証されません （必要に応じて、限定的なアクセスを認証することはできます）。 ＳｏｎｉｃＷＡＬＬ ＳＳＯで認証されていない場合、以降の認証には手動での装置へのログインが必要があるという内容のメッセージが画面に表示されます。
ユーザとして識別されたとしても、設定されているポリシー ルールに必要なグループ メンバーシップが不足している場合、アクセスが拒否されたことを示すページにリダイレクトされます。
ＳｏｎｉｃＷＡＬＬ ＳＳＯのメリット
ＳｏｎｉｃＷＡＬＬ ＳＳＯは、管理者によって設定されたグループ メンバーシップとポリシー照合に基づき、ユーザが１回のログインで複数のネットワーク リソースにアクセスできるようにする信頼性に優れた機能です。 何度もログインする手間が省けるため、時間の節約にもつながります。 エンド ユーザがＳｏｎｉｃＷＡＬＬ ＳＳＯの存在を意識する必要はなく、また、管理者に要求される設定も最小限で済みます。
ＳｏｎｉｃＷＡＬＬ ＳＳＯでは、ユーザがいつログインし、いつログアウトしたかが、ワークステーションＩＰアドレスのトラフィック （ターミナル サービスまたはＣｉｔｒｉｘの場合は、サーバＩＰアドレスの特定のユーザからのトラフィック） に基づいて自動的に判別されるため、セキュリティに優れ、手間もかかりません。 ＳＳＯ認証は、ＳｏｎｉｃＷＡＬＬ ＡＤコネクタ互換のプロトコルを使用することで、ワークステーションまたはターミナル サービス／ＣｉｔｒｉｘサーバのＩＰアドレスを持ったユーザのＩＤを返すことができるエージェントであれば、どのような外部エージェントとでも連携できるように設計されています。
ＳｏｎｉｃＷＡＬＬ ＳＳＯは、コンテンツ フィルタ サービス （ＣＦＳ）、ファイアウォール アクセス ルール、グループのメンバーシップと継承、セキュリティ サービス （アプリケーション制御、ＩＰＳ、ＧＡＶ、ＳＰＹ） の包含／除外リストを含め、ユーザ レベル認証が使用されるＳｏｎｉｃＷＡＬＬセキュリティ装置上のあらゆるサービスに使用できます。
ＳｏｎｉｃＷＡＬＬ ＳＳＯのその他のメリット
･ 使いやすい － ユーザは１回サインインするだけで複数のリソースに自動的にアクセスできます。
･ ユーザ エクスペリエンスの向上 － どのような種類のトラフィックを使用するユーザの場合でも、ウィンドウズ ドメインの資格情報を使用してユーザ認証が行われるため、ウェブ ブラウザを使って装置にログインする必要がありません。
･ 透過性 － ユーザが認証のためにユーザ名やパスワードを何度も再入力する必要がなくなります。
･ セキュアな通信 － 共有鍵暗号化によってデータ伝送を保護します。
･ ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントはＬＡＮ上の任意のウィンドウズ サーバにインストールでき、ＴＳＡは任意のターミナル サーバにインストールできます。
･ 複数のＳＳＯエージェント － 最大８つのエージェントをサポートして、大規模インストールに適した容量を提供します。
･ 複数のＴＳＡ － 複数のターミナル サービス エージェント （ターミナル サーバごとに１つ） をサポートします。 サポートされる数は４～２５６で、ＳｏｎｉｃＷＡＬＬ装置のモデルによって異なります。
･ ログイン メカニズムは、ＨＴＴＰだけでなくあらゆるプロトコルに対応しています。
･ ブラウザＮＴＬＭ認証 － ＳｏｎｉｃＷＡＬＬ ＳＳＯは、ＳＳＯエージェントを使わずにＨＴＴＰトラフィックを送信するユーザを認証できます。
･ ＭａｃおよびＬｉｎｕｘサポート － Ｓａｍｂａ ３.５以降で、ＳｏｎｉｃＷＡＬＬ ＳＳＯ はＭａｃおよびＬｉｎｕｘユーザに対してサポートされます。
･ ゾーン単位の執行 － ＳｏｎｉｃＷＡＬＬ ＳＳＯは、ファイアウォール アクセス ルールかセキュリティー サービス ポリシーによって自動的に開始されないときでも、どんなゾーンからのトラフィックに対しても開始できます。
プラットフォームおよびサポートされている標準
ＳｏｎｉｃＷＡＬＬ ＳＳＯは、ＳｏｎｉｃＯＳ５.０以降が動作しているＳｏｎｉｃＷＡＬＬ ＮＳＡシリーズ装置と、ＳｏｎｉｃＯＳ４.０以降が動作しているＳｏｎｉｃＷＡＬＬ ＰＲＯセキュリティ装置で利用できます。 ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントは、ＳｏｎｉｃＷＡＬＬ ＳＳＯをサポートしているＳｏｎｉｃＯＳの全バージョンと互換性があります。 ＳｏｎｉｃＷＡＬＬ ＴＳＡは、ＳｏｎｉｃＯＳ５.６以降が動作しているＳｏｎｉｃＷＡＬＬ ＮＳＡシリーズ装置およびＴＺ ２１０シリーズ装置でサポートされます。
ＳｏｎｉｃＷＡＬＬ ＳＳＯ機能は、ＬＤＡＰおよびローカル データベース プロトコルをサポートします。 ＳｏｎｉｃＷＡＬＬ ＳＳＯは、ＳｏｎｉｃＷＡＬＬディレクトリ コネクタをサポートしています。 ＳｏｎｉｃＷＡＬＬ ＳＳＯは、ＳｏｎｉｃＷＡＬＬ ＣＳＭを含むインストール内のＡＤコネクタとも相互に連携して動作させることができますが、ディレクトリ コネクタをお勧めします。 ＳｏｎｉｃＷＡＬＬ ＳＳＯの全機能を正しく動作させるには、ＳｏｎｉｃＯＳ５.５とディレクトリ コネクタ３.１.７以降を使用してください。
ＳｏｎｉｃＷＡＬＬ ＳＳＯをウィンドウズ ターミナル サービスまたはＣｉｔｒｉｘで使用するには、ＳｏｎｉｃＯＳ５.６以降が必要であり、ＳｏｎｉｃＷＡＬＬ ＴＳＡをサーバにインストールする必要があります。
ＳｏｎｉｃＷＡＬＬ ＳＳＯをブラウザＮＴＬＭ認証で使用するには、ＳｏｎｉｃＯＳ５.８以降が必要です。 ブラウザＮＴＬＭ認証に対しては、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントは不要です。
ノベル ユーザとの相互運用性を実現するため、ＳｏｎｉｃＯＳ５.５以降のＳｏｎｉｃＷＡＬＬ ＳＳＯは、ＳｏｎｉｃＷＡＬＬ ＮＤコネクタと互換性があります。 ＮＤコネクタはディレクトリ コネクタの一部としても利用できます。
ブラウザＮＴＬＭ認証のみを使うときを除いて、ＳｏｎｉｃＷＡＬＬ ＳＳＯを使用するには、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントがウィンドウズ ドメイン内のサーバ （そのサーバからクライアントに、そして装置からそのサーバに、直接またはＶＰＮパス経由で到達できなければならない） にインストールされているか、ＳｏｎｉｃＷＡＬＬ ＴＳＡがドメイン内のターミナル サーバにインストールされているか、あるいはその両方が必要です。
ＳｏｎｉｃＯＳ ＳＳＯ機能は、仮想マシン環境内で動作することが可能ですが、公式にはサポートされていません。これは、ＶＭ配備環境の潜在的なリソース消費の多様性により、有効な試験とすべての可能性のある組み合わせの確認が実行できないためです。
ＳＳＯエージェントを実行するには、次の要件が満たされている必要があります。
･ ＵＤＰポート２２５８ （既定） が開放されていること。 既定では、ファイアウォールとＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントとの通信にＵＤＰポート２２５８が使用されます。 ２２５８に代わって別のポートが設定されている場合は、そのポートにこの要件が適用されます。
･ ウィンドウズ サーバ （最新のサービス パック）
･ .ＮＥＴ Ｆｒａｍｅｗｏｒｋ ２.０
･ Ｎｅｔ ＡＰＩまたはＷＭＩ
補足 ＭａｃおよびＬｉｎｕｘのＰＣは、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントが使用するウィンドウズのネットワーク要求をサポートしていないので、ＳｏｎｉｃＷＡＬＬ ＳＳＯと動作するにはＳａｍｂａ ３.５以降が必要です。 Ｓａｍｂａ無しでもＭａｃおよびＬｉｎｕｘのユーザでもアクセスは可能ですが、それにはログインする必要があります。 認証を要求するようポリシー規則が設定されている場合は、ログイン プロンプトにリダイレクトされる可能性があります。 詳細については、「ＭａｃユーザおよびＬｉｎｕｘユーザへの対応」 を参照してください。
ＳｏｎｉｃＷＡＬＬ ＴＳＡを実行するには、次の要件が満たされている必要があります。
･ ＴＳＡがインストールされているすべてのターミナル サーバでＵＤＰポート２２５９ （既定） が開放されていること。 既定では、ファイアウォールとＳｏｎｉｃＷＡＬＬ ＴＳＡとの通信にＵＤＰポート２２５９が使用されます。 ２２５９に代わって別のポートが設定されている場合は、そのポートにこの要件が適用されます。
･ ウィンドウズ サーバ （最新のサービス パック）
･ ウィンドウズ ターミナル サービスまたはＣｉｔｒｉｘがウィンドウズ ターミナル サーバ システムにインストールされていること （Ｃｉｔｒｉｘ ＸｅｎＡｐｐ ５.０ サポート）。
シングル サイン オンの動作
エンド ユーザがＳｏｎｉｃＷＡＬＬ ＳＳＯの存在を意識する必要はなく、また、管理者に要求される設定も最小限で済みます。
ＳＳＯは、以下の状況で開始されます。
･ ユーザ認証を要求するファイアウォール アクセス ルールが、ＷＡＮゾーンから着信するのではないトラフィックに適用される場合。
･ アクセス ルール内でユーザ グループが指定されていないが、以下の状況のどれかが存在する場合に、ＳＳＯはゾーン上のすべてのトラフィック （補足 - これらの状況に影響されるトラフィックだけではありません） で開始されます。
･ ゾーン上でＣＦＳが有効で、ＣＦＳポリシーが設定されている
･ ゾーン上でＩＰＳが有効で、認証が必要なＩＰＳポリシーがある
･ ゾーン上でアンチスパイウェアが有効で、認証が必要なアンチスパイウェア ポリシーがある
･ 送信元ゾーンに対して、認証が必要なアプリケーション制御ポリシーが適用されている
･ ゾーンに対してＳＳＯのゾーン単位の執行が設定されている
ＳＳＯユーザ テーブルはまた、コンテンツ フィルタ、侵入防御、アンチスパイウェア、およびアプリケーション制御を含むセキュリティ サービスが必要とするユーザとグループの識別のために使用されます。
ＳＳＯエージェントを使用したＳｏｎｉｃＷＡＬＬ ＳＳＯ認証
個々のウィンドウズ ワークステーションのユーザについては、ＳＳＯワークステーション上のＳＳＯエージェントがＳｏｎｉｃＷＡＬＬ装置からの認証要求を処理します。 次の図に示してあるように、ＳＳＯエージェントを使用したＳｏｎｉｃＷＡＬＬ ＳＳＯ認証は６つのステップで行われます。
ＳｏｎｉｃＷＡＬＬ ＳＳＯの認証プロセスは、ユーザ トラフィックがＳｏｎｉｃＷＡＬＬセキュリティ装置を通過した時点 （ユーザがインターネットにアクセスしたときなど） で開始されます。 送信されたパケットは一時的に遮断され、ＳｏｎｉｃＷＡＬＬセキュリティ装置が、ＳＳＯエージェント （ＳＳＯワークステーション） を実行する認証エージェントに“ユーザ名”要求とワークステーションのＩＰアドレスを送信する間保存されます。
ＳＳＯエージェントを実行している認証エージェントは、ＳｏｎｉｃＷＡＬＬセキュリティ装置に対し、現在ワークステーションにログインしているユーザ名を提供します。 ＲＡＤＩＵＳやＬＤＡＰと同様、ユーザＩＰテーブルには、ログインしたユーザのエントリが作成されます。
ターミナル サービス エージェントを使用したＳｏｎｉｃＷＡＬＬ ＳＳＯ認証
ターミナル サービスまたはＣｉｔｒｉｘサーバからログインするユーザについては、認証プロセスでＳｏｎｉｃＷＡＬＬ ＴＳＡがＳＳＯエージェントの代わりをします。 このプロセスは以下の点が異なります。
･ ＴＳＡはユーザのログイン先のサーバで実行され、ＳｏｎｉｃＷＡＬＬ装置への初期通知にユーザ名とドメインとサーバＩＰアドレスを含めます。
･ ユーザはユーザ番号とＩＰアドレスによって識別されます （ただし、非ターミナル サービス ユーザの場合は、どのＩＰアドレスにもユーザが１つしか存在しないので、ユーザ番号は使用されません）。 ゼロ以外のユーザ番号は、ＳｏｎｉｃＯＳ管理インターフェースに「ｘ.ｘ.ｘ.ｘ ｕｓｅｒ ｎ」という形式で表示されます （ｘ.ｘ.ｘ.ｘはサーバＩＰアドレスで、ｎはユーザ番号です）。
･ ユーザがログアウトすると、ＴＳＡはＳｏｎｉｃＷＡＬＬ装置に通知を送信します。 したがって、ポーリングは行われません。
ユーザが識別されると、ＳｏｎｉｃＷＡＬＬセキュリティ装置がＬＤＡＰまたはローカル データベース （管理者の設定による） に対して問い合わせを行い、ユーザ グループのメンバーシップを検索して、そのメンバーシップとポリシーとを照合し、その結果に基づいて、ユーザにアクセスを許可または拒否します。 ログイン シーケンスが正常に完了した場合、保存されていたパケットが送信されます。 ログイン シーケンスが完了する前に、同じ送信元アドレスからパケットを受信した場合は、最新のパケットだけが保存されます。
ＳＳＯエージェントを実行する認証エージェントからは、ユーザ名が<ｄｏｍａｉｎ>／<ｕｓｅｒ-ｎａｍｅ>の形式で返されます。 ローカルで設定したユーザ グループについては、ＳＳＯエージェントを実行する認証エージェントから返されるユーザ名をフル ネームとするか （その場合は、ＳｏｎｉｃＷＡＬＬセキュリティ装置のローカル ユーザ データベース内の名前も一致するように設定する）、ドメイン要素を除去した簡易ユーザ名 （既定） とするかを選択できます。
ＬＤＡＰプロトコルの場合、ドメイン名と一致する“ｄｃ” （ドメイン構成要素） 属性を持った“ドメイン”クラスのオブジェクトを探すためのＬＤＡＰ検索を作成して、<ｄｏｍａｉｎ>／<ｕｓｅｒ-ｎａｍｅ>形式をＬＤＡＰ識別名に変換します。 目的のオブジェクトが見つかった場合、その識別名をディレクトリのサブツリーとして使用し、ユーザのオブジェクトを検索します。 例えば、ユーザ名が“ＳＶ／ｂｏｂ”として返された場合、“ｏｂｊｅｃｔＣｌａｓｓ＝ｄｏｍａｉｎ”および“ｄｃ＝ＳＶ”というオブジェクトが検索されます。 ここで、“ｄｃ＝ｓｖ,ｄｃ＝ｕｓ,ｄｃ＝ｓｏｎｉｃｗａｌｌ,ｄｃ＝ｃｏｍ”という識別名を持つオブジェクトが返された場合は、そのディレクトリ サブツリー下から、“ｏｂｊｅｃｔＣｌａｓｓ＝ｕｓｅｒ”および“ｓＡＭＡｃｃｏｕｎｔＮａｍｅ＝ｂｏｂ” （アクティブ ディレクトリの場合） というオブジェクトを探すための検索が作成されます。 ドメイン オブジェクトが見つからなかった場合は、ディレクトリ ツリーの最上位からユーザ オブジェクトが検索されます。
ドメイン オブジェクトが見つかると、同じオブジェクトを検索しなくても済むように、その情報が保存されます。 保存されたドメインからユーザを特定できなかった場合、保存されていたドメイン情報が削除され、目的のドメインが再度検索されます。
ＳＳＯエージェントを使用したＳｏｎｉｃＷＡＬＬ ＳＳＯでのユーザ ログアウトの処理は、ＴＳＡを使用したＳＳＯとは少し異なります。 ＳｏｎｉｃＷＡＬＬセキュリティ装置は、ＳＳＯエージェントを実行している認証エージェントをポーリングすることによって、ユーザがログアウトしたタイミングを判別します。 このポーリングの頻度は必要に応じて設定できます。 ユーザがログアウトすると、ＳＳＯエージェントを実行する認証エージェントからＳｏｎｉｃＷＡＬＬセキュリティ装置にＵｓｅｒ Ｌｏｇｇｅｄ Ｏｕｔ応答が送信され、ユーザが既にログアウトしていることが確認されて、ＳＳＯセッションが終了します。 ＴＳＡは、ＳｏｎｉｃＷＡＬＬ装置によるポーリングではなく、ＴＳＡ自体でターミナル サービス／Ｃｉｔｒｉｘサーバを監視することでログアウト イベントを調べ、ログアウト イベントが発生するとＳｏｎｉｃＷＡＬＬ装置に通知し、それによってＳＳＯセッションが終了します。 どちらのエージェントについても、無動作タイマーを設定できます。 ＳＳＯエージェントについては、ユーザ名要求ポーリング間隔を設定できます （ログアウトをすばやく検知するには、設定するポーリング時間を短くし、システムのオーバーヘッドを少なくするには、ポーリング時間を長くします）。
ブラウザＮＴＬＭ認証を使用したＳｏｎｉｃＷＡＬＬ ＳＳＯ認証
Mozilla ベースのブラウザ (インターネット エクスプローラ、Firefox、Chrome、Safari を含む) を使ってブラウズするユーザのために、SonicWALL 装置は NTLM （NT LAN Maanager） 認証を使った識別をサポートします。 NTLM は、“統合ウィンドウズ セキュリティ” として知られるブラウザ認証スイートで、すべての Mozilla ベースのブラウザでサポートされます。 これにより、SonicWALL 装置からブラウザに対して SSO エージェントの関与無しで直接認証要求ができます。 NTLM は、ユーザがウェブ上でリモートに認証されるような、ドメイン コントローラが利用できない場合にたびたび使用されます。
NTLM 認証は現在 HTTP に対して利用可能で、HTTPS では利用できません。
ブラウザ NTLM 認証は、SonicWALL SSO エージェントがユーザ情報の入手を試みる前または後に試行できます。 例えば、SonicWALL SSO エージェントを最初に試行してユーザの識別に失敗してから、トラフィックが HTTP の場合に NTLM が試行されます。
この方式を Linux または Mac クライアントでウィンドウズ クライアントと同じように使うために、SSO をNetAPI または WMI （SSO エージェントがどちらに対して設定されているかに応じて） のどちらかに対してクライアントを調査するように有効にできます。 これにより、SonicWALL 装置は、SSO エージェントにユーザ識別を要求する前に、NetAPI/WMI ポート上の応答を調査するようになります。 応答が無い場合は、これらの機器は即時に SSO を失敗します。 通常ウィンドウズ PC に対しては、調査は動作 （パーソナル ファイアウォールで遮断されない限り） して、SonicWALL SSO エージェントが使用されます。 Linux/Mac PC （Samba サーバが動作するように設定されていないと仮定） に対しては、調査は失敗して、SSO エージェントはバイパスされ、HTTP トラフィックが送信された際に NTLM 認証が使用されます。
NTLM は、ユーザが HTTP でブラウズするまではユーザを識別できないため、その前に送信されたどんなトラフィックも未確認として扱われます。 既定の CFS ポリシーが適用されて、ユーザ認証が必要などのルールもトラフィックを通過させません。
NTLM が SonicWALL SSO エージェントの前に使われるように設定されている場合は、もし最初に HTTP トラフィックを受信したならば、ユーザは NTLM で認証されます。 もし最初に非 HTTP トラフィックを受信したならば、SonicWALL SSO エージェントが認証に使われます。
NTLM ユーザ ログイン数は、SSO ログイン数と合わせられ、合計は常に装置モデルに対する最大 SSO ユーザ数 の制限を越えられません。 具体的な最大 SSO ユーザ数の値は、TSR 内に提供されます。 TSR に関する情報については、「ＴＳＲのシングル サイン オン統計の利用」セクション を参照してください。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントの動作
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントは、直接ＩＰアドレスを使って、または、ＶＰＮなどのパスを使ってクライアントおよびＳｏｎｉｃＷＡＬＬセキュリティ装置と通信できれば、ウィンドウズ ドメインに参加している任意のワークステーションにインストールできます。 ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントのインストール手順については、「ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントのインストール」セクション を参照してください。
数千ユーザから成る大規模インストールに対応するため、複数のＳＳＯエージェントがサポートされています。 最大８つのＳＳＯエージェントを設定して、それぞれをネットワーク内にある専用の高性能ＰＣ上で動作させることができます。 高速ＰＣ上にある１つのＳＳＯエージェントで、最大２５００ユーザをサポートできることに注意してください。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントは、クライアントおよびＳｏｎｉｃＷＡＬＬセキュリティ装置とのみ通信します。 ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントとＳｏｎｉｃＷＡＬＬセキュリティ装置との間で交わされるメッセージは、共有鍵を使って暗号化されます。
補足 共有鍵はＳＳＯエージェントで生成されます。 ＳＳＯの設定時、ＳｏｎｉｃＷＡＬＬセキュリティ装置に入力する鍵は、ＳＳＯエージェントによって生成された鍵と完全に一致している必要があります。
ＳｏｎｉｃＷＡＬＬセキュリティ装置は、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントに対し、既定のポート２２５８を使って問い合わせを行います。 次に、ＳＳＯエージェントがクライアントとＳｏｎｉｃＷＡＬＬセキュリティ装置の間に入って通信し、クライアントのユーザＩＤを調べます。 ＳｏｎｉｃＷＡＬＬセキュリティ装置は、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントを定期的に （管理者によって設定された頻度で） ポーリングして、絶えずユーザのログイン状況が確認されます。
ログ
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントは、管理者によって選択されたログ レベルに基づいて、ウィンドウズ イベント ログにログ イベント メッセージを送信します。
また、ＳｏｎｉｃＷＡＬＬセキュリティ装置も、そのイベント ログにＳＳＯエージェント固有のイベントを記録します。 ＳｏｎｉｃＷＡＬＬセキュリティ装置から送信されるＳＳＯエージェント固有のログ イベント メッセージとしては、次のようなものがあります。
･ ユーザ ログインが拒否されました － ポリシー規則で許可されていません － ユーザＩＤは確認されましたが、ポリシーによって許可されているいずれのユーザ グループにも属していないため、ユーザのトラフィックが遮断されました。
･ ユーザ ログインが拒否されました － ローカルには見つかりませんでした － ユーザがローカルに見つかりませんでした。 ＳｏｎｉｃＷＡＬＬセキュリティ装置では、「ローカルに登録されたユーザのみ許可する」が選択されています。
･ ユーザ ログインが拒否されました － ＳＳＯエージェントがタイムアウトしました － ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントへの接続を試みているときにタイムアウトが発生しました。
･ ユーザ ログインが拒否されました。 － ＳＳＯエージェントの設定エラー － このユーザのアクセスを許可するための適切な設定がＳＳＯエージェントに対してなされていません。
･ ユーザ ログインが拒否されました － ＳＳＯエージェントに通信上の問題があります － ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントを実行しているワークステーションとの通信に問題があります。
･ ユーザ ログインが拒否されました － ＳＳＯエージェントの名前解決に失敗しました － ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントがユーザ名を解決できません。
･ ＳＳＯエージェントから返されたユーザ名が長すぎます － ユーザ名が長すぎます。
･ ＳＳＯエージェントから返されたドメイン名が長すぎます － ドメイン名が長すぎます。
補足 ＳＳＯエージェントに固有のログ メッセージの備考フィールドには、次のようなテキストが表示されます。 <ｄｏｍａｉｎ／ｕｓｅｒ-ｎａｍｅ> （ＳＳＯエージェントにより認証）.
SonicWALL シングル サイン オンは、ドメイン コントローラのウィンドウズ セキュリティ ログ（WSL）を使用して、ログインしたユーザを識別できます。この機能は SonicWALL ディレクトリ サービス コネクタ3.4.51 に追加され、リリース ノートにディレクトリ サービス コネクタの設定に関する説明があります。以前の DSC リリースでは、ユーザ識別のためのユーザ ワークステーションとの通信に SSO エージェントが WMI または NetAPI を使うように設定できましたが、ドメイン コントローラ セキュリティ ログは利用できませんでした。
ドメイン管理者はドメイン コントローラにあるイベント ビューア機能を使用してログ オプションを設定可能です。ログイン情報を記録するように監査ポリシーを設定すると、ウィンドウズ セキュリティ ログが SSO に必要な情報を追跡するようになります。詳細情報については、下記の SonicWALL のウェブ ページからダウンロードできる『User Identification Using the Domain Controller Security Log』テックノートを参照してください。
ドメイン コントローラ セキュリティ ログはドメイン管理者アカウントを使用せずに利用可能な問い合わせの送信元オプションもあります。それでも、このオプションにはセキュリティ ログの読み取りアクセスが必要ですが、下記の SonicWALL のウェブ ページからダウンロードできる『Configuring a Non-Admin Domain Account for SSO Agent to Read Domain Security Logs』テックノートで説明されている方法を使うことにより、非管理者アカウントで実行できます。
ＳｏｎｉｃＷＡＬＬターミナル サービス エージェントの動作
ＳｏｎｉｃＷＡＬＬ ＴＳＡは、ターミナル サービスまたはＣｉｔｒｉｘがインストールされている任意のウィンドウズ サーバ マシンにインストールできます。 このサーバは、直接ＩＰアドレスを使用するかＶＰＮなどのパスを使用してＳｏｎｉｃＷＡＬＬセキュリティ装置と通信できるウィンドウズ ドメインに属していなければなりません。
ＳｏｎｉｃＷＡＬＬ ＴＳＡのインストール手順については、「ＳｏｎｉｃＷＡＬＬターミナル サービス エージェントのインストール」セクション を参照してください。
ＳｏｎｉｃＷＡＬＬ ＴＳＡについては、以下のセクションを参照してください。
複数のＴＳＡのサポート
数千のユーザから成る大規模インストールに対応するため、ＳｏｎｉｃＷＡＬＬネットワーク セキュリティ装置は、複数のターミナル サービス エージェント （ターミナル サーバごとに１つ） と共に動作するように設定できます。 サポートされるエージェントの数は、表 1に示すように、モデルによって異なります。
表 1ＳｏｎｉｃＷＡＬＬネットワーク セキュリティ装置のどのモデルでも、ターミナル サーバごとに最高３２個のＩＰアドレスがサポートされます。
ＴＳＡメッセージの暗号化とセッションＩＤの使用
ＳｏｎｉｃＷＡＬＬ ＴＳＡは、ＴＳＡとＳｏｎｉｃＷＡＬＬ装置との間でやり取りされるメッセージにユーザ名とドメインが含まれていると、そのメッセージの暗号化に共有鍵を使用します。 ユーザに対する最初のオープン通知は常に暗号化されます。 ＴＳＡがユーザ名とドメインを含めるからです。
補足 共有鍵はＴＳＡで作成され、ＳＳＯ設定時にＳｏｎｉｃＷＡＬＬ装置に入力される鍵とＴＳＡの鍵は完全に一致していなくてはなりません。
装置とＴＳエージェント（およびＳＳＯエージェント）の間のメッセージは、ＤＥＳ暗号化（３ＤＥＳを使用）されていて、ＤＥＳは１６進文字列で表現可能な数値鍵を使います。この鍵の各オクテットには、値を表現する２つの１６進数字が必要なので、この鍵は１６進数の偶数になる必要があります。
１６進数鍵を使うことは、暗号化強度に貢献します。 例えば、代わりにパスフレーズが使われていてから数値鍵に変換された場合、最終結果は直接数値鍵を使うことと違いがなくなり、そのパスフレーズは１６進表記の鍵よりも推測しやすかったはずです。
そして、私たちがここで ”保護”している情報は、実際はそれほど機密ではないことに注意します。 これはユーザ名とＴＣＰ／ＵＤＰ接続（ＴＳＡ）またはユーザ名とＩＰアドレス（ＳＳＯ）の間の単なるマッピングです。パスワードのような機密データは送信されません。
ＴＳＡはユーザ セッションＩＤをすべての通知に含めます。 ユーザ名とドメインを毎回含めることはしません。 これは効率的で安全であり、ＴＳＡが再起動後にターミナル サービス ユーザと再同期することを可能にします。
ローカル サブネットへの接続
ＴＳＡは装置から返された情報に基づいてネットワーク トポロジを動的に学習し、いったん学習すると、装置を通らないサブネット ユーザ接続に関して通知を装置に送信しません。 ＴＳＡがこれらのローカル送信先を“記憶から消し去る”メカニズムはないので、装置のインターフェース間でサブネットが移動された場合は、ＴＳＡを再起動する必要があります。
ターミナル サーバからの非ドメイン ユーザ トラフィック
ＳｏｎｉｃＷＡＬＬ装置には、必要に応じて非ドメイン ユーザ （ドメインではなく、ローカル マシンにログインしたユーザ） に限定的なアクセスを許可するための「非ドメイン ユーザには限定的なアクセスのみを許可」設定があります。 これはターミナル サービス ユーザに対して、他のＳＳＯユーザに対してと同様に作用します。
パーソナル ファイアウォールが動作しているウィンドウズ コンピュータや非ウィンドウズ機器がネットワークに含まれている場合は、「ユーザ監視対象」の横のチェックボックスを選択し、ＳＳＯエージェントに対する設定に応じて「ＮｅｔＡＰＩ」または「ＷＭＩ」のラジオ ボタンを選択します。 これにより、ＳｏｎｉｃＷＡＬＬ装置が、ＳＳＯエージェントに対してユーザを識別するように要求するのに先立って、ＮｅｔＡＰＩ／ＷＭＩポートで応答を監視するようになります。 応答がなければ、これらの機器は直ちにＳＳＯを中止します。 このような機器は、ＳＳＯエージェントがユーザの識別に使用するウィンドウズ ネットワーク メッセージに応答しませんし、遮断することもあります。
ターミナル サーバからの非ユーザ トラフィック
非ユーザ接続は、ウィンドウズの更新とアンチウィルスの更新のためにターミナル サーバから開かれます。 ＴＳＡはログイン サービスからの接続を非ユーザ接続であると認識することができ、装置への通知の中でこれを示します。
これらの非ユーザ接続の処理を制御するため、装置のＴＳＡ設定で「ターミナル サーバの非ユーザ トラフィックにはアクセス ルールでのユーザ認証を免除する」チェックボックスが用意されています。 このチェックボックスを選択すると、これらの接続が許可されます。 このチェックボックスを選択しないと、これらのサービスはローカル ユーザとして扱われます。その場合、「非ドメイン ユーザには限定的なアクセスのみを許可」設定を選択し、対応するサービス名を使用して装置上でユーザ アカウントを作成することにより、アクセスを許可することができます。
ブラウザＮＴＬＭ認証の動作
以下のセクションを参照してください。
ドメイン ユーザのＮＴＬＭ認証
ドメイン ユーザに対しては、NTLM 応答は MSCHAP メカニズムを介して RADIUS で認証されます。 装置でRADIUS を有効にする必要があります。
NTLM 認証を設定する際には、SSO 設定の 「ユーザ」 タブの以下の設定が適用されます。
･ ローカルに登録されたユーザのみ許可する
･ ローカル データベースでシンプルなユーザ名を使用する
･ ユーザ グループのメンバシップの設定方法 （LDAP または ローカル）
･ LDAP ユーザ名を複製してユーザ グループ メンバーシップをローカルで設定可能にする （ユーザ グループ メンバーシップの方式が LDAP の場合に LDAP 設定で設定）
･ ポーリング間隔
非ドメイン ユーザのＮＴＬＭ認証
NTLM を使うと、非ドメインユーザはドメインではなく PC にログインするユーザになることができ、または、ユーザ名とパスワードを要求されて、ドメインの資格情報ではない情報を入力するユーザになることができます。
ユーザ名が SonicWALL 装置上のローカル ユーザ アカウントと一致すると、NTLM 応答はそのアカウントのパスワードに対してローカルで確認されます。 成功した場合は、ユーザはログインしてアカウントに基づいた権限が与えられます。 ユーザ グループ メンバーシップは、LDAP からではなく、ローカル アカウントから設定され、そして （パスワードがローカルで確認されたため） Trusted Users グループのメンバーシップを含みます。
ユーザ名がローカル ユーザ アカウントと一致しないと、ユーザはログインされません。 NTLM を介して認証されたユーザに対しては、「非ドメイン ユーザには限定的なアクセスのみ許可する」 オプションは適用されません。
ブラウザでのＮＴＬＭ認証の資格情報
NTLM 認証では、ブラウザはドメインの資格情報も使う （ユーザがドメインにログインする場合） ため、完全なシングル サインオン機能を提供する、または、アクセスするウェブサイト （この場合は SonicWALL 装置） のユーザ名とパスワードを入力するようユーザに要求します。 ユーザがドメインにログインする場合は、種々の要因がドメインの資格情報を使うためのブラウザの機能に影響します。 これらの要因は、使用するブラウザの種別に依存します。
･ インターネット エクスプローラ 7 - インターネット エクスプローラは、ログインするウェブサイト （SonicWALL 装置） がローカル イントラネットの場合は、インターネット オプションのセキュリティ タブに応じて、ユーザのドメイン資格情報を使用して透過的に認証します。 これには、インターネット オプションのローカル イントラネット ゾーンのウェブサイトのリストに、SonicWALL 装置を追加する必要があります。
補足 ウィンドウズ 7 および Vista マシンは、インターネット エクスプローラを通したブラウザ NTLM 認証を用いた RADIUS 認証を使うために追加の設定が必要です。 「ウィンドウズ上で NTLMv2 セッション セキュリティを設定する」セクション を参照してください。
･ Google Chrome 7 - Chrome は、インターネット オプションのローカル イントラネット ゾーンのウェブサイトのリストに、SonicWALL 装置を追加することが必要であることを含めて、インターネット エクスプローラと同じように振舞います。
･ Firefox 3.6 - Firefox は、ログインするウェブサイト （SonicWALL 装置） が、設定 （Firefox の アドレス バーに about:config を入力することによりアクセスする） 内の network.automatic-ntlm-auth.trusted-uris エントリにリストされている場合は、ユーザのドメイン資格情報を使用して透過的に認証します。
･ Safari 3.6 - Safari は NTLM をサポートしていますが、現状ユーザのドメイン資格情報を使った完全な透過的ログオンはサポートしていません。
･ 非 PC プラットフォーム上のブラウザ - Linux や Mac といった、非 PC プラットフォームは、Samba を通してウィンドウズ ドメイン内のリソースにアクセスできますが、ウィンドウズ PC が行うような、”PC がドメイン内にログインする” 概念がありません。 ゆえに、これらのプラットフォーム上のブラウザは、ユーザのドメイン資格情報へのアクセスを持たず、それらを NTLM のために使えません。
ユーザがドメインにログインしていない、または、ブラウザがユーザのドメイン資格情報を使えない場合は、名前とパスワードを入力するように求められるか、事前にユーザが保存するように設定している場合は、キャッシュされた資格情報が使われます。
すべてのケースで、万一ユーザのドメイン資格情報の使用時に認証が失敗した場合は （ユーザがアクセスを得るために必要な権限を持たないために可能性がある） 、ブラウザはユーザに名前とパスワードの入力を求めます。 これにより、ユーザはドメイン資格情報とは別の資格情報を入力してアクセスを得ることが可能になります。
複数管理者サポートの概要
このセクションでは、複数管理者サポート機能の概要を説明します。このセクションは次のサブセクションから構成されています。
複数管理者サポートとは
これまでのバージョンのＳｏｎｉｃＯＳ は、完全な管理者権限でＳｏｎｉｃＷＡＬＬセキュリティ装置にログオンできる管理者は１人だけでした。他のユーザに“Ｌｉｍｉｔｅｄ Ａｄｍｉｎｉｓｔｒａｔｏｒｓ （制限付き管理者）”のアクセス権を付与することはできますが、ＳｏｎｉｃＯＳ ＧＵＩのあらゆる領域を変更できる完全なアクセス権を複数の管理者が同時に持つことはできません。
ＳｏｎｉｃＯＳリリース４.０以降では、複数管理者の同時アクセスがサポートされています。この機能により、複数のユーザが完全な管理者権限でログインできるようになりました。既定のａｄｍｉｎユーザ名に加え、他の管理者ユーザ名を作成できます。
複数の管理者が同時に設定を変更することによって競合が生じる可能性もあるため、設定の変更は１人の管理者にのみ許可されています。その他の管理者にはＧＵＩに対する完全なアクセス権が付与されますが、設定を変更することはできません。
メリット
複数管理者サポートには、次のようなメリットがあります。
･ 生産性の向上 － ＳｏｎｉｃＷＡＬＬセキュリティ装置に対して複数の管理者が同時にアクセスできるため、装置に対して２人の管理者が同時にアクセスした場合に一方の管理者が自動的にシステムからログアウトされる“自動ログアウト”が不要になります。
･ 設定に伴うリスクの削減 － 新たに読み取り専用モードが追加されたため、意図しない設定変更を誤って実行してしまうリスクなしに、ＳｏｎｉｃＷＡＬＬセキュリティ装置の現在の設定と状況を確認することができます。
複数管理者サポートの動作
以下のセクションでは、複数管理者サポート機能の動作について説明します。
設定モード
複数の管理者による同時アクセスを実現しながらも、設定変更の競合を防ぐために、次の設定モードが定義されています。
･ 設定モード － 管理者に設定を編集するための完全な権限が割り当てられます。装置にログインしている管理者がいない場合、完全な管理者権限および制限付き管理者権限を持った （読み取り専用管理者以外の） 管理者には自動的に設定モードが適用されます。
補足 完全な設定権限を持つ管理者は、コマンド ライン インターフェース （ＣＬＩ） を使ってログインすることもできます。
･ 読み取り専用モード － 管理者は設定に変更を加えることは一切できませんが、管理ＵＩ全体を閲覧したり、監視操作を実行したりすることができます。
･ 非設定モード － 管理者は、読み取り専用グループと同じ情報を閲覧できるほか、設定の競合を引き起こすおそれのない管理操作を実行できます。
次の表は、各種の設定モードで利用できるアクセス権をまとめたものです。なお、この表には制限付き管理者のアクセス権も記載されていますが、制限付き管理者が利用できる機能の一部が含まれていません。
ユーザ グループ
複数管理者サポート機能により、次の２つの既定ユーザ グループが追加されました。
･ ＳｏｎｉｃＷＡＬＬ Ａｄｍｉｎｉｓｔｒａｔｏｒｓ － このグループのメンバーには、設定を編集するための完全な管理者アクセス権が付与されます。
･ ＳｏｎｉｃＷＡＬＬ Ｒｅａｄ-Ｏｎｌｙ Ａｄｍｉｎｓ － このグループのメンバーには、完全な管理インターフェースを閲覧できる読み取り専用アクセス権が付与されます。設定を編集したり、完全な設定モードに切り替えることはできません。
これらの複数のユーザ グループにユーザを追加することはお勧めできません。ただし、そのようにした場合は、次の動作が適用されます。
･ ＳｏｎｉｃＷＡＬＬ Ａｄｍｉｎｉｓｔｒａｔｏｒｓユーザ グループのメンバーをＬｉｍｉｔｅｄ Ａｄｍｉｎｉｓｔｒａｔｏｒｓユーザ グループまたはＳｏｎｉｃＷＡＬＬ Ｒｅａｄ-Ｏｎｌｙ Ａｄｍｉｎｓユーザ グループにも追加した場合、メンバーには完全な管理者権限が付与されます。
･ Ｌｉｍｉｔｅｄ Ａｄｍｉｎｉｓｔｒａｔｏｒｓユーザ グループのメンバーをＳｏｎｉｃＷＡＬＬ Ｒｅａｄ-Ｏｎｌｙ Ａｄｍｉｎｓユーザ グループに追加した場合、メンバーには制限付き管理者権限が付与されます。
管理者の先制時に適用される優先順位
既に装置にログインしている管理者を先制する場合、各種の管理者区分には、次の規則に従って優先順位が適用されます。
1.ＧＭＳと複数管理者サポート
ＳｏｎｉｃＷＡＬＬ ＧＭＳを使用してＳｏｎｉｃＷＡＬＬセキュリティ装置を管理している場合、ＧＭＳは各種のアクティビティ （ＧＭＳ管理のＩＰＳｅｃトンネルが正しく作成されたかどうかを確認するなど） を行う関係上、装置にログインする機会が多くなります。ＧＭＳはローカル管理者を先制できるため、このようにＧＭＳが頻繁にログインすることで、装置のローカル管理が困難になる場合があります。
「ユーザ ＞ 状況」での状況の表示
「ユーザ ＞ 状況」ページには、ＳｏｎｉｃＷＡＬＬ上の「現在のユーザ」の一覧が表示されます。このテーブルには、「ユーザ名」、「ＩＰアドレス」、「セッション時間」、「残り時間」、「残り無動作時間」、「設定」、および「ログアウト」が表示されます。ユーザをログアウトさせるには、目的のユーザ エントリの削除アイコン 
を選択します。
以下のセクションでは、このページの設定手順について説明します。
･ 「規約の承諾」
ユーザ ログイン設定
「ログインの認証方法」ドロップダウン リストから、ネットワークで使用するユーザ アカウント管理の種別を選択します。
･ 「ユーザ ＞ ローカル ユーザ」、「ユーザ ＞ ローカル グループ」ページを使用してＳｏｎｉｃＷＡＬＬ装置のローカル データベース内のユーザを設定するには、「ローカル ユーザ」を選択します。
･ ユーザ数が１,０００人を超える場合、またはＳｏｎｉｃＷＡＬＬのユーザ認証にさらなるセキュリティを付加したい場合は、「ＲＡＤＩＵＳ」を選択します。ＲＡＤＩＵＳを選択した場合、ユーザはＳｏｎｉｃＷＡＬＬに送るパスワードを暗号化するためにＨＴＴＰＳを使用してＳｏｎｉｃＷＡＬＬにログインする必要があります。ユーザがＨＴＴＰを使用してＳｏｎｉｃＷＡＬＬへのログインを試みた場合、ブラウザは自動的にＨＴＴＰＳにリダイレクトされます。
･ 認証にＲＡＤＩＵＳとＳｏｎｉｃＷＡＬＬローカル ユーザ データベースの両方を使用する場合は、「ＲＡＤＩＵＳ＋ローカル ユーザ」を選択します。
･ Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ （ＬＤＡＰ） サーバ、マイクロソフト アクティブ ディレクトリ （ＡＤ） サーバ、またはノベル イーディレクトリを使用してアカウント データを管理する場合は、「ＬＤＡＰ」を選択します。
･ 認証にＬＤＡＰとＳｏｎｉｃＷＡＬＬローカル ユーザ データベースの両方を使用する場合は、「ＬＤＡＰ＋ローカル ユーザ」を選択します。
「シングル サイン オン方法」ドロップダウン リストで、以下から１つを選択します。
･ 認証にアクティブ ディレクトリを使用している場合で、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントが同じドメイン内のコンピュータにインストールされている場合は、「ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント」を選択します。
･ ターミナル サービスを使用していて、ＳｏｎｉｃＷＡＬＬターミナル サービス エージェント （ＴＳＡ） が同じドメイン内のターミナル サーバにインストールされている場合は、「ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント」を選択します。
･ ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントまたはＴＳＡを使わずにウェブ ユーザを認証したい場合は、「ブラウザＮＴＬＭ認証のみ」 を選択します。 ユーザはＨＴＴＰトラフィックを送信すると即時に識別されます。 ＮＴＬＭはＭＳＣＨＡＰ認証にアクセスするためにＲＡＤＩＵＳ （ＬＤＡＰを使う場合はＬＤＡＰ） が設定されている必要があります。 上でＬＤＡＰが選択されている場合は、ＮＴＬＭを選択した際にＲＡＤＩＵＳのための独立した「設定」 ボタンが現れます。
･ ＳＳＯを使わない場合は、「なし」を選択します。
ＳＳＯの詳細な設定手順については、「シングル サイン オンの設定」 を参照してください。
ブラウザＮＴＬＭ認証の詳細な設定手順については、「ブラウザＮＴＬＭ認証のためのＳｏｎｉｃＷＡＬＬセキュリティ装置の設定」 を参照してください。
「認証ページの表示時間 （分）」フィールドには、ユーザがログインしなければならない制限時間、つまりログイン ページがタイム アウトするまでの分数を入力します。ログイン ページがタイム アウトすると、再度ログインを試みる前に選択するよう促すメッセージが表示されます。
ユーザ アカウント名を照合する際に大文字と小文字を区別する場合は、「ユーザ名の大文字と小文字を区別する」を選択します。
複数の場所から同じユーザ名でネットワークにログインできないようにするには、「ログインの一意性を強制する」を選択します。この設定は、ローカル ユーザとＲＡＤＩＵＳ／ＬＤＡＰユーザの両方に適用されます。ただし、多重ログインを禁止する設定は、ユーザ名がａｄｍｉｎの既定の管理者には適用されません。
ユーザがＨＴＴＰＳでログインした後のＳｏｎｉｃＷＡＬＬ装置経由のネットワーク接続にＨＴＴＰを使用したい場合には、「ログイン完了時にユーザをＨＴＴＰＳからＨＴＴＰにリダイレクトする」を選択します。ＨＴＴＰＳはＨＴＴＰよりも多くのシステム リソースを消費するので、ＨＴＴＰＳでのログイン ユーザ数が多い場合には、ＨＴＴＰへのリダイレクトを使用したほうがよいでしょう。このオプションを非選択にした場合、警告ダイアログが表示されます。
ＲＡＤＩＵＳユーザがＨＴＴＰでログインする際にＣＨＡＰチャレンジを発行する場合は、「ＲＡＤＩＵＳ ＣＨＡＰモードでのログインを許可する」を選択します。これは、ＨＴＴＰＳを使わずに保護された接続を可能にして、ブラウザがＨＴＴＰ上で平文テキストのパスワードを送信することを防ぎます。ＲＡＤＩＵＳサーバがこのオプションをサポートしていることを確認してください。
補足 この方式を使ってログインする管理者は、実行可能な管理操作が制限されます （いくつかの操作では、装置が管理者パスワードを知る必要があるためで、この認証方式では対応できません）。
ワンタイム パスワード認証を使う場合は、環境に応じて 「ワンタイム パスワードの電子メール形式」 に、「プレーン テキスト」 か 「ＨＴＭＬ」 のどちらかを選択します。
ユーザ セッション設定
以下の設定は、ＳｏｎｉｃＷＡＬＬを使用して認証されたすべてのユーザに適用されます。
･ 無動作時タイムアウト （分）： 事前設定された無動作時間が経過した時点で、ユーザをＳｏｎｉｃＷＡＬＬからログアウトさせることができます。このフィールドに時間を分単位で入力します。既定値は5分です。
･ ウェブ接続のログイン セッション時間の制限を有効にする： チェック ボックスを選択し、「ログイン セッション時間の制限 （分）」フィールドに時間を分単位で入力することにより、ユーザがＳｏｎｉｃＷＡＬＬにログインできる時間の長さを制限できます。既定値は３０分です。
･ ユーザ ログイン状況ウィンドウを表示する： ユーザ セッションが継続している間、「ログアウト」ボタンのある状況ウィンドウを表示します。ユーザは、「ログアウト」ボタンを選択することにより、セッションからログアウトすることができます。
･ ユーザ ログイン状況ウィンドウが、ハートビートを送信する間隔 （秒）： ユーザが有効な接続を保持しているかどうかを確認するために使用されるハートビート信号の周期を設定します。
･ 切断されたユーザの検出を有効にする： 接続が有効でなくなったユーザを検出すると、ＳｏｎｉｃＷＡＬＬはそのセッションを終了させます。
･ ユーザ ログイン状況ウィンドウから、次の時間ハートビートがなかった場合に切断とみなす （分）： ハートビートからの応答がなかった場合に、ユーザ セッションを終了するまでの時間を設定します。
その他のグローバル ユーザ設定
ワイルドカード一致は、接頭辞 '*.' かつ/または 接尾辞 '...' を使います （例: *.windowsupdate.com...）。
どのホスト上のファイルへのアクセスも許可するには、接頭辞 '*/' を使います （例: */wpad.dat）。
ユーザ認証をバイパスさせる URL の自動設定
自動設定ユーティリティを使って、単一の特定の IP アドレスからのトラフィックを認証をバイパスして一時的に許可できます。 トラフィックがアクセスする宛先は記録され、トラフィックがユーザ認証をバイパスすることを許可するために使われます。通常これはアンチウィルスの更新やウィンドウズ アップデートのようなトラフィックを許可するために使われます。 URL バイパス リストを自動設定するには、以下の手順に従います。
ヒント ウィンドウズ アップデートはいくつかの宛先に HTTPS でアクセスし、それらは IP アドレスのみで追跡可能です。 しかしながら、各回でアクセスされた実際の IP アドレスは変化することがあり、そのため、そのような IP アドレスそれぞれに対してバイパスの設定を試みるのではなく、「ネットワークに変換する」 オプションを使って、対象ネットワーク内のすべての IP アドレスへの HTTPS に対してバイパスを許可する設定をするほうが良いでしょう。
ヒント アクセスされる宛先が変化する場合は、アップデートを複数回実行すると良いでしょう。
規約の承諾
規約承諾 （ＡＵＰ） は、ネットワークやインターネットにアクセスするためにユーザが従う必要のあるポリシーです。多くの企業や教育施設では、社員や学生がＳｏｎｉｃＷＡＬＬを使用してネットワークやインターネットにアクセスする前に、規約の承諾に同意するよう求めるのが一般的です。
「規約の承諾」セクションでは、ユーザに表示されるＡＵＰメッセージ ウィンドウを作成できます。メッセージの本文にはＨＴＭＬフォーマットを使用できます。「サンプル テンプレート」ボタンを選択すると、ＡＵＰウィンドウ用に書式設定済みのＨＴＭＬテンプレートが挿入されます。
･ 規約の承諾を要求する － ユーザがログインしたときに規約承諾画面を表示するネットワーク インターフェースを選択します。「保護ゾーン」、「ＷＡＮゾーン」、「公開ゾーン」、「無線ゾーン」、および「ＶＰＮゾーン」から任意の組み合わせを選択できます。
･ ウィンドウ サイズ （ピクセル） － ＡＵＰウィンドウのサイズをピクセル単位で指定できます。「ウィンドウでスクロール バーを有効にする」を選択すると、ＡＵＰウィンドウの内容をスクロールできるようになります。
･ ウィンドウでスクロール バーを有効にする － ウィンドウの表示サイズに内容が収まりきらない場合、スクロール バーが表示されます。
「画面の確認」ボタンを選択すると、作成したＡＵＰメッセージがどのようにユーザに表示されるかを確認できます。
ログイン ページのカスタマイズ
SonicOS は、ユーザに表示されるログイン認証ページのテキストをカスタマイズする機能を提供するようになりました。 管理者は自身の表現でログイン関連ページを編集して、変更を適用して再起動することなく反映できます。
SonicOS インターフェース全体は異なる言語で利用可能ですが、管理者はユーザ インターフェース全体の言語を特定の地域の言語に変更したくない場合があります。
しかしながら、ユーザが他のネットワークにアクセス可能になる、または外部アクセス サービス (例：VPN、SSL-VPN) を有効にする前に、ファイアウォールが認証を要求する場合に、それらのログイン関連ページを一般ユーザがより使いやすいようにローカライズすることができます。
ユーザ定義可能なログイン ページの機能は、下記の機能性を提供します。
･ 既定ではオリジナル ログインのスタイルを保持する
･ 管理者はログイン関連ページをカスタマイズできる
･ 管理者は既定のログイン ページをテンプレートとして使用できる
･ 管理者はシステム プリファレンス内にカスタマイズしたページを保存できる
･ 管理者は変更をプリファレンスに保存する前にプレビューできる
･ 一般ユーザにカスタマイズしたログイン関連ページを公開する
以下のログイン関連ページがカスタマイズできます。
･ 管理の先制
･ ログイン認証
･ ログアウト
･ ログイン数超過
･ ログイン拒否
･ ログイン ロックアウト
･ ログイン状況
･ ゲスト ログイン状況
･ ポリシー アクセス ブロック
･ ポリシー アクセス ダウン
･ ポリシー アクセス利用不可
･ ポリシー ログイン リダイレクト
･ ポリシー シングル サイン オン監視失敗
･ ユーザ パスワード更新
･ ユーザ ログイン メッセージ
これらのページの 1 つをカスタマイズするには、以下の手順に従います。
1. 「補足 テンプレート ページ内の “var strXXX =” の行は、カスタマイズされた JavaScript 文字列です。 これらを好きな表現に変更できます。 編集は JavaScript の文法に従っている必要があります。 HTML セクション内の表現も編集できます。
ユーザに見せるページを既定に戻すには、「ログイン ページの内容」 フィールドを空白のままにして変更を適用します。
警告 個別ログイン ページのＨＴＭＬは、ＨＴＭＬエラーによってログイン ページが正しく機能しなくなることがあるので、配備する前に慎重に確認してください。カスタマイズしたログイン ページに何か問題がある場合のために、管理者に対しては代わりのログイン ページが常に利用可能です。 この代わりのログイン ページにアクセスするには、手動でブラウザのアドレス バーに、http://(device_ip)/defauth.html のURL を直接入力します (大文字小文字が区別されます)。 すると、カスタマイズされていない既定のログインページが表示され、通常どおりログインしてカスタマイズしたログイン関連ページをリセットできます。
ローカル ユーザの設定
ローカル ユーザは、セキュリティ装置のローカル データベースに格納され、管理されるユーザです。「ユーザ ＞ ローカル ユーザ」ページでは、すべてのローカル ユーザの表示、新しいローカル ユーザの追加、既存ユーザの編集を行うことができます。 LDAP サーバからユーザをインポートすることもできます。
設定手順については、次の各セクションを参照してください。
ローカル ユーザ設定の構成
「ユーザ ＞ ローカル ユーザ」ページでは、すべてのユーザに対する以下のグローバル設定が構成できます。
･ すべてのローカル ユーザに パスワード制約 を適用する - 「システム ＞ 管理」 ページで指定したパスワード制約をすべてのローカル ユーザに適用します。 パスワード制約の詳細については、「ログイン セキュリティの設定」 を参照してください。
補足 これは、既定の "ａｄｍｉｎ" ユーザ アカウントには影響しません。
･ 期限切れユーザ アカウントを削除する - 制限された有効期限を持つように設定されたユーザ アカウントに対して、このチェックボックスは有効期限が切れた後にそのユーザ アカウントが削除されるようにします。 有効期限が切れた後に単にアカウントを無効にするには、このチェックボックスを無効にします。 そうすると、管理者はそのアカウントの有効期限をリセットすることで再度有効にできます。
ローカル ユーザの表示、編集、削除
「ユーザ ＞ ローカル ユーザ」ページでは、ユーザが所属するすべてのグループを表示できます。ユーザの横の展開アイコン 
を選択すると、ユーザのグループ メンバーシップが表示されます。
ユーザ名の右側に、ユーザに対する権限を示す３つの列があります。展開表示では、ユーザが各権限を得ている元のグループが表示されます。
･ 「ＶＰＮアクセス」列のコメント アイコン
にマウス カーソルを重ねると、ユーザがＶＰＮアクセス可能なネットワーク リソースが表示されます。
･ 展開表示で「設定」の下の削除アイコン
を選択すると、該当するグループからユーザを削除できます。
･ 「設定」の下の編集アイコン
を選択すると、ユーザを編集できます。
･ 「設定」の下のごみ箱アイコン
を選択すると、その行のユーザまたはグループを削除できます。
ローカル ユーザの追加
ＳｏｎｉｃＷＡＬＬセキュリティ装置の内部データベースにローカル ユーザを追加するには、「ユーザ ＞ ローカル ユーザ」ページを使用します。 ここで説明するように、ユーザは手動で追加可能であり、また、「ローカル ユーザを LDAP からインポートする」セクション で説明するように、LDAP からユーザをインポートすることも可能です。 手動でデータベースにローカル ユーザを追加するには、次の手順に従います。
ヒント ローカル ユーザがワンタイム パスワードを有効にしていないが、そのユーザが所属するグループは有効にしている場合には、そのユーザの電子メール アドレスが設定されていることを確認してください。 電子メール アドレスが設定されていない場合、このユーザはログインできません。
･ 制限された有効期限を選択した場合は、有効期限が切れた後にユーザ アカウントが削除されるようにするための、「有効期間が切れた場合に削除する」 チェックボックスが選択できます。 有効期限が切れた後に単にアカウントを無効にするには、このチェックボックスを無効にします。 そうすると、管理者はそのアカウントの有効期限をリセットすることで再度有効にできます。
補足 「ＶＰＮアクセス」 タブは、ＧＶＣ、ＮｅｔＥｘｔｅｎｄｅｒおよびＳＳＬ ＶＰＮ仮想オフィス ブックマークを使ってネットワーク リソースにアクセスするリモート クライアントの能力に影響します。 ＧＶＣ、ＮｅｔＥｘｔｅｎｄｅｒ、または、仮想オフィスのユーザがネットワーク リソースへアクセスすることを許可するには、ネットワーク アドレス オブジェクトかグループを、「ＶＰＮアクセス」 タブの ”許可” リストに追加する必要があります。
補足 ユーザがブックマークを自ら設定するためには、ＳＳＬ ＶＰＮサービス グループのメンバーである必要があります。
ローカル ユーザの編集
「ユーザ ＞ ローカル ユーザ」画面では、ローカル ユーザを編集することができます。ローカル ユーザを編集するには、次の手順に従います。
ローカル ユーザを LDAP からインポートする
LDAP サーバからユーザ名を取得することで SonicWALL 上のローカル ユーザを設定できます。「LDAP からインポート」 ボタンは、SonicWALL にインポートするために利用可能なユーザ名のリストを含むダイアログ ボックスを起動します。
SonicWALL 上に既存の LDAP/AD ユーザと同じ名前を持つユーザがある場合、LDAP 認証の成功によって SonicWALL ユーザ権限が与えられます。
LDAP サーバから読み込んだユーザのリストは、非常に長くなる場合があるため、それらのうち少数をインポートしたいことがあります。 望まないユーザを選択するいくつかの方法と共に、「リストより削除」 ボタンが提供されます。 に、これらのオプションを使って、リストを管理可能なサイズに縮小してからインポートするユーザを選択できます。
LDAP サーバからユーザをインポートするには、次の手順に従います。
･ チェックボックスを選択したユーザを削除するには、「選択したすべてのユーザ」 ラジオ ボタンを選択します。
･ 名前、説明、または場所に基づいて特定のユーザを削除するには、「次に一致するユーザ ＜フィールド 1＞ に次を含む ＜フィールド 2＞」 ラジオ ボタンを選択します。 1 つめのフィールドのドロップダウン リストから、「名前」 、「説明」 、または 「場所」 を選択して、2 つめのフィールドに一致させる値を入力します。
･ LDAP ディレクトリ内の場所に基づいて特定のユーザをリストから削除するには、「すべてのユーザ＜フィールド 1＞ ＜フィールド 2＞」 ラジオ ボタンを選択します。 1 つめのフィールドのドロップダウン リストから、「次の場所」 または 「次の場所とその配下」 のどちらかを選択して、2 つめのフィールドに、ドロップダウン リストから LDAP ディレクトリの場所を選択します。
補足 インポートしないようにリストからユーザを削除することは必須ではありません。 こうすると、簡単にリスト内に残すユーザを見ることができます。 これをやらない選択をする場合は、直接 手順 7 に進めます。
ローカル グループの設定
ローカル グループは、「ローカル グループ」テーブルに表示されます。テーブルには「名前」、「コンテンツ フィルタのバイパス」、「ゲスト サービス」、「管理」、「ＶＰＮアクセス」、および「設定」が表示されます。
設定手順については、次の各セクションを参照してください。
ローカル グループの作成
このセクションではローカル グループの作成方法を説明しますが、その内容は既存のローカル グループの編集にも当てはまります。 ローカル グループを編集するには、編集対象のグループと同じ行にある編集アイコンを選択したうえで、次の手順に従います。
ローカル グループの追加または編集時に、他のローカル グループをグループのメンバーとして追加することができます。
ローカル グループを追加するには、次の手順に従います。
補足 ワンタイム パスワード機能では、リモート ユーザはグループ レベルで制御できます。 元の認証が完了したときに、ＬＤＡＰユーザの電子メール アドレスがサーバから取得されます。 ＲＡＤＩＵＳによるリモート ユーザの認証には、管理者が電子メール アドレスを管理インターフェースから手動で入力する必要があります。 ただし、ＲＡＤＩＵＳユーザの設定で、「ユーザ グループ情報の検索にＬＤＡＰを使用する」を設定している場合は除きます。
補足 「ＶＰＮアクセス」 タブは、ＧＶＣ、ＮｅｔＥｘｔｅｎｄｅｒおよびＳＳＬ ＶＰＮ仮想オフィス ブックマークを使ってネットワーク リソースにアクセスするリモート クライアントの能力に影響します。 ＧＶＣ、ＮｅｔＥｘｔｅｎｄｅｒ、または、仮想オフィスのユーザがネットワーク リソースへアクセスすることを許可するには、ネットワーク アドレス オブジェクトかグループを、「ＶＰＮアクセス」 タブの ”許可” リストに追加する必要があります。
補足 グループ レベルで多数のユーザに対してＳＳＬ ＶＰＮのアクセス許可を設定できます。 それには、「ネットワーク ＞ アドレス オブジェクト」の管理インターフェースでアドレス オブジェクトを作成します。 たとえば、グループのすべてのユーザがアクセスする必要がある公開ファイル サーバに対して行います。 こうして新規作成したオブジェクトは「ＶＰＮアクセス」タブの「ネットワーク」に表示されるため、「アクセス許可」に追加してグループを割り当てることができます。
補足 個別のコンテンツ フィルタ サービス ポリシーは、「セキュリティ サービス ＞ コンテンツ フィルタ」ページで作成します。 「セキュリティ サービス ＞ コンテンツ フィルタ」 を参照してください。
ＬＤＡＰからのローカル グループのインポート
ＬＤＡＰサーバからユーザ グループ名を取得することにより、ＳｏｎｉｃＷＡＬＬ上でローカル ユーザ グループを設定できます。「ＬＤＡＰからインポート」ボタンを選択すると、ダイアログ ボックスが起動し、ＳｏｎｉｃＷＡＬＬにインポートできるユーザ グループ名が一覧表示されます。
既存のＬＤＡＰ／ＡＤユーザ グループと同じ名前のユーザ グループがＳｏｎｉｃＷＡＬＬ上にあれば、ＬＤＡＰ認証に成功したときにＳｏｎｉｃＷＡＬＬのグループ メンバーシップおよび権限が与えられます。
ＬＤＡＰサーバからグループをインポートするには、次の手順に従います。
ＲＡＤＩＵＳ認証の設定
ＳｏｎｉｃＯＳでのＲＡＤＩＵＳ認証の概要は、「ＲＡＤＩＵＳを使った認証」 を参照してください。「ユーザ ＞ 設定」ページの「ログイン認証方式」ドロップダウン リストから「ＲＡＤＩＵＳ」または「ＲＡＤＩＵＳ＋ローカル ユーザ」を選択した場合、「設定」ボタンが選択可能な状態になります。
「シングル サインオン方式」 ドロップダウン リストで 「ブラウザＮＴＬＭ認証のみ」 を選択した場合、または、設定のどこかでＲＡＤＩＵＳの使用が必要なさまざまな場合に、ＲＡＤＩＵＳのための独立した「設定」 ボタンが現れます。 設定手順は同じです。
ＲＡＤＩＵＳを使用する場合、実際の認証方法は自動的に選択されるため、ＲＡＤＩＵＳ設定ウィンドウ内ではそれに対する設定オプションはありません。 ＲＡＤＩＵＳは標準モード（よく誤ってＰＡＰモード1 として呼ばれる）そしてＣＨＡＰ、ＭＳＡＨＣＰ、およびＭＳＣＨＡＰｖ２を含むどのモードでも完全に保護されるため、標準ＲＡＤＩＵＳに対してＲＡＤＩＵＳ ＣＨＡＰモードを強要する理由はありません。 ＭＳＣＨＡＰ/ＭＳＣＨＡＰｖ２を選択する唯一の理由は、これらが提供するパスワード更新機能を利用することで、そしてこれは他の場所で設定できます。
･ Ｌ２ＴＰに対して、使用されるＰＰＰプロトコルに応じて適切なＲＡＤＩＵＳプロトコルが自動的に選択されます。
･ グローバルＶＰＮクライアントを含むＶＰＮに対しては、パスワード更新を許可するために、ＲＡＤＩＵＳ ＭＳＣＨＡＰ/ＭＳＣＨＡＰｖ２モードを強要できます。 これは、「ＶＰＮ ＞ 詳細」 ページと 「ＳＳＬ ＶＰＮ ＞ 設定」 ページで選択できます。
･ 他のシナリオはすべて、内部ユーザの認証を伴います、そして、パスワード更新の仕組みを提供する必要はありません (ユーザはＰＣ上でローカルで行えます)。 この場合は標準ＲＡＤＩＵＳモードが使われます。
･ 「ユーザ ＞ 設定」 ページの 「RADIUS CHAP モードでのログインを許可する」 オプションにより、ユーザは認証にＲＡＤＩＵＳを使う場合、ＨＴＴＰＳではなくＨＴＴＰを介してログイン可能になります。 ＣＨＡＰモードは、ブラウザがユーザのパスワードをＨＴＴＰ上で平文で送信しないように、認証に対してチャレンジ プロトコルを提供します。
ＲＡＤＩＵＳを設定するには、次の手順に従います。
ＲＡＤＩＵＳサーバ
「ＲＡＤＩＵＳサーバ」セクションでは、プライマリＲＡＤＩＵＳサーバのほか、必要に応じてセカンダリＲＡＤＩＵＳサーバを指定することもできます。バックアップＲＡＤＩＵＳサーバがネットワーク上に存在する場合は、オプションのセカンダリＲＡＤＩＵＳサーバを定義できます。
ＲＡＤＩＵＳユーザ
「ＲＡＤＩＵＳユーザ」タブでは、ＲＡＤＩＵＳ認証と組み合わせて使用するローカルまたはＬＤＡＰ情報の種類を指定できます。ＲＡＤＩＵＳユーザの既定のユーザ グループを定義することもできます。
ＲＡＤＩＵＳユーザの設定
ＲＡＤＩＵＳユーザの設定を行うには、次の手順に従います。
･ ＲＡＤＩＵＳサーバから設定済みのベンダー固有の属性を適用する場合は、「ＳｏｎｉｃＷＡＬＬベンダー固有の属性をＲＡＤＩＵＳサーバで使用する」を選択します。この属性には、ユーザが所属するユーザ グループが指定されている必要があります。
･ ＲＡＤＩＵＳサーバから設定済みのＦｉｌｔｅｒ-ＩＤ属性を適用する場合は、「Ｆｉｌｔｅｒ-Ｉｄ属性をＲＡＤＩＵＳサーバで使用する」を選択します。この属性には、ユーザが所属するユーザ グループが指定されている必要があります。
･ ＬＤＡＰサーバからユーザ グループを取得する場合は、「ユーザ グループ情報の検索にＬＤＡＰを使用する」を選択します。まだＬＤＡＰを設定していない場合、または、変更を加える必要がある場合は、「設定」ボタンを選択すると、ＬＤＡＰの設定を行うことができます。ＬＤＡＰの設定については、「ＬＤＡＰを使用するためのＳｏｎｉｃＷＡＬＬ装置の設定」 を参照してください。
･ ユーザ グループ情報をＲＡＤＩＵＳからもＬＤＡＰからも取得しない場合は、「ローカル設定のみ」を選択します。
･ ＲＡＤＩＵＳユーザ グループの管理を簡単にするには、「重複したＲＡＤＩＵＳユーザ名によるメンバーシップ設定可能です」を選択します。セキュリティ装置上に同じ名前のユーザをローカルに作成し、そのグループ メンバーシップを管理すると、その内容がＲＡＤＩＵＳデータベース内のメンバーシップの設定に自動的に反映されます。
ＲＡＤＩＵＳユーザ用の新しいユーザ グループの作成
新しいグループを作成するには、ＲＡＤＩＵＳユーザ設定画面の「すべてのＲＡＤＩＵＳユーザが初期状態で所属するグループ」ドロップダウン リストから「ユーザ グループの作成」を選択します。
補足 ＧｒｏｕｐＶＰＮ アクセス設定は、リモート クライアントおよびＳＳＬ ＶＰＮ 仮想オフィスブックマークに影響します。
ユーザ グループにＬＤＡＰを使用するＲＡＤＩＵＳ
ＲＡＤＩＵＳをユーザ認証に使用している場合、ＲＡＩＤＵＳユーザのユーザ グループ メンバーシップを設定するためのメカニズムとしてＬＤＡＰを選択できるようにするオプションが、ＲＡＤＩＵＳ設定内の「ＲＡＤＩＵＳユーザ」ページにあります。
「ユーザ グループ情報の検索にＬＤＡＰを使用する」が選択されている場合、ＲＡＤＩＵＳを介してユーザ認証が行われた後、ユーザ グループ メンバーシップ情報が、ＬＤＡＰを介してＬＤＡＰ／ＡＤサーバ上のディレクトリ内で参照されます。
補足 この機能が選択されないで、ワンタイム パスワードが有効の場合、ＲＡＤＩＵＳユーザはＳＳＬ ＶＰＮを通してログインを試行した際に、ワンタイム パスワードの失敗メッセージを受け取ります。
「設定」ボタンを選択すると、「ＬＤＡＰ設定」ウィンドウが表示されます。
この場合、ＬＤＡＰはユーザ パスワードを扱わず、ディレクトリから読み込まれる情報も通常は制限されるので、ＴＬＳを使用しない操作を選択することもできます。ＴＬＳが利用できない場合 （証明書サービスがアクティブ ディレクトリにインストールされていない場合など） は警告を無視してください。その際、ＳｏｎｉｃＷＡＬＬは平文テキストを使用してＬＤＡＰサーバにログインするので、セキュリティが侵されないように注意してください。例えば、ＳｏｎｉｃＷＡＬＬで使用するディレクトリに対して読み取りアクセスしかないユーザ アカウントを作成します。この場合は管理者アカウントを使用しないでください。
ＲＡＤＩＵＳクライアントのテスト
「ＲＡＤＩＵＳの設定」ダイアログ ボックスでは、有効なユーザ名とパスワードを入力し、「テスト」でいずれかの認証方式を選択することによって、ＲＡＤＩＵＳクライアントのユーザ名やパスワードなどの設定をテストできます。テストを実行すると、それまでに行ったすべての変更が適用されます。
ＲＡＤＩＵＳの設定をテストするには、次の手順に従います。
･ パスワード認証： 認証にパスワードを使用する場合に選択します。
･ ＣＨＡＰ： チャレンジ ハンドシェーク認証プロトコルを使用する場合に選択します。ＣＨＡＰでは、初回検証後、３ウェイ ハンドシェークを使ってクライアントのＩＤが定期的に検証されます。
･ ＭＳＣＨＡＰ： マイクロソフトの実装によるＣＨＡＰを使用する場合に選択します。ＭＳＣＨＡＰは、ウィンドウズＶｉｓｔａより前のすべてのバージョンのウィンドウズに対応しています。
･ ＭＳＣＨＡＰｖ２： マイクロソフトによる実装のＣＨＡＰバージョン２を使用する場合に選択します。ＭＳＣＨＡＰｖ２は、ウィンドウズ２０００以降のバージョンのウィンドウズに対応しています。
ＲＡＤＩＵＳの設定を完了するには、「ＯＫ」を選択します。
ＳｏｎｉｃＷＡＬＬが設定されると、ＲＡＤＩＵＳ認証を必要とするＶＰＮ Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎから、着信ＶＰＮクライアントがユーザ名とパスワードをダイアログ ボックスに入力するよう求められます。
ＳｏｎｉｃＯＳでのＬＤＡＰ統合の設定
ＳｏｎｉｃＷＡＬＬ装置をＬＤＡＰディレクトリ サービスと統合するには、証明書管理のための設定がＬＤＡＰサーバに必要となります。さらに、ＳｏｎｉｃＷＡＬＬ装置に正しい証明書をインストールし、ＬＤＡＰサーバからの情報を使用できるように設定する必要があります。ＬＤＡＰの概要については、「ＬＤＡＰ／アクティブ ディレクトリ／イーディレクトリ認証」 を参照してください。
以下のセクションを参照してください。
統合に向けてのＬＤＡＰサーバの準備
ＬＤＡＰの設定を行う前に、ＬＤＡＰ ｏｖｅｒ ＴＬＳをサポートするようにＬＤＡＰサーバとＳｏｎｉｃＷＡＬＬを準備する必要があります。これには次の操作が必要です。
･ ＬＤＡＰサーバにサーバ証明書をインストールする。
･ ＳｏｎｉｃＷＡＬＬ装置に発行元ＣＡのＣＡ （Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ） 証明書をインストールする。
次の手順は、これらのタスクをアクティブ ディレクトリ環境で行う方法を示しています。
アクティブ ディレクトリ サーバでのＣＡの設定
アクティブ ディレクトリ サーバ上でＣＡを設定するには、次の手順に従います （証明書サービスが既にインストールされている場合、手順１から手順５はスキップしてください）。
〈http://support.microsoft.com/kb/931125〉
アクティブ ディレクトリ サーバからのＣＡ証明書のエクスポート
ＡＤサーバからＣＡ証明書をエクスポートするには、次の手順に従います。
ＳｏｎｉｃＷＡＬＬへのＣＡ証明書のインポート
ＳｏｎｉｃＷＡＬＬにＣＡ証明書をインポートするには、次の手順に従います。
ＬＤＡＰを使用するためのＳｏｎｉｃＷＡＬＬ装置の設定
管理インターフェースの「ユーザ ＞ 設定」ページには、ＬＤＡＰ統合を管理するための設定が用意されています。
･ 名前またはＩＰアドレス － 認証に使用するＬＤＡＰサーバのＦＱＤＮまたはＩＰアドレスを入力します。名前を使用する場合は、ＤＮＳサーバで名前が解決できることを確認してください。また、「サーバからの有効な証明書を要求する」オプションとともにＴＬＳを使用している場合、ここで指定した名前は、サーバ証明書の発行先の名前 （すなわちＣＮ） と一致する必要があります。一致しない場合、ＴＬＳ交換は失敗します。
･ ポート番号 － 既定のＬＤＡＰ ｏｖｅｒ ＴＬＳポート番号はＴＣＰ ６３６です。既定のＬＤＡＰ （非暗号化） ポート番号は、ＴＣＰ ３８９です。ＬＤＡＰサーバで個別のリッスン ポートを使用している場合は、ここでポート番号を指定します。
･ サーバ タイムアウト － ＳｏｎｉｃＷＡＬＬがＬＤＡＰサーバからの応答を待つ秒数を入力します。この秒数が経過すると、タイム アウトが発生します。指定可能な値の範囲は１～９９９９９です （「９９９９９」の指定が必要なのは、月面上のＶＩＣ-２０上でＬＤＡＰサーバを実行しているような場合だけかもしれません）。既定値は１０秒です。
･ 総合操作のタイムアウト － 自動動作に費やす時間を分単位で指定します。複数のＬＤＡＰサーバを使用している場合は特に、ディレクトリの設定やユーザ グループのインポートなど、数分かかる動作もあります。 既定の設定は５分です。
･ 次のいずれかのラジオ ボタンを選択します。
･ 匿名ログイン － ＬＤＡＰサーバによっては、匿名でツリーにアクセスできます。利用するサーバでこの機能がサポートされている場合 （通常、アクティブ ディレクトリではサポートされません）、このオプションを選択することができます。
･ ログイン名／ツリー内の位置を渡す － 以下の規則に従って、ＬＤＡＰサーバへのバインドに使用する識別名 （ｄｎ） を“ログイン ユーザ名”フィールドと“サーバ ログインに使用するユーザ ツリー”フィールドから作成するには、このオプションを選択します。
･ 最初の名前構成要素は“ｃｎ＝”で開始する
･ ‘ｌｏｃａｔｉｏｎ ｉｎ ｔｒｅｅ （ツリー内の場所）’構成要素はすべて“ｏｕ＝”を使用する （“ｃｎ＝”で始まる特定のアクティブ ディレクトリのビルトインとは別に）
･ ドメイン構成要素はすべて“ｄｃ＝”を使用する
･ 識別名のバインドを渡す － バインドｄｎが上記の１番目の項目に一致していない場合 （最初の名前構成要素が“ｃｎ＝”で始まらない場合） は、このオプションを選択します。ｄｎがわかっている場合は、常にこのオプションを選択することができます。バインドｄｎが上記の１番目の項目に一致しない場合は、バインドｄｎを明示的に指定する必要があります。
･ ログイン ユーザ名 － ＬＤＡＰディレクトリにログインする権限のあるユーザ名を指定します。ログイン名は、完全な“ｄｎ”表記法でＬＤＡＰサーバに自動的に提示されます。ＬＤＡＰの読み取り権限があるアカウント （実質的にすべてのユーザ） である必要があり、管理者権限は必要ありません。これは、ユーザの名前で、ログインＩＤでないことに注意してください （例えば、ｊｓｍｉｔｈではなく、Ｊｏｎｅｓ Ｓｍｉｔｈです）。
･ ログイン パスワード － 上記で指定したユーザ アカウントのパスワードを指定します。
･ プロトコル バージョン － ＬＤＡＰバージョン３かＬＤＡＰバージョン２を選択します。現在のＬＤＡＰのほとんど （アクティブ ディレクトリを含む） の実装では、ＬＤＡＰバージョン３が採用されています。
･ ＴＬＳ （ＳＳＬ） を使用する － ＬＤＡＰサーバへのログインにＴｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ （ＳＳＬ） を使用します。ネットワーク上に送信されるユーザ名とパスワード情報を保護するためにＴＬＳを使用することを強くお勧めします。現在のＬＤＡＰのほとんど （アクティブ ディレクトリを含む） の実装では、ＴＬＳがサポートされています。この既定の設定を変更して選択を解除した場合は、警告が表示されます。続行するには、この警告を受け入れる必要があります。
･ ＬＤＡＰ‘Ｓｔａｒｔ ＴＬＳ’要求を送信する － 一部のＬＤＡＰサーバの実装では、ネイティブなＬＤＡＰ ｏｖｅｒ ＴＬＳを使用しないで、Ｓｔａｒｔ ＴＬＳ指示をサポートしています。これにより、ＬＤＡＰサーバが、ＬＤＡＰ接続を１つのポート （通常３８９） でリッスンすること、および、クライアントによる指示でＴＬＳへ切り替えることが可能になります。アクティブ ディレクトリではこのオプションはサポートされません。このオプションは、ＬＤＡＰサーバによって要求された場合にのみ選択すべきです。
･ サーバからの有効な証明書を要求する － ＴＬＳ交換時に、サーバによって提示された証明書の名前が上記で指定した名前と一致するかどうかを確認します。この既定のオプションを非選択にした場合、警告が表示されますが、ＳｏｎｉｃＷＡＬＬとＬＤＡＰサーバ間の交換にはＴＬＳが使われます （確認を行わないだけです）。
･ ＴＬＳに用いるローカル証明書 － オプション。ＬＤＡＰサーバが接続のためにクライアント証明書を要求する場合にのみ使用されます。ＬＤＡＰクライアントの識別を確実にするためにパスワードを返すＬＤＡＰサーバの実装では有用です （アクティブ ディレクトリではパスワードは返されません）。この設定はアクティブ ディレクトリでは必要ありません。
･ ＬＤＡＰスキーマ － 次のいずれかを選択します。
･ マイクロソフト アクティブ ディレクトリ
･ ＲＦＣ２７９８ ＩｎｅｔＯｒｇＰｅｒｓｏｎ
･ ＲＦＣ２３０７ネットワーク インフォメーション サービス
･ サンバＳＭＢ
･ ノベル イーディレクトリ
･ ユーザ定義
･ オブジェクト クラス － 次の２つのフィールドが適用される個々のユーザアカウントを表す属性を選択します。
･ ログイン名属性 － 次のいずれかを選択して、ログイン認証に使用する属性を定義します。
･ ｓＡＭＡｃｃｏｕｎｔＮａｍｅ：マイクロソフト アクティブ ディレクトリ用
･ ｉｎｅｔＯｒｇＰｅｒｓｏｎ：ＲＦＣ ２７９８ ｉｎｅｔＯｒｇＰｅｒｓｏｎ用
･ ｐｏｓｉｘＡｃｃｏｕｎｔ：ＲＦＣ２３０７ネットワーク インフォメーション サービス用
･ ｓａｍｂａＳＡＭＡｃｃｏｕｎｔ：サンバＳＭＢ用
･ ｉｎｅｔＯｒｇＰｅｒｓｏｎ：ノベル イーディレクトリ用
･ 資格のあるログイン名属性 － ユーザの代替ログイン名を「名前＠ドメイン」形式で設定するユーザ オブジェクトの属性を、必要に応じて指定します。これは特に、単純なログイン名ではドメイン間で一意性を保てない可能性がある複数ドメインを持つ場合に必要になります。マイクロソフト アクティブ ディレクトリおよびＲＦＣ ２７９８ ｉｎｅｔＯｒｇＰｅｒｓｏｎの場合は、「ｍａｉｌ」に設定します。
･ ユーザ グループ メンバーシップ属性 － ユーザ オブジェクトの所属先グループについての情報を表す属性を選択します。これに該当するのは、マイクロソフト アクティブ ディレクトリのｍｅｍｂｅｒＯｆ属性です。他の定義済みのスキーマでは、グループ メンバーシップ情報がユーザ オブジェクトではなくグループ オブジェクト内に格納されるので、このフィールドは使用されません。
･ 構築されたＩＰアドレス属性 － ディレクトリ内でユーザに割り当てられた静的ＩＰアドレスを取得するための属性を選択します。現在は、Ｌ２ＴＰを介してＳｏｎｉｃＷＡＬＬのＬ２ＴＰサーバと接続するユーザに対してのみ使用されます。将来的には、グローバルＶＰＮクライアントでもサポートされる予定です。アクティブ ディレクトリでは、ユーザ プロパティの「ダイヤルイン」タブで静的ＩＰアドレスを設定します。
･ ユーザ グループ オブジェクト － このセクションは、「ＬＤＡＰスキーマ」で「ユーザ定義」を選択しない場合は自動設定されます。
･ オブジェクト クラス － 属性のグループに関連付けられる名前を指定します。
･ メンバー属性 － メンバーに関連付けられる属性を指定します。
･ 識別名 または ユーザＩＤのどちらかを選択します。
･ サーバから読み込み － 選択すると、ＬＤＡＰサーバからユーザ グループ オブジェクトの情報を読み込みます。
･ スキーマ設定を自動的に更新 または スキーマの詳細をエクスポート のどちらかを選択します。
･ プライマリ ドメイン － ＬＤＡＰ実装により使用されているユーザ ドメイン。ＡＤの場合、これは、アクティブ ディレクトリのドメイン名です （例えば、ｙｏｕｒＡＤｄｏｍａｉｎ.ｃｏｍ）。オプションで、このフィールドを変更したときにページ内の残りのツリー情報を自動的に更新することもできます。既定では、ノベル イーディレクトリを除くすべてのスキーマでｍｙｄｏｍａｉｎ.ｃｏｍに設定されます （ノベル イーディレクトリの既定値はｏ＝ｍｙｄｏｍａｉｎです）。
･ サーバ ログインに使用するユーザ ツリー － 「設定」タブで指定したユーザが含まれるツリー。例えば、アクティブ ディレクトリにおける“ａｄｍｉｎｉｓｔｒａｔｏｒ”アカウントの既定のツリーはユーザ ツリーと同じです。
･ ユーザを含むツリー － ＬＤＡＰディレクトリ内でユーザが一般に含まれるツリー。編集可能な１つの既定値が提供されます。合計６４個のＤＮ値を登録することができます。ＳｏｎｉｃＷＡＬＬは、これらすべてを使用して、一致するかリストの最後になるまで、ディレクトリを検索します。ＬＤＡＰまたはＡＤディレクトリ内に他のユーザ コンテナを作成している場合は、ここにユーザ コンテナを指定する必要があります。
･ ユーザ グループを含むツリー － ユーザ グループ コンテナに関連し、ＤＮ値の最大数が３２であること以外は、「ユーザを含むツリー」と同じです。スキーマのユーザ オブジェクト内にユーザ グループ メンバーシップ属性がない場合にのみ適用できます。ＡＤでは使用されません。
補足 ＡＤには、通常の書式ルールに従っていないいくつかのビルトイン コンテナがあります （例えば、最上位のユーザ コンテナのＤＮは“ｃｎ＝Ｕｓｅｒｓ，ｄｃ＝．．．”というように、“ｏｕ”ではなく“ｃｎ”を使っています）。しかし、ＳｏｎｉｃＷＡＬＬはこれを認識して対処できるようになっているため、より簡易なＵＲＬ形式で入力することができます。
補足 ＡＤを使用している場合、「サーバ ログインに使用するユーザ ツリー」フィールドで指定したディレクトリのどの位置にユーザが含まれているかを確認するために、サーバ上の管理ツール内の「Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙユーザとコンピュータ」コントロール パネル アプレットを使用して、ディレクトリを手動で検索することができます。また、ウィンドウズＮＴ／２０００／ＸＰリソース キットに含まれるｑｕｅｒｙａｄ.ｖｂｓのようなディレクトリ検索ユーティリティをドメイン内の任意のＰＣ上で実行することもできます。
･ 自動設定 － ディレクトリをスキャンしてユーザ オブジェクトが含まれるすべてのツリーを検出することにより、「ユーザを含むツリー」フィールドと「ユーザ グループを含むツリー」フィールドを自動的に設定します。自動設定を使用するには、最初に「サーバ ログインに使用するユーザ ツリー」フィールドに値を入力し （匿名ログインが設定されていない場合）、「自動設定」ボタンを選択して、次のダイアログ ボックスを表示します。
･ 現在のツリーに追加する － 新たに検出されたツリーを現在の設定に追加します。
･ 既存のツリーを置き換える － 現在設定されているすべてのツリーを削除してから新規に作り直します。
･ 「ＯＫ」を選択します。
･ 紹介を許可する － 設定されたプライマリＬＤＡＰサーバ以外のＬＤＡＰサーバ上にユーザ情報がある場合は常にこのオプションを選択します。
･ ユーザ認証時の継続参照を許可する － 個々のディレクトリ ツリーを複数のＬＤＡＰサーバにわたって手動で設定した場合は常にこのオプションを選択します。
･ ディレクトリ自動設定時の継続参照を許可する － １回の動作で複数のＬＤＡＰサーバからツリーを読み出せるようにするにはこのオプションを選択します。
･ ドメイン検索の継続参照を許可する － 別個のＬＤＡＰサーバを持つ複数サブドメイン内のユーザに対してシングル サイン オンを使用する場合はこのオプションを選択します。
･ ローカルに登録されたユーザのみ許可する － ＬＤＡＰユーザがＳｏｎｉｃＷＡＬＬローカル ユーザ データベースにも登録されている場合にのみ、そのユーザのログインを許可するようにします。
･ ＬＤＡＰユーザ名を複製してユーザ グループ メンバーシップをローカルで設定可能にする － ローカル ユーザとＬＤＡＰユーザ設定の共通部分に基づいてグループ メンバーシップ （と権限） が決定されるようにします。
･ 既定のＬＤＡＰユーザ グループ － ＬＤＡＰサーバ上で設定されたグループ メンバーシップに加えて、ＬＤＡＰユーザが所属するＳｏｎｉｃＷＡＬＬ上の既定のグループ。
･ ユーザのインポート － このボタンを選択すると、ＬＤＡＰサーバからユーザ名を取得することにより、ＳｏｎｉｃＷＡＬＬ上でローカル ユーザを設定できます。 「ユーザのインポート」ボタンを選択すると、ＳｏｎｉｃＷＡＬＬにインポートできるユーザ名の一覧を含むウィンドウが起動されます。
･ ユーザ グループのインポート － このボタンを選択すると、ＬＤＡＰサーバからユーザ グループ名を取得することにより、ＳｏｎｉｃＷＡＬＬ上でユーザ グループを設定できます。「ユーザ グループのインポート」ボタンを選択すると、ＳｏｎｉｃＷＡＬＬにインポートできるユーザ グループ名の一覧を含むウィンドウが起動されます。
･ ＲＡＤＩＵＳからＬＤＡＰへのリレーを有効にする － この機能を有効にします。
･ 以下のＲＡＤＩＵＳクライアントからの接続を許可する － 適切なチェックボックスを選択します。着信ＲＡＤＩＵＳ要求を許可するためのポリシー ルールが追加されます。
･ ＲＡＤＩＵＳ事前共有鍵 － すべてのリモートＳｏｎｉｃＷＡＬＬに共通の事前共有鍵です。
･ レガシーＶＰＮユーザに対するユーザ グループ － 従来の‘ＶＰＮへのアクセスを許可する’権限に対応するユーザ グループを定義します。このユーザ グループに所属するユーザが認証された場合、リモートのＳｏｎｉｃＷＡＬＬに通知が送られ、そのユーザに適切な権限が与えられます。
･ レガシーＶＰＮクライアント ユーザに対するユーザ グループ － 従来の‘ＸＡＵＴＨによるＶＰＮクライアントからのアクセスを許可する’権限に対応するユーザ グループを定義します。このユーザ グループに所属するユーザが認証された場合、リモートのＳｏｎｉｃＷＡＬＬに通知が送られ、そのユーザに適切な権限が与えられます。
･ レガシーＬ２ＴＰユーザに対するユーザ グループ － 従来の‘Ｌ２ＴＰによるＶＰＮクライアントからのアクセスを許可する’権限に対応するユーザ グループを定義します。このユーザ グループに所属するユーザが認証された場合、リモートのＳｏｎｉｃＷＡＬＬに通知が送られ、そのユーザに適切な権限が与えられます。
･ インターネット アクセスのあるレガシー ユーザに対するユーザ グループ － 従来の‘インターネット アクセスを許可する （アクセス制限時）’権限に対応するユーザ グループを定義します。このユーザ グループに所属するユーザが認証された場合、リモートのＳｏｎｉｃＷＡＬＬに通知が送られ、そのユーザに適切な権限が与えられます。
補足 ‘フィルタのバイパス’権限と‘制限された管理機能へのアクセスを許可する’権限は、「Ｃｏｎｔｅｎｔ Ｆｉｌｔｅｒｉｎｇ Ｂｙｐａｓｓ」と「Ｌｉｍｉｔｅｄ Ａｄｍｉｎｉｓｔｒａｔｏｒｓ」のユーザ グループのメンバーシップに基づいて返されます。これらを設定することはできません。
MacOS と iOS 接続に対して LDAP を使うための L2TP 設定
LDAP または RADIUS を使う L2TP 接続に対して MacOS または Apple iOS で稼動している機器 (iPad/iPhone/iPod touch) を設定する場合は、いくつか注意を払う必要がります。 これは iOS 機器がサーバによって提供された最初にサポートされる認証プロトコルを受諾するためです。 SonicOS では、既定の認証プロトコルの順序が SonicOS 5.8.0.8 と 5.8.1.1 リリースから変更されました。 以下は既定の認証プロトコル順序です。
･ 5.8.0.8 と 5.8.1.1 より前： CHAP、PAP、MS-CHAP、MS-CHAPv2
･ 5.8.0.8 と 5.8.1.1 および、それより後： MS-CHAPv2、CHAP、MS-CHAP、PAP
補足 以前のファームウェア バージョンからのアップグレードは、元の順序を保持します。 この新しい順序は新規設定のみに適用されます。
最初にサポートされる認証プロトコルを受諾する iOS の振舞いに対応した、この既定の認証順序変更は、SonicOS および iOS 機器が既定で RADIUS 認証を使うようにします (アクティブ ディレクトリが CHAP、MS-CHAP、または MS-CHAPv2 をサポートしないため)。
iOS 機器からの L2TP 接続が RADIUS の代わりに LDAP を使うようにするには、以下の手順に従います。
1. 「VPN ＞ L2TP サーバ」 ページに移動します。シングル サイン オンの設定
ＳＳＯを設定するには、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント および／または、ＳｏｎｉｃＷＡＬＬ ターミナル サービス エージェント （ＴＳＡ） のインストールと設定、さらに、ＳｏｎｉｃＯＳを実行するＳｏｎｉｃＷＡＬＬセキュリティ装置でこのＳＳＯエージェントまたはＴＳＡを使用するための設定が必要になります。 ＳＳＯをＨＴＴＰトラフィックでＳＳＯエージェントを用いてまたは用いずに、ブラウザＮＴＬＭ認証を使うように設定することも可能です。 ＳｏｎｉｃＷＡＬＬ ＳＳＯの概要については、「シングル サイン オンの概要」セクション を参照してください。
補足 ＳｏｎｉｃＯＳ ＳＳＯ機能は、仮想マシン環境内で動作することが可能ですが、公式にはサポートされていません。これは、ＶＭ配備環境の潜在的なリソース消費の多様性により、有効な試験とすべての可能性のある組み合わせの確認が実行できないためです。
以下のセクションでは、ＳＳＯの設定方法について説明します。
･ 「概要」
･ 「改善措置」
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントのインストール
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントは、ＳｏｎｉｃＷＡＬＬディレクトリ コネクタの一部です。ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントは、ＶＰＮまたはＩＰを使ってアクセスできるアクティブ ディレクトリ サーバへのアクセスがあるウィンドウズ ドメイン内のワークステーションまたはサーバに、最低１台から最大８台にインストールされている必要があります。ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントには、ＳｏｎｉｃＷＡＬＬセキュリティ装置へのアクセス権が必要です。ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントをインストールするには、次の手順を実行します。
が表示されます。「
補足 このセクションは後で設定できます。この手順をスキップして、後で設定する場合は、 「スキップ」を選択します。
補足 この情報は後で設定できます。この手順をスキップして、後で設定する場合は、フィールドを空欄のままにして、「次へ」を選択します。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントのインストールが開始され、 状況バーが表示されます。
「ＳｏｎｉｃＷＡＬＬディレクトリ コネクタを起動する」ボックスを選択した場合、ＳｏｎｉｃＷＡＬＬディレクトリ コネクタが表示されます。
ＳｏｎｉｃＷＡＬＬターミナル サービス エージェントのインストール
ウィンドウズ ドメイン内のネットワークの１つ以上のターミナル サーバにＳｏｎｉｃＷＡＬＬ ＴＳＡをインストールします。 ＳｏｎｉｃＷＡＬＬ ＴＳＡはＳｏｎｉｃＷＡＬＬセキュリティ装置へのアクセスが必要で、セキュリティ装置はＴＳＡへのアクセスが必要です。 ターミナル サーバでソフトウェア ファイアウォールが動作している場合には、装置からの受信メッセージ用のＵＤＰポート番号を開くことが必要な場合があります。
補足 ターミナル サーバのユーザが Ping と DNS を使うことを許可するために、追加のファイアウォール アクセス ルールが必要になることがあります。
ＳｏｎｉｃＷＡＬＬ ＴＳＡはＭｙＳｏｎｉｃＷＡＬＬから無償でダウンロードできます。 ＳｏｎｉｃＷＡＬＬ ＴＳＡをインストールするには、次の手順を実行します。
･ ＳｏｎｉｃＷＡＬＬ ＴＳＡＩｎｓｔａｌｌｅｒ３２.ｍｓｉ （３２ビット、バージョン３.０.２８.１００１以降）
･ ＳｏｎｉｃＷＡＬＬ ＴＳＡＩｎｓｔａｌｌｅｒ６４.ｍｓｉ （６４ビット、バージョン３.０.２８.１００１以降）
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントの設定
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントは、ＮｅｔＡＰＩまたはＷＭＩを使用してワークステーションと通信します。どちらも、ワークステーションにログインしているユーザに関する情報 （ドメイン ユーザ、ローカル ユーザ、ウィンドウズ サービスなど） を提供するものです。ウィンドウズ サーバ２００３、ウィンドウズＸＰ、ウィンドウズＭＥ、およびウィンドウズ２０００には、ＷＭＩがあらかじめインストールされています。その他のウィンドウズ バージョンについては、ｗｗｗ.ｍｉｃｒｏｓｏｆｔ.ｃｏｍにアクセスして、ＷＭＩをダウンロードしてください。ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントの設定前に、ＷＭＩまたはＮｅｔＡＰＩがインストールされていることを確認します。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントを設定する前に、.ＮＥＴ Ｆｒａｍｅｗｏｒｋ ２.０がインストールされている必要があります。.ＮＥＴ Ｆｒａｍｅｗｏｒｋは、マイクロソフトのウェブ サイトｗｗｗ.ｍｉｃｒｏｓｏｆｔ.ｃｏｍからダウンロードできます。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントの通信プロパティを設定するには、以下の手順に従います。
補足 既定のＳｏｎｉｃＷＡＬＬセキュリティ装置のＩＰアドレスが設定されていなかった場合、または正しく設定されていなかった場合は、ポップアップが表示されます。既定のＩＰアドレス （１９２.１６８.１６８.１６８） を使用する場合は「はい」を、現在の設定を使用する場合は「いいえ」を選択してください。
「いいえ」を選択した場合、または、「はい」を選択したが既定の設定に誤りがある場合は、「ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント サービスが実行されていません。設定を確認してサービスを開始してください」というメッセージが表示されます。「ＯＫ」を選択します。
「ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント サービスが実行されていません。設定を確認してサービスを開始してください」というメッセージが表示された場合、ＳＳＯエージェント サービスは既定で無効になります。サービスを有効にするには、左側のナビゲーション パネルでＳｏｎｉｃＷＡＬＬディレクトリ コネクタ設定ツールを展開 （＋アイコンを選択） し、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントを強調表示して、
ボタンを選択します。
･ ログ レベル０ － 重大なイベントのみ記録されます。
･ ログ レベル１ － 重大なイベントと深刻なイベントが記録されます。
･ ログ レベル２ － デバッグ レベルの重大度を使用し、装置からのすべての要求が記録されます。
補足 ログ レベル２を選択した場合、ウィンドウズ イベント ログがその最大容量に達すると、ＳＳＯエージェント サービスが強制的に終了されます。
補足 ＮｅｔＡＰＩは高速ですが、精度は若干ＷＭＩよりも劣ります。ＷＭＩは低速ですが、精度はＮｅｔＡＰＩよりも優れています。 ＮｅｔＡＰＩを使って、ウィンドウズはワークステーションへの最終ログインと、ユーザがまだログインしているかどうかをレポートします。 これは、ＮｅｔＡＰＩを使っている場合は、ユーザが自身のコンピュータからログアウトした後に、装置がユーザをログインしているとして表示することを意味します。 別のユーザが同じコンピュータにログオンした場合は、以前のユーザはその時点でＳｏｎｉｃＷＡＬＬからログアウトされます。
ウィンドウズ サーバ２００３、ウィンドウズＸＰ、ウィンドウズＭＥ、およびウィンドウズ２０００には、ＷＭＩがあらかじめインストールされています。ＮｅｔＡＰＩもＷＭＩも手動でダウンロードおよびインストールできます。ＮｅｔＡＰＩおよびＷＭＩは、ワークステーションにログインしているユーザに関する情報 （ドメイン ユーザ、ローカル ユーザ、ウィンドウズ サービスなど） を提供するものです。
WMI に対して非管理者アカウントを用いて、ドメイン コントローラのセキュリティ ログを介したユーザの識別を設定できます。このオプションはドメイン管理者アカウントの使用を要求しませんが、セキュリティ ログの読取りアクセスは必要であり、これは非管理者アカウントを構成することで付与できます。詳細については、sonicwall.com サイトの「Support > Product Documentation」ページから入手できる技術文書『Configuring a Non-Admin Domain Account for SSO Agent to Read Security Logs』を参照してください。
Ｃ：￥Ｐｒｏｇｒａｍ Ｆｉｌｅｓ￥ＳｏｎｉｃＷＡＬＬ￥ＤＣＯＮ￥ＳＳＯ￥ＣＩＡＣｏｎｆｉｇ.ｘｍｌです。
ＳｏｎｉｃＷＡＬＬセキュリティ装置の追加
インストール時にＳｏｎｉｃＷＡＬＬセキュリティ装置を追加しなかった場合、または、別のＳｏｎｉｃＷＡＬＬセキュリティ装置を追加する場合は、以下の手順に従って手動で追加してください。
ＳｏｎｉｃＷＡＬＬセキュリティ装置を追加するには、次の手順を実行します。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントの装置の編集
過去にＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントに追加したＳｏｎｉｃＷＡＬＬセキュリティ装置の設定は、ＩＰアドレス、ポート番号、ニックネーム、共有鍵を含め、すべて編集できます。ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントに追加したＳｏｎｉｃＷＡＬＬセキュリティ装置を編集するには、該当する装置を左側のナビゲーション パネルで選択し、上にある編集アイコン 
を選択します。右側のウィンドウの下にある「編集」タブを選択してもかまいません。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントからの装置の削除
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントからＳｏｎｉｃＷＡＬＬセキュリティ装置を削除するには、該当する装置を左側のナビゲーション パネルで選択し、上にある削除アイコン 
を選択します。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントのサービスに対する変更
ＳｏｎｉｃＷＡＬＬセキュリティ装置に対するＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントのサービスを開始、停止、一時停止できます。装置に対するサービスを一時停止するには、左側のナビゲーション パネルで該当する装置を選択し、一時停止ボタン 
を選択します。装置に対するサービスを停止するには、左側のナビゲーション パネルで該当する装置を選択し、停止ボタン 
を選択します。サービスを再開するには、開始ボタン 
を選択します。
補足 ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントでＳｏｎｉｃＷＡＬＬセキュリティ装置の設定に変更を加えた場合、サービスを再起動するように求められる場合があります。サービスを再起動するには、停止ボタンを押してから開始ボタンを押します。
ＳｏｎｉｃＷＡＬＬターミナル サービス エージェントの設定
ＳｏｎｉｃＷＡＬＬ ＴＳＡをインストールしてウィンドウズ サーバ システムを再起動した後で、インストーラによってデスクトップ上に作成されたＳｏｎｉｃＷＡＬＬ ＴＳＡのアイコンをダブルクリックすると、ＳｏｎｉｃＷＡＬＬ ＴＳＡの起動と設定、トラブル シューティング レポート （ＴＳＲ） の生成、状態とバージョン情報の確認を行うことができます。
以下のセクションを参照してください。
ＳｏｎｉｃＷＡＬＬ ＴＳＡの設定へのＳｏｎｉｃＷＡＬＬネットワーク セキュリティ装置の追加
以下の手順に従って、ＳｏｎｉｃＷＡＬＬ装置をＳｏｎｉｃＷＡＬＬ ＴＳＡに追加します。
ＳｏｎｉｃＷＡＬＬ ＴＳＡトラブル シューティング レポートの作成
現在のログ メッセージおよびエージェント、ドライバ、システム設定についての情報をすべて含んだトラブル シューティング レポート （ＴＳＲ） を作成できます。 これを使用して、内容を調べたり、ＳｏｎｉｃＷＡＬＬテクニカル サポートに送信して問い合わせたりできます。
以下の手順に従って、ＳｏｎｉｃＷＡＬＬ ＴＳＡのＴＳＲを作成します。
ＳｏｎｉｃＷＡＬＬ ＴＳＡの状態とバージョンの表示
ウィンドウズ サーバ システムでのＳｏｎｉｃＷＡＬＬ ＴＳＡサービスの現在の状態、またはＳｏｎｉｃＷＡＬＬ ＴＳＡのバージョン番号を表示するには、以下の手順に従います。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントのためのＳｏｎｉｃＷＡＬＬセキュリティ装置の設定
ＳＳＯ方式としてＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント または ブラウザＮＴＬＭ認証 のどちらかを使用するためには、ＳｏｎｉｃＷＡＬＬセキュリティ装置を設定する必要があります。 ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント はまた、装置がＳｏｎｉｃＷＡＬＬ ターミナル サービス エージェントを使用するように設定する場合にも選択する正しい手法です。
以下の手順では、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント を使うようにＳｏｎｉｃＷＡＬＬセキュリティ装置を設定する方法を説明します。以下の手順を実行します。
フィールドに値を入力すると、ページ上部の行が赤色に更新され、新しい情報が強調表示されます。
エージェントは、各要求を処理する別個のスレッドをエージェントＰＣ内に生成し、複数の要求を同時に処理します。一度に送信する要求が多すぎると、ＰＣが過負荷になることがあります。その一方、装置から送信される要求数が最大値を超えると、一部の要求は内部の‘リング バッファ’キューで待機します。待機している要求が多すぎると、シングル サイン オン認証の応答時間が遅くなることがあります。詳細については、「シングル サイン オンの詳細設定の調整」 を参照してください。
監視テスト モードは、最初のＳＳＯ配備とトラブルシュートに役立ちます。 監視テスト モードが有効の場合、以下により振舞いを分析できます。
･ 監視失敗に対してエージェント統計を確認する
･ ＳＳＯが動作していて監視が失敗したときの警告 (これらのメッセージはホスト アドレスを示します) をコンソール ポートで確認する。
統計が１００％の監視失敗を表示した場合は、ネットワーク上に何かしら問題があります。 断続的な失敗を表示した場合は、「監視タイムアウト」 設定の変更を試して改善するか見ると良いでしょう。
このリストは、ウィンドウズ サービスが使用するログイン名を実際のユーザ ログインと区別するためのものです。ＳＳＯエージェントがコンピュータにログインしているユーザを探すようウィンドウズに問い合わせると、実際には、ウィンドウズはコンピュータにログインしている、またはログインしていたユーザ アカウントのリストを返すので、ユーザ ログインとサービス ログインは区別されません。したがって、ＳＳＯエージェントは、ログイン名がサービスに所属しているかどうか判断することができません。このため、ＳＳＯエージェントは、誤って実際のユーザ名ではなくサービス名を報告することがあります。
ここには、エンド ユーザのコンピュータ上でサービスが使用する可能性のあるログイン名を最大６４個入力することができます。ＳＳＯエージェントは、これらの名前を使用したログインを無視します。
シングル サイン オンの使用時に、「ユーザ ＞ 状況」ページに予期せぬユーザ名や、予期せぬユーザ名によるユーザ ログインまたはユーザ ログイン失敗のログが表示された場合、ウィンドウズのサービス ログインに起因することがあります。ＳＳＯエージェントが無視するユーザ名を識別できるよう、そのようなユーザ名をここで設定してください。
複数のＳｏｎｉｃＷＡＬＬ装置が１つのＳＳＯエージェントと通信している場合、サービス アカウント名のリストはいずれか１台の装置上でのみ設定してください。異なる装置上で複数のリストを設定した場合の影響は不明確です。
サービス アカウント名を編集するには、そのサービス アカウント名を選択し、「編集」を選択し、「サービス ユーザ名」ダイアログ ボックスで必要な変更を行ってから、「ＯＫ」を選択します。
サービス アカウント名を削除するには、１つまたは複数のサービス アカウント名を選択してから、「削除」を選択します。
これらのゾーン毎の SSO 強制設定は、SSO が別の方法で、コンテンツ フィルタ、IPS、またはアプリケーション制御ポリシーによって、またはユーザ認証が必要なファイアウォール アクセス ルールによって開始されない場合でも、イベント ログ取得とアプリケーション フロー監視の視覚化の際にユーザの識別と追跡に役立ちます。
ユーザ認証を要求するように設定されたセキュリティ サービス ポリシーやファイアウォール アクセス ルールがあるゾーン上では、SSO は常に影響のあるトラフィックに対して開始されるので、さらに SSO の強制を有効にする必要はありません。
１つ目の設定は、セキュリティ サービス保護の対象となるトラフィックが、ユーザのワークステーション以外の機器 （内部プロキシ ウェブ サーバやＩＰ電話など） から送出される可能性がある場合に使用します。適用するコンテンツ フィルタ ポリシーをＳｏｎｉｃＷＡＬＬが選択する際、このような機器がネットワーク ユーザとして識別されないようにするための設定です。選択されたＩＰアドレスからのすべてのトラフィックに、既定のコンテンツ フィルタ ポリシーが使用されます。
２つ目の設定は、認証される必要のないユーザ トラフィックに対して適切で、ＳＳＯを開始することにより、サービスに対して望ましくない遅延を引き起こす可能性があります。
ＳＳＯのバイパス設定は、ユーザ認証を要求するファイアウォール アクセス ルールによってＳＳＯが開始された場合には適用されません。 この種のＳＳＯバイパスを設定するには、影響されるトラフィックに対してユーザ認証を要求しないアクセス ルールを追加します。 アクセス ルール設定の詳細については、「アクセス ルールの追加」 を参照してください。
補足 既定では、ＳＳＯによって認証されないＬｉｎｕｘおよびＭａｃユーザには、既定のコンテンツ フィルタ ポリシーが割り当てられます。そのような、ＳＳＯにより認証されないすべてのユーザを資格情報を手動で入力させるようリダイレクトするには、「ＨＴＴＰ」サービスに対して、「ＷＡＮ」ゾーンから「ＬＡＮ」ゾーンへのアクセス ルールを「許可するユーザ」を「すべて」に設定して作成します。そして、ユーザまたはユーザ グループに対して適切なＣＦＳポリシーを設定します。アクセス ルール設定の詳細については、「アクセス ルールの追加」 を参照してください。
既存のエージェントの横にある緑色のＬＥＤ形式のアイコンは、エージェントが稼働していることを示します。 赤色のＬＥＤは、エージェントが停止していることを示します。 黄色のＬＥＤは、ＴＳＡが無動作状態で、ＴＳＡから装置への通知が５分以上途絶えていることを示します。 装置がエージェントに要求を送信するのではなく、ＴＳＡが装置に通知を送信する形であることから、通知がないときには問題が生じている可能性もあり得ますが、それより考えられるのは、単にターミナル サーバで現在どのユーザも何の処理も行っていないという可能性です。
フィールドに値を入力すると、ページ上部の行が赤色に更新され、新しい情報が強調表示されます。
詳細については、このタブ上のツールチップを調べるか、「ブラウザＮＴＬＭ認証の動作」 を参照してください。
･ 無効 - NTLM 認証を使いません。
･ エージェントによる SSO が使用される前 - SonicWALL SSO エージェントを使う前に NTLM を使ってユーザの認証を試行します。
･ エージェントによる SSO が失敗した場合のみ - 最初に SSO エージェントを介したユーザの認証を試行てから、それが失敗した場合に、NTLM の使用を試行します。
･ SonicWALL 装置のドメインの完全な DNS 名を、 "www.somedomain.com" の形式で入力します。
･ LDAP 設定内で使っているものと同じドメインを使うために、「LDAP 設定のドメインを使用する」 チェックボックスを選択します。
ブラウザが装置のドメインをローカル ドメインと見た場合にのみ、完全に透過的な認証が行われます。
･ インターフェースの IP アドレス - ブラウザを装置のウェブ サーバ インターフェースの IP アドレスにリダイレクトする場合に選択します。
･ インターフェース IP アドレスの逆引き DNS 調査 - ウィンドウ下部の 「逆引き DNS キャッシュの表示」 ボタンを有効にします。 このボタンを選択すると、ポップアップが装置のウェブ サーバのインターフェース、IP アドレス、DNS名、TTL の秒数を表示します。 ユーザのブラウザをリダイレクトするために使われているドメイン名 （DNS 名） を確認する場合にこのボタンを選択します。
･ ドメイン名 - ユーザのブラウザがリダイレクトされる先のウェブ サーバのドメイン名を入力します。
･ SSO エージェントでポーリング - ネットワーク内で SSO エージェントを使っている場合は、それを使ってユーザをポーリングするにはこれを選択します。 NTLM を介して認証されるユーザに対しては、エージェントが記憶するユーザ名がNTLM 認証で使用される名前と一致する必要があるか、ログイン セッションが終了されます。 Linux や Mac ユーザに対しては、それらのシステムが SSO エージェントによって使用されるウィンドウズ ネットワーキングの要求をサポートしないので、別のポーリング方式を選択します。
･ NTLM で再認証 - ブラウザがドメインの資格情報を保存するように設定されている、またはユーザがブラウザに資格情報を保存するように指示した場合は、この方式はユーザに透過的です。
･ 再認証しない - このオプションを選択した場合は、無動作タイムアウト以外ではログアウトは検出されません。
補足 このページでテストを実行すると、それまでに行ったすべての変更が適用されます。
ヒント 「エージェントが応答しません」または「設定エラー」というメッセージが表示された場合は、設定内容を確認してから、これらのテストをもう一度実行します。
ブラウザＮＴＬＭ認証のためのＳｏｎｉｃＷＡＬＬセキュリティ装置の設定
シングル サインオンを使うためには、SonicWALL セキュリティ装置が SSO 方式として 「SonicWALL SSO エージェント」 か 「ブラウザ NTLM 認証のみ」 のいずれかを使うように設定されている必要があります。
以下の手順では、SonicWALL セキュリティ装置が 「ブラウザ NTLM 認証のみ」 を使うように設定する方法を説明します。
ＮＴＬＭで使用するＲＡＤＩＵＳの設定
「ログインの認証方法」 フィールドで LDAP を選択した場合でも、NTLM 認証を使う場合は RADIUS 設定が必要です。 NTLM 認証は、 LDAP では提供されず RADIUS で提供される MSCHAP を必要とします。
「ユーザ ＞ 設定」 ページで LDAP 認証を選択した場合は、「RADIUS も CHAP/NTLM で必要とされる場合があります。」 の隣の 「設定」 ボタンが有効になります。
LDAP が設定されていると、それは NTLM によって提供されたユーザの資格情報がRADIUS を通して認証された後でユーザ グループ メンバーシップの検索に使われます。 こうして、NTLM を使用する場合はユーザ グループ メンバーシップ情報を返すために RADIUS を設定する必要はありません (ISA のような、いくつかの RADIUS サーバで行うことは非常に複雑になることがあります。
補足 ウィンドウズ 7 および Vista マシンでは、インターネット エクスプローラを介したブラウザ NTLM 認証を用いた RADIUS 認証を使うために追加の設定が必要です。 「ＲＡＤＩＵＳ認証の設定」 を参照してください。
RADIUS 設定を構成するには、「設定」 ボタンを選択して、「ＲＡＤＩＵＳ認証の設定」 の手順に従ってください。
ウィンドウズ上で NTLMv2 セッション セキュリティを設定する
マイクロソフト ウィンドウズ 7 および Vista では、インターネット エクスプローラは既定では NTLM のNTLMv2 変化形を使います。 NTLM と同じ方法では、NTLMv2 変化形は RADIUS を通して認証できません。 これらのバージョンのウィンドウズで SSO 方式としてブラウザ NTLM 認証を使用する場合は、NTLMv2 の代わりに NTLMv2 セッション セキュリティを使用するようにウィンドウズ マシンを構成する必要があります。 NTLMv2 セッション セキュリティ は、RADIUS/MSCHAPv2と互換性があるように設計されている変化形です。 この設定は、ウィンドウズ グループ ポリシーを使って行います。
ウィンドウズ 7 または Vista マシンをNTLMv2 セッション セキュリティ を使うように設定するには、以下の手順に従います。
･ NTLM 応答のみ送信する
･ LM と NTLM を送信する - ネゴシエーションの場合、NTLMv2 セッション セキュリティを使う
･ 「ネットワーク セキュリティ: NTLMを制限する: このドメイン内のNTLM認証」 を 「すべて拒否する」 に設定します。
･ 「ネットワーク セキュリティ: NTLMを制限する: リモート サーバーに対する送信 NTLM トラフィック」 を 「すべて拒否する」 に設定します。
それから、以下の 1 つまたは両方を行います。
･ 「ネットワーク セキュリティ: NTLMを制限する: NTLM 認証に対するリモート サーバーの例外を追加する」 の設定に、SonicWALL 装置のドメイン名か IP アドレスを追加します。
･ 「ネットワーク セキュリティ: NTLMを制限する: このドメインにサーバーの例外を追加する」 の設定に、SonicWALL 装置のドメイン名か IP アドレスを追加します。
ＬＤＡＰの詳細設定
「ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントのためのＳｏｎｉｃＷＡＬＬセキュリティ装置の設定」 の手順19で、「ユーザ」タブで「ＬＤＡＰを使用してユーザ グループ情報を検索する」を選択した場合は、ＬＤＡＰの設定を行う必要があります。 ＬＤＡＰの設定を行うには、以下の手順に従います。
･ 既定のＬＤＡＰポート － ３８９
･ 既定のＬＤＡＰ ｏｖｅｒ ＴＬＳポート － ６３６
ログイン名でツリーにアクセスするには、「ログイン名／ツリー内位置を渡す」を選択します。
識別名でツリーにアクセスするには、「識別名のバインドを渡す」を選択します。
補足 実際に使用するのは、ユーザ名やログインＩＤではなく、「ログイン ユーザ名」フィールドに入力したユーザの名前です。例えば、Ｊｏｈｎ Ｄｏｅという名前のユーザであれば、ｊｄｏｅではなく、Ｊｏｈｎ Ｄｏｅとしてログインする必要があります。
補足 「ＬＤＡＰ‘Ｓｔａｒｔ ＴＬＳ’要求を送信する」ボックスは、ＴＬＳと非ＴＬＳとで同じポート番号が使用される場合にのみ選択してください。
･ マイクロソフト アクティブ ディレクトリ
･ ＲＦＣ２７９８ ＩｎｅｔＯｒｇＰｅｒｓｏｎ
･ ＲＦＣ２３０７ネットワーク インフォメーション サービス
･ サンバＳＭＢ
･ ノベル イーディレクトリ
･ ユーザ定義
ウィンドウズには各ユーザがプライマリ ユーザ グループを持つというコンセプトがあり、これは通常ドメインのユーザに対してはＤｏｍａｉｎ Ｕｓｅｒｓ、管理者に対してはＡｄｍｉｎ Ｕｓｅｒｓ です。 しかしながら、ユーザのグループ メンバーシップに対するＬＤＡＰ検索は、アクティブ ディレクトリから返されるリスト内に、このプライマリ グループを含みません。 その結果、Ｄｏｍａｉｎ Ｕｓｅｒｓ または Ａｄｍｉｎ Ｕｓｅｒｓ に対するルールとポリシーの設定を許可するためには、装置はまた、ユーザのプライマリ ユーザ グループを独立したＬＤＡＰ検索を用いて取得する必要があります。
アクティブ ディレクトリ内ではユーザのプライマリ グループは、他のユーザ グループ メンバーシップのように名前で設定されていないために、検索のために属性を使う必要があります。 その代わり、これはユーザ オブジェクト内にＩＤ番号を与える ｐｒｉｍａｒｉＧｒｏｕｐＩＤ 属性を用いて設定されていて、このＩＤ番号はユーザ グループ オブジェクト内に ｐｒｉｍａｒｙＧｒｏｕｐＴｏｋｅｎ 属性を用いて与えられています。
これらのユーザ グループが装置上でグループ ポリシーを適用するために使われることを許可するには、ＬＤＡＰからユーザ オブジェクトをそのユーザ グループ メンバーシップと共に読み取った後で、装置はユーザ グループに対して ｐｒｉｍａｒｙＧｒｏｕｐＴｏｋｅｎ 属性をユーザの ｐｒｉｍａｒｉＧｒｏｕｐＩＤ 属性と照合させる追加の検索を実行する必要があります。
これらの属性の使用はユーザ グループ検索に追加の時間オーバーヘッドがかかるため、既定ではオフになっています。 ユーザのプライマリ ユーザ グループを検索するためには 「使用」 チェックボックスは有効にする必要があります。
これは本来アクティブ ディレクトリの属性用ですが、「追加ユーザ グループ ID 属性」 および 「追加ユーザ グループ一致属性」 に適切な属性値を設定することによる１つの追加ユーザ グループの検索を許可するために、どのようなスキーマでも動作できます。 アクティブ ディレクトリが選択されている場合、これらのフィールドの既定はｐｒｉｍａｒｉＧｒｏｕｐＩＤ および ｐｒｉｍａｒｙＧｒｏｕｐＴｏｋｅｎ です。
上記のすべてのツリーは、通常ＵＲＬ形式で指定しますが、識別名で指定することもできます （例えば、“ｍｙＤｏｍ.ｃｏｍ／Ｓａｌｅｓ／Ｕｓｅｒｓ”は“ｏｕ＝Ｕｓｅｒｓ，ｏｕ＝Ｓａｌｅｓ，ｄｃ＝ｍｙＤｏｍ，ｄｃ＝ｃｏｍ”というＤＮで指定することもできます）。後者の形式は、ＤＮがサンプルに示すような通常の書式ルールに従っていない場合に必要になります。アクティブ ディレクトリでは、ツリーの識別名に対応するＵＲＬが、ツリーの最上部にあるコンテナのプロパティの「オブジェクト」タブに表示されます。
補足 ＡＤには、通常の書式ルールに従っていないいくつかのビルトイン コンテナがあります （例えば、最上位のユーザ コンテナのＤＮは“ｃｎ＝Ｕｓｅｒｓ，ｄｃ＝．．．”というように、“ｏｕ”ではなく“ｃｎ”を使っています）。しかし、ＳｏｎｉｃＷＡＬＬはこれを認識して対処できるようになっているため、より簡易なＵＲＬ形式で入力することができます。
順序は重要ではありませんが、検索が特定の順序で行われることから、最も効率的な検索を行うためには頻繁に使用されるツリーを各リストの先頭に配置します。複数のＬＤＡＰサーバに渡った参照をする場合は、プライマリ サーバのツリーを最初に配置し、残りのツリーはサーバを参照する順に並べるようにすると、ツリーを最適に並べ替えることができます。
補足 ＡＤを使用している場合、「サーバ ログインに使用するユーザ ツリー」フィールドで指定したディレクトリのどの位置にユーザが含まれているかを確認するために、サーバ上の管理ツール内の「Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙユーザとコンピュータ」コントロール パネル アプレットを使用して、ディレクトリを手動で検索することができます。また、ウィンドウズＮＴ／２０００／ＸＰリソース キットに含まれるｑｕｅｒｙａｄ.ｖｂｓのようなディレクトリ検索ユーティリティをドメイン内の任意のＰＣ上で実行することもできます。
新しく検出されたツリーを現在の設定に追加するか、または現在設定されているすべてのツリーを削除してから新規に作り直すかを選択し、「ＯＫ」を選択します。ユーザ ログインには不必要なツリーが検出される場合もあるので、そのようなエントリは手動で削除することをお勧めします。
参照機能を使用して複数のＬＤＡＰ／ＡＤサーバを利用している場合は、「検索するドメイン」を適切な情報で置き換え、「現在のツリーに追加する」オプションを選択して、それぞれのサーバに対してこの処理を繰り返します。
･ 紹介を許可する － プライマリＬＤＡＰサーバ以外のＬＤＡＰサーバ上にユーザ情報がある場合に選択します。
･ ユーザ認証時の継続参照を許可する － 個々のディレクトリ ツリーが複数のＬＤＡＰサーバにまたがる場合に選択します。
･ ディレクトリの自動設定時の継続参照を許可する － １つの動作で複数のＬＤＡＰサーバからディレクトリ ツリーを読み出す場合に選択します。
･ ドメイン検索に継続参照を許可する － 複数のＬＤＡＰサーバでサブドメインを検索する場合に選択します。
ヒント 単にＬＤＡＰを使用してグループ メンバーシップ （と権限） を割り当てることもできます。ＳｏｎｉｃＷＡＬＬセキュリティ装置のビルトイン グループ （「ゲスト サービス」、「Ｃｏｎｔｅｎｔ Ｆｉｌｔｅｒｉｎｇ Ｂｙｐａｓｓ」、「Ｌｉｍｉｔｅｄ Ａｄｍｉｎｉｓｔｒａｔｏｒｓ」など） と同じ名前のユーザ グループをＬＤＡＰ／ＡＤサーバ上で作成し、ユーザをディレクトリ内のこれらのグループに割り当てることにより、または、既存のＬＤＡＰ／ＡＤユーザ グループと同じ名前のユーザ グループをＳｏｎｉｃＷＡＬＬセキュリティ装置上で作成することにより、ＬＤＡＰ認証が成功したときにＳｏｎｉｃＷＡＬＬグループ メンバーシップが与えられます。
アクティブ ディレクトリの場合、ＳｏｎｉｃＷＡＬＬセキュリティ装置は、独自仕様である戻り値‘ｍｅｍｂｅｒＯｆ’ユーザ属性を利用することにより、より効率的にグループ メンバーシップを取得できます。
さらに、拡張されていないファームウェアで実行されるリモートＳｏｎｉｃＷＡＬＬセキュリティ装置に対し、セントラルＳｏｎｉｃＷＡＬＬセキュリティ装置は、ＬＤＡＰを使用して取得したユーザ グループ メンバーシップに基づいて従来のユーザ権限情報を返すことができます。これにより、ＩＡＳのような外部ＲＡＤＩＵＳサーバの非常に複雑な設定を回避することができます。
･ 保護ゾーン
･ ＷＡＮゾーン
･ 公開ゾーン
･ 無線ゾーン
･ ＶＰＮゾーン
補足 「フィルタのバイパス」と「制限された管理機能へのアクセスを許可する」権限は、「Ｃｏｎｔｅｎｔ Ｆｉｌｔｅｒｉｎｇ Ｂｙｐａｓｓ」と「Ｌｉｍｉｔｅｄ Ａｄｍｉｎｉｓｔｒａｔｏｒｓ」のユーザ グループのメンバーシップに基づいて返されます。これらを設定することはできません。
「テスト」ページでは、指定したユーザとパスワード資格情報を使用して認証を試みることにより、設定されたＬＤＡＰ設定をテストすることができます。ユーザに対してＬＤＡＰ／ＡＤサーバ上で設定されたユーザ グループ メンバーシップや構築されたＩＰアドレスが表示されます。
補足 ＣＨＡＰは、ＬＤＡＰを使ってユーザ パスワードを取得できるサーバでのみ使用できます。場合によっては、パスワードを可逆的に保存するための設定をＬＤＡＰサーバに対して行う必要があります。ＣＨＡＰをアクティブ ディレクトリで使用することはできません。
シングル サイン オンの詳細設定の調整
このセクションでは、ＳｏｎｉｃＷＡＬＬ装置のＳＳＯの詳細設定の調整について説明します。以下のセクションを参照してください。
･ 「概要」
･ 「改善措置」
概要
ＳＳＯを使用しているＳｏｎｉｃＷＡＬＬを介して、ユーザが初めてトラフィックを送信しようとするとき、ＳｏｎｉｃＷＡＬＬ装置はＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントに“ｗｈｏ ｉｓ ｔｈｉｓ”要求を送信します。エージェントは、ウィンドウズ ネットワークを介してユーザのＰＣに問い合わせを行い、ＳｏｎｉｃＷＡＬＬ装置にユーザ名を返します。ユーザ名がポリシーに設定されているいずれかの条件に一致した場合、ＳｏｎｉｃＷＡＬＬはユーザが“ログオンしている”と見なします。ユーザがＳＳＯを使用してＳｏｎｉｃＷＡＬＬにログインしている場合、ＳＳＯ機能によってログアウトも検出されます。ログアウトを検出するため、ＳｏｎｉｃＷＡＬＬ装置はエージェントに繰り返しポーリングを行い、各ユーザがまだログインしているかどうか確認します。特に、非常に数多くのユーザが接続している場合、このポーリングと内部の識別要求によって、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェント アプリケーション、およびこのアプリケーションが動作しているＰＣに大きな負荷がかかることがあります。
ＳｏｎｉｃＷＡＬＬ ＳＳＯ機能は、速度制限メカニズムを利用して、ＳｏｎｉｃＷＡＬＬ装置がこのようなユーザ要求をＳＳＯエージェントに大量に送信しないようにします。自動計算と装置に設定できる項目の両方で、この速度制限の動作を制御します。ＳｏｎｉｃＷＡＬＬ ＳＳＯ機能は、最新のポーリング応答時間に基づいて、エージェントへの各メッセージに格納され、ポーリング期間中に処理できるユーザ要求の最大数を自動的に計算します。また、複数ユーザ要求時のタイムアウトは、ポーリング中にたまにタイムアウトが長くなる可能性を低減できるだけの値に自動的に設定されます。設定可能な項目で、一度にエージェントに送信する要求数を制御します。また、この項目を調整して、ＳＳＯのパフォーマンスを最適化し、潜在的な問題を防ぐことができます。このセクションは、適切な設定値を選択するための指針となります。
エージェントの過負荷によって問題が生じる可能性は、エージェントを専用の高性能ＰＣ上で動作させたり、複数エージェントを別個のＰＣ上で使用してＰＣ間で負荷を共有することによって、低減することができます。後者の方法では、エージェントＰＣのいずれかが故障した場合の冗長性も実現されます。エージェントは、ウィンドウズ サーバＰＣ上で動作させなければなりません （古いワークステーションの中には使用可能なものもありますが、ウィンドウズ ２０００／ＸＰ／Ｖｉｓｔａワークステーションの新しいリリースや、古いバージョン用のサービス パックにおける変更によって、ＳＳＯエージェントの動作を妨げるＴＣＰ接続速度制限機能が追加されました）。
詳細設定について
「一度に送信できる最大要求数」項目がＳＳＯエージェント設定の「詳細設定」タブに表示されます。
この項目は、ＳｏｎｉｃＷＡＬＬ装置からエージェントに一度に送信できる要求の最大数を制御します。エージェントは、各要求を処理する別個のスレッドをＰＣ内に生成し、複数の要求を同時に処理します。一度に送信する要求が多すぎると、エージェントが動作しているＰＣが過負荷になることがあります。送信する要求数が最大値を超えた場合、一部の要求は内部の“リング バッファ”キューに配置されます （「ＴＳＲのシングル サイン オン統計の利用」 および「マウスを移動したときに表示されるＳＳＯの統計とツール チップ」 を参照してください）。リング バッファでの要求の待機が長くなりすぎると、ＳＳＯ認証の応答時間が遅くなることがあります。
この項目は、ログインしているユーザの状況を確認するためのポーリング時に自動計算される、エージェントへのメッセージごとのユーザ要求数とともに機能します。メッセージごとのユーザ要求数は、最新のポーリング応答時間に基づいて計算されます。送信する必要があるメッセージ数が最小になるよう、ＳｏｎｉｃＯＳはこのユーザ要求数をできる限り大きく調整して、エージェントにかかる負荷を低減し、ＳｏｎｉｃＷＡＬＬ装置とエージェント間のネットワーク トラフィックを減らせるようにします。ただし、ユーザ要求数は、エージェントがメッセージに含まれる全ユーザ要求をポーリング期間内に処理できる値に保たれます。これによって、タイムアウトや、ログアウトしたユーザを迅速に検出できないなどの潜在的な問題を回避します。
マウスを移動したときに表示されるＳＳＯの統計とツール チップ
「ＳＳＯの設定」ページでは、各エージェントの上にマウスを移動すると、そのエージェントに関する統計が表示されます。また、多くのフィールド上にマウスを移動すると、そのフィールドに関するツール チップが表示されます。「設定」タブで、エージェントの横にある緑色のＬＥＤ形式のアイコンは、エージェントが稼働していることを示します。赤色のＬＥＤは、エージェントが停止していることを示します。
特定のエージェントの統計を表示するには、ＳＳＯエージェントの右にある統計アイコン 
の上にマウス ポインタを置きます。 これは、ターミナル サービス タブの個々のＴＳＡに対しても動作します。
統計の表示を閉じるには、「閉じる」を選択します。
表示されている値をすべてクリアするには、「リセットのために選択する」を選択します。
ＳＳＯの設定画面の多くのフィールドに対して、利用可能なツール チップを表示するには、そのフィールドの右側にある三角形のアイコンの上にマウス ポインタを置きます。ツール チップは、マウス ポインタをアイコン上から移動するまで表示されます。
ＴＳＲのシングル サイン オン統計の利用
トラブル シューティング レポート （ＴＳＲ） には、ＳＳＯのパフォーマンスとエラーに関する豊富な統計が含まれています。これらを利用して、インストールされているＳＳＯのパフォーマンスを測定することができます。「システム ＞ 診断」ページでＴＳＲをダウンロードして、“SSO operation statistics”というタイトルを検索してください。特に注意すべきカウンタは以下のとおりです。
1. 「･ コンテンツ フィルタを使用している場合は、ＳＳＯ設定の「強制」タブで、「次からのトラフィックに対してシングル サイン オン処理をバイパスする」設定にそのアドレス オブジェクトを選択します。
･ 認証済みのユーザのみを許可するようアクセス ルールが設定されている場合は、「許可するユーザ」を「すべて」にして、そのアドレス オブジェクト用の別個のルールを設定します。
補足 Ｍａｃ／Ｌｉｎｕｘ ＰＣのＩＰアドレスが表示されている場合は、「ＭａｃユーザおよびＬｉｎｕｘユーザへの対応」セクション を参照してください。
「ＳＳＯの設定」ページでのＳＳＯ統計の表示については、「マウスを移動したときに表示されるＳＳＯの統計とツール チップ」 を参照してください。
エージェントの検査
前述の統計が、エージェントに関して問題がある可能性を示している場合、次の手順としては、エージェントが動作しているＰＣ上でウィンドウズ タスク マネージャを実行し、「パフォーマンス」タブのＣＰＵ使用率と、「プロセス」タブの“ＣＩＡＳｅｒｖｉｃｅ.ｅｘｅ”プロセスのＣＰＵ使用率を調べることをお勧めします。後者はＣＰＵ時間の大部分を消費しており、ＣＰＵ使用率はほぼ１００％に急増しています。これは、エージェントが過負荷になっていることを示すものです。「一度に送信できる最大要求数」の値を小さくすることで、負荷を減らすことができます。前述の"ＴＳＲのシングル サイン オン統計の利用"の＃1を参照してください。
改善措置
設定でバランスを取ってエージェントのＰＣが過負荷にならないようにすることはできないが、まだ十分な速さでエージェントに要求を送信できている場合は、以下のアクションのいずれかを実行してください。
･ ポーリング時間を増やすことによって、「ユーザ」タブで設定されているポーリング間隔を低下させることを検討する。これを実行すると、エージェントにかかる負荷は減少しますが、ログアウトの検出は遅くなります。共有ＰＣ環境では、ポーリング間隔をできる限り短く保ち、異なるユーザが同じＰＣを使用する場合にログアウトを検出できないことから生じる可能性のある問題 （あるＰＣの２番目のユーザからの最初のトラフィックが、前のユーザが送信したものと記録される可能性があるなど） を回避することが最善の策かもしれないことに注意してください。
･ エージェントをより高性能な専用ＰＣに移動する。
･ １つまたは複数のエージェントを追加して設定する。
ファイアウォール アクセス ルールの設定
ＳｏｎｉｃＷＡＬＬ ＳＳＯを有効にすると、ＳｏｎｉｃＯＳ管理インターフェースの「ファイアウォール ＞ アクセス ルール」ページのポリシーに影響を与えます。「ファイアウォール ＞ アクセス ルール」に指定されたルールは、ＳＳＯ ＬＤＡＰ問い合わせで返されたユーザ グループ メンバーシップに照らしてチェックされ、自動的に適用されます。
詳細については、次の各セクションを参照してください。
ＳｏｎｉｃＷＡＬＬ ＳＳＯの自動生成ルール
ＳｏｎｉｃＯＳ管理インターフェースでＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントまたはＴＳＡを設定すると、エージェントからＬＡＮへの応答を許可するためのファイアウォール アクセス ルールと、対応するＮＡＴポリシーが作成されます。これらのルールは、ＳｏｎｉｃＷＡＬＬ ＳＳＯ Ａｇｅｎｔｓ または ＳｏｎｉｃＷＡＬＬ Ｔｅｒｍｉｎａｌ Ｓｅｒｖｉｃｅｓ Ａｇｅｎｔｓアドレス グループ オブジェクトのどちらかを使用します。このアドレス グループ オブジェクトは、設定されたエージェントごとにメンバー アドレス オブジェクトを持ちます。エージェントが追加または削除されると、メンバー アドレス オブジェクトも自動的にグループ オブジェクトに追加、またはグループ オブジェクトから削除されます。ＩＰアドレスがＤＮＳによって解決された （エージェントがＤＮＳ名で指定されている場合） ときなど、エージェントのＩＰアドレスが変更されると、メンバー アドレス オブジェクトも自動的に更新されます。
ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントまたはＴＳＡをさまざまなゾーンで設定すると、ファイアウォール アクセス ルールとＮＡＴポリシーが該当する各ゾーンに追加されます。各ゾーンで、同じＳｏｎｉｃＷＡＬＬ ＳＳＯ Ａｇｅｎｔｓ または ＳｏｎｉｃＷＡＬＬ Ｔｅｒｍｉｎａｌ Ｓｅｒｖｉｃｅｓ Ａｇｅｎｔｓアドレス グループが使用されます。
補足 ＳｏｎｉｃＷＡＬＬ ＳＳＯが使用されているゾーンではゲスト サービスを有効にしないでください。 ゲスト サービスを有効にすると、そのゾーンでのＳＳＯが無効化され、それによりＳＳＯを介して認証されるユーザがアクセスを失うことになります。 ゲスト サービスには個別のゾーンを作成してください。
ＭａｃユーザおよびＬｉｎｕｘユーザへの対応
ＭａｃおよびＬｉｎｕｘのシステムは、ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントが使用するウィンドウズのネットワーク要求をサポートせず、そのため、ＳｏｎｉｃＷＡＬＬ ＳＳＯが動作するためにはＳａｍｂａ ３.５以降が必要です。
Mac および Linux 上で Samba を用いて SSO を使用するウィンドウズ ユーザに対しては、SonicWALL SSO はSonicWALL セキュリティ装置によってウィンドウズ ドメイン内のユーザを自動的に認証するために使用されます。 これによりユーザは、ウィンドウズ ドメインへのログイン後に追加のログイン処理をして自身を識別する必要無しに、適切なフィルタとポリシー承諾を使って装置を通したアクセスを得ることが可能になります。
Samba は、Linux/Unix または Mac マシンで、ユーザにウィンドウズドメイン内のリソースへのアクセスを与える （Samba の smbclient ユーティリティを介して） ため、および／または、ウィンドウズ ドメイン ユーザにLinux や Mac マシン上のリソースへのアクセスを与える （Samba サーバを介して） ため に使われる、ソフトウェア パッケージです。
ウィンドウズ ドメイン内で Samba を用いて Linux PC または Mac 上で動作するユーザは、SonicWALL SSO によって識別可能ですが、それには、Linux/Mac マシンと SSO エージェントの適切な設定と、恐らく装置のいくつかの再設定が必要です。 例えば、以下の設定が必要です。
･ Linux/Mac ユーザで SonicWALL SSL を使うには、SonicWALL SSO エージェントがユーザのマシンからユーザのログイン情報を得るために、WMI ではなく NetAPI を使うように設定されている必要があります。
･ Samba がSonicWALL SSO エージェントからの要求を受信して応答するためには、ドメインのメンバーとして設定され、Samba サーバが動作してドメイン認証を使うように正しく設定されている必要があります。
これらの、およびその他の設定の詳細は、次のテックノートで説明されています。
http://www.sonicwall.com/downloads/Using_SSO_with_Samba_TechNote.pdf
SonicWALL SSO は、Samba 3.5 以降でサポートされます。
補足 Linux PC に複数のユーザがログインする場合は、その PC からのトラフィックへのアクセスは、最新のログインに基づいて与えられます。
Samba 無しでも、Mac および Linux ユーザはアクセスを得ることができますが、そのためには SonicWALL 装置にログインする必要があります。これにより、以下の問題が発生することがあります。
･ ユーザがログインするまで、ＭａｃまたはＬｉｎｕｘのシステムからのトラフィックによって、ＳＳＯ識別が開始され続けることがあります。そのようなシステムが多数ある場合は、これがＳＳＯシステムに対するパフォーマンスのオーバーヘッドとなる可能性がありますが、“失敗後の保留”タイムアウトによって影響は幾分緩和されます。
･ ユーザ レベル認証を要求するポリシー ルールがない状態で、ユーザごとのコンテンツ フィルタ （ＣＦＳ） ポリシーを使用する場合、最初に手動でログインするまで、ＭａｃおよびＬｉｎｕｘのシステムのユーザには既定のＣＦＳポリシーが適用されます。
･ ユーザ レベル認証を要求するようポリシー ルールが設定されている場合、ＭａｃおよびＬｉｎｕｘのシステムのユーザからのウェブ ブラウザ接続は、ＳＳＯの失敗後にログイン ページにリダイレクトされますが、失敗によってタイムアウトが発生し、ユーザに対して遅延が生じることがあります。
これらの問題を回避するため、「ファイアウォール ＞ アクセス ルール」ページで「追加」を選択してファイアウォール アクセス ルールを設定する （「表示形式」を「すべてのルールを表示」に設定） 際に、「ユーザ認証するためにシングル サイン オンを起動しない」チェックボックスを使用できます。このチェックボックスは、ＳｏｎｉｃＷＡＬＬ ＳＳＯが有効で、かつ「ルールの追加」ページの「許可するユーザ」フィールドが「すべて」に設定されていない場合にのみ表示されます。このチェックボックスをオンにすると、ルールに一致するトラフィックに対してＳＳＯが試みられなくなります。また、ルールに一致し、認証されていないＨＴＴＰ接続は、ログイン ページに直接リダイレクトされます。通常、「送信元」フィールドには、ＭａｃおよびＬｉｎｕｘのシステムのＩＰアドレスを含むアドレス オブジェクトが設定されます。
ＣＦＳの場合は、ＭａｃおよびＬｉｎｕｘのシステムからのＨＴＴＰセッションがログイン ページに自動的にリダイレクトされ、これらのシステムのユーザが手動でログインする必要がなくなるよう、ＣＦＳの“前”にこのチェックボックスをオンにしたルールを追加することができます。
補足 ユーザ認証プロセス全体のバイパスが許可されている機器に対しては、「ユーザ認証するためにシングル サイン オンを起動しない」オプションを選択しないでください。このオプションが有効になっているとき、アクセス ルールによって影響を受ける可能性がある機器は、手動ログイン可能でなければなりません。そのような機器に対しては、「許可するユーザ」を「すべて」に設定して、別個のアクセス ルールを追加してください。
SSO と認証をバイパスするために IP アドレスをホワイト リストに載せる
ユーザ認証を必要とせずに常にアクセスを許可すべき IP アドレスがある場合に、それらをホワイト リストに載せることができます。
IP アドレスをホワイト リストに載せ、認証を不要にして SSO をバイパスできるようにするには、以下の手順に従います。
既定の CFS ポリシーがこれらの IP アドレスのユーザに適用され、また、特定のユーザを含む IPS ポリシーや アプリケーション制御ポリシーは、彼らに適用されません。
この方法は少数の IP アドレスや、サブネットまたは IP アドレス範囲をホワイト リストに載せるために適しています。 多数の独立した IP アドレスに対しても動作しますが、むしろ効率が悪くなるでしょう。
CFS、IPS、アプリケーション制御で SSO が失敗した場合にユーザにログインを強制する
シングル サインオン (SSO) を介してユーザを識別できなかった場合に、ウェブ UI を介したログインを強制するアクセス ルールを使用できます。 ユーザは CFS、IPS、アプリケーション ルール、その他のポリシーが正しく適用されるように識別される必要があります。 アクセス ルールにより、SonicWALL がユーザに対してユーザ名とパスワードの入力を求めるようにできます。
特定の ユーザ/ユーザ グループ を 含む/除外 するように設定されている複数の CFS ポリシー、またはポリシーを持つ IPS、アプリケーション ルール、アプリケーション制御、アンチスパイウェア、DPI-SSLがある場合、SSO はユーザを識別するために開始されます。 既定では、SSO がユーザの識別に失敗すると、ユーザはファイアウォールを通したアクセスを与えられる一方、既定の CFS ポリシーにより抑制される、または IPS ポリシー、アプリケーション ルール、その他のポリシーが適用されずに抑制されます。
すべてのユーザに SSO が失敗した際に、ファイアウォールを通したアクセスを許可する前に、ユーザ名/パスワードを使うウェブ UI を介したログインを強制するために、上記のサービスとともに、アクセス ルールを使うことができます。 ユーザが認証されることを要求するアクセス ルールを設定して、そのルールはSSO を開始します。 この場合、SSO がユーザの識別に失敗しすると彼らは遮断され、HTTP の場合はログイン ページにリダイレクトされます。
2 つのうちの 1 つの方法でこれを実行できます。 ここでは送信元ゾーンは LAN として示されていますが、適用可能なゾーンどれでも可能です。
1. 既定の LAN -> WAN ルール内の 「
これら 2 つでは、オプション 1 はより安全なオプションですが、認証なしでアクセスが許可されるべき予期しない物を遮断することによって問題を起こす可能性はより高いです。
ターミナル サーバからのＩＣＭＰ ＰｉｎｇとＤＮＳを許可する
ウィンドウズでは、ターミナル サーバ上のユーザからの発信ＩＣＭＰ Ｐｉｎｇはソケットを介して送信されないためにＴＳＡから見えず、それゆえに装置はそれらに対しての通知を受け取りません。 その結果、ファイアウォール ルールがユーザ レベルの認証を使用していて、Ｐｉｎｇの通過を許可したい場合、それらを ”すべて”から許可するための個別のアクセスルールを作成する必要があります。
同様に、ＩＰアドレスではなく完全修飾ドメイン名（ＦＱＤＮ）を用いた発信ユーザ要求には、ＤＮＳトラフィックの通過が許可されている必要があります。 ターミナル サーバのユーザにＦＱＤＮの使用を許可するには、"すべて"からのＤＮＳトラフィックを許可するファイアウォール アクセス ルールを作成する必要があります。
ファイアウォール アクセス ルールについて
管理者は、ファイアウォール アクセス ルールを使ってユーザ アクセスを制御できます。「ファイアウォール ＞ アクセス ルール」に指定されたルールは、ＳＳＯ ＬＤＡＰ問い合わせで返されたユーザ グループ メンバーシップに照らしてチェックされ、自動的に適用されます。アクセス ルールは、着信および発信アクセス ポリシーの定義、ユーザ認証の設定、およびＳｏｎｉｃＷＡＬＬセキュリティ装置のリモート管理を可能にするネットワーク管理ツールです。ＳｏｎｉｃＯＳの「ファイアウォール ＞ アクセス ルール」ページには、並べ替え可能なアクセス ルール管理インターフェースが用意されています。
補足 限定的なポリシー規則には、汎用的なポリシー規則よりも高い優先順位を割り当てる必要があります。特性階層としては、一般に送信元、送信先、サービスが使用されます。ポリシー規則の特性定義に、ユーザ名や対応するグループ権限などのユーザＩＤ要素は含まれません。
既定では、ＳｏｎｉｃＷＡＬＬセキュリティ装置のステートフル パケット検査によって、ＬＡＮからインターネットへの通信をすべて許可し、インターネットからＬＡＮへのトラフィックをすべて遮断できます。
既定のアクセス ルールを拡張または指定変更する、追加のネットワーク アクセス ルールを定義することもできます。例えば、アクセス ルールを作成することによって、特定の種類のトラフィック （ＬＡＮからＷＡＮへのＩＲＣなど） を遮断したり、特定の種類のトラフィック （インターネット上の特定のホストからＬＡＮ上の特定のホストへのＬｏｔｕｓ Ｎｏｔｅｓデータベースの同期など） を許可したり、特定のプロトコル （Ｔｅｌｎｅｔなど） の使用をＬＡＮ上の承認されたユーザのみに制限したりすることができます。
補足 ネットワーク アクセス ルールを定義する機能は強力なツールです。個別アクセス ルールを使用して、ファイアウォールの保護を無効にしたり、インターネットへのアクセスをすべて遮断したりすることができます。ネットワーク アクセス ルールを作成または削除するときには注意が必要です。
アクセス ルールの詳細については、「ファイアウォール ＞ アクセス ルール」 を参照してください。
ターミナル サーバからのＨＴＴＰログインによるＳｏｎｉｃＯＳの管理
通常、ＳｏｎｉｃＷＡＬＬ装置は、ＨＴＴＰログインで指定された認証資格情報に基づくポリシーにより、１つのＩＰアドレスの１人のユーザに対してアクセス権を付与します。 ターミナル サーバを使用するユーザについては、ＩＰアドレスごとに１人のユーザというこの方法による認証は不可能です。 しかし、装置を管理する目的に限り、ターミナル サーバからのＨＴＴＰログインが認められています。 このとき、以下の制限および要件が適用されます。
･ ターミナル サーバからのインターネット アクセスはＴＳＡから制御され、ＨＴＴＰログインによるオーバーライドは行われません。 ターミナル サーバのユーザには、ＨＴＴＰログインで指定された資格情報に基づく装置へのアクセス権は付与されません。
･ ターミナル サーバからのＨＴＴＰログインは、組み込みのａｄｍｉｎアカウントおよび管理者権限を持つその他のユーザ アカウントに対してのみ許可されます。 管理者以外のアカウントからログインしようとすると、“この場所からは不許可”のエラーにより失敗します。
･ 管理者ユーザがＨＴＴＰログインに成功すると、直ちに管理インターフェースが表示されます。 小さな「ユーザ ログイン状況」ページは表示されません。
･ ターミナル サーバからのＨＴＴＰログインに使用する管理者ユーザ アカウントは、ターミナル サーバへのログインに使用したユーザ アカウントと同じである必要はありません。 装置上には、完全に別個のログイン セッションとして表示されます。
･ １つのターミナル サーバで装置を管理できるのは、１度に１人のユーザのみです。 ２人のユーザが同時に管理しようとすると、最後にログインしたユーザが優先され、もう１人のユーザには、“最後のログインに使用されたブラウザではありません”のエラーが表示されます。
･ ＴＳＡとの通信の問題によりユーザを識別できなかった場合、ＳＳＯの場合とは異なり、ＨＴＴＰブラウザ セッションはウェブ ログイン ページにリダイレクトされません。 代わりに、“ネットワーク問題により目的のページは一時的に利用不可になっています”というメッセージを示す新規ページが表示されます。
ＳＳＯユーザ セッションの表示および管理
このセクションでは、ＳｏｎｉｃＷＡＬＬ装置でのＳＳＯの管理について説明します。以下のセクションを参照してください。
ＳＳＯユーザのログアウト
「ユーザ ＞ 状況」ページには、ＳｏｎｉｃＷＡＬＬセキュリティ装置上の「現在のユーザ」の一覧が表示されます。このテーブルには、「ユーザ名」、「ＩＰアドレス」、「セッション時間」、「残り時間」、「残り無動作時間」、「設定」、および「ログアウト」が表示されます。ＳｏｎｉｃＷＡＬＬ ＳＳＯエージェントを使って認証されたユーザについては、ＳＳＯエージェントにより認証されたことを示すメッセージが表示されます。ユーザをログアウトさせるには、目的のユーザ エントリの横にある削除アイコン を選択します。
補足 「ユーザ ＞ 設定」で行ったユーザ設定の変更は、そのユーザのセッションが続いている間は反映されません。変更を反映するには、ユーザを手動でログアウトさせる必要があります。その後、変更が反映された状態で、ユーザが透過的に再度ログインされます。
追加のＳＳＯユーザ設定の構成
「ユーザ ＞ 設定」ページでは、管理者が、ＳＳＯなどのユーザ ログイン設定、ユーザ セッション設定、グローバル ユーザ設定、規約の承諾設定に関連した設定オプションを選択できるようになっています。
「ユーザ セッション設定」の「ウェブ接続のログイン セッション時間の制限を有効にする」および対応する「ログイン セッション時間の制限 （分）」設定は、ＳＳＯを使ってログインしたユーザに適用されます。ＳＳＯユーザはセッション時間の制限設定に従ってログアウトされますが、その後、トラフィックを送信すれば自動的にかつ透過的に再度ログインされます。
補足 ログイン セッション時間の制限の設定を小さくしすぎないように注意してください。特にユーザ数が多い環境では、パフォーマンス上の問題を引き起こす可能性があります。
ＳＳＯセッションがアクティブのときに「ユーザ ＞ 設定」ページで適用した変更は、そのセッション中は反映されません。
ヒント 変更を反映するには、ユーザをログ アウトさせる必要があります。その直後、変更が反映された状態で、ユーザが自動的に再度ログインされます。
パケット監視を使用したＳＳＯメッセージおよびＬＤＡＰメッセージの表示
ＳｏｎｉｃＯＳ ５.６以降では、「システム ＞ パケット監視」で利用できるパケット キャプチャ機能によって、ＳＳＯエージェントとの間の復号化されたメッセージと、復号化されたＬＤＡＰ ｏｖｅｒ ＴＬＳ （ＬＤＡＰＳ） メッセージのキャプチャを有効にするための２つのチェックボックスが提供されます。
ＳｏｎｉｃＯＳ ５.５では、「システム ＞ パケット キャプチャ」で使用できるパケット キャプチャ機能でこの機能が導入されました。
ＳＳＯメッセージのキャプチャ
ＳＳＯ認証エージェントとの間の復号化されたメッセージをキャプチャするには、以下の手順に従います。
パケットには、受信／送信インターフェース フィールドで （ＳＳＯ） というマークが付きます。 パケットにはダミーのイーサネット、ＴＣＰ、およびＩＰヘッダーがあるため、これらのフィールドの値は正しくないことがあります。
これによって、復号化されたＳＳＯパケットをパケット監視にフィードできますが、監視フィルタは引き続き適用されます。
キャプチャされたＳＳＯメッセージは、完全に復号化されて「システム ＞ パケット監視」画面に表示されます。
ＬＤＡＰ ｏｖｅｒ ＴＳＬメッセージのキャプチャ
復号化されたＬＤＡＰ ｏｖｅｒ ＴＬＳ （ＬＤＡＰＳ） パケットをキャプチャするには、以下の手順に従います。
パケットには、受信／送信インターフェース フィールドで （ｌｄｐ） というマークが付きます。パケットにはダミーのイーサネット、ＴＣＰ、およびＩＰヘッダーがあるため、これらのフィールドの値は正しくないことがあります。外部のキャプチャ解析プログラム （Ｗｉｒｅｓｈａｒｋなど） がこれらのパケットをＬＤＡＰとして復号化することを認識できるよう、ＬＤＡＰサーバ ポートは３８９に設定されます。キャプチャされたＬＤＡＰバインド要求内のパスワードは、難読化されます。ＬＤＡＰメッセージは、「パケット キャプチャ」画面では復号化されませんが、キャプチャをＷｉｒｅｓｈａｒｋにエクスポートして、復号化された状態で表示することができます。
これによって、復号化されたＬＤＡＰＳパケットをパケット監視にフィードできますが、監視フィルタは引き続き適用されます。パケット キャプチャを機能させるには、「中間パケットをキャプチャする」チェックボックスも選択する必要があります。
補足 ＬＤＡＰＳキャプチャは、ＳｏｎｉｃＷＡＬＬ装置のＬＤＡＰクライアントからの接続に対してのみ機能します。ＳｏｎｉｃＷＡＬＬ装置を通過した外部ＬＤＡＰクライアントからのＬＤＡＰ ｏｖｅｒ ＴＬＳ接続は表示されません。
複数管理者サポートの設定
このセクションは次のサブセクションから構成されています。
管理者ユーザ プロファイルの追加設定
管理者ユーザ プロファイルを追加設定するには、次の手順を実行します。
･ Ｌｉｍｉｔｅｄ Ａｄｍｉｎｉｓｔｒａｔｏｒｓ － ユーザには、制限付きの管理者設定権限が付与されます。
･ ＳｏｎｉｃＷＡＬＬ Ａｄｍｉｎｉｓｔｒａｔｏｒｓ － ユーザには、完全な管理者設定権限が付与されます。
･ ＳｏｎｉｃＷＡＬＬ Ｒｅａｄ-Ｏｎｌｙ Ａｄｍｉｎｓ － ユーザは、管理インターフェース全体を閲覧できますが、設定に変更を加えることは一切できません。
ＬＤＡＰまたはＲＡＤＩＵＳ使用時の管理者のローカル設定
ＲＡＤＩＵＳまたはＬＤＡＰ認証を使用しているとき、ＲＡＤＩＵＳまたはＬＤＡＰサーバが到達不能であっても管理者ユーザの一部または全員が常に装置を管理できるようにしたい場合は、「ＲＡＤＩＵＳ＋ローカル ユーザ」または「ＬＤＡＰ＋ローカル ユーザ」オプションを選択し、これらの特定のユーザのアカウントをローカルで設定します。
ＲＡＤＩＵＳまたはＬＤＡＰによって認証されるユーザについて、「ＳｏｎｉｃＷＡＬＬ Ａｄｍｉｎｉｓｔｒａｔｏｒｓ」または「ＳｏｎｉｃＷＡＬＬ Ｒｅａｄ-Ｏｎｌｙ Ａｄｍｉｎｓ」という名前のユーザ グループをＲＡＤＩＵＳサーバまたはＬＤＡＰサーバ （またはそのバックエンド） 上に作成し、これらのグループに適切なユーザを割り当てます。ＲＡＤＩＵＳの場合、ユーザ グループ情報を返すための特別な設定がＲＡＤＩＵＳサーバに必要となります。詳細については、ＳｏｎｉｃＷＡＬＬ ＲＡＤＩＵＳのドキュメントを参照してください。
ＲＡＤＩＵＳまたはＬＤＡＰ認証を使用しているとき、管理者ユーザをＲＡＤＩＵＳ／ＬＤＡＰで認証すると共に、管理者ユーザの設定を装置上でローカルに管理したい場合は、次の手順を実行します。
管理者の先制
ある管理者が既にログインしているときに、別の管理者がログインを試みると、次のメッセージが表示されます。このメッセージには、現在の管理者のユーザ名、ＩＰアドレス、電話番号 （ＬＤＡＰから取得できた場合） のほか、その管理者がＧＵＩでログインしたのか、ＣＬＩでログインしたのかが表示されます。
このウィンドウでは、次の３つのオプションを選択できます。
･ 続行 － 現在の管理者を先制します。現在の管理者は非設定モードに降格され、新しい管理者に完全な管理者アクセス権が付与されます。
･ 非設定モード － 装置に非設定モードでログインします。現在の管理者のセッションはそのまま維持されます。
･ キャンセル － 認証画面に戻ります。
設定モードの有効化
完全な管理者権限を持つユーザ （つまりａｄｍｉｎ以外のユーザ） としてログインしている場合、「ユーザ ログインの状態」ウィンドウが表示されます。
ＳｏｎｉｃＷＡＬＬのユーザ インターフェースにアクセスし、「管理」ボタンを選択します。パスワードの再入力を求められます。これは、管理者がセッションをログアウトせずに自分のコンピュータから離れている隙に不正アクセスされるのを防ぐための措置です。
ユーザ ログイン状況ポップアップの無効化
装置への特権的なアクセスのためではなく、装置の管理のためだけに特定のユーザにログインを許可する場合は、「ユーザ ログイン状況」ポップアップ ウィンドウを無効にするとよいでしょう。このポップアップ ウィンドウを無効にするには、ローカル グループの追加または編集の際に「メンバーはウェブ ログイン時に管理ＵＩに直接進む」チェックボックスをオンにします。
一部のユーザ アカウントを管理専用にして、他のユーザが装置への特権的なアクセスとその管理を行う場合にはログインを要求する （つまり、一部のユーザにはログイン時に管理インターフェースを直接表示し、他のユーザには「管理」ボタンが付いた「ユーザ ログイン状況」ポップアップ ウィンドウを表示する） には、次の手順に従います。
非設定モードから完全設定モードに切り替えるには、次の手順を実行します。
複数管理者サポートの設定の確認
管理者および読み取り専用管理者のユーザ アカウントは、「ユーザ ＞ ローカル グループ」ページで確認できます。
管理者は、管理インターフェースの右上隅またはブラウザのステータス バーで現在の設定モードを確認できます。
Ｆｉｒｅｆｏｘおよびインターネット エクスプローラでステータス バーを表示するには、「表示」メニューを選択し、「ステータス バー」を有効にします。インターネット エクスプローラ７.０およびＦｉｒｅｆｏｘ ２.０の場合、既定ではウェブ ページがステータス バーにテキストを表示することは許可されません。インターネット エクスプローラでステータス バー メッセージを許可するには、「ツール ＞ インターネット オプション」を選択し、「セキュリティ」タブを選択します。次に、「レベルのカスタマイズ」ボタンを選択し、リストの一番下までスクロールして、「スクリプトでのステータス バーの更新を許可する」に「有効にする」を選択します。
Ｆｉｒｅｆｏｘでステータス バー メッセージを許可するには、「ツール ＞ オプション」にアクセスし、「コンテンツ」タブを選択します。「詳細設定」ボタンを選択すると、ポップアップ ウィンドウが表示されるので、「ステータス バーのテキストを変更する」のチェックボックスを選択します。
管理者が完全設定モードの場合、右上隅にメッセージは表示されず、ステータス バーに「終了」と表示されます。
複数管理者関連のログ メッセージの表示
次のイベントが発生した場合、ログ メッセージが生成されます。
･ ＧＵＩまたはＣＬＩユーザが設定モードを開始した （ａｄｍｉｎログイン時など）。
･ ＧＵＩまたはＣＬＩユーザが設定モードを終了した （ａｄｍｉｎログアウト時など）。
･ ＧＵＩユーザが非設定モードでの管理を開始した （ａｄｍｉｎログイン時や、設定モードのユーザが先制されて読み取り専用モードに降格された時など）。
･ ＧＵＩユーザが読み取り専用モードで管理を開始した。
ＧＵＩユーザが上記のいずれかの管理セッションを終了した （ａｄｍｉｎログアウト時など）。