資格レベルと認証方法の構成

クライアントに適用されるセキュリティ・モデルは、資格レベルと認証方式の組合せで定義されます。

Directory Serverでは、次の資格レベルがサポートされています。

匿名。ディレクトリの特定部分に匿名アクセスを許可すると、そのディレクトリにアクセスできるすべてのユーザーに読取りアクセス権を与えることになります。

匿名資格レベルを使用する場合、すべてのLDAPネーミング・エントリおよび属性に読取りアクセスを許可する必要があります。

注意: 匿名でのディレクトリへの書込みアクセスは許可しないでください。これを許可すると、どのユーザーでも、書込みアクセス権のあるDIT内の情報(別のユーザーのパスワードや自分自身の識別情報など)の変更が可能になります。

プロキシ。クライアントは、プロキシ・アカウントを使用してディレクトリへの認証またはバインドを行います。

このプロキシ・アカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このプロキシ・アカウントは、ディレクトリでネーミング・サービス機能を実行するための十分なアクセス権を必要とします。プロキシ資格レベルを使用して、すべてのクライアントでproxyDNおよびproxyPasswordを構成する必要があります。暗号化されたproxyPasswordはクライアントでローカルに格納されます。
匿名プロキシ。複数の資格レベルが定義された複数値エントリ。

匿名プロキシ・レベルを割り当てられたクライアントは、最初にそのプロキシ・アイデンティティを使用して認証を試みます。ユーザーのロックアウトやパスワードの有効期限切れなどなんらかの理由でプロキシ・ユーザーとして認証できなかった場合、クライアントは匿名アクセスを使用します。この場合、ディレクトリの構成によっては、別のサービス・レベルに移行する可能性があります。

クライアント認証は、クライアントのアイデンティティを確認するためのサーバーのメカニズムです。

クライアント認証は、次のいずれかの方法で実行できます。

DNとパスワードを提供する。
クライアントによって提供された証明書を使用する。

証明書ベースの認証では、SSLプロトコルを介して入手したクライアント証明書を使用して、ユーザー・エントリの識別情報が検出されます。証明書ベースの認証では、クライアントが外部メカニズムを指定するSASLバインド・リクエストを送信します。バインド・リクエストは、すでに確立されたSSL認証メカニズムに依存します。
SASLベースのメカニズムを使用する。
- すべてのオペレーティング・システムで、DIGEST-MD5によるSASL。
- Solarisオペレーティング・システムで、Kerberos V5によるクライアント認証が可能である、GSSAPIメカニズムによるSASL。
2つのうちどちらのSASLメカニズムを使用する場合も、アイデンティティのマッピングを行うようにサーバーを構成する必要があります。SASL資格は、主体と呼ばれます。主体の内容のバインドDNを決定するために、各メカニズムに特定のマッピングが必要です。主体が1つのユーザー・エントリにマッピングされ、SASLメカニズムがそのユーザーのアイデンティティを検証すると、ユーザーのDNがその接続のバインドDNとなります。
SSLクライアント認証モードを使用する。

SSL層ですべてのクライアントが認可されるようにするには、SSLクライアント認証を使用します。クライアント・アプリケーションは、SSL証明書をサーバーに送信することで認証を行います。SSL-client-auth-modeフラグを使用して、サーバーがSSLクライアント認証を許可する、リクエストする、または許可しないよう指定します。デフォルトでは、クライアントは認証を許可されます。

この項では、Directory Serverでの2つのSASLメカニズムの構成に関する次の情報について説明します。

Directory ServerでのSASL暗号化レベルの設定
DIGEST-MD5を利用したSASL認証
GSSAPIを利用したSASL認証

セキュリティの構成の詳細は、「LDAPクライアントでセキュリティを使用するための構成」を参照してください。

Directory ServerでのSASL暗号化レベルの設定

