test

Sun Java System Messaging Server 6.3 管理ガイド

第 23 章 セキュリティーとアクセス制御を設定する

Messaging Server は、広範囲にわたる柔軟なセキュリティー機能をサポートします。これらの機能を使用して、メッセージが横取りされないようにしたり、侵入者がユーザーや管理者になりすますことを防いだり、メッセージングシステム内の特定部分へのアクセスを特定のユーザーだけに許可したりできます。

Messaging Server のセキュリティーアーキテクチャーは、Sun Java System サーバー全体のセキュリティーアーキテクチャーの一部です。このアーキテクチャーは、最大の相互運用性と一貫性を実現するために業界標準と公開プロトコルに基づいて構築されています。

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

23.1 サーバーのセキュリティーについて

サーバーのセキュリティーには広範囲にわたる説明が含まれます。ほとんどの企業では、承認されたユーザーだけがサーバーにアクセスできること、パスワードや識別情報が安全なこと、ほかのユーザーになりすました通信ができないこと、必要に応じて通信の機密性を確保できることなどがすべてメッセージングシステムの重要な要件になります。

サーバーのセキュリティーはさまざまな方法で攻撃される可能性があるため、さまざまな方法でセキュリティーを強化します。この章では、暗号化、認証、アクセス制御の設定に重点を置きます。この章で説明する Messaging Server のセキュリティー関連の内容は、次のとおりです。

この章では、Messaging Server に関連するすべてのセキュリティーとアクセスの問題について説明するわけではありません。この章で説明していないセキュリティー関連の項目として、次のものがあります。

