プロファイル

Ericom Shieldは、お客様の環境で使用される認証方法に従って、いくつかの認証方法(ベーシック認証、KerberosおよびDLAP)をサポートしています。 認証方法とそれに関連する設定は、ページの上部に定義されています。

LDAPがシステムに定義されている場合、Active DirectoryグループをShield のプロファイル フォームでサポートすることができます。 これにより、特定のプロファイルごとに ポリシー および アプリケーション セクションで正確な定義が可能になります。 詳細は、指定されたセクションを参照してください。 プロファイルは、ページの下部に作成され、管理されます。

../../_images/Profile7.png

認証

Shieldではいくつかの認証方法が利用できます:Basic, Kerberos, LDAP,認証連鎖

認証連鎖

この認証方法は、ユーザーの詳細がShield以外の異なるコンポーネントによって事前に認証されている場合に使用されます。 この場合、追加の認証は必要ありません。

有効

この認証方法を有効または無効にします。 このメソッドが有効の場合、他の認証方法は自動的に無効になります(LDAPとの組み合わせは可能です)。

信頼するIP アドレス

ユーザーの詳細をShieldに送信するために信頼されている送信元IPアドレスを定義します。 ユーザーの詳細は、X-Authenticated-Userヘッダーを介して受信されます。 この場合、他の認証は行われません。

次の構文を使用してください。

  • IP アドレス - 例: 126.0.2.50
  • サブネット - 例: 126.01.1.1/16
  • 範囲 - 例: 126.0.0.0-126.255.255.255

参考

0.0.0.0/0.0.0.0 に設定すると、任意のアドレスからの接続が許可されます。

Basic認証

Basic認証には、ユーザーがプロキシにログインするための資格情報の設定が含まれます。

有効

このメソッドが有効の場合、他の認証メソッドは自動的に無効になります。

ユーザー名・ パスワード

プロキシ認証のためのBasic認証情報(ユーザ名・パスワード)

メッセージ

新しいタブを開いているときにユーザーに表示するカスタマイズ可能なプロンプトメッセージ。

資格情報TTL(分)

資格情報の 生存時間 。 この期間が過ぎると、新しいタブを開くときに資格情報が再度必要になります。

Active Directory認証

追加の認証方法には、KerberosとLDAP認証が含まれます。 両方の方法に関連する共通の設定と、各認証方法の特定の設定があります。

プライマリディレクトリとセカンダリの2つのActive Directoryを定義できます。プライマリ AD が完全に定義されると、セカンダリ AD を定義することが可能になります。

ユーザーは、UPN形式 (username@domain.com など) と SamAccountName 形式 (domain.comusername など) の両方でShieldに接続できます。これは、すべてのActive Directory(プライマリおよびセカンダリ)で可能です。

プライマリActive Directory設定

Kerberos と LDAP の両方に共通する次の設定をグループ化します。

ドメイン

接続先の Active Directory ドメイン名。

DC アドレス

接続先のドメイン コントローラの IP アドレス。複数の値をコンマ 「,」 で区切って定義できます。

セキュアなドメインコントローラとの通信

ドメインコントローラーとの通信をSSLで保護する必要がある場合に選択します。

ベース DN