SASLメカニズムを構成する前に、暗号化が必要かどうかを指定する必要があります。SASL暗号化の要件は、最大および最小SSF(Strength Security Factor)によって設定されます。

属性dsSaslMinSSF(5dsat)およびdsSaslMaxSSF(5dsat)は、暗号化鍵の長さを示します。これらは、cn=SASL, cn=security, cn=configに保存されています。

サーバーに対しては、暗号化しないという選択肢も含めて、すべてのレベルの暗号化を設定できます。つまり、Directory Serverは256より大きいdsSaslMinSSF値とdsSaslMaxSSF値を受け入れます。しかし、現在SASLメカニズムは128より大きいSSFをサポートしません。Directory Serverはこれらの値のネゴシエーションを行い最大限のSSF値(128)にします。このため、基になるメカニズムによっては、実際の最大SSF値は、構成された最大値より小さい可能性があります。

SASLセキュリティ・ファクタ認証は、次の2つの主要な項目に基づきます。サーバーとクライアント・アプリケーションによってリクエストされる最小ファクタと最大ファクタ、および使用可能な暗号化メカニズム。これらは背後のセキュリティ・コンポーネントによって提供されます。つまり、サーバーとクライアントは両方で設定された最大ファクタ以下で、両方で設定された最小ファクタ以上の、使用可能な中で最も大きいセキュリティ・ファクタを使用しようとします。

Directory Serverに対するデフォルトの最小SASLセキュリティ・ファクタであるdsSaslMinSSFは0で、保護されていないことを示します。実際の最小値は、Directory Serverの最小値を変更しないかぎり、クライアント設定によって変わります。実際は、サーバーとクライアントに使用する最低レベルに最小値を設定します。サーバーとクライアントが最低要件を満たすメカニズムのネゴシエーションに失敗した場合、接続は確立されません。

SASL暗号化をリクエストするには:

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

SASL暗号化をリクエストするにはdsSaslMinSSF値を最低限必要な暗号化に設定します。

$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
replace: dsSaslMinSSF
dsSaslMinSSF: 128
^D

SASL暗号化を許可しないためには:

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

SASL暗号化を許可しない場合は、dsSaslMinSSFとdsSaslMaxSSFの両方の値を0に設定します。

$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
replace: dsSaslMinSSF
dsSaslMinSSF: 0

replace: dsSaslMaxSSF
dsSaslMaxSSF: 0

DIGEST-MD5を利用したSASL認証

DIGEST-MD5メカニズムは、クライアントによって送信されたハッシュされた値をユーザーのパスワードのハッシュと比較することによって、クライアントを認証します。ただし、このメカニズムはユーザー・パスワードを読み取る必要があり、DIGEST-MD5による認証を希望するすべてのユーザーは、ディレクトリ内に{CLEAR}パスワードを持つ必要があります。{CLEAR}パスワードをディレクトリに保存する場合に、第6章「Directory Serverのアクセス制御」で説明されているように、パスワード値へのアクセスがACIによって正しく制限されていることを確認する必要があります。さらに、「属性値の暗号化」で説明しているように、接尾辞で属性の暗号化を設定する必要があります。

DIGEST-MD5メカニズムを構成するには:

次の手順は、DIGEST-MD5を使用するようにDirectory Serverを構成する方法を説明しています。

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

DIGEST-MD5がルート・エントリ上でsupportedSASLMechanisms属性の値であることを確認するには、ldapsearchコマンドを使用します。

たとえば、次のコマンドはどのSASLメカニズムが有効であるかを表示します。

$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \
 -s base -b "" "(objectclass=*)" supportedSASLMechanisms
Enter bind password:
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: GSSAPI

DIGEST-MD5が有効でない場合は、有効にします。

$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - 
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
add: dsSaslPluginsEnable
dsSaslPluginsEnable: DIGEST-MD5
-
replace: dsSaslPluginsPath
dsSaslPluginsPath: SASL-library