セキュリティーに関するさまざまな説明を含んだ数多くのマニュアルがあります。この章に記載した内容の背景情報や、その他のセキュリティー関連情報については、文書 Web サイト (http://docs.sun.com) を参照してください。

23.2 HTTP のセキュリティーについて

Messaging Server は、ユーザー ID とパスワード認証、クライアント証明書認証、および Access Manager をサポートしています。ただし、クライアントとサーバー間におけるネットワーク接続の処理方法は、この 2 つのプロトコルでいくつか異なります。

POP、IMAP、または SMTP クライアントが Messaging Server にログインすると、接続が確立され、セッションが開始されます。この接続は、セッションの間中、すなわちログインからログアウトまで維持されます。新しい接続を確立する場合は、クライアントが再びサーバーで認証される必要があります。

HTTP クライアントが Messaging Server にログインする場合は、サーバーからクライアントに固有のセッション ID が与えられます。クライアントは、このセッション ID を使って、セッション中に複数の接続を確立できます。HTTP クライアントは接続するたびに再認証を行う必要はありません。ただし、セッションが切断された場合やクライアントが新しいセッションを確率する必要がある場合だけは、クライアントが、再び認証を行う必要があります。指定した時間にわたり HTTP セッションのアイドル状態が続くと、サーバーは自動的に HTTP セッションを切断し、クライアントがログアウトされます。デフォルトの時間は 2 時間です。

HTTP セッションのセキュリティーを向上させるには、次の方法を使用します。

設定パラメータを指定して接続のパフォーマンスを向上させる方法については、第 5 章「POP、IMAP、および HTTP サービスの設定」を参照してください。

Access Manager の詳細については、第 6 章「シングルサインオン (SSO) の有効化」を参照してください。

23.3 認証メカニズムを構成する

認証メカニズムは、クライアントが識別情報をサーバーに提示する方法の 1 つです。Messaging Server は SASL (Simple Authentication and Security Layer) プロトコルで定義されている認証方法をサポートし、さらに、証明書に基づく認証もサポートしますこの節では、SASL による認証メカニズムについて説明します。証明書に基づく認証の詳細は、「23.5 暗号化と証明書に基づく認証を構成する」を参照してください。

Messaging Server は、パスワードに基づく認証の場合、次の SASL 認証方法をサポートします。

注 –

この機能は、推奨されておらず、将来のリリースで削除される予定です。

チャレンジ/応答型の認証メカニズムでは、サーバーからクライアントにチャレンジ文字列が送られます。クライアントは、そのチャレンジのハッシュとユーザーのパスワードを使用して応答します。クライアントの応答がサーバー自体のハッシュと一致すると、ユーザーが認証されます。ハッシュは元のデータに戻すことができないため、ネットワークを介して送信してもユーザーのパスワードが危険にさらされることはありません。

注 –

POP、IMAP、および SMTP サービスは、すべての SASL メカニズムをサポートします。HTTP サービスは、プレーンテキストパスワードによるメカニズムだけをサポートします。

表 23–1 に、SASL および SASL 関連の configutil パラメータの一部を示します。configutil パラメータがもっとも多く挙げられている最新のリストについては、『Sun Java System Messaging Server 6.3 Administration Reference』の「configutil Parameters」を参照してください。

表 23–1 SASL および SASL 関連の configutil パラメータの一部

パラメータ 

説明 

sasl.default.ldap.has_plain_passwords

ブール代数値です。ディレクトリがプレーンテキストパスワードを格納していることを示します。この値により APOP、CRAM-MD5、および DIGEST-MD5 が有効になります。 

デフォルト: False 

sasl.default.transition_criteria

サポートされず使用されません。sasl.default.auto_transition を参照してください。

sasl.default.auto_transition

ブール型です。設定し、ユーザーがプレーンテキストのパスワードを入力した場合、パスワード保存形式がディレクトリサーバーのデフォルトのパスワード保存形式に移行されます。プレーンテキストのパスワードから、APOP、CRAM-MD5 または DIGEST-MD5 への移行に使用することができます。 

デフォルト: False 

service.imap.allowanonymouslogin

IMAP による使用のため、SASL ANONYMOUS メカニズムを有効にします。 

デフォルト: False 

service.{imap|pop|http}.plaintextmincipher

0 より大きな値に設定すると、セキュリティーレイヤー (SSL または TLS) が有効でないかぎり、プレーンテキストのパスワードの使用を無効にします。これによりユーザーは、ログインする自分のクライアントで SSL または TLS を強制的に有効にすることになり、自分のパスワードがネットワーク上で漏洩することを防ぎます。MMP には同等のオプション「RestrictPlainPasswords」があります。 

注: Messaging Server の 5.2 リリースでは、SSL または TLS が使用する暗号の強度の数値が調べられます。この機能はオプションの簡潔化のため、また一般的な使用法に合わせるため削除されました。 

デフォルト: 0 

sasl.default.mech_list

有効にする SASL メカニズムの、スペース区切りのリストです。空でない場合、この設定は sasl.default.ldap.has_plain_passwords オプションおよび service.imap.allowanonymouslogin オプションよりも優先します。このオプションは、すべてのプロトコル (imap、pop、smtp) に適用されます。

デフォルト: False 

sasl.default.ldap.searchfilter

ユーザーがドメインの inetDomainSearchFilter に指定されていない場合に、ユーザーの検索に使用されるデフォルトの検索フィルタです。構文は inetDomainSearchFilter と同じです (スキーマガイドを参照)。

デフォルト: (&(uid=%U)(objectclass=inetmailuser))

sasl.default.ldap.searchfordomain

デフォルトでは、認証システムは LDAP 内のドメインをドメイン検索のルールに従って検索し (参照は必要)、その後ユーザーを検索します。ただし、このオプションがデフォルトの「1」ではなく「0」に設定されている場合、ドメイン検索は行われず、sasl.default.ldap.searchfilter を使用したユーザーの検索が local.ugldapbasedn で指定した LDAP ツリーの直下で行われます。旧バージョンの単一ドメインスキーマとの互換性のために提供されていますが、小さな企業であっても合併や名称変更により複数ドメインのサポートが必要になる可能性があるため、新しい配備のための使用にはお勧めしません。

23.3.1 プレーンテキストパスワードへのアクセスを構成する

CRAM-MD5、DIGEST-MD5、または APOP SASL の認証メソッドでは、ユーザーのプレーンテキストパスワードにアクセスする必要があります。次の手順を実行する必要があります。

  1. パスワードがクリアテキストで保存されるように Directory Server を構成します。

  2. Directory Server がクリアテキストのパスワードを使用していることを認識できるように、Messaging Server を構成します。

Procedureパスワードがクリアテキストで保存されるように Directory Server を構成する

CRAM-MD5、DIGEST-MD5、または APOP メカニズムを有効にするには、パスワードがクリアテキストで保存されるように Directory Server を構成する必要があります。バージョン 6 より前の Directory Server を使用している場合は、次の手順が適用されます。バージョン 6 以降については、Directory Server の最新のマニュアル (『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』) を参照してください。

  1. ディレクトリサーバーコンソールで、構成する Directory Server を開きます。

  2. 「設定」タブをクリックします。

  3. 左のペインで「Data」を開きます。

  4. 右のペインで「パスワード」をクリックします。

  5. 「パスワードの暗号化」ドロップダウンリストで「cleartext」を選択します。

    注 –

    この変更は、将来作成するユーザーにのみ影響を与えます。既存のユーザーは、この変更を加えたあとで移行するか、パスワードを再設定する必要があります。

23.3.1.1 クリアテキストのパスワード用に Messaging Server を設定する

次に、Directory Server がクリアテキストのパスワードを使用していることを認識できるように Messaging Server を構成することができます。これにより、Messaging Server で APOP、CRAM-MD5、および DIGEST-MD5 を安全に使用できるようになります。

configutil -o sasl.default.ldap.has_plain_passwords -v 1

値を 0 に設定すると、これらのチャレンジ/応答型の SASL メカニズムを無効にすることができます。

注 –

既存のユーザーは、パスワードを再設定または移行するまで APOP、CRAM-MD5、または DIGEST-MD5 を使用できません (次の「ユーザーを移行する」を参照)。

MMP には同等のオプション「CRAM」があります。

23.3.2 ユーザーを移行する

configutil を使用して、移行するユーザーに関する情報を指定できます。たとえば、ユーザーパスワードを変更する場合や、適切なユーザーエントリがないメカニズムを使ってクライアントが認証を試みている場合に、この情報を指定します。

configutil -o sasl.default.auto_transition -v value

value には、次のいずれかを指定できます。

ユーザーを正常に移行するには、Messaging Server がユーザーパスワード属性に書き込みアクセスできるように、Directory Server の ACI を設定する必要があります。次の手順を実行して確認します。

Procedureユーザーを移行する

バージョン 6 より前の Directory Server を使用している場合は、次の手順が適用されます。バージョン 6 以降については、Directory Server の最新のマニュアル (『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』) を参照してください。

  1. コンソールで、構成する Directory Server を開きます。

  2. 「ディレクトリ」タブをクリックします。

  3. ユーザー/グループツリーのベースサフィックスを選択します。

  4. 「オブジェクト」メニューから「アクセス権を設定」を選択します。

  5. 「Messaging Server End User Administrator Write Access Rights (Messaging Server エンドユーザー管理者書き込みアクセス権)」に対する ACI を選択 (ダブルクリック) します。

  6. 「ACI 属性」をクリックします。

  7. 既存の属性のリストに userpassword 属性を追加します。

  8. 「了解」をクリックします。

    sasl.default.mech_list を使用して SASL メカニズムのリストを有効にできます。空でない場合、この設定は sasl.default.ldap.has_plain_passwords オプションおよび service.imap.allowanonymouslogin オプションよりも優先します。このオプションは、すべてのプロトコル (imap、pop、smtp) に適用されます。

23.4 ユーザーパスワードログイン

Messaging Server にログインしてメールの送受信を行うには、ユーザーがパスワードを入力する必要があります。これは承認されていないアクセスを防ぐための最初の防御手段です。Messaging Server では、IMAP、POP、HTTP、および SMTP の各サービスに対して、パスワードに基づくログインがサポートされています。

23.4.1 IMAP、POP、HTTP のパスワードログイン

デフォルトでは、内部ユーザーは、Messaging Server からメッセージを取得するためにパスワードを送信する必要があります。POP、IMAP、HTTP のサービスごとにパスワードログインを有効または無効にできます。POP、IMAP、HTTP サービスのパスワードログインの詳細は、「5.2.2 パスワードに基づくログイン」を参照してください。

ユーザーパスワードは、クリアテキストまたは暗号文の形式で、ユーザーのクライアントソフトウェアからサーバーに転送できます。クライアントとサーバーの両方が、SSL を使用できるように構成され、かつ必要な強度の暗号化 (「23.5.2 SSL を有効化し暗号化方式を選択する」を参照) をサポートしている場合に、暗号化が実行されます。

ユーザー ID とパスワードは、LDAP ユーザーディレクトリに保存されます。最小長などのパスワードに関するセキュリティー条件は、ディレクトリポリシーの要件によって決まり、Messaging Server では管理されません。

パスワードに基づくログインの代わりに証明書に基づくログインを使用できます。証明書に基づくログインについては、SSL の説明とともにこの章で後述します。「23.5.3 証明書に基づくログインを設定する」を参照してください。

プレーンテキストパスワードによるログインの代わりに、チャレンジ/応答型の SASL メカニズムを使用できます。

23.4.2 SMTP パスワードログイン

デフォルトでは、Messaging Server の SMTP サービスに接続してメッセージを送信する場合に、ユーザーはパスワードを入力する必要がありません。しかし、認証 SMTP を使用可能にするために、SMTP サービスへのパスワードログインを有効にすることができます。

「認証 SMTP」とは、クライアントがサーバーに対して認証を行うことを可能にする、SMTP プロトコルの拡張機能のことです。認証は、メッセージの送受信時に実行されます。認証 SMTP の主要な用途は、ほかのユーザーが悪用できるオープンリレーの発生を防ぎながら、ローカルユーザーが移動先から (または自宅用の ISP を使用して) メールを送信 (リレー) できるようにすることです。クライアントは、「AUTH」コマンドを使用してサーバーに対する認証を行います。

SMTP パスワードログイン (すなわち認証 SMTP) を有効にする方法については、「12.4.4 SMTP 認証、SASL、TLS」を参照してください。

認証 SMTP は、SSL 暗号化とともに使用することも、SSL 暗号化を使わずに使用することもできます。

23.5 暗号化と証明書に基づく認証を構成する

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

Messaging Server では、クライアントとサーバー間で、暗号化された通信および証明書に基づく認証を行うために TLS (Transport Layer Security) プロトコルを使用します。TLS プロトコルは、SSL (Secure Sockets Layer) プロトコルとも呼ばれます。Messaging Server は、SSL バージョン 3.0 および 3.1 をサポートします。TLS には、SSL との完全な互換性があり、必要な SSL 機能がすべて含まれています。

SSL に関する背景情報については、『Managing Servers With iPlanet Console 5.0 』の「Introduction to SSL」を参照してください。SSL は、公開鍵暗号方式の概念に基づいています。この概念については、『Managing Servers With iPlanet Console 5.0 』の「Introduction to Public-Key Cryptography」を参照してください。

Messaging Server とそのクライアント間、および Messaging Server とほかのサーバー間におけるメッセージの転送が暗号化される場合は、通信が盗聴される危険性はほとんどありません。また、接続しているクライアントが認証済みの場合は、侵入者がそれらのクライアントになりすます (スプーフィングする) 危険性もほとんどありません。

SSL は、IMAP4、HTTP、POP3 および SMTP のアプリケーションレイヤーの下のプロトコルレイヤーとして機能します。SMTP と SMTP/SSL は同じポートを使用しますが、HTTP と HTTP/SSL は異なるポートを必要とします。IMAP と IMAP/SSL、POP と POP/SSL は、同じポートを使用することも異なるポートを使用することもできます。図 23–1 に示すように、SSL は、送信メッセージと着信メッセージの両方で、メッセージ通信の特定の段階で作用します。

図 23–1 Messaging Server での暗号化された通信

この図では、暗号化された受信メッセージおよび送信メッセージを示します。

SSL は、ホップ間の暗号化を提供しますが、中間にある各サーバー上ではメッセージは暗号化されません。

注 –

送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytls や musttls などの tls チャネルキーワードを追加する必要があります。詳細は、「12.4.7 Transport Layer Security」のマニュアルを参照してください。

SSL 接続を設定する際のオーバーヘッドによって、サーバーのパフォーマンスが低下する可能性があります。メッセージングシステムの設計とパフォーマンスの分析を行う際には、セキュリティー要件とサーバーのパフォーマンスのバランスをとる必要があります。

23.5.1 証明書の入手

SSL の用途が暗号化か認証かにかかわらず、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、使用するサーバーの識別情報をクライアントや他のサーバーに提供します。証明書を入手するためのもっとも効率的な方法は、msgcert コマンド (この節のあとの方で説明) の使用です。古い certutil コマンドもまだ機能しますが、新しいコマンドに比べてずっと複雑で、グローバル化もされていないことに注意してください。certutil の詳細は、「23.5 暗号化と証明書に基づく認証を構成する」および http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html を参照してください。

23.5.1.1 内部モジュールと外部モジュールを管理する

サーバー証明書によって、キーのペアの所有権と有効性が確立されます。キーのペアは、データの暗号化と解読に使用される数値です。サーバーの証明書とキーのペアは、そのサーバーの識別情報を示します。これらは、サーバー内部または取り外し可能な外部のハードウェアカード (スマートカード) の証明書データベース内に保存されます。

Sun Java System サーバーは、PKCS (Public-Key Cryptography System) #11 API に準拠するモジュールを使用して、キーと証明書のデータベースにアクセスします。通常、特定のハードウェアデバイスの PKCS #11 モジュールは、そのデバイスの供給元から入手できます。Messaging Server でそのデバイスを使用する前に、このモジュールを Messaging Server にインストールする必要があります。Messaging Server にプリインストールされている「Netscape Internal PKCS # 11 Module」は、サーバー内部の証明書データベースを使用する単一の内部ソフトウェアトークンをサポートします。

証明書を使用できるようにサーバーを設定する場合は、証明書とそのキーを格納するためのデータベースを作成し、PKCS #11 モジュールをインストールする必要があります。外部のハードウェアトークンを使用しない場合は、サーバー上に内部データベースを作成し、Messaging Server に含まれるデフォルトの内部モジュールを使用します。外部トークンを使用する場合は、スマートカードリーダーハードウェアを接続し、そのハードウェアの PKCS #11 モジュールをインストールします。

注 –

以降の節では、コンソールまたはディレクトリサーバーコンソールについて触れています。これは、バージョン 6 より前の Directory Server を指しています。バージョン 6 以降では、グラフィカルユーザーインタフェースは Directory Server Control Center と呼ばれています。詳細は、Directory Server の最新のマニュアル (『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』) を参照してください。

外部モジュールか内部モジュールかにかかわらず、PKCS #11 モジュールは、コンソールを使用して管理できます。PKCS #11 モジュールをインストールするには、次の手順を実行します。

  1. カードリーダーハードウェアを Messaging Server ホストマシンに接続し、ドライバをインストールします。

  2. msg-svr-base/sbin にある modutil を使用して、インストールしたドライバ用の PKCS #11 モジュールをインストールします。

ハードウェア暗号化アクセラレータのインストール暗号化用に SSL を使用する場合は、ハードウェア暗号化アクセラレータをインストールすることによって、メッセージの暗号化と解読のパフォーマンスを向上させることができます。一般的に、暗号化アクセラレータは、サーバーマシンに常設されたハードウェアボードとソフトウェアドライバで構成されます。Messaging Server は、PKCS #11 API に準拠したアクセラレータモジュールをサポートしています。これらは、基本的に独自のキーを格納しないハードウェアトークンで、キーの格納には内部データベースが使用されます。まず、製造元の指示に従ってハードウェアとドライバをインストールすることにより、アクセラレータをインストールします。その後、PKCS #11 モジュールをインストールすることにより、ハードウェア証明書トークンをインストールします。

23.5.1.2 パスワードファイルの作成

SSL を有効にしている Sun Java System サーバーでは、ほとんどの場合、起動時に管理者がキーのペアの解読に必要なパスワードを入力します。ただし、Messaging Server では、パスワードを何度も入力する手間を省き (少なくとも 3 つのサーバープロセスで入力が必要)、さらに無人でサーバーを再起動できるように、パスワードファイルからパスワードが読み取られます。パスワード自体は、msgcert generate_certdb コマンドを使用して証明書データベースが作成されるときに生成されます。

パスワードファイルは、sslpassword.conf という名前で、ディレクトリ msg-svr-base/config/ に保存されています。ファイル内の各エントリは、次の形式で 1 行ずつ記述されます。

moduleName:password

moduleName は使用される (内部または外部) PKCS #11 モジュールの名前です。password はそのモジュールのキーのペアを暗号化するためのパスワードです。パスワードは、クリアテキスト (暗号化されていないテキスト) として保存されます。

Messaging Server には、デフォルトのパスワードファイルが用意されています。このファイルには、次のような内部モジュールとデフォルトのパスワードのエントリが 1 つだけ含まれています。

Internal (Software) Token:netscape!

内部証明書をインストールするときにデフォルト以外のパスワードを指定する場合は、指定するパスワードに合わせてパスワードファイル内の上記の行を編集する必要があります。外部モジュールをインストールする場合は、ファイルに新しい行を追加し、モジュール名とモジュール用に指定するパスワードを記述する必要があります。

注意 – 注意 –

管理者はサーバー起動時にモジュールパスワードの入力を要求されません。そのため、管理者のアクセスが適切に制御されていること、およびサーバーホストマシンとそのバックアップの物理的なセキュリティーが確保されていることの確認が重要になります。

23.5.1.3 証明書の入手と管理

SSL の用途が暗号化か認証かにかかわらず、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、使用するサーバーの識別情報をクライアントや他のサーバーに提供します。証明書を取得して管理するための主なメカニズムとして、msgcert を使用します。ただし、管理サーバーがインストールされている場合は、管理コンソールも使用できます。

この節の残りの部分では、msgcert を使用する方法について説明します。

23.5.1.4 msgcert について

msgcert を使用すると、証明書要求の生成、証明書データベースへの証明書の追加、データベース内の証明書の一覧表示などを行うことができます。詳細な情報を表示するには、コマンド行で次のコマンドを入力します。

msg-svr-base/sbin/msgcert --help

次の情報が表示されます。


# ./msgcert --help

Usage: msgcert SUBCMD [GLOBAL_OPTS] [SUBCMD_OPTS] [SUBCMD_OPERANDS]
Manages the Messaging Servers Certificate Database
The accepted values for SUBCMD are:

add-cert              Adds a certificate to the certificate database
add-selfsign-cert     Creates and adds a selfsign certificate to the 
                      certificate database
export-cert           Exports a certificate and its keys from the database
generate-certDB       Creates Messaging Server Databases cert8.db key3.db 
                      secmod.db and sslPassword
import-cert           Adds a new certificate and its keys to the cert database
import-selfsign-cert  Adds a new selfsign certificate and its keys to the 
                      cert database
list-certs            Lists all certificates in the Certificate database
remove-cert           Removes a certificate from the database
renew-cert            Renews a certificate
renew-selfsign-cert   Renews a selfsign certificate
request-cert          Generates a certificate request
show-cert             Displays a certificate

The accepted value for GLOBAL_OPTS is:-?, --help
                Displays SUBCMD help

NOTE: You must stop all the TLS or SSL-enabled servers before making any 
changes to the Certificate Database.

上に示されている各サブコマンドが、特定の証明書管理機能を実行します。これらのサブコマンドやその機能に関する詳細情報を得るには、次のコマンドを入力します。

msgcert SUBCMD –help

この節の残りの部分では、いくつかの一般的な証明書管理手順について説明します。

23.5.1.5 証明書を管理する

ここでは、Messaging Server で SSL 証明書を管理する方法について説明します。Messaging Server で SSL を実行するには、自己署名付き証明書か、または外部の認証局 (CA) を含む公開鍵インフラストラクチャー (PKI) ソリューションのどちらかを使用してください。PKI ソリューションの場合は、公開鍵と非公開鍵の両方を含む CA 署名付きサーバー証明書が必要です。この証明書は、1 つの Messaging Server に固有です。また、公開鍵を含む、信頼できる CA 証明書も必要です。信頼できる CA 証明書によって、CA からのすべてのサーバー証明書が信頼できることが保証されます。この証明書は、CA ルートキーまたはルート証明書とも呼ばれることがあります。

証明書データベースのパスワードの設定

証明書を管理する場合、証明書のパスワードを入力したり、パスワードファイルを指定したりする必要はありません。パスワードを -W 引数として渡すだけで済みます。次に例を示します。


echo "password22" > /tmp/certdbpwd
echo "password22" > /tmp/certdbpwd
# ./msgcert list-certs -W /tmp/certdbpwd

Procedureデフォルトの自己署名付き証明書を含む Messaging Server 証明書データベースを作成する

  1. Messaging Server 証明書データベースを作成するには、次のコマンドを実行します。


    msgcert generate-certDB

    このコマンドによって CERT_PW_FILE から証明書データベースのパスワードが読み取られます。(デフォルトはパスワードの入力を要求)

  2. この証明書は、次のコマンドを使用して表示できます。


    msgcert show-cert Server-Cert

Procedure自己署名付き証明書を管理する

テストの目的で証明書を使用している場合は、自己署名付き証明書を使用できます。配備の設定では、信頼できる証明書発行局 (CA) の証明書を使用するほうを選択する可能性があります。また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

  1. 証明書データベースを作成する場合は、デフォルトの自己署名付き証明書が自動的に提供されます。デフォルト以外の設定を含む自己署名付き証明書を使用する場合は、msgcert add-selfsign-cert コマンドを使用します。次に例を示します。


    msgcert add-selfsign-cert --name siroe --org comms --org-unit Messaging 
--city SantaClara --state ca --country us MySelfSigned-Cert

    自己署名付き証明書の有効期間は 3 か月です。

  2. 自己署名付き証明書の期限が切れたら、次のコマンドを使用して証明書を更新します。


    msgcert renew-selfsign-cert cert_alias

23.5.1.6 信頼できる CA の証明書をインストールする

認証局の証明書をインストールするには、./msgcert add-cert を使用します。CA 証明書は、認証局自体の身元を証明します。サーバーは、クライアントやほかのサーバーを認証するプロセスで、これらの CA 証明書を使用します。

たとえば、パスワードに基づく認証 (157ページの「証明書に基づくログインを設定する」を参照) に加え、証明書に基づく認証にも対応するように会社の環境を設定した場合は、クライアントが提示する可能性のある証明書の発行元として信頼できる CA の証明書をすべてインストールする必要があります。これらの CA は、社内組織の場合もあれば、商業機関、政府機関、ほかの企業などの外部組織の場合もあります。認証用 CA 証明書の使用方法については、『Managing Servers With iPlanet Console 5.0 』の「Introduction to Public-Key Cryptography」を参照してください。

Messaging Server をインストールすると、いくつかの商用認証局の CA 証明書もインストールされます。ほかの商用認証局の CA 証明書を追加する場合や、社内使用のために (Sun Java System Certificate Server を使用して) 独自の認証局を開発する場合は、追加の CA 証明書を入手して、インストールする必要があります。

注 –

Messaging Server により自動的に提供される CA 証明書は、インストール時にはクライアント証明書用の信頼できる証明書としてマークされていません。これらの CA から発行されるクライアント証明書を信頼できるものにする必要がある場合は、信頼設定を編集する必要があります。手順については、「23.5.1 証明書の入手」を参照してください。

次の手順は、Messaging Server で使用する CA 署名付きサーバー証明書と信頼できる認証局の証明書を要求してインストールするプロセスを示しています。

ProcedureCA 署名付きサーバー証明書を要求する

また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

  1. CA 署名付きサーバー証明書に対する要求を生成します。


    msgcert request-cert [-W CERT_PW_FILE] {-S DN|--name NAME [--org ORG] [--org-unit ORG-UNIT]
   [--city CITY] [--state STATE] [--country COUNTRY] } [-F FORMAT] [-o OUTPUT_FILE]

    CA 署名付きサーバー証明書に対する要求の例を次に示します。この場合は、バイナリ形式の証明書が返されます。


    ./msgcert request-cert --name aqua --org siroe --org-unit Messaging -o my_ca_signed_request_cert

    ASCII 形式の証明書を返すには、次のコマンドを使用します。


    ./msgcert request-cert --name aqua --org siroe --org-unit Messaging -F ascii -o my_casigned_request_cert

    DURGA:どうして 2 つのコマンドがあるのですか。

    通常、CA はサーバーを完全に識別するために、この例に含まれるすべての属性を必要とします。各属性の説明を表示するには、./msgcert request-cert --help を入力します。msgcert request-cert を使用して証明書を要求した場合、出力形式として ASCII を指定しないかぎり、得られる証明書要求はバイナリ形式の証明書要求になります。ASCII を指定すると、得られる証明書要求は、PEM 形式の PKCS #10 証明書要求になります。PEM (Privacy Enhanced Mail) は、RFC 1421 〜 1424 で指定されている形式で、US-ASCII 文字を使用した base64 形式で符号化されます。要求の内容は、次の例のようになります。


    -----BEGIN NEW CERTIFICATE REQUEST-----
MIIBdTCB3wIBADA2MRIwEAYDVQQLEwlNZXNzYWdpbmcxDjAMBgNVBAoTBXNpcm9l
MRAwDgYDVQQDEwdhcXVhdGljMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDt
KEh5Fnj/h9GEu18Da6DkJpcNShkwxanjnKs2883ZoUV5Sp4pN7U6Vfbh0414WXZh
D26m3t81q9b9h47Klkf0pW1X3BB6LOjGOHSt2VoNBI8n3hJ6XiN2zYbrlLTgdKuo
y0YrSG/kHFnqKghikag9O/Ox+cwD+mpjl2QnsPZgswIDAQABoAAwDQYJKoZIhvcN
AQEEBQADgYEArqgWQIwNZDC2d3EZawI23Wj9o6Pyvu9J1rkb+NYgIEnNp9jugxqX
F326N0ABLdHXXNX/2ZvC5TKOgS4RidTBM89N9xJvokmvRGfc+1x80uxy474YdNlZ
s+nP8AYo9dW9mrLOammozx9HLPSVYNFp4FxekgV2n8QG7WC5rkN5bCE=
-----END NEW CERTIFICATE REQUEST-----

  2. ここで説明する手順に従って、証明書要求を CA に送信します。

    認証局証明書を取得するプロセスは、使用する認証局によって異なります。一部の商用認証局は、証明書を自動的にダウンロードできる Web サイトを提供しています。その他の認証局は、要求された証明書を電子メールで送信します。

    要求を送信したら、CA から証明書が送られてくるまで待ちます。要求に対する回答が届くまでの時間は、状況によって異なります。たとえば、CA が社内にある場合は、要求に対する回答は 1 〜 2 日しかかからないこともあります。CA が社外にある場合は、数週間かかることもあります。

  3. 認証局から送られてきた証明書を保存します。

    証明書を安全な場所にバックアップするようにしてください。これにより、証明書を失ってもバックアップファイルを使用して再インストールできます。証明書は、テキストファイルに保存できます。次に、PEM 形式の PKCS #11 証明書の例を示します。


    -----BEGIN CERTIFICATE-----
MIICjCCAZugAwIBAgICCEEwDQYJKoZIhKqvcNAQFBQAwfDELMAkGA1UEBhMCVVMx
IzAhBgNVBAoGlBhbG9a2FWaWxsZGwSBXaWRnZXRzLCBJbmMuMR0wGwYDVQQLExRX
aWRnZXQgTW3FrZXJzICdSJyBVczEpMCcGAx1UEAxgVGVzdCBUXN0IFRlc3QgVGVz
dCBUZXN0IFlc3QgQ0EswHhcNOTgwMzEyMDIzMzUWhcNOTgwMzI2MDIzMpzU3WjBP
MQswCYDDVQQGEwJVUzEoMCYGA1UEChMfTmV0c2NhcGUgRGlyZN0b3J5VIFB1Ymxp
Y2F0aW9uczEWMB4QGA1UEAxMNZHVgh49dq2tLNvbjTBaMA0GCSqGSIb3DQEBAQUA
A0kAMEYkCQCksMR/aLGdfp4m0OiGgijG5KgOsyRNvwGYW7kfW+8mmijDtZaRjYNj
jcgpF3VnlbxbclX9LVjjNLC5737XZdAgEDozYwpNDARBglghkgBhvhCEAQEEBAMC
APAwHkwYDVR0jBBgwFAU67URjwCaGqZHUpSpdLxlzwJKiMwDQYJKoZIhQvcNAQEF
BQADgYEAJ+BfVem3vBOPBveNdLGfjlb9hucgmaMcQa9FA/db8qimKT/ue9UGOJqL
bwbMKBBopsDn56p2yV3PLIsBgrcuSoBCuFFnxBnqSiTS7YiYgCWqWaUA0ExJFmD6
6hBLseqkSWulk+hXHN7L/NrViO+7zNtKcaZLlFPf7d7j2MgX4Bo=
-----END CERTIFICATE-----

ProcedureCA 署名付きサーバー証明書と信頼できる認証局の証明書を追加する

また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

  1. 次のコマンドを使用して、CA 署名付きサーバー証明書を追加します。


    msgcert add-cert cert_alias cert_file

    ここで、cert_alias は証明書を識別するために指定する名前です。cert_file は、PEM 形式の PKCS #11 証明書を含むテキストファイルです。

    たとえば、CA 署名付きサーバー証明書をインストールするには、次のようなコマンドを使用できます。


    msgcert add-cert /my_cert/server-cert-file

    これで証明書がインストールされましたが、まだ信頼されてはいません。CA 署名付きサーバー証明書を信頼できるものにするには、認証局証明書をインストールしてください。

  2. 次のコマンドを使用して、信頼できる証明書発行局の証明書を追加します。


    msgcert add-cert -C cert_alias cert_file

    -C オプションは、この証明書が信頼できる証明書発行局の証明書であることを示します。

    たとえば、認証局から信頼できる証明書をインストールするには、次のコマンドを使用できます。


    msgcert add-cert -C CA-cert /my_cert/ca-cert-file

  3. 必要に応じて、インストールした証明書を、次のコマンドを使用して確認します。

    すべてのサーバー証明書を一覧表示して、エイリアスや有効期限などの情報を表示するには、次のコマンドを実行します。


    msgcert list-certs

    ./msgcert generate-CertDB で生成された場合、Messaging Server には Server-Cert と呼ばれるデフォルトの証明書が用意されています。「発行者と同じ」というテキストは、デフォルトの証明書が自己署名付きサーバー証明書であることを示しています。次に例を示します。


    # ./msgcert list-certs
証明書データベースのパスワードを入力してください:
エイリアス     有効期限開始日   有効期限         自己   発行元                 発行先
                                                 署名付き
------------   ----------------  --------------- ------  --------------------- -------------------------  --------------
SelfSignedCrt 2006/07/28 12:58  2006/10/28 12:58   y     CN=SFO,L=SC,ST=ca,C=us  発行者と同じ
Server-Cert   2006/07/28 07:47  2006/10/28 07:47   y     CN=perseids             発行者と同じ
2 個の証明書が見つかりました

    信頼できる認証局の証明書を一覧表示するには、次のコマンドを実行します。


    msgcert list-certs -C

    証明書の詳細 (証明書の満了日を含む) を表示するには、次のコマンドを実行します。


    msgcert show-cert cert_alias

    たとえば、自己署名付き証明書を表示するには、次のコマンドを実行します。


    # ./msgcert show-cert MySelfSigned-Cert
Enter the certificate database password:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:83:35:37:94
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer:
            "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us"
        Validity:
            Not Before: Fri Jul 28 19:58:31 2006
            Not After : Sat Oct 28 19:58:31 2006
        Subject:
            "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    aa:9d:3d:23:b2:59:39:f3:77:c8:69:7f:b0:d1:ac:d2:
                    4e:81:c8:51:0f:27:6f:a1:21:4b:a9:27:46:d7:0f:b4:
                    c8:44:86:32:5e:4f:2f:1c:2f:a9:b8:a3:49:b5:b8:ab:
                    51:a8:a5:ba:1c:e8:90:7d:46:67:f9:a7:44:c5:1d:24:
                    e6:bd:e8:8f:07:b4:5a:68:41:b1:19:f2:ea:98:ba:25:
                    55:b8:ba:9c:af:bb:43:c3:c0:8f:14:a7:4c:2b:50:b4:
                    ac:df:b5:cd:68:de:a6:14:9d:68:77:d3:8b:7f:de:c0:
                    5d:35:d7:55:8d:b5:c3:14:2a:60:a9:bf:de:96:90:a9
                Exponent: 65537 (0x10001)
    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        15:86:f1:cc:85:c9:08:0f:ff:d3:56:d8:e2:c8:ea:3c:
        8e:45:36:be:8b:b0:7d:2f:e9:cd:e3:b4:ad:8c:70:59:
        c8:a5:14:da:9c:fa:7f:70:86:64:34:0b:21:ae:c4:28:
        d2:f5:94:5c:a6:78:0f:d9:fd:fc:c5:5e:37:49:25:a9:
        bc:12:59:cb:fb:4e:e9:d4:8a:8d:3d:41:12:ae:f1:7f:
        8d:d3:10:ac:fb:33:51:5d:0c:1b:dc:23:5f:95:d5:6d:
        c6:1d:e5:ed:13:8b:16:41:89:5b:4d:de:c0:c7:56:a2:
        48:82:38:32:5a:99:d5:21:20:c5:0d:5c:ea:0c:84:aa
    Fingerprint (MD5):
        EF:76:A3:6C:09:4E:BC:6B:87:76:A3:35:70:1F:B2:C4
    Fingerprint (SHA1):
        BB:1C:20:4B:79:3A:F1:49:F0:83:FB:CC:9C:56:10:D3:06:97:AA:07

    Certificate Trust Flags:
        SSL Flags:
            Valid CA
            Trusted CA
            User
            Trusted Client CA
        Email Flags:
            User
        Object Signing Flags:
            User

Procedure期限が切れた CA 署名付きサーバー証明書の更新

CA 署名付きサーバー証明書 (公開鍵および非公開鍵) の期限が切れた場合は、次の手順を使用して証明書を更新できます。また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

  1. 認証局から、更新された CA 署名付きサーバー証明書を取得します。

  2. 更新された証明書を受信したら、その証明書をインストールします。


    msgcert renew-cert cert_alias cert_file

ProcedureCA 署名付きサーバー証明書をエクスポートおよびインポートする

場合によっては、証明書を (たとえば、別のホストに) エクスポートして、あとでその証明書をインポートできるようにしたいことがあります。また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

  1. 証明書をエクスポートします。


    msgcert export-cert [-o OUTPUT_FILE] CERT_ALIAS

    次に例を示します。


    $ ./msgcert export-cert -o /tmp/first-certificate "First Certificate"
$./msgcert export-cert -o /tmp/first-server-certificate Server-Cert
Choose the PKCS#12 file password:
Confirm the PKCS#12 file password:
$ls /tmp
first-server-certificate
/tmp/first-certificate

  2. 証明書をインポートします。


    $ msgcert import-cert  CERT_FILE

    たとえば、証明書をインポートするには、次のコマンドを実行します。


    $ msgcert import-cert /tmp/first-server-certificate
Enter the PKCS#12 file password:
$

23.5.2 SSL を有効化し暗号化方式を選択する

コンソールを使用すると、SSL を有効にし、Messaging Server がクライアントとの暗号通信で使用できる暗号化方式を選択できます。また、msgcert ユーティリティーを使用して SSL 証明書をインストールし、対応する configutil を実行するか、またはその特定のサービスの SSL を有効にするために必要な対応する設定ファイルを編集することもできます。

23.5.2.1 暗号化方式について

「暗号化方式」とは、暗号化プロセスでデータの暗号化と解読に使用されるアルゴリズムのことです。各暗号化方式によって強度が異なります。つまり、強度の高い暗号化方式で暗号化したメッセージほど、承認されていないユーザーによる解読が困難になります。

暗号化方式では、キー (長い数値) をデータに適用することによってデータを操作します。一般的に、暗号化方式で使用するキーが長いほど、適切な解読キーを使わずにデータを解読することが難しくなります。

クライアントは、Messaging Server と SSL 接続を開始するときに、サーバーに対して、希望する暗号化用の暗号化方式とキー長を伝えます。暗号化された通信では、両方の通信者が同じ暗号化方式を使用する必要があります。一般的に使用される暗号化方式とキーの組み合わせは数多くあります。そのため、サーバーが柔軟な暗号化方式をサポートしている必要があります。Messaging Server では、最大 6 つの暗号化方式とキー長の組み合わせをサポートできます。

表 23–2 に、Messaging Server が SSL 3.0 を使用する場合にサポートする暗号化方式の一覧を示します。この表には概要を記載しています。詳細は、『 Managing Servers with iPlanet Console』の「Introduction to SSL」を参照してください。

表 23–2 Messaging Server の SSL 暗号化方式

暗号化方式 

説明 

128 ビットの暗号化と MD5 メッセージ認証を使用した RC4 

RSA が提供する暗号化方式で、もっとも高速で、もっとも強度の高い暗号化方式と暗号化キーの組み合わせを提供します。 

168 ビットの暗号化と SHA メッセージ認証を使用した DES 

米国政府の標準となっている暗号化方式で、低速で、強度の高い暗号化方式と暗号化キーの組み合わせを提供します。 

56 ビットの暗号化と SHA メッセージ認証を使用した DES 

米国政府の標準となっている暗号化方式で、低速で、中程度の強度の暗号化方式と暗号化キーの組み合わせを提供します。 

40 ビットの暗号化と MD5 メッセージ認証を使用した RC4 

RSA が提供する暗号化方式で、もっとも高速で、強度の低い暗号化方式と暗号化キーの組み合わせを提供します。 

40 ビットの暗号化と MD5 メッセージ認証を使用した RC2 

RSA が提供する暗号化方式で、低速で、強度の低い暗号化方式と暗号化キーの組み合わせを提供します。 

暗号化なし、MD5 メッセージ認証のみ 

暗号化を使用せず、認証用のメッセージダイジェストのみを使用します。 

特定の暗号化方式を使わないようにする妥当な理由がないかぎり、すべての暗号化方式をサポートする必要があります。ただし、特定の暗号化方式の使用が法律で制限されている国もあります。また、米国の輸出規制法規が緩和される前に開発されたクライアントソフトウェアの中には、強度の高い暗号化を使用できないものもあります。40 ビットの暗号化方式では、偶発的な漏洩は防ぐことができますが、セキュリティーが確保されないため、意図的な攻撃を防ぐことはできません。

SSL を有効にし、暗号化方式を選択するには、次のコマンド行を実行します。

証明書を指定するには、次のように入力します。

configutil -o encryption.rsa.nssslpersonalityssl -v certname

また、SSL サーバー証明書のニックネームに対するサービスごとの設定も存在します。新しい configutil 設定は次のとおりです。

local.imta.sslnicknames - SMTP および Submit サーバーの場合 local.imap.sslnicknames - IMAP サーバーの場合 local.pop.sslnicknames - POP サーバーの場合 local.http.sslnicknames - Web メールサーバーの場合

これらの設定は、encryption.rsa.nssslpersonalityssl の設定と同じ意味を持ち、その設定より優先されます。具体的には、この値は NSS 証明書のニックネームのコンマ区切りリストです。リスト内には複数のニックネームを指定できますが、この設定がほぼ常に 1 つのニックネームだけになるように、各ニックネームが別の種類の証明書 (たとえば、RSA 証明書と DSS 証明書) を参照するようにしてください。ニックネームは非修飾にすることができます。この場合は、NSS ソフトウェアトークンまたはデフォルトのトークンが検索されます。または、"security-module:nickname" の形式にすることができます。この場合は、指定されたセキュリティーモジュールでそのニックネームが検索されます。この指定方法は、ハードウェアトークン、またはデフォルトの NSS データベース以外の場所に格納された証明書の場合に必要です。

これにより、製品内で複数の NSS ソフトウェアトークンを使用することは許可されません。特に、IMAP、POP、SMTP、および HTTP に対しては 1 つの cert8.db、key3.db、および secmod.db しか存在しません。NSS ではそれが許可されません。

注 –

送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytls や musttls などの tls チャネルキーワードを追加する必要があります。詳細は、「12.4.7 Transport Layer Security」のマニュアルを参照してください。

23.5.3 証明書に基づくログインを設定する

Sun Java System サーバーでは、パスワードに基づくログインに加えて、デジタル証明書の確認によるユーザー認証もサポートしています。証明書に基づく認証では、クライアントはサーバーとの SSL セッションを確立し、ユーザーの証明書をサーバーに提出します。その後、サーバーが、提出された証明書の信頼性を評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。

証明書に基づくログインを実行できるように Messaging Server を設定するには、次の手順を実行します。

Procedure証明書に基づくログインを設定する

  1. 使用しているサーバー用の証明書を入手します (詳細は、「23.5.1 証明書の入手」を参照)。

  2. 証明書セットアップウィザードを実行して、サーバーが認証するユーザーに証明書を発行する、信頼できる認証局の証明書をインストールします (詳細は「23.5.1.6 信頼できる CA の証明書をインストールする」を参照)。

    サーバーのデータベース内に信頼できる CA の証明書が 1 つでもあるかぎり、サーバーは接続するクライアントに対してクライアント証明書を要求します。

  3. SSL を有効にします (詳細は、「23.5.2 SSL を有効化し暗号化方式を選択する」を参照)。

  4. サーバーが提出された証明書の情報に基づいて LDAP ユーザーディレクトリを適切に検索するように、サーバーの certmap.conf ファイルを編集します (省略可)。

    ユーザーの証明書内の電子メールアドレスと、ユーザーのディレクトリエントリ内の電子メールアドレスが一致する場合は、certmap.conf ファイルを編集する必要はありません。また、検索を最適化したり、提出された証明書をユーザーエントリ内の証明書と照合したりする必要もありません。

    certmap.conf の形式と変更可能な部分の詳細は、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。

    上記の手順を実行したあとに、ユーザーが、IMAP または HTTP にログインできるようにクライアントで SSL セッションを確立すると、Messaging Server からクライアントに対してユーザーの証明書が要求されます。サーバーによって信頼されている CA から発行された証明書をクライアントが提出し、かつ証明書の識別情報がユーザーディレクトリ内のエントリと一致する場合、そのユーザーは、認証され、ユーザーに適用されるアクセス制御ルールに応じたアクセス権が与えられます。

    証明書に基づくログインを有効にするためにパスワードに基づくログインを無効する必要はありません。パスワードに基づくログインが許可されている場合 (デフォルトの状態) に、この節で説明した作業を実行すると、パスワードに基づくログインと証明書に基づくログインの両方がサポートされます。その場合は、クライアントが SSL セッションを確立し、証明書を提出すると、証明書に基づくログインが使用されます。クライアントが SSL を使用しない場合、または証明書を提出しない場合は、パスワードを要求されます。

23.5.4 SMTP プロキシを使用した SSL パフォーマンスの最適化方法

SMTP プロキシを使用すると、SMTP プロトコルの待ち時間が増加するため、ほとんどのサイトでは SMTP プロキシを使用しません。ただし、SMTP 接続を保護するために SSL を頻繁に使用する大規模サイトでは、SSL とプロキシ専用の 1 台のサーバー上で、すべてのプロトコルのすべての SSL 操作を実行することで、SSL アクセラレータハードウェアに対する投資効果を最大化する必要があります。SMTP プロキシを使用すると、フロントエンドのプロキシサーバーで SSL を処理し、メールキューを別の MTA マシン上に置くことができます。この方法により、各タスクに最適なハードウェアを個別に購入して構成することができます。

SMTP プロキシをインストールする方法については、『Sun Java Communications Suite 5 配備計画ガイド』の「MMP SMTP プロキシの使用」および「23.8 POP before SMTP を有効にする」を参照してください。

23.6 Messaging Server への管理者アクセスを構成する

この節では主に Sun Java System LDAP スキーマ v. 1 について説明します。次の項があります。

この節では、サーバー管理者による Messaging Server へのアクセスを制御する方法について説明します。特定の Messaging Server および Messaging Server タスクへの管理アクセスは、委任サーバー管理を行うときに発生します。

「委任サーバー管理」とは、ほとんどの Sun Java System サーバーが持っている機能で、管理者が、ほかの管理者に対して、個々のサーバーやサーバー機能へのアクセス権を選択して提供できる機能を意味します。この章では、委任されたサーバーのタスクについて簡単に説明します。詳細は、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。

23.6.1 委任管理の階層

ネットワーク上に最初の Sun Java System サーバーをインストールすると、インストールプログラムによって、LDAP ユーザーディレクトリに構成管理者グループと呼ばれるグループが自動的に作成されます。デフォルトでは、構成管理者グループのメンバーには、ネットワーク上のすべてのホストおよびサーバーに対する無制限のアクセス権が与えられます。

構成管理者グループは、次のようなアクセス階層の最上位に位置します。このようなアクセス階層を構築して、Messaging Server の委任管理 (Sun Java System LDAP スキーマ v. 1 を使用している場合) を実装することができます。

  1. 構成管理者: Sun Java System サーバーネットワークの「スーパーユーザー」。すべてのリソースに対する完全なアクセス権を持ちます。

  2. サーバー管理者: ドメイン管理者は、各タイプのサーバーを管理するためのグループを作成することがあります。たとえば、管理ドメイン内またはネットワーク全体にあるすべての Messaging Server を管理するためにメッセージング管理者グループを作成する場合があります。このグループのメンバーは、その管理ドメイン内のすべての Messaging Server にアクセスできます (ほかのサーバーにはアクセス不可)。

  3. タスク管理者: 上記のすべての管理者は、単一または複数の Messaging Server に対する制限付きアクセス権を持つグループを作成したり、そのようなアクセス権を持つ個別のユーザーを指定したりできます。指定されたタスク管理者は、特定の制限されたサーバータスク (サーバーの起動または停止、特定のサービスのログへのアクセス) だけを実行できます。

管理者は、コンソールが提供する便利なインタフェースを使用して、次のタスクを実行できます。

Procedureサーバー全体に対するアクセス権を与える

この章では、ユーザーまたはグループに Messaging Server の特定のインスタンスに対するアクセス権を与える方法について説明します。

  1. アクセス権を与える対象の Messaging Server へのアクセス権を持っている管理者として、コンソールにログインします。

  2. 「コンソール」ウィンドウでそのサーバーを選択します。

    「コンソール」ウィンドウのメニューから「オブジェクト」を選択し、「アクセス権の設定」を選択します。

  3. そのサーバーへのアクセス権を持つユーザーおよびグループのリストに対する追加や編集を行います。

    詳細な手順については、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。

    特定の Messaging Server へのアクセス権を持つユーザーおよびグループのリストの設定が済んだら、次に説明する ACI を使用して、特定のサーバータスクをリスト内の特定のユーザーまたはグループに委任することができます。

23.6.2 特定タスクへのアクセスを限定する

一般的に、管理者はサーバーに接続して 1 つ以上の管理タスクを実行します。コンソールの「Messaging Server タスク」フォームには、頻繁に実行される管理タスクが一覧表示されます。

デフォルトでは、特定の Messaging Server にアクセスできると、そのサーバーのすべてのタスクにアクセスできます。ただし、タスクフォーム内の各タスクには、一連のアクセス制御インストラクション (ACI) を関連付けることができます。サーバーは、接続しているユーザー (サーバー全体に対するアクセス権をすでに持っているユーザー) にタスクへのアクセス権を与える前に、これらの ACI を参照します。実際、タスクフォームには、そのユーザーがアクセス権を持っているタスクだけが表示されます。

Messaging Server へのアクセス権がある場合は、アクセスできる任意のタスクに関する ACI を作成または編集して、ほかのユーザーやグループがそのタスクに対して持つことができるアクセス権を制限できます。

Procedureユーザーまたはグループのタスクアクセス権を制限する

  1. 制限付きアクセス権を与える対象の Messaging Server へのアクセス権を持っている管理者として、コンソールにログインします。

  2. サーバーを開き、そのサーバーのタスクフォームで、タスクのテキストをクリックして、タスクを選択します。

  3. 「編集」メニューの「アクセス権の設定」を選択し、アクセスルールのリストに対する追加や編集を行い、ユーザーまたはグループに必要なアクセス権を与えます。

  4. 必要に応じて、ほかのタスクについて同じ手順を繰り返します。

    詳細な手順については、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。

    ACI とその作成方法の詳細については、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。

23.7 POP、IMAP、および HTTP サービスへのクライアントアクセスを構成する

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

Messaging Server には、IMAP、POP、HTTP の各サービスを個別に制御できる精巧なアクセス制御機能があります。これにより、クライアントによるサーバーへのアクセスを広範囲に細かく制御できます。

大企業やインターネットサービスプロバイダのメッセージングサービスを管理する場合、これらの機能を使用して、スパム (大量メール送信) や DNS スプーフィングを行うユーザーをシステムから除外したり、ネットワークの全般的なセキュリティーを強化したりできます。不特定多数宛メールを制御するための具体的な方法については、第 18 章「メールのフィルタリングとアクセス制御」を参照してください。

注 –

IP アドレスによるアクセス制御が重要な問題ではない場合は、この節で説明しているフィルタを作成する必要はありません。最小限のアクセス制御だけが必要な場合は、その設定手順について、「23.7.3.2 大半のアクセスを許可」を参照してください。

23.7.1 クライアントアクセスフィルタのしくみ

Messaging Server のアクセス制御機能は、プログラムであり、TCP デーモンと同じポートで応答を待機します。このプログラムは、アクセスフィルタを使用してクライアントの識別情報を確認し、クライアントがフィルタリングプロセスを通過した場合に、そのクライアントに対してデーモンへのアクセス権を与えます。

Messaging Server の TCP クライアントアクセス制御システムは、必要な場合、その処理の一部として、次のようなソケットの終端アドレスの分析を行います。

システムは、この情報を「フィルタ」と呼ばれるアクセス制御文と比較して、アクセスの許可または拒否を決定します。サービスごとに、個別の許可フィルタと拒否フィルタのセットを使用して、アクセスを制御します。許可フィルタは明示的にアクセスを許可し、拒否フィルタは明示的にアクセスを禁止します。

クライアントがサービスへのアクセスを要求すると、アクセス制御システムは、そのクライアントのアドレスまたは名前情報を、以下の条件を使用して順番に対象のサービスのフィルタと比較します。

ここで説明するフィルタの構文は柔軟性に富んでいるため、わかりやすい簡単な方法で、さまざまなアクセス制御ポリシーを実装できます。許可フィルタと拒否フィルタは自由に組み合わせて使用できますが、大半のアクセスを許可するフィルタまたは大半のアクセスを拒否するフィルタを使用すると、ほとんどのポリシーを実装できます。

次の節では、フィルタの構文について詳しく説明し、さらに使用例を紹介します。アクセスフィルタの作成手順については、「23.7.4 各サービス用のアクセスフィルタを作成する」を参照してください。

23.7.2 フィルタの構文

フィルタ文には、サービス情報とクライアント情報の両方が含まれています。サービス情報には、サービス名、ホスト名、ホストアドレスを含めることができます。クライアント情報には、ホスト名、ホストアドレス、ユーザー名を含めることができます。サービス情報とクライアント情報の両方で、ワイルドカード名やパターンを使用できます。

以下に、非常に単純な形式のフィルタを示します。

service: hostSpec

service には、サービス名 (smtp、pop、imap、http など) を指定し、hostSpec には、ホスト名、IP アドレス、またはアクセス要求元のクライアントを表すワイルドカード名やパターンを指定します。フィルタが処理されるときに、アクセス要求元のクライアントが client に一致すると、service で指定されているサービスへのアクセスが、フィルタのタイプに応じて許可または拒否されます。次に例をいくつか示します。

imap: roberts.newyork.siroe.com
pop: ALL
http: ALL

これらが許可フィルタの場合は、最初の行によって roberts.newyork.siroe.com というホストに対して、IMAP サービスへのアクセスが許可されます。さらに 2 行目と 3 行目によって、それぞれ POP サービスと HTTP サービスへのアクセスがすべてのクライアントに許可されます。これらが拒否フィルタの場合は、それらのクライアントによる指定したサービスへのアクセスが拒否されます。ALL などのワイルドカード名の詳細は、「23.7.2.1 ワイルドカード名」を参照してください。

フィルタ内のサーバー (サービス) 情報やクライアント情報は、これよりも少々複雑になることがあります。次に、その場合の一般的な形式を示します。

serviceSpec: clientSpec

serviceSpec は service または service@hostSpec のどちらかを示し、clientSpec は hostSpec または user@hostSpec のどちらかを示します。user はアクセス要求元のクライアントホストに関連付けられたユーザー名 (またはワイルドカード名) です。次に 2 つの例を示します。

pop@mailServer1.siroe.com: ALL
imap: srashad@xyz.europe.siroe.com

これらが拒否フィルタの場合、最初のフィルタは、すべてのクライアントに対して、ホスト mailServer1.siroe.com 上の SMTP サービスへのアクセスを拒否します。2 番目のフィルタは、ホスト xyz.europe.siroe.com のユーザー srashad に対して、IMAP サービスへのアクセスを拒否します。これらの詳細なサーバーおよびクライアントに対する指定を使用する状況については、「23.7.2.4 サーバーホストの指定」および 「23.7.2.5 クライアントのユーザー名の指定」を参照してください。

もっとも一般的なフィルタの形式は次のようになります。

serviceList: clientList

serviceList は、1 つ以上の serviceSpec エントリで構成され、clientList は、1 つ以上の clientSpec エントリで構成されます。serviceList と clientList 内の各エントリは、空白またはカンマで区切ります。

この場合、フィルタが処理されるときに、アクセス要求元のクライアントが、clientList 内の clientSpec エントリのいずれかと一致すると、serviceList で指定されているすべてのサービスへのアクセスが、フィルタのタイプに応じて許可または拒否されます。次に例を示します。

pop, imap, http: .europe.siroe.com .newyork.siroe.com

これが許可フィルタの場合、europe.siroe.comドメインおよび newyork.siroe.com ドメイン内のすべてのクライアントに対して、POP、IMAP、HTTP サービスへのアクセスが許可されます。ドメインやサブネットを指定する場合の先頭に付けるドットやほかのパターンの使用方法については、「23.7.2.2 ワイルドカードのパターン」を参照してください。

次の構文も使用できます。

「+」または「-」serviceList:*$next_rule

+ (許可フィルタ) は、デーモンリストサービスがクライアントリストに付与されることを意味します。

- (拒否フィルタ) は、クライアントリストに対してサービスが拒否されることを意味します。

* (ワイルドカードフィルタ) は、すべてのクライアントにこれらのサービスの使用を許可します。

$ は、ルールの区切りです。

次の例では、すべてのクライアントで複数のサービスを有効にしています。

+imap,pop,http:*

次の例では、複数のルールを単純化して各ルールが単一のサーバー名を所有し、クライアントリスト用のワイルドカードを使用するようにします。これは、LDIF ファイルでアクセス制御を指定するためのもっとも一般的な方法です。

+imap:ALL$+pop:ALL$+http:ALL

次の例では、あるユーザーに対してすべてのサービスを許可しない方法を示します。

-imap:*$-pop:*$-http:*

23.7.2.1 ワイルドカード名

次のワイルドカード名を使用して、サービス名、ホストの名前やアドレス、またはユーザー名を表すことができます。

表 23–3 サービスフィルタのワイルドカード名

ワイルドカード名 

意味 

ALL, *

汎用のワイルドカードです。すべての名前に一致します。 

LOCAL

すべてのローカルホスト (ドット文字を含まない名前を持つホスト) に一致します。ただし、正規名のみを使用しているシステムの場合は、ローカルホスト名もドットを含むため、このワイルドカードに一致しません。 

UNKNOWN

名前が不明なすべてのユーザー、あるいは名前またはアドレスが不明なすべてのホストに一致します。 

このワイルドカード名は、次のことに注意して使用する必要があります。 

一時的な DNS サーバーの問題により、ホスト名が使用できなくなる場合があります。このような場合、UNKNOWN を使用しているすべてのフィルタはすべてのクライアントホストに一致します。

ソフトウェアが通信相手のネットワークのタイプを識別できない場合は、ネットワークアドレスを使用できません。そのような場合、UNKNOWN を使用しているすべてのフィルタは、そのネットワーク上にあるすべてのクライアントホストに一致します。

KNOWN

名前が認識されているすべてのユーザー、または名前およびアドレスが認識されているすべてのホストに一致します。

このワイルドカード名は、次のことに注意して使用する必要があります。 

一時的な DNS サーバーの問題により、ホスト名が使用できなくなる場合があります。このような場合、KNOWN を使用しているすべてのフィルタはどのクライアントホストにも一致しません。

ソフトウェアが通信相手のネットワークのタイプを識別できない場合は、ネットワークアドレスを使用できません。そのような場合、KNOWN を使用しているすべてのフィルタは、そのネットワーク上にあるどのクライアントホストにも一致しません。

DNSSPOOFER

IP アドレスと DNS 名が一致しないすべてのホストに一致します。 

23.7.2.2 ワイルドカードのパターン

サービスまたはクライアントアドレスを指定するときは、次のパターンを使用できます。

23.7.2.3 EXCEPT 演算子

アクセス制御システムでは、1 つの演算子がサポートされています。この EXCEPT 演算子を使うと、serviceList または clientList 内に複数のエントリがある場合に、名前やパターンの一致に関する例外を指定することができます。たとえば、次のような式を使用します。

list1 EXCEPT list2

この式では、list1 に一致するもので、list2 に一致しないものが、すべて一致します。

次に例を示します。

ALL: ALL EXCEPT isserver.siroe.com

これが拒否フィルタの場合、ホストマシン isserver.siroe.com 上のクライアントを除くすべてのクライアントに対して、すべてのサービスへのアクセスが拒否されます。

EXCEPT 句は入れ子にすることができます。次に入れ子の式の例を示します。

list1 EXCEPT list2 EXCEPT list3

これは次の式と同様に評価されます。

list1 EXCEPT (list2 EXCEPT list3)

23.7.2.4 サーバーホストの指定

serviceSpec エントリにサーバーホストの名前またはアドレス情報を含めることで、要求される特定のサービスをフィルタ内で識別することができます。この場合、次の形式でエントリを指定します。

service@hostSpec

この機能は、Messaging Server ホストマシンが、異なるインターネットホスト名を持つ複数のインターネットアドレス用に設定されている場合に有効です。サービスプロバイダの場合、この機能を使用することで、異なるアクセス制御ルールを持つ複数のドメインを 1 つのサーバーインスタンス上でホストできます。

23.7.2.5 クライアントのユーザー名の指定

RFC 1413 に記載された identd サービスをサポートするクライアントホストマシンの場合は、フィルタの clientSpec エントリ内にクライアントのユーザー名を含めることにより、サービスを要求している特定のクライアントを識別することができます。この場合、次の形式でエントリを指定します。

user@hostSpec

user は、クライアントの identd サービスによって返されるユーザー名 (またはワイルドカード名) です。

フィルタ内でクライアントユーザー名を指定すると便利ですが、次のことに注意する必要があります。

ユーザー名検索の機能は、クライアントホスト上の承認されていないユーザーからの攻撃を防ぐために役立つ場合があります。たとえば、一部の TCP/IP の実装環境では、侵入者が rsh (リモートシェルサービス) を使用して信頼されているクライアントホストになりすます場合があります。クライアントホストが ident サービスをサポートしている場合は、ユーザー名の検索を使用してそのような攻撃を検出できます。

23.7.3 フィルタの例

この節では、さまざまなアクセス制御方法の例を紹介します。これらの例を参照する際には、許可フィルタが拒否フィルタよりも先に処理されること、一致するものが見つかった時点で検索が終了すること、および一致するものがまったく見つからないとアクセスが許可されることに注意してください。

ここに記載した例では、IP アドレスではなく、ホスト名とドメイン名を使用します。フィルタにアドレス情報やネットマスク情報を含めておくと、ネームサービスに障害が発生した場合の信頼性を向上させることができます。

23.7.3.1 大半のアクセスを拒否

この例では、デフォルトでアクセスを拒否します。明示的に許可したホストだけにアクセスを許可します。

デフォルトのポリシー (アクセスなし) は、次のような 1 つの単純な拒否フィルタを使用して実装します。

ALL: ALL

このフィルタは、許可フィルタによって明示的にアクセスを許可されていないすべてのクライアントに対して、すべてのサービスへのアクセスを拒否します。この場合の許可フィルタは、たとえば次のようになります。

ALL: LOCAL @netgroup1

ALL: .siroe.com EXCEPT externalserver.siroe.com

最初のルールは、ローカルドメイン内のすべてのホスト (ドットを含まないホスト名を持つすべてのホスト) からのアクセス、および netgroup1 というグループのメンバーからのアクセスを許可します。2 番目のルールでは、先頭にドットが付いたワイルドカードパターンを使用することで、siroe.com ドメイン内のすべてのホストからのアクセスを許可しますが、ホスト externalserver.siroe.com は除外されます。

23.7.3.2 大半のアクセスを許可

この例では、デフォルトでアクセスを許可します。明示的に拒否したホストだけにアクセスを拒否します。

デフォルトのポリシー (アクセス許可) により、許可フィルタは不要になります。次のように、アクセスを拒否するクライアントのリストを拒否フィルタ内に明示的に指定します。

ALL: externalserver.siroe1.com, .siroe.asia.com
ALL EXCEPT pop: contractor.siroe1.com, .siroe.com

最初のフィルタは、特定のホストおよびドメインに対して、すべてのサービスを拒否します。2 番目のフィルタは、特定のホストおよびドメインからの POP アクセスだけを許可します。

23.7.3.3 スプーフィングされたドメインのアクセスを拒否

フィルタ内で、DNSSPOOFER を使用すると、ホスト名のスプーフィングを検出できます。DNSSPOOFER を指定すると、アクセス制御システムによって正引きまたは逆引きの DNS 検索が実行され、クライアントが提示したホスト名とホストの実際の IP アドレスが一致するかどうかが調べられます。以下に拒否フィルタの例を示します。

ALL: DNSSPOOFER

このフィルタは、IP アドレスとその DNS ホスト名が一致しないすべてのリモートホストに対して、すべてのサービスを拒否します。

23.7.3.4 仮想ドメインへのアクセス制御

メッセージングシステムで仮想ドメインを使用し、1 つのサーバーインスタンスが複数の IP アドレスおよびドメイン名に関連付けられている場合は、許可フィルタと拒否フィルタを組み合わせて各仮想ドメインのアクセスを制御できます。たとえば、次のような許可フィルタを使用できます。

ALL@msgServer.siroe1.com: @.siroe1.com
ALL@msgServer.siroe2.com: @.siroe2.com
...

この場合、次のような拒否フィルタと組み合わせることができます。

ALL: ALL

各許可フィルタは、domainN 内のホストだけに、msgServer.siroeN.com に対応する IP アドレスを持つサービスへの接続を許可します。ほかの接続はすべて拒否されます。

23.7.3.5 Webmail へのアクセスを許可したまま IMAP アクセスを制御する

ユーザーが Webmail にアクセスできるが、IMAP にはアクセスできないようにする場合は、次のようなフィルタを作成します。


+imap:access_server_host, access_server_host

これにより、アクセスサーバーホストからは IMAP のみが許可されます。このフィルタは、service.imap.domainallowed を使用して IMAP サーバーのレベルで、または LDAP 属性を使用してドメイン/ユーザーのレベルで設定できます。

23.7.4 各サービス用のアクセスフィルタを作成する

IMAP、POP、HTTP の各サービス用の許可フィルタと拒否フィルタを作成できます。SMTP サービス用に作成することもできますが、認証済みの SMTP セッションにしか適用されないため、あまり価値はありません。第 18 章「メールのフィルタリングとアクセス制御」を参照してください。

Procedureフィルタを作成する

  1. コマンド行: 次のように、コマンド行を使用して許可フィルタや拒否フィルタを指定することもできます。

    各サービス用のアクセスフィルタを作成または編集するには、次のように入力します。


    configutil -o service.service.domainallowed -v filter

    service には pop、imap、http のいずれかを指定し、filter は 「23.7.2 フィルタの構文」で説明した構文ルールに従って指定します。

    各サービス用の拒否フィルタを作成または編集するには、次のように入力します。


    configutil -o service.service.domainnotallowed -v filter

    service には pop、imap、http のいずれかを指定し、filter は 「23.7.2 フィルタの構文」で説明した構文ルールに従って指定します。各種の例については、「23.7.3 フィルタの例」を参照してください。

23.7.5 HTTP プロキシ認証用のアクセスフィルタを作成する

すべてのストア管理者は、任意のサービスに対してプロキシ認証を行うことができます (ストア管理者の詳細については、「20.4 ストアへの管理者によるアクセスを指定する」を参照)。HTTP サービスの場合にだけ、すべてのエンドユーザーがサービスに対してプロキシ認証を行うことができます。ただし、ユーザーが使用するクライアントホストが、プロキシ認証アクセスフィルタを介してアクセスを許可されている必要があります。

プロキシ認証を使用すると、ポータルサイトなどのほかのサービスが、ユーザーを認証して、HTTP ログインサービスに認証資格情報を渡すことができます。たとえば、1 つのポータルサイトが複数のサービスを提供し、そのうちの 1 つが Messenger Express の Web ベースの電子メールだとします。HTTP プロキシ認証機能を使用すると、エンドユーザーはポータルサービスに対する認証を一度行うだけで済み、電子メールにアクセスするために再び認証を行う必要はありません。ただし、ポータルサイトでは、クライアントとサービス間のインタフェースとして機能するログインサーバーを構成する必要があります。Messenger Express の認証用にログインサーバーを設定する場合は、Sun Java System が提供する Messenger Express 認証 SDK を利用できます。

この節では、許可フィルタを使用し、IP アドレスを基準として、HTTP プロキシ認証を許可する方法について説明します。ログインサーバーの設定方法や Messenger Express 認証 SDK の使用方法については説明しません。Messenger Express 用のログインサーバーの設定方法や、認証 SDK の使用方法については、Sun Java System の担当者に問い合わせてください。

ProcedureHTTP プロキシ認証用のアクセスフィルタを作成する

  1. コマンド行: 次のように、コマンド行を使用して、HTTP サービスに対するプロキシ認証用のアクセスフィルタを指定します。


    configutil -o service.service.proxydomainallowed -v filter

    filter は、「23.7.2 フィルタの構文」 で説明した構文ルールに従って指定します。

23.8 POP before SMTP を有効にする

SMTP リレーサーバーのセキュリティーを提供する方法としては、SMTP 認証または SMTP Auth (RFC 2554) をお勧めします。SMTP Auth は、認証済みのユーザーだけに MTA を介したメール送信を許可します。ただし、一部のレガシークライアントは、POP before SMTP だけをサポートします。この場合には、後述のように、POP before SMTP を有効にすることができます。ただし、可能な場合は、POP before SMTP を使用するのではなく、POP クライアントをアップグレードするようにユーザーに指示します。POP before SMTP をサイトに導入すると、ユーザーがクライアントに依存するようになり、インターネットのセキュリティー標準を守れなくなります。これにより、エンドユーザーがハッキングの危険にさらされ、さらにパフォーマンスが低下して、サイトの処理が遅くなります。これは、最後の正常な POP セッションの IP アドレスを追跡して同期する必要があるためです。

Messaging Server での POP before SMTP の実装は、SIMS や Netscape Messaging Server での実装とはまったく異なっています。POP before SMTP をサポートするには、POP と SMTP プロキシの両方を使用するように Messaging Multiplexor (MMP) を構成します。SMTP クライアントが SMTP プロキシに接続すると、プロキシは、メモリー内キャッシュで最新の POP 認証をチェックします。同じクライアント IP アドレスからの POP 認証が見つかった場合、SMTP プロキシは、ローカルとローカル以外の両方の受取人宛のメッセージを許可する必要があることを SMTP サーバーに通知します。

ProcedureSMTP プロキシをインストールする

SMTP プロキシの使用に関するガイドラインについては、『Sun Java Communications Suite 5 配備計画ガイド』の「MMP SMTP プロキシの使用」を参照してください。

  1. Messaging Multiplexor (MMP) をインストールします。

    手順については、『Sun Java Communications Suite 5 インストールガイド』を参照してください。

  2. MMP 上で SMTP プロキシを有効にします。

    以下の文字列を

    msg-svr-base/lib/SmtpProxyAService@25|587

    msg-svr-base/config/AService.cfg ファイルの ServiceList オプションに追加します。このオプションは、1 行に記述し、改行を入れないようにします。

    注 –

    MMP をアップグレードすると、MMP 用の既存の 4 つの設定ファイルに対応する 4 つの新しいファイルが作成されます。そのファイルを次に示します。

    AService-def.cfg、ImapProxyAService-def.cfg、PopProxyAService-def.cfg、SmtpProxyAService-def.cfg

    これらのファイルは、インストーラによって作成されます。docs 内に記述された 4 つの設定ファイルは、インストールプロセスによって作成されず、また影響も受けません。MMP は、起動時に、通常の設定ファイルを検索します。通常の設定ファイルが見つからない場合、MMP は、それぞれの *AService-def.cfg ファイルをコピーして、対応する *AService.cfg という名前を付けます。

  3. 各 SMTP リレーサーバー上で、SMTP チャネルオプションファイル tcp_local_option の PROXY_PASSWORD オプションを設定します。

    SMTP プロキシは、SMTP サーバーに接続する際に、実際の IP アドレスとその他の接続情報を SMTP サーバーに通知する必要があります。この情報により、SMTP サーバーは、リレーブロッキングやその他のセキュリティーポリシー (POP before SMTP を含む) を適切に適用できるようになります。この操作はセキュリティー上重要な操作であり認証される必要があります。MMP SMTP プロキシと SMTP サーバーの両方で構成されたプロキシパスワードにより、第三者によるこの機能の悪用が確実に防止されます。

    例: PROXY_PASSWORD=A_Password

  4. MMP が SMTP サーバーに接続するために使用する IP アドレスが INTERNAL_IP マッピングテーブルによって「internal」として扱われていないことを確認します。

    INTERNAL_IP マッピングテーブルについては、第 18 章「メールのフィルタリングとアクセス制御」の 「18.6 SMTP リレーを追加する」を参照してください。

  5. POP before SMTP をサポートするように SMTP プロキシを構成します。

    1. msg-svr-base/config/SmtpProxyAService.cfg 設定ファイルを編集します。

      次の SMTP プロキシオプションは、IMAP プロキシおよび POP プロキシの同名のオプションとまったく同じように機能します。第 7 章「マルチプレクササービスの設定および管理」を参照してください。また、これらのオプションについては、『Sun Java System Messaging Server 6.3 Administration Reference』の「Encryption (SSL) Option」を参照してください。

      LdapURL、LogDir、LogLevel、BindDN、BindPass、Timeout、Banner、SSLEnable、SSLSecmodFile、SSLCertFile、SSLKeyFile、SSLKeyPasswdFile、SSLCipherSpecs、SSLCertNicknames、SSLCacheDir、SSLPorts、CertMapFile、CertmapDN、ConnLimits、TCPAccess

      上記のリストにないその他の MMP オプション (BacksidePort オプションを含む) は、現在のところ SMTP プロキシには適用されません。

      次の 5 つのオプションを追加します。

      SmtpRelays。このオプションは、スペースで区切られた SMTP リレーサーバーホスト名 (およびオプションのポート) のリストで、ラウンドロビンリレー用に使用されます。これらのリレーサーバーは、XPROXYEHLO 拡張キーワードをサポートしている必要があります。このオプションは必須で、デフォルトはありません。

      例: default:SmtpRelays manatee:485 gonzo mothra

      SmtpProxyPassword。SMTP リレーサーバー上でソースチャネルの変更を認証するために使用されるパスワードです。このオプションは必須で、デフォルト値はありません。また、SMTP サーバー上の PROXY_PASSWORD オプションと一致している必要があります。

      例: default:SmtpProxyPassword A_Password

      EhloKeywords。このオプションは、プロキシがクライアントを通過させるために使用する、EHLO 拡張キーワードのリストを提供します。また、デフォルト値のセットも提供します。MMP は、SMTP リレーから返される EHLO のリストから、認識できない EHLO キーワードをすべて削除します。EhloKeywords は、リストから削除されない追加の EHLO キーワードを指定します。デフォルト値は空白ですが、SMTP プロキシは次のキーワードをサポートするので、これらのキーワードをこのオプションで指定する必要はありません。8BITMIME、PIPELINING、DSN、ENHANCEDSTATUSCODES、EXPN、HELP、XLOOP、ETRN、SIZE、STARTTLS、AUTH

      次に、使用頻度の少ない「TURN」拡張キーワードを使用するサイトで使用できる指定例を示します。

      例: default:EhloKeywords TURN

      PopBeforeSmtpKludgeChannel オプション。POP before SMTP で認証される接続で使用する MTA チャネルの名前に設定されます。デフォルトは空で、POP before SMTP を有効にするユーザーに対する通常の設定は tcp_intranet です。SSL のパフォーマンスを最適化するためにこのオプションを指定する必要はありません (「23.5.4 SMTP プロキシを使用した SSL パフォーマンスの最適化方法」を参照)。

      例: default:PopBeforeSmtpKludgeChannel tcp_intranet

      ClientLookup。このオプションはデフォルトで no に設定されます。yes に設定すると、クライアントの IP アドレスに関する DNS 逆引き検索が無条件に実行されるため、SMTP リレーサーバーで検索を行う必要がなくなります。このオプションは、ホストしているドメインごとに設定できます。

      例: default:ClientLookup yes

    2. PopProxyAService.cfg 設定ファイルに PreAuth オプションと AuthServiceTTL オプションを設定します。SSL のパフォーマンスを最適化するためにこのオプションを指定する必要はありません (「23.5.4 SMTP プロキシを使用した SSL パフォーマンスの最適化方法」を参照)。

      これらのオプションは、POP 認証後にユーザーがメールの送信を許可される時間を秒単位で指定します。一般的な設定は、900 〜 1800 (15 〜 30 分) です。

      例:


      default:PreAuth yes
default:AuthServiceTTL 900

    3. オプションで、MMP が、SMTP リレーからの応答を待つ時間を秒単位で指定することができます。この時間が経過すると MMP はリスト内の次の SMTP リレーを試行します。

      デフォルトは 10 (秒) です。SMTP リレーへの接続が失敗すると、MMP は、このフェイルオーバータイムアウトと同じ時間 (分単位) が経過するまで、そのリレーへの接続を試行しません。つまり、フェイルオーバータイムアウトが 10 秒のときに、あるリレーへの接続が失敗したとすると、MMP は、10 分間経過するまでそのリレーを再試行しません。

      例: default:FailoverTimeout 10

23.9 SMTP サービスへのクライアントアクセスを構成する

SMTP サービスへのクライアントアクセスの構成方法については、第 18 章「メールのフィルタリングとアクセス制御」を参照してください。

23.10 SSL を使用したユーザーまたはグループディレクトリの検索

MTA、MMP、および IMAP/POP/HTTP の各サービスに対して、SSL によるユーザーディレクトリまたはグループディレクトリの検索を行うことができます。この機能を使用するためには、Messaging Server を SSL モードで構成しておく必要があります。この機能を有効にするには、configutil パラメータのlocal.service.pab.ldapport を 636 に設定し、local.ugldapport を 636 に設定し、local.ugldapusessl を 1 に設定します。