を選択します。「グローバル ポリシーの編集」ウィンドウが表示されます。Use_Cases
この付録では、次の使用事例を紹介します。
この使用事例では、goDaddy証明書とサーバ証明書という2つの証明書をインポートします。以下のセクションを参照してください。
この使用事例では、ウィンドウズ システム上でgoDaddyルートCA証明書をフォーマットし、それをSRA装置にインポートます。
1. goDaddy.p7bファイルをダブルクリックして「証明書」ウィンドウを開き、goDaddy証明書にナビゲートします。
.p7b形式はPKCS#7形式の証明書ファイルであり、ごく一般的な証明書形式です。
2. 証明書ファイルをダブルクリックし、「詳細」タブを選択します。
3. 「ファイルにコピー」を選択します。証明書のエクスポート ウィザードが起動します。
4. 証明書のエクスポート ウィザードで、「次へ」を選択します。
5. 「Base 64 encoded X.509 (CER)」を選択し、「次へ」を選択します。
6. 「エクスポートするファイル」画面で、ファイル名としてgoDaddy.cerを入力し、「次へ」を選択します。
7. 証明書のエクスポートの完了ウィザードの画面で、パスと形式を確認し、「終了」を選択します。
8. 確認のダイアログ ボックスで「OK」を選択します。
証明書がBase 64 encoded形式でエクスポートされます。これはテキスト エディタで表示することができます。
9. SRA管理インターフェースで、「システム > 証明書」にナビゲートします。
10. 「追加のCA証明書」セクションで、「CA証明書のインポート」を選択します。「証明書のインポート」ウィンドウが表示されます。
11. 「証明書のインポート」ウィンドウで「参照」を選択し、ウィンドウズ システム上のgoDaddy.cerファイルにナビゲートし、それをダブルクリックします。
12. 「アップロード」を選択します。証明書が「追加のCA証明書」テーブル内に表示されます。
13. 「システム > 再起動」にナビゲートし、SRA装置を再起動して、CA証明書を有効にします。
この使用事例では、マイクロソフトCAサーバ証明書をウィンドウズ システムにインポートします。ここでの目的は、メール サーバへのアプリケーション オフロードにSSL証明書を使用することにあります。
サーバ証明書はmail.chaoslabs.nlです。この証明書をserver.crtファイルとしてbase 64形式にエクスポートする必要があります。このファイルを.zipファイルに入れ、サーバ証明書としてアップロードします。
.p7bファイルには秘密鍵は含まれていません。秘密鍵を所定の場所からエクスポートし、base 64形式で保存し、.zipファイル内のserver.keyファイルに含める必要があります。
1. mail.chaoslabs.nl.pb7ファイルをダブルクリックし、証明書にナビゲートします。
2. 証明書ファイルをダブルクリックし、「詳細」タブを選択します。
3. 「ファイルにコピー」を選択します。
4. 証明書のエクスポート ウィザードで、「Base 64 encoded X.509 (CER)」を選択します。
5. 「次へ」を選択し、ファイルをserver.crtとしてウィンドウズ システム上に保存します。
証明書がBase 64 encoded形式でエクスポートされます。
6. server.crtファイルを.zipファイルに追加します。
7. 秘密鍵は別にserver.keyとしてBase 64形式で保存します。
8. server.crtを入れた.zipファイルにserver.keyファイルを 追加します。
9. .zipファイルをサーバ証明書としてサーバにアップロードします。
この使用事例では、アウトルック ウェブ アクセス (OWA) リソースをSRA装置に追加します。また、複数のアクティブ ディレクトリ (AD) グループのユーザに対するアクセス ポリシーを設定する必要があります。ADグループごとにローカル グループを作成し、それぞれのローカル グループに別々のアクセス ポリシーを適用します。
アクティブ ディレクトリではユーザは複数のグループのメンバーなれますが、SRA装置では各ユーザが1つのグループにしか属せません。ユーザに割り当てられるアクセス ポリシーはこのグループによって決まります。
ADからユーザをインポートすると、そのユーザは最も多くのADグループを持つローカルSRAグループに入れられます。例: BobはUsers、Administrators、Engineeringの各ADグループに属しています。UsersにあるSRAグループが関連付けられていて、AdministratorsとEngineeringの両方に別のSRAグループに関連付けられているとすると、BobはAdministratorsとEngineeringのSRAグループに割り当てられます。なぜなら、そのSRAグループのほうが、Bobの属しているADグループが多いからです。
この使用事例の目的は、次の設定を行うことにより、Dell SonicWALL SRAファームウェアがグループベースのアクセス ポリシーをサポートしていることを示すことにあります。
• アクティブ ディレクトリのAcme Groupに対して、10.200.1.102のサーバへのSSHによるアクセスを許可する。
• アクティブ ディレクトリのMega Groupに対して、10.200.1.10のアウトルック ウェブ アクセス (OWA) へのアクセスを許可する。
• アクティブ ディレクトリのIT Groupに対して、上述したSSHとOWAの両方のリソースへのアクセスを許可する。
• 他のすべてのグループに対して、これらのリソースへのアクセスを拒否する。
この設定例は、Vincent Caiの好意によって2008年6月に提供されたものです。
Figure C:1 ネットワーク トポロジ
以下のセクションの順番に従ってタスクを実行します。
このセクションでは、SRAローカル ドメインであるSNWL_ADの作成方法を説明します。SNWL_ADはOWAサーバのアクティブ ディレクトリ ドメインと関連付けられています。
1. SRA管理インターフェースにログインし、「ポータル > ドメイン」ページにナビゲートします。
2. 「ドメインの追加」を選択します。「ドメインの追加」ウィンドウが表示されます。
3. 「認証種別」ドロップダウン リストから「アクティブ ディレクトリ」を選択します。
4. 「ドメイン名」フィールドにSNWL_ADと入力します。
5. 「アクティブ ディレクトリ ドメイン」フィールドに、ADドメイン名としてin.loraxmfg.comと入力します。
6. 「サーバ アドレス」フィールドに、OWAサーバのIPアドレスとして10.200.1.10と入力します。
7. 「追加」を選択します。
8. 「ポータル > ドメイン」ページで新しいドメインを確認します。
この手順では、明示的な許可ポリシーが設定されたグループを除く全グループに対してOWAリソースへのアクセスを拒否するポリシーを作成します。
SRAの既定のポリシーはすべて許可です。よりきめ細かな制御を行うため、ここですべて拒否ポリシーを追加します。後でグループごとに一度に1つずつ許可ポリシーを追加することができます。
1. 「ユーザ > ローカル ユーザ」ページを開きます。
2. 「グローバル ポリシー」行の「設定」ボタン を選択します。「グローバル ポリシーの編集」ウィンドウが表示されます。
3. 「グローバル ポリシーの編集」ウィンドウで「ポリシー」タブを選択します。
4. 「ポリシーの追加」を選択します。「ポリシーの追加」ウィンドウが表示されます。
5. 「ポリシーの適用先」ドロップダウン リストから「IPアドレス範囲」を選択します。
6. 「ポリシー名」フィールドに、すべて拒否と入力します。
7. 「IPネットワーク アドレス」フィールドに、ネットワーク アドレスとして10.200.1.0と入力します。
8. 「サブネット マスク」フィールドに、10進形式のサブネット マスクとして 255.255.255.0と入力します。
9. 「サービス」ドロップダウン リストから「すべてのサービス」を選択します。
10. 「状況」ドロップダウン リストから「拒否」を選択します。
11. 「追加」を選択します。
12. 「グローバル ポリシーの編集」ウィンドウで、すべて拒否ポリシー設定を確認し、「OK」を選択します。
この手順では、SRA装置上のSNWL_ADドメインに属するローカル グループを作成します。アクティブ ディレクトリ グループごとにローカル グループを1つずつ作成します。
ローカル グループの追加
1. 「ユーザ > ローカル グループ」ページにナビゲートし、「グループの追加」を選択します。「ローカル グループの追加」ウィンドウが表示されます。3つのアクティブ ディレクトリ グループに対応して、3つのローカル グループを追加することにします。
2. 「ローカル グループの追加」ウィンドウの「グループ名」フィールドにAcme_Groupと入力します。
3. 「ドメイン」ドロップダウン リストから「SNWL_AD」を選択します。
4. 「追加」を選択します。
5. 「ユーザ > ローカル グループ」ページで「グループの追加」を選択して、2番目のローカル グループを追加します。
6. 「ローカル グループの追加」ウィンドウの「グループ名」フィールドにMega_Groupと入力します。
7. 「ドメイン」ドロップダウン リストから「SNWL_AD」を選択します。
8. 「追加」を選択します。
9. 「ユーザ > ローカル グループ」ページで「グループの追加」を選択して、2番目のローカル グループを追加します。
10. 「ローカル グループの追加」ウィンドウの「グループ名」フィールドにIT_Groupと入力します。
11. 「ドメイン」ドロップダウン リストから「SNWL_AD」を選択します。
12. 「追加」を選択します。
13. 「ユーザ > ローカル グループ」ページで、追加したグループを確認します。
ローカル グループの設定
この手順では、新たに作成した各ローカル グループを編集し、それぞれを対応するアクティブ ディレクトリ グループと関連付けます。
1. 「Acme_Group」行の「設定」ボタンを選択します。「グループ設定の編集」ウィンドウが表示されます。
2. 「グループ設定の編集」ウィンドウで「ADグループ」タブを選択します。
3. 「ADグループ」タブで「グループの追加」ボタンを選択します。
4. 「アクティブ ディレクトリ グループの編集」ウィンドウの「アクティブ ディレクトリ グループ」ドロップダウン リストから「Acme Group」を選択します。
5. 「編集」を選択します。
「ADグループ」タブの「アクティブ ディレクトリ グループ」テーブルに「Acme Group」が表示されます。
6. 「グループ設定の編集」ウィンドウで「OK」を選択します。
7. 「ユーザ > ローカル グループ」ページで、「Mega_Group」行の「設定」ボタンを選択します。「グループ設定の編集」ウィンドウが表示されます。
8. 「グループ設定の編集」ウィンドウで「ADグループ」タブを選択し、「グループの追加」ボタンを選択します。
9. 「アクティブ ディレクトリ グループの編集」ウィンドウの「アクティブ ディレクトリ グループ」ドロップダウン リストから「Mega Group」を選択し、「編集」を選択します。
「ADグループ」タブの「アクティブ ディレクトリ グループ」テーブルに「Mega Group」が表示されます。
10. 「グループ設定の編集」ウィンドウで「OK」を選択します。
11. 「ユーザ > ローカル グループ」ページで、「IT_Group」行の「設定」ボタンを選択します。「グループ設定の編集」ウィンドウが表示されます。
12. 「グループ設定の編集」ウィンドウで「ADグループ」タブを選択し、「グループの追加」ボタンを選択します。
13. 「アクティブ ディレクトリ グループの編集」ウィンドウの「アクティブ ディレクトリ グループ」ドロップダウン リストから「IT Group」を選択し、「編集」を選択します。
「ADグループ」タブの「アクティブ ディレクトリ グループ」テーブルに「IT Group」が表示されます。
14. 「グループ設定の編集」ウィンドウで「OK」を選択します。
以上で、3つのローカル グループを作成し、それぞれをアクティブ ディレクトリ グループと関連付けたことになります。
このセクションでは、Acme_GroupとIT_Groupの両方に対して10.200.1.102のサーバへのSSHによるアクセスを許可するSSHv2許可ポリシーを追加します。
この手順では、Acme_GroupというSRAローカル グループのためのポリシーを作成して、Acme Groupというアクティブ ディレクトリ グループのメンバーにSSHアクセスを許可します。
IT_Groupについても同じ手順を繰り返し、それによってIT Groupアクティブ ディレクトリ グループのメンバーにもSSHアクセスを許可します。
1. 「ユーザ > ローカル グループ」ページで、「Acme_Group」行の「設定」ボタンを選択します。「グループ設定の編集」ウィンドウが表示されます。
2. 「グループ設定の編集」ウィンドウで「ポリシー」タブを選択します。
3. 「ポリシー」タブで「ポリシーの追加」を選択します。
4. 「ポリシーの追加」ウィンドウの「ポリシーの適用先」ドロップダウン リストから「IPアドレス」を選択します。
5. 「ポリシー名」フィールドにSSH許可と入力します。
6. 「IPアドレス」フィールドに、ターゲット サーバのIPアドレスとして10.202.1.102と入力します。
7. 「サービス」ドロップダウン リストから「セキュア シェル バージョン2 (SSHv2)」を選択します。
8. 「状況」ドロップダウン リストから「許可」を選択し、「追加」を選択します。
9. 「グループ設定の編集」ウィンドウで「OK」を選択します。
このセクションでは、Mega_GroupとIT_Groupの両方に対してOWAサービスへのセキュア ウェブ (HTTPS)によるアクセスを許可する2つのOWA許可ポリシーを追加します。
この手順では、Mega_GroupというSRAローカル グループのためのポリシーを作成して、Mega Groupというアクティブ ディレクトリ グループのメンバーにOWAアクセスを許可します。
Exchangeサーバにアクセスするには、10.200.1.10/exchange URLオブジェクト自体に許可ポリシーを追加するだけでは十分ではありません。10.200.1.10/exchwebへのアクセスを許可するURLオブジェクト ポリシーも必要です。なぜなら、OWAウェブ コンテンツの中にはexchwebディレクトリに置かれているものもあるからです。
IT_Groupについても同じ手順を繰り返し、それによってIT Groupアクティブ ディレクトリ グループのメンバーにもOWAアクセスを許可します。
Note この設定では、IT_GroupとMega_Groupのメンバーは 〈https://owa-server/public〉 フォルダへのアクセスを拒否されます。なぜなら、これらのグループは/exchangeサブフォルダと/exchwebサブフォルダにしかアクセスできないからです。
OWAはウェブ サービスなので、これらのOWAポリシーはサーバIPアドレスではなく、ExchangeサーバURLオブジェクトに適用されます。
1. 「ユーザ > ローカル グループ」ページで、「Mega_Group」行の「設定」ボタンを選択します。Mega_GroupがOWA Exchangeサーバにアクセスできるようにするため、2つの許可ポリシーを作成することにします。
2. 「グループ設定の編集」ウィンドウで「ポリシー」タブを選択し、「ポリシーの追加」を選択します。
3. 「ポリシーの追加」ウィンドウの「ポリシーの適用先」ドロップダウン リストから「URLオブジェクト」を選択します。
4. 「ポリシー名」フィールドにOWAと入力します。
5. 「サービス」ドロップダウン リストから「セキュア ウェブ (HTTPS)」を選択します。
6. 「URL」フィールドに、ターゲット アプリケーションのURLとして10.200.1.10/exchangeと入力します。
7. 「状況」ドロップダウン リストから「許可」を選択し、「追加」を選択します。
8. 「グループ設定の編集」ウィンドウの「ポリシー」タブで、「ポリシーの追加」を選択します。
9. 「ポリシーの追加」ウィンドウの「ポリシーの適用先」ドロップダウン リストから「URLオブジェクト」を選択します。
10. 「ポリシー名」フィールドにOWA exchwebと入力します。
11. 「サービス」ドロップダウン リストから「ウェブ (HTTPS)」を選択します。
12. 「URL」フィールドに、ターゲット アプリケーションのURLとして10.200.1.10/exchwebと入力します。
13. 「状況」ドロップダウン リストから「許可」を選択し、「追加」を選択します。
14. 「グループ設定の編集」ウィンドウで「OK」を選択します。これでMega_Group用のポリシーは完成しました。IT_Groupについても同じ手順を繰り返し、それによってIT Groupアクティブ ディレクトリ グループのメンバーにもOWAアクセスを許可します。
この時点で次のような設定になっています。
• Acme_Groupのユーザには10.200.1.102へのSSHアクセスが許可されている。
• Mega_Groupのユーザには10.200.1.10のOWAへのアクセスが許可されている。
• IT_Groupのユーザには上述したSSHとOWAの両方へのアクセスが許可されている。
この設定を確認するには、別々のADグループのメンバーとしてSRA装置上のSNWL_ADドメインにログインし、これらのリソースへのアクセスを試みます。
テスト結果: acmeuser によるアクセスの試み
acmeuserがSNWL_ADドメインにログインします。
「ユーザ > 状況」ページに、acmeuserがAcme_Groupローカル グループのメンバーであることが示されます。
acmeuserは予想どおりSSHアクセスができます。
acmeuserは他のリソース (OWA 10.200.1.10など) へのアクセスを試みますが、予想どおり拒否されます。
テスト結果: megauser によるアクセスの試み
megauserがSNWL_ADドメインにログインします。
「ユーザ > 状況」ページに、megauserがMega_Groupローカル グループのメンバーであることが示されます。
megauserは予想どおりOWAリソースにアクセスできます。
megauserはSSHアクセスを試みますが、予想どおり拒否されます。
テスト結果: ituser によるアクセスの試み
ituserがSNWL_ADドメインにログインします。「ユーザ > 状況」ページに、ituserがIT_Groupローカル グループのメンバーであることが示されます。
ituserは予想どおり10.200.1.102へのSSHアクセスができます。
ituserは予想どおりOWAリソースにアクセスできます。