ここで、SASL-libraryは次のいずれかです。

ネイティブ・パッケージ・ベース・インストール: /usr/lib/mps/sasl2
Zipインストール: install-path/lib/private/

DIGEST-MD5のデフォルトのアイデンティティ・マッピングを使用するか新規作成します。
詳細は、「DIGEST-MD5アイデンティティ・マッピング」を参照してください。
DIGEST-MD5を使用するSSL経由でサーバーにアクセスするすべてのユーザーのパスワードが{CLEAR}で格納されていることを確認します。
パスワード保存スキーマについては、第7章「Directory Serverのパスワード・ポリシー」を参照してください。
SASL構成エントリまたはDIGEST-MD5アイデンティティ・マッピング・エントリの1つを変更した場合は、Directory Serverを再起動します。

DIGEST-MD5アイデンティティ・マッピング

SASLメカニズムのアイデンティティ・マッピングは、SASLアイデンティティの資格とディレクトリ内のユーザー・エントリをマッチングします。マッピングによって、SASLアイデンティティに対応するDNが見つからなかったときは、認証は失敗します。このメカニズムの詳細な説明については、Oracle Directory Server Enterprise Editionリファレンスを参照してください。

SASLアイデンティティは、Principalという文字列です。これは、各メカニズムに固有の形式でユーザーを表します。DIGEST-MD5では、クライアントは、dn:接頭辞とLDAP DN、またはu:接頭辞の後にクライアントが決定するテキストを続けた情報のいずれかが含まれる主体を作成する必要があります。マッピング時に、クライアントが送信した主体は、${Principal}プレースホルダで使用されます。

サーバー構成内の次のエントリは、DIGEST-MD5のデフォルト・アイデンティティ・マッピングです。

dn: cn=default,cn=DIGEST-MD5,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: dn:(.*)
dsMappedDN: \$1

このアイデンティティ・マッピングは、主体のdnフィールドに、ディレクトリ内の既存ユーザーの正確なDNが含まれていることを前提としています。

DIGEST-MD5用の独自のアイデンティティ・マッピングを定義するには:

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

cn=DIGEST-MD5,cn=identity mapping,cn=configの下でデフォルトのマッピング・エントリを編集するか、新しいマッピング・エントリを作成します。

次のコマンドは、このマッピングを定義する方法を示しています。

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=unqualified-username,cn=DIGEST-MD5,cn=identity mapping
cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: unqualified-username
dsMatching-pattern: \${Principal}
dsMatching-regexp: u:(.*)@(.*)\\.com
dsSearchBaseDN: dc=\$2
dsSearchFilter: (uid=\$1)

Directory Serverを再起動して、新しいマッピングを有効にします。

GSSAPIを利用したSASL認証

SASL上のGSSAPI(Generic Security Service API)では、クライアントを認証するために、Kerberos V5などのサード・パーティのセキュリティ・システムを使用できます。GSSAPIライブラリは、SolarisおよびLinuxオペレーティング・システムで使用できます。Sun Enterprise Authentication Mechanism(SEAM)サーバーにKerberos V5実装をインストールすることをお薦めします。

サーバーは、GSSAPIを使用してユーザーのアイデンティティを検証します。次に、SASLメカニズムはGSSAPIマッピング・ルールを適用して、この接続中のすべての操作のバインドDNとなるDNを取得します。

Kerberosシステムを構成するには:

製造元の指示に従って、Kerberosソフトウェアを構成します。Sun Enterprise Authentication Mechanism 1.0.1サーバーを使用している場合、次の手順を使用します。

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

始める前に

Solaris上では、デフォルトでKerberos 5パッケージがインストールされます。

Linux上では、次のKerberos 5パッケージがインストールされていることを確認してください。

krb5–workstation-1.6.1–36.e15
krb5–libs-1.6.136e15

詳細は、オペレーション・システムのドキュメントを参照してください。