ベースDN - ドメイン名のルート。カンマで区切ります。(例: DC=COMPANY、DC=LOCAL

参考

Active DirectoryをShieldに接続するには、指定されたユーザーを作成する必要があります。このユーザー資格情報は、以下に説明するようにフィールドに入力する必要があります。

ドメインユーザー名

Active Directoryに登録された、Shieldユーザーのユーザー名を入力します。 ユーザー名のみ。ドメインなし、接尾辞なし。(例: 「shieldUser」)

パスワード

指定したActive Directory上のShieldユーザーのパスワードを入力します。

代替UPNサフィックス

ドメインコントローラの代替 UPN サフィックス。複数の値をコンマ 「,」 で区切って定義できます。

参考

ドメイン名がdomain.comで、定義されているサフィックスがドメインABCの場合、george というユーザーは、george@domain、ABCgeorge、domain.comgeorgeなどの方法でシステムに接続できます。

セカンダリ Active Directory - セカンダリ Active Directory を定義するには、このオプション (プライマリ AD が完全に定義された後のみ) を選択します。このオプションを選択すると、プライマリ Active Directory と同じ設定を含む セカンダリ Active Directory 設定 という名前の新しいサブセクションが表示されます。

セカンダリ Active Directoryが定義され、削除する必要がある場合は、セカンダリ Active Directoryの削除 オプションを選択します。確認ダイアログが表示され、セカンダリ Active Directoryが削除されることを確認すると、次のダイアログが表示されます。

参考

このセクションで行われたその他の変更はすべて、セカンダリ Active Directory の削除 操作によってコミットされます。

Kerberos

Kerberos 設定には、次の設定が含まれます。

有効

この認証方法を有効または無効にします。 この方法はLDAPのみで有効にすることができます。それ以外の場合、他の認証方法は自動的に無効になります。

サービス プリンシパル名

サービスインスタンスの一意の識別子。接続するブラウザーが認証のために使用します。プロキシホスト名とドメイン名(Active Directoryドメイン名、 常に大文字 )から構築されます。ホスト名はDNSで認識されている必要があります。特定のIP(nslookup [IP])に関連付けられたホスト名が1つだけであることを確認することは重要です。正しい構文は次のとおりです:HTTP/<hostname>@<domain>(例: HTTP/Shieldnode.company.local@COMPANY.LOCAL )

Keytab

生成 オプションを選択すると、コマンドが記載されたポップアップが開きます。

../../_images/generate7.png

このコマンドをコピーし、それを使用してKeytabファイルを作成します。 完了したら、Keytabファイルを選択して管理者にアップロードします。 Keytabファイルが既に存在する場合、アップロードは直接行われます。 Keytabファイルは、 サービスプリンシパル名 で指定されている同じマシンと一致することが不可欠です。

NTLMへのフォールバック

Kerberos認証中にエラーが発生した場合の代替メカニズムとしてNTLMを使用するかどうかを選択します。

LDAP

LDAP設定には、次の設定が含まれます。

有効

この認証方法を有効または無効にします。 このメソッドは、Kerberos認証メソッドまたは認証連鎖メソッドでのみ有効にできます。

Proxy メッセージ

プロキシにログインするために、新しいタブを開いているときにユーザーに表示するカスタマイズ可能なプロンプトメッセージ。

参考

このメッセージは、ASCII文字コードのみ をサポートしています。

管理者ログインにActive Directory プロファイルを利用する

この設定は、LDAPが有効になっている場合にのみ表示されます。LDAPプロファイルを使用して管理コンソールにログインするかどうかを定義します(この場合、デフォルトのユーザーを使用します)。 はい に設定した場合、管理コンソールにログインできるユーザーのActive Directoryグループを定義します。このオプションは、LDAPが正しく定義され、関連するすべての設定が保存されている場合にのみ使用できます。それ以前は、LDAP グループを取得できません。

参考

この設定を「はい」に設定すると、管理コンソールへのログインはADプロファイルのみを使用して行われます。このシナリオでは、LDAPが有効になっていることが重要です。

Active Directory 管理者ユーザーグループ

(LDAPグループのリストから)管理コンソールにログインできるユーザーのActive Directoryグループを選択します。 前の設定が はい に設定されている場合、この設定には値が必要です。 必要なグループの名前を入力して、グループのリストを取得します。 リストを取得したら、管理コンソールにログインできるユーザーのグループを1つ選択します。

参考

LDAPグループのリストは、LDAPが適切に定義され、関連するすべての設定が保存される場合にのみ表示されます。

LDAP認証またはKerberos認証が有効の場合、Basic認証は自動的に無効になります。

両方の認証方法(Kerberos / LDAP)を同時に有効にすることができます。

参考

Kerberosを使用する場合 - プロキシサーバーはそのIPアドレスではなくその名前で参照されなければ なりません 。 ユーザーがプロキシに接続するときは、サーバー名 のみで 行う必要があります。 さらに、特定のIP(nslookup [IP])に関連付けられているホスト名が1つだけであることを確認することが 肝心 です。 つまり、Kerberos認証が正しく機能するためには、LinuxマシンをDNSに登録する必要があります。

Ericom Shieldには、Kerberosプロトコルを使用してドメインユーザーを認証し、LDAPグループの探索を実行するための専用のユーザーアカウントが必要です。 詳細な手順(実際の例を含む)については、 こちら を参照してください。

有効な認証方法(Kerberos / LDAP)が多いほど、ユーザーの資格情報を入力する頻度が少なくなります。 これは、ブラウザが認証に最適なメソッドを簡単に選択し、そのメソッドが失敗した場合にのみユーザーに認証を促すためです。 たとえば、ドメイン上のプロキシにアクセスしているユーザがマシンに参加した場合、ブラウザはまずKerberosを介して認証を試みます。 成功した場合は、認証のプロンプトを表示せずにページが表示されます。

保存をクリックしてください。 これで、 プロファイル を作成し、各プロファイルに関連するポリシーを定義することができます。 詳細は下記をご覧ください。

既存の設定の更新

認証設定セクションの既存の情報( domain / Base DN ** フィールドなど)を更新する場合 - このアクションにより、定義済みのプロファイルがすべて削除され、関連するポリシーも削除されます。いったん削除すると、これらの項目は復元できず、再入力する必要があります。重要な構成を失うことを避けるために、更新プログラムを慎重に適用することが **重要 です。その他のフィールドは、プロファイルやポリシーに影響を与えずに必要に応じて更新できます。 更新によってこれらの項目が削除される場合は、次のメッセージが表示されます。

../../_images/savesettingsconfirmation7.png

妥当性チェックは、認証の 有効 なメソッドに対してのみ実行されます。 更新された情報が有効でないか正しくない場合は、エラーメッセージが表示されます。

プロファイルテーブル

このテーブルには、システムで定義されている既存のプロファイルが表示されます。 プロファイルはActive Directoryグループに割り当てられ、管理者は特定のグループメンバーシップに基づいて異なるユーザーに別々のポリシーを適用できます。 利用可能なアクションは、 プロファイルの追加プロファイルの削除、および``プロファイルの更新`` です。

../../_images/ProfilesTable7.png

テーブルには、 All というデフォルトのプロファイルが含まれています。 ポリシーテーブルに定義されている特定のプロファイルに関連していないすべてのポリシー(URL)は、デフォルトで All プロファイルに紐づきます。

新しいプロファイルを作成するには プロファイルの追加 オプションを選択してください。プロファイル名を入力し、1つ以上の Active Directory グループに関連付けます。コメントフィールドはオプションです。

参考

このオプションは、LDAP 対応設定が はい に設定されている場合にのみ使用できます。

プロファイルが作成されると、ポリシーを定義し、このプロファイルにポリシーを割り当てることが可能です。プロファイルのポリシーの設定の詳細については、 ポリシー を参照してください。

既存のプロファイルを編集するには、テーブル内の特定のエントリを選択し、プロファイルの詳細と共にダイアログが表示されます。必要に応じてフィールドを変更します。コメントフィールドを除くすべてのフィールドに値が必要です。

プロファイルの削除 オプションを使用してプロファイルが削除された場合、関連するすべてのポリシーも削除されます。 このアクションは不可逆的なので、アクションを実行するかどうかを確認するメッセージが表示されます。

../../_images/deleteProfileMessage7.png

関連するポリシーを削除しないようにするには、最初にポリシーセクションのポリシーを表示し、削除されずに残るものに割り当てなおします。

参考

各ユーザーが単一のShieldプロファイルにのみ関連付けられることを強くお勧めします。ユーザーが複数の Active Directory グループに関連付けられている場合、これによって複数のShieldプロファイルが発生し、Shieldポリシーの適用が不整合になる可能性があります。

高度な構成で複数の認証方法を使用する場合は、 こちら. を参照してください。