SASL 上の GSSAPI (Generic Security Service API) では、クライアントを認証するために、Kerberos V5 などのサードパーティーのセキュリティーシステムを使用できます。GSSAPI ライブラリは、Solaris OS SPARC® プラットフォームの場合にのみ使用できます。Sun Enterprise Authentication MechanismTM 1.0.1 サーバーに Kerberos V5 実装をインストールすることをお勧めします。
サーバーは、GSSAPI を使用してユーザーの識別情報を検証します。次に、SASL メカニズムは GSSAPI マッピングルールを適用して、この接続中のすべての操作のバインド DN となる DN を取得します。
製造元の指示に従って、Kerberos ソフトウェアを設定します。Sun Enterprise Authentication Mechanism 1.0.1 サーバーを使用している場合、次の手順を使用します。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
/etc/krb5 内のファイルを設定します。
ユーザーとサービスを保存するために Kerberos データベースを作成します。
データベース内で LDAP サービスの主体を作成します。
$ ldap/server-FQDN@realm |
ここで、server-FQDN は Directory Server の完全修飾ドメイン名です。
Kerberos デーモンプロセスを開始します。
DNS は、ホストマシンに設定されている必要があります。
各手順の詳細については、ソフトウェアのマニュアルを参照してください。「GSSAPI と SASL を使用した Kerberos 認証の設定例」も参照してください。
次の手順は、Solaris OS 上で GSSAPI を使用するよう Directory Server を設定する方法を説明しています。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
「GSSAPI アイデンティティーマッピング」での説明に従って、GSSAPI のデフォルトアイデンティティーマッピングと任意のカスタムマッピングを作成します。
サービスキーを保存するために鍵タブを作成します。
LDAP サービスキーは、鍵タブに保存されます。
SASL 設定エントリまたは GSSAPI アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。
DNS は、ホストマシンに設定されている必要があります。
SASL メカニズムのアイデンティティーマッピングは、SASL アイデンティティーの資格をディレクトリ内のユーザーエントリと一致させようとします。マッピングによって、SASL アイデンティティーに対応する DN が見つからなかったときは、認証は失敗します。
SASL アイデンティティーは、Principal という文字列です。これは、各メカニズムに固有の形式でユーザーを表します。Kerberos で GSSAPI を使用した主体は uid [/instance][@ realm] という形式のアイデンティティーです。uid にはオプションの instance ID を含め、オプションの realm を続けることができます。これはドメイン名の場合があります。次の例は、いずれも有効なユーザー主体です。
bjensen bjensen/Sales bjensen@EXAMPLE.COM bjensen/Sales@EXAMPLE.COM |
最初は、ディレクトリ内には GSSAPI マッピングは定義されていません。デフォルトのマッピングを定義し、使用する主体をクライアントがどのように定義するかに応じてカスタムマッピングを定義する必要があります。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
cn=GSSAPI,cn=identity mapping, cn=config の下に新しいマッピングエントリを作成します。
アイデンティティーマッピングエントリ内の属性の定義については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。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 を再起動して、新しいマッピングを有効にします。