構成ファイルを編集します。
Solaris: /etc/krb5/krb5.config
Linux: /etc/krb5.config
ユーザーとサービスを保存するためにKerberosデータベースを作成します。
データベース内でLDAPサービスの主体を作成します。
```
$ ldap/server-FQDN@realm
```
ここで、server-FQDNはDirectory Serverの完全修飾ドメイン名です。
Kerberosデーモン・プロセスを開始します。
注意: DNSは、ホスト・マシンに構成されている必要があります。

各手順の詳細は、ソフトウェアのマニュアルを参照してください。「GSSAPIとSASLを使用したKerberos認証の構成例」も参照してください。

GSSAPIメカニズムを構成するには:

次の手順は、GSSAPIを使用するようDirectory Serverを構成する方法を説明しています。

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

「GSSAPIアイデンティティ・マッピング」での説明に従って、GSSAPIのデフォルト・アイデンティティ・マッピングと任意のカスタム・マッピングを作成します。
サービス・キーを保存するために鍵タブを作成します。
LDAPサービス・キーは、鍵タブに保存されます。
1. 鍵タブは必ずDirectory Serverユーザーのみが読み取れるようにします。
2. 鍵タブを保存するための専用ファイルを作成します。例: /var/dsee7/ds7.keytab
  ファイル名をデフォルトの鍵タブファイル名から変更します。
3. デフォルトの鍵タブではなく、必ず新しい鍵タブが使用されるように、環境変数KRB5_KTNAMEを設定します。
SASL構成エントリまたはGSSAPIアイデンティティ・マッピング・エントリの1つを変更した場合は、Directory Serverを再起動します。
DNSは、ホスト・マシンに構成されている必要があります。

GSSAPIアイデンティティ・マッピング

SASLメカニズムのアイデンティティ・マッピングは、SASLアイデンティティの資格をディレクトリ内のユーザー・エントリとマッチングします。マッピングによって、SASLアイデンティティに対応するDNが見つからなかったときは、認証は失敗します。

SASLアイデンティティは、Principalという文字列です。これは、各メカニズムに固有の形式でユーザーを表します。KerberosでGSSAPIを使用した主体はuid [/instance][@ realm]という形式のアイデンティティです。uidにはオプションのinstance識別子を含め、オプションのrealmを続けられます(多くの場合、ドメイン名)。次の例は、いずれも有効なユーザー主体です。

bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM

最初は、ディレクトリ内にはGSSAPIマッピングは定義されていません。デフォルトのマッピングを定義し、使用する主体をクライアントがどのように定義するかに応じてカスタム・マッピングを定義する必要があります。

GSSAPI用のアイデンティティ・マッピングを定義するには:

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

cn=GSSAPI,cn=identity mapping, cn=configの下に新しいマッピング・エントリを作成します。
アイデンティティ・マッピング・エントリ内の属性の定義については、Oracle Directory Server Enterprise Editionリファレンスを参照してください。GSSAPIのマッピングの例は、instance-path/ldif/identityMapping_Examples.ldifにあります。
このファイル内のデフォルトGSSAPIマッピングは、主体にユーザーIDのみが含まれていることを前提としています。このマッピングは、ディレクトリの固定ブランチでユーザーを決定します。
```
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: nsContainer
objectclass: top
cn: default
dsMappedDN: uid=\${Principal},ou=people,dc=example,dc=com
```
このファイルに含まれるもう1つの例は、既知のレルムを含む主体にユーザーIDが記録されている場合に、ユーザーIDを決定する方法を示しています。
```
dn: cn=same_realm,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: same_realm
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=$1,ou=people,dc=EXAMPLE,dc=COM
```
Directory Serverを再起動して、新しいマッピングを有効にします。

ナビゲーション・リンクをスキップ
印刷ビューの終了
	Oracle Directory Server Enterprise Edition管理ガイド 11gリリース1(11.1.1.5.0)