test

Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド

第 6 章 Directory Server のセキュリティー

Directory Server は、ネットワークを介してセキュリティーが確保された、信頼できる通信を行ういくつかのメカニズムをサポートしています。LDAPS は LDAP の標準プロトコルで、SSL (Secure Socket Layer) 上で実行されます。LDAPS はデータを暗号化し、オプションとして認証のために証明書を使用します。この章で SSL という用語を使用する場合、サポートされているプロトコル SSL2、SSL3、および TLS 1.0 を指します。

Directory Server は StartTLS (Start Transport Layer Security) 拡張処理もサポートしているため、元は暗号化されていない LDAP 接続でも TLS を有効にできます。

さらに は、SASL (Simple Authentication and Security Layer) を介した GSSAPI (Generic Security Service API) にも対応しています。GSSAPI により、Solaris オペレーティングシステム (Solaris OS) で Kerberos Version 5 セキュリティープロトコルを利用できます。アイデンティティーマッピングメカニズムによって、Kerberos 主体とディレクトリ内のアイデンティティーが関連付けられます。

セキュリティー情報の詳細については、http://www.mozilla.org/projects/security/pki/nss/ の NSS の Web サイトを参照してください。

この章では、SSL によってセキュリティーを設定する手順について説明します。ACI については、第 7 章「Directory Server のアクセス制御」を参照してください。ユーザーアクセスとパスワードについては、第 8 章「Directory Server のパスワードポリシー」を参照してください。

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

Directory Server での SSL の使用

SSL (Secure Sockets Layer) は暗号化された通信と、オプションとして Directory Server とクライアントの間の認証を提供します。SSL は LDAP 上または DSML-over-HTTP で使用できます。SSL は、LDAP 上でデフォルトで有効になりますが、DSML-over-HTTP を使用している場合、簡単に SSL を有効にできます。さらに、サーバー間のセキュリティー保護された通信に SSL を使用するよう、レプリケーションを設定できます。

単純認証 (バインド DN とパスワード) で SSL を使用すると、サーバーとやり取りしたデータがすべて暗号化されます。暗号化によって、機密性とデータの完全性が保証されます。必要に応じて、クライアントは証明書を使用して Directory Server への接続の認証、および SASL (Simple Authentication and Security Layer) を利用したサードパーティー製のセキュリティーメカニズムへの接続の認証ができます。証明書ベースの認証では、公開鍵暗号方式を使用してクライアントまたはサーバーを偽装したり、認証されているユーザーになりすますことはできなくなります。

Directory Server では、SSL による通信と SSL を使用しない通信を別々のポートで同時に実行できます。また、セキュリティーのためにすべての通信をセキュリティー保護された LDAP ポートに限定することもできます。クライアント認証も設定できます。クライアント認証を必要とする、または許可するように設定できます。この設定によって、実行するセキュリティーのレベルが決定されます。

SSL によって、通常の LDAP 接続をセキュリティー保護する Start TLS 拡張処理への対応も有効になります。クライアントが通常の LDAP ポートにバインドされても、TLS (Transport Layer Security) プロトコルを使用して接続を保護できます。Start TLS 処理では、クライアントに一層の柔軟性が与えられ、ポートの割り当ても簡素化できます。

SSL が提供する暗号化メカニズムは、属性の暗号化にも使用されます。SSL を有効にすることで、サフィックスでの属性の暗号化を設定し、ディレクトリに格納するときにデータを保護することができます。詳細については、「属性値の暗号化」を参照してください。

これ以外のセキュリティーとして、アクセス制御命令 (ACI) を使用してディレクトリの内容にアクセス制御を設定できます。ACI は、特定の認証メソッドを必要としデータがセキュリティー保護されたチャネルでのみ送信します。SSL と証明書の使用を補完するように ACI を設定します。詳細については、第 7 章「Directory Server のアクセス制御」を参照してください。

SSL は LDAP 上ではデフォルトで有効になります。DSML-over-HTTP では簡単に SSL を有効にできます。さらに、次に説明するように、一部の SSL 設定は変更が可能です。

証明書の管理

この節では、Directory Server で SSL 証明書を管理する方法について説明します。

Directory Server 上で SSL を実行するには、自己署名付き証明書または公開鍵インフラストラクチャー (PKI) ソリューションを使用する必要があります。

PKI ソリューションには、外部の認証局 (CA) が関係します。PKI ソリューションの場合、CA 署名付きサーバー証明書が必要です。これには、公開鍵と非公開鍵の両方が含まれます。この証明書は、Directory Server に固有のものです。また、公開鍵を含む信頼できる CA 証明書も必要です。信頼できる CA 証明書は、CA からのサーバー証明書がすべて信頼できることを示します。この証明書は CA ルート鍵またはルート証明書と呼ばれることもあります。

注 –

テスト目的で証明書を使用している場合、自己署名付き証明書を使用できます。しかし、本番で自己署名付き証明書を使用することはあまり安全ではありません。本番では、信頼できる証明書発行局 (CA) の証明書を使用してください。

この節で示す手順では、dsadm コマンドと dsconf コマンドを使用します。これらのコマンドについては、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

この節では、Directory Server での証明書設定に関する次の情報について説明します。

Procedureデフォルトの自己署名付き証明書を表示する

Directory Server インスタンスを初めて作成した場合、これには、デフォルトの自己署名付き証明書が含まれています。自己署名付き証明書は、公開鍵と非公開鍵のペアで、公開鍵が非公開鍵によって署名されています。自己署名付き証明書は、3 か月間有効です。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. デフォルトの自己署名付き証明書を表示するには、次のコマンドを使用します。


    $ dsadm show-cert instance-path defaultCert

Procedure自己署名済み証明書を管理する

Directory Server インスタンスを作成すると、デフォルトの自己署名付き証明書が自動的に用意されます。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. デフォルト設定以外の自己署名付き証明書を作成するには、次のコマンドを使用します。


    $ dsadm add-selfsign-cert instance-path cert-alias

    ここで、cert-alias は、証明書を特定するために付ける名前です。

    このコマンドのオプションをすべて確認するには、dsadm(1M) のマニュアルページまたはコマンド行のヘルプを参照してください。 


    $ dsadm add-selfsign-cert --help

  2. 自己署名付き証明書の期限が切れた場合は、サーバーインスタンスを停止して、証明書を更新します。


    $ dsadm stop instance-path
$ dsadm renew-selfsign-cert instance-path cert-alias

  3. サーバーインスタンスを再起動します。


    $ dsadm start instance-path

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

この手順は、Directory Server とともに使用するために CA 署名付きサーバー証明書を要求し、インストールする方法を説明しています。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

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


    $ dsadm request-cert [-W cert-pwd-file] {-S DN | --name name [--org org] \
  [--org-unit org-unit] [--city city] [--state state] [--country country]} \
  [-o output-file] [-F format] instance-path

    たとえば、Example 社の CA 署名付きサーバー証明書を要求するには、次のコマンドを使用します。


    $ dsadm request-cert --name host1 --org Example --org-unit Marketing \
 -o my_cert_request_file /local/ds

    サーバーを完全に特定するために、認証局はこの例で示す属性すべてを必要とする場合があります。各属性の説明については、dsadm(1M) のマニュアルページを参照してください。

    dsadm request-cert を使用して証明書を要求すると、出力形式として ASCII を指定しない限り、作成される証明書要求はバイナリ証明書要求になります。ASCII を指定すると、作成される証明書要求は、PEM 形式の PKCS #10 証明書要求になります。PEM (Privacy Enhanced Mail) は、RFC 1421 〜 1424 (http://www.ietf.org/rfc/rfc1421.txt ) で指定されている形式で、US-ASCII 文字を使用した base64 形式で符号化されます。要求の内容は、次の例のようになります。


    -----BEGIN NEW CERTIFICATE REQUEST-----
MIIBrjCCARcCAQAwbjELMAkGA1UBhMCVXMxEzARBgNVBAgTCkNBElGT1JOSUExLD
AqBgVBAoTI25ldHNjYXBlIGNvb11bmljYXRpb25zIGNvcnBvcmF0aWuMRwwGgYDV
QQDExNtZWxsb24umV0c2NhcGUuY29tMIGfMA0GCSqGSIb3DQEBAUAA4GNADCBiQK
BgCwAbskGh6SKYOgHy+UCSLnm3ok3X3u83Us7u0EfgSLR0f+K41eNqqWRftGR83e
mqPLDOf0ZLTLjVGJaHJn4l1gG+JDf/n/zMyahxtV7+T8GOFFigFfuxJaxMjr2j7I
vELlxQ4IfZgwqCm4qQecv3G+N9YdbjveMVXW0v4XwIDAQABAAwDQYJKoZIhvcNAQ
EEBQADgYEAZyZAm8UmP9PQYwNy4Pmypk79t2nvzKbwKVb97G+MT/gw1pLRsuBoKi
nMfLgKp1Q38K5Py2VGW1E47/rhm3yVQrIiwV+Z8Lcc=
-----END NEW CERTIFICATE REQUEST-----

  2. 手順に従って、証明書要求を認証局に転送します。

    認証局証明書を入手するプロセスは、使用する認証局によって異なります。商用 CA のなかには、証明書を自動的にダウンロードできる Web サイトを備えているものもあります。その他の CA は、要求に応じて電子メールで証明書を送信します。

    証明書要求を送信したら、証明書に関する 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 署名付きサーバー証明書と信頼できる CA 証明書を追加する

この手順は、Directory Server で使用するために、CA 署名付きサーバー証明書と信頼できる CA 証明書をインストールする方法を説明しています。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. CA 署名付きサーバー証明書を追加します。


    $ dsadm add-cert --ca instance-path cert-alias cert-file

    ここで、cert-alias は証明書を特定するために付ける名前です。cert-file は、PEM 形式の PKCS #11 証明書を含むテキストファイルです。

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


    $ dsadm add-cert /local/ds server-cert /local/safeplace/serv-cert-file

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

  2. 信頼できる認証局証明書を追加します。


    $ dsadm add-cert --ca instance-path cert-alias cert-file

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

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


    $ dsadm add-cert --ca /local/ds CA-cert /local/safeplace/ca-cert-file

  3. (省略可能) インストールした証明書を確認します。

    • サーバー証明書をすべて一覧表示して、有効期限とエイリアスを表示するには、次のように入力します。


      $ dsadm list-certs instance-path

      次に例を示します。


      $ dsadm list-certs /local/ds1
Enter the certificate database password:
Alias       Valid from Expires on Self-   Issued by          Issued to
                                  signed?                                     
----------- ---------- ---------- ------- -----------------  -----------------
serverCert  2000/11/10 2011/02/10 n       CN=CA-Signed Cert, CN=Test Cert,
            18:13      18:13              OU=CA,O=com        dc=example,dc=com
defaultCert 2006/05/18 2006/08/18 y       CN=host1,CN=DS,    Same as issuer
            16:28      16:28              dc=example,dc=com
2 certificates found

      デフォルトで、Directory Proxy Server のインスタンスには、defaultCert と呼ばれるデフォルトのサーバー証明書が含まれます。Same as issuer は、デフォルト証明書が自己署名付きサーバー証明書であることを示します。

    • 信頼できる CA 証明書を一覧表示するには、次のように入力します。


      $ dsadm list-certs -C instance-path

      次に例を示します。


      $ dsadm list-certs -C /local/ds1
Enter the certificate database password:
Alias   Valid from Expires on Self-   Issued by           Issued to
                              signed?                                   
------- ---------- ---------- ------- -----------------   --------------
CA-cert 2000/11/10 2011/02/10 y       CN=Trusted CA Cert, Same as issuer
        18:12      18:12              OU=CA,O=com
1 certificate found

    • 証明書の有効期限を含む、証明書の詳細を表示するには、次のように入力します。


      $ dsadm show-cert instance-path cert-alias

      たとえば、サーバー証明書を表示するには、次のように入力します。


      $ dsadm show-cert /local/ds1 "Server-Cert"
Enter the certificate database password:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer:
            "CN=Server-Cert,O=Sun,C=US"
        Validity:
            Not Before: Fri Nov 10 18:12:20 2000
            Not After : Thu Feb 10 18:12:20 2011
        Subject:
            "CN=CA Server Cert,OU=ICNC,O=Sun,C=FR"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    bd:76:fc:29:ca:06:45:df:cd:1b:f1:ce:bb:cc:3a:f7:
                    77:63:5a:82:69:56:5f:3d:3a:1c:02:98:72:44:36:e4:
                    68:8c:22:2b:f0:a2:cb:15:7a:c4:c6:44:0d:97:2d:13:
                    b7:e3:bf:4e:be:b5:6a:df:ce:c4:c3:a4:8a:1d:fa:cf:
                    99:dc:4a:17:61:e0:37:2b:7f:90:cb:31:02:97:e4:30:
                    93:5d:91:f7:ef:b0:5a:c7:d4:de:d8:0e:b8:06:06:23:
                    ed:5f:33:f3:f8:7e:09:c5:de:a5:32:2a:1b:6a:75:c5:
                    0b:e3:a5:f2:7a:df:3e:3d:93:bf:ca:1f:d9:8d:24:ed
                Exponent: 65537 (0x10001)
    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        85:92:42:1e:e3:04:4d:e5:a8:79:12:7d:72:c0:bf:45:
        ea:c8:f8:af:f5:95:f0:f5:83:23:15:0b:02:73:82:24:
        3d:de:1e:95:04:fb:b5:08:17:04:1c:9d:9c:9b:bd:c7:
        e6:57:6c:64:38:8b:df:a2:67:f0:39:f9:70:e9:07:1f:
        33:48:ea:2c:18:1d:f0:30:d8:ca:e1:29:ec:be:a3:43:
        6f:df:03:d5:43:94:8f:ec:ea:9a:02:82:99:5a:54:c9:
        e4:1f:8c:ae:e2:e8:3d:50:20:46:e2:c8:44:a6:32:4e:
        51:48:15:d6:44:8c:e6:d2:0d:5f:77:9b:62:80:1e:30
    Fingerprint (MD5):
        D9:FB:74:9F:C3:EC:5A:89:8F:2C:37:47:2F:1B:D8:8F
    Fingerprint (SHA1):
        2E:CA:B8:BE:B6:A0:8C:84:0D:62:57:85:C6:73:14:DE:67:4E:09:56

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

Procedure有効期限の切れた CA 署名付きサーバー証明書を更新する

CA 署名付きサーバー証明書 (公開鍵と非公開鍵) の有効期限が切れた場合は、次の手順に従って更新します。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

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

  2. 更新された証明書を受け取ったら、サーバーインスタンスを停止して、証明書をインストールします。


    $ dsadm stop instance-path
$ dsadm renew-cert instance-path cert-alias cert-file

  3. サーバーインスタンスを再起動します。


    $ dsadm start instance-path

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

場合によって、あとで証明書をインポートできるように、証明書の公開鍵と非公開鍵をエクスポートすることがあります。たとえば、別のサーバーで使用する証明書が必要な場合があります。

この手順のコマンドは、"cn=*,o=example" のようなワイルドカードを含む証明書で使用できます。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

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


    $ dsadm export-cert [-o output-file] instance-path cert-alias

    次に例を示します。


    $ dsadm export-cert -o /tmp/first-certificate /local/ds1 "First Certificate"
$ dsadm export-cert -o /tmp/first-ca-server-certificate /local/ds1/ defaultCert
Choose the PKCS#12 file password:
Confirm the PKCS#12 file password:
$ ls /tmp
first-ca-server-certificate

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


    $ dsadm import-cert instance-path cert-file

    たとえば、サーバーインスタンスに証明書をインポートするには、次のように入力します。


    $ dsadm import-cert /local/ds2 /tmp/first-ca-server-certificate
Enter the PKCS#12 file password:

  3. (省略可能) サーバーに証明書をインポートしたら、インポートした証明書を使用するようサーバーを設定します。


    $ dsconf set-server-prop -e -h host -p port ssl-rsa-cert-name:server-cert

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

デフォルトで、Directory Server は保存されたパスワードを使用して SSL 証明書データベースのパスワードを内部的に管理します。証明書を管理する場合に、ユーザーは証明書パスワードを入力したり、パスワードファイルを指定したりする必要はありません。パスワードは暗号化されているのではなく、非表示になっているだけなので、このオプションはあまり安全ではありません。

より安全に証明書を使用したい場合には、コマンド行でユーザーがパスワード入力を求められるようにサーバーを設定できます。この場合、ユーザーは autostart、 backup、disable-service、enable-service、 info、reindex、restore、および stop 以外の dsadm のすべてのサブコマンドに対して証明書データベースのパスワードを入力する必要があります。証明書データベースは、ディレクトリ instance-path/alias にあります。

Procedureユーザーが証明書のパスワード入力を求められるようにサーバーを設定する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. サーバーを停止します。


    $ dsadm stop instance-path

  2. パスワードプロンプトフラグを on に設定します。


    $ dsadm set-flags instance-path cert-pwd-prompt=on

    証明書に対してパスワードを設定するよう求められます。

  3. 次のように入力して、サーバーを起動します。


    $ dsadm start instance-path

Directory Server の証明書データベースのバックアップと復元

Directory Server のインスタンスをバックアップする場合、Directory Server の設定と証明書をバックアップします。バックアップされた証明書は archive-path/alias ディレクトリに格納されます。

Directory Server のバックアップと復元の方法については、「障害回復用のバックアップを作成する」を参照してください。

SSL 通信の設定

この節では、SSL の有効化と無効化に関する手順について説明します。

セキュリティー保護されていない接続の無効化

サーバーインスタンスが作成されると、デフォルトで LDAP クリアポートとセキュア LDAP ポート (LDAPS) が作成されます。しかし、サーバーが SSL を介してのみ通信するように SSL 以外の通信を無効にする場合もあります。

SSL 接続は、デフォルトの自己署名付き証明書で有効になります。希望する場合は、自分の証明書をインストールできます。サーバーの起動後の証明書の管理と、SSL の無効化の手順については、第 6 章「Directory Server のセキュリティー」を参照してください。証明書、証明書データベース、CA 署名付きサーバー証明書の入手の概要については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。

ProcedureLDAP クリアポートを無効にする

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. LDAP クリアポートを無効にします。

    セキュリティー保護されていないポートを無効にするには、LDAP セキュアポートにバインドします。この例は、ホストサーバー host1 上のデフォルトの LDAP セキュアポート 1636 へのバインドを示しています。


    $ dsconf set-server-prop -h host1 -P 1636 ldap-port:disabled

  2. 変更内容を有効にするために、サーバーを再起動します。


    $ dsadm restart /local/ds

    これで、セキュリティー保護されていないポートにバインドすることはできなくなります。

暗号化方式の選択

暗号化方式は、データを暗号化、復号化するために使用するアルゴリズムです。一般に、暗号化に使用するビット数が多いほど、強度と安全性は高まります。SSL の暗号化方式は、使用するメッセージ認証のタイプによっても識別されます。メッセージ認証は、データの整合性を保証するチェックサムを計算する別のアルゴリズムです。

クライアントがサーバーとの SSL 接続を開始するときは、情報の暗号化にどの暗号を使用するかについて、クライアントとサーバーが合意する必要があります。双方向の暗号化プロセスでは、必ず、送信側と受信側の両方が同じ暗号化方式を使用する必要があります。使用する暗号化方式は、サーバーが保存している暗号化方式の一覧の現在の順序によって決まります。サーバーは、その一覧内でクライアントに提示された暗号化方式に一致する最初の暗号化方式を選択します。Directory Server のデフォルトの暗号化方式値は all です。これは、背後の SSL ライブラリにサポートされている既知のセキュリティー保護されたすべての暗号化方式を意味します。ただし、この値は特定の暗号化方式のみを受け入れるように変更できます。

Directory Server で使用できる暗号化方式の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。

Procedure暗号化方式を選択する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. サーバーに対して SSL が有効であることを確認します。

    「SSL 通信の設定」を参照してください。

  2. 使用可能な SSL 暗号化方式を表示します。


    $ dsconf get-server-prop -h host -p port ssl-supported-ciphers
ssl-supported-ciphers  :  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_DHE_RSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_DHE_DSS_WITH_AES_256_CBC_SHA 
...

  3. (省略可能) 暗号化されていないデータのコピーを維持する場合は、SSL 暗号化方式を設定する前にデータをエクスポートします。

    「LDIF へのエクスポート」を参照してください。

  4. SSL 暗号化方式を設定します。


    $ dsconf set-server-prop -h host -p port ssl-cipher-family:cipher

    たとえば、暗号ファミリを SSL_RSA_WITH_RC4_128_MD5 と SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA に設定するには、次のように入力します。


    $ dsconf set-server-prop -h host1 -P 1636 ssl-cipher-family:SSL_RSA_WITH_RC4_128_MD5 \
 ssl-cipher-family:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Enter "cn=Directory Manager" password:  
Before setting SSL configuration, export Directory Server data. 
Do you want to continue [y/n] ? y
Directory Server must be restarted for changes to take effect.

  5. (省略可能) 既存のリストに SSL 暗号化方式を追加します。

    指定した暗号化方式のリストがすでに存在し、そのリストに暗号化方式を追加する場合は、次のコマンドを使用します。


    $ dsconf set-server-prop -h host -p port ssl-cipher-family+:cipher

    たとえば、SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA 暗号化方式を追加するには、次のように入力します。


    $ dsconf set-server-prop -h host1 -P 1636 \
 ssl-cipher-family+:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

  6. 変更内容を有効にするために、サーバーを再起動します。


    $ dsadm restart /local/ds

資格レベルと認証方法の設定

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

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

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

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

この節では、Directory Server での 2 つの 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 の最小値を変更しない限り、クライアント設定によって変わります。実際は、サーバーとクライアントに使用する最低レベルに最小値を設定します。サーバーとクライアントが最低要件を満たすメカニズムのネゴシエーションに失敗した場合、接続は確立されません。

ProcedureSASL 暗号化を要求する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 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

ProcedureSASL 暗号化を許可しない

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

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


    $ 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 による認証を希望するすべてのユーザーは、ディレクトリ内に平文パスワードを持つ必要があります。平文パスワードをディレクトリに保存する場合に、第 7 章「Directory Server のアクセス制御」で説明されているように、パスワード値へのアクセスが ACI によって正しく制限されていることを確認する必要があります。さらに、「属性値の暗号化」で説明しているように、サフィックスで属性の暗号化を設定する必要があります。

ProcedureDIGEST-MD5 メカニズムを設定する

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 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

  2. 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 は次のいずれかです。

    JES installation

    /usr/lib/mps/sasl2

    Zip installation

    install-path/dsee6/private/lib

  3. DIGEST-MD5 のデフォルトのアイデンティティーマッピングを使用するか新規作成します。

    詳細については、「DIGEST-MD5 アイデンティティーマッピング」を参照してください。

  4. DIGEST-MD5 を使用する SSL 経由でサーバーにアクセスするすべてのユーザーのパスワードが平文形式で格納されていることを確認します。

    パスワード保存スキーマについては、第 8 章「Directory Server のパスワードポリシー」を参照してください。

  5. SASL 設定エントリまたは DIGEST-MD5 アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。

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

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

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 が含まれていることを前提としています。

ProcedureDIGEST-MD5 用の独自のアイデンティティーマッピングを定義する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 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)

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

GSSAPI を利用した SASL 認証 (Solaris OS のみ)

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 を取得します。

ProcedureKerberos システムを設定する

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. /etc/krb5 内のファイルを設定します。

  2. ユーザーとサービスを保存するために Kerberos データベースを作成します。

  3. データベース内で LDAP サービスの主体を作成します。


    $ ldap/server-FQDN@realm

    ここで、server-FQDN は Directory Server の完全修飾ドメイン名です。

  4. Kerberos デーモンプロセスを開始します。

    注 –

    DNS は、ホストマシンに設定されている必要があります。

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

ProcedureGSSAPI メカニズムを設定する

次の手順は、Solaris OS 上で GSSAPI を使用するよう Directory Server を設定する方法を説明しています。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 「GSSAPI アイデンティティーマッピング」での説明に従って、GSSAPI のデフォルトアイデンティティーマッピングと任意のカスタムマッピングを作成します。

  2. サービスキーを保存するために鍵タブを作成します。

    LDAP サービスキーは、鍵タブに保存されます。

    1. 鍵タブは必ず Directory Server ユーザーのみが読み取れるようにします。

    2. ファイル名をデフォルトの /etc/krb5/krb5.keytab から変更します。

    3. デフォルトの鍵タブではなく、必ず新しい鍵タブが使用されるように、環境変数 KRB5_KTNAME を設定します。

  3. SASL 設定エントリまたは GSSAPI アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。

    DNS は、ホストマシンに設定されている必要があります。

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

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 マッピングは定義されていません。デフォルトのマッピングを定義し、使用する主体をクライアントがどのように定義するかに応じてカスタムマッピングを定義する必要があります。

ProcedureGSSAPI 用のアイデンティティーマッピングを定義する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 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

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

LDAP クライアントでセキュリティーを使用するための設定

次に、Directory Server とセキュリティー保護された接続を確立する LDAP クライアント内で SSL を設定および使用する方法を説明します。SSL 接続では、サーバーがクライアントに証明書を送信します。クライアントは、まず最初に証明書を信頼することで、サーバーが信頼できるものであることを確認します。次に、必要に応じてクライアントは独自の証明書または SASL メカニズム (2 つのうち 1 つ) の情報を送信することで、いずれかのクライアント認証メカニズムを開始できます。SASL メカニズムは、Kerberos V5 を使用した DIGEST-MD5 および GSSAPI です。

次の各項では、SSL が有効な LDAP クライアントの例として、ldapsearch ツールを使用します。

他の LDAP クライアントに SSL 接続を設定する方法については、アプリケーションに付属するマニュアルを参照してください。

注 –

クライアントアプリケーションによっては、SSL を実装しても、信頼された証明書がサーバーにあるかどうかを検証しません。これらのクライアントアプリケーションは SSL プロトコルを使用してデータの暗号化を行いますが、機密の保護を保証することも第 3 者がユーザーとして認証されることを防止することもできません。

次の項では、セキュリティーを使用するために LDAP クライアントを設定する方法を説明します。

クライアントでの SASL DIGEST-MD5 の使用

クライアントで DIGEST-MD5 メカニズムを使用している場合、ユーザー証明書をインストールする必要はありません。ただし、暗号化された SSL 接続を利用するには、「証明書の管理」で説明した方法で、サーバー証明書を信頼する必要があります。

レルムの指定

レルムは、認証アイデンティティーが選択される名前空間を定義します。DIGEST-MD5 認証では、特定のレルムに対して認証を行う必要があります。

Directory Server は、DIGEST-MD5 のデフォルトレルムとして、マシンの完全修飾ホスト名を使います。サーバーは、nsslapd-localhost 設定属性に含まれる小文字のホスト名を使用します。

レルムを指定しない場合、サーバーが提供するデフォルトのレルムが適用されます。

環境変数の指定

UNIX 環境では、LDAP ツールが DIGEST-MD5 ライブラリを見つけることができるように、SASL-PATH 環境変数を設定する必要があります。DIGEST-MD5 ライブラリは、SASL プラグインに動的に読み込まれる共有ライブラリです。SASL_PATH 環境変数を次のように設定します。


export SASL_PATH=SASL-library

このパスは、Directory Server が LDAP ツールが起動されたホストと同じホストにインストールされていることを前提としています。

ldapsearch コマンドの例

SSL を使用せずに DIGEST-MD5 クライアント認証を実行することができます。次の例は、デフォルトの DIGEST-MD5 アイデンティティーマッピングを使用してバインド DN を決定します。


$ ldapsearch -h host1 -p 1389 \
 -o mech=DIGEST-MD5 [ \
 -o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -w - \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=56,maxssf=256,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

上の例は、-o (小文字の o) オプションを使用して SASL オプションを指定しています。レルムの指定は省略できますが、指定する場合は、サーバーホストマシンの完全修飾ドメイン名を指定する必要があります。プロキシ操作を対象とする authzid は使用されませんが、authid と authzid はどちらも必要であり、同じ値を指定する必要があります。-w パスワードオプションは authid に適用されます。

authid の値は、アイデンティティーマッピングで使用される主体です。authid には、ディレクトリ内の有効なユーザー DN が後に続くdn: プレフィックス か、クライアントが決定した任意の文字列が後に続く u: プレフィックスが含まれているはずです。このように authid を使用すると、「DIGEST-MD5 アイデンティティーマッピング」で説明しているマッピングを使用することができます。

最も一般的な設定は、クライアント認証のために LDAPS セキュアポートと DIGEST-MD5 を使用して暗号化を行う SSL 接続に対する設定です。次の例は、同じ処理を SSL 経由で実行します。


$ ldapsearch -h host1 -P 1636 \
 -Z -P .mozilla/bjensen/BJE6001.slt/cert8.db \
 -N "cert-example" -w - \
 -o mech=DIGEST-MD5 [-o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=0,maxssf=0,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

この例では、SSL を経由して処理を行う場合に ldapsearch コマンドに -N オプションと -w オプションが必要です。ただし、これらのオプションはクライアント認証には使用されません。その代わりに、サーバーは authid の値に含まれる主体の DIGEST-MD5 アイデンティティーマッピングを行います。

クライアントでの Kerberos SASL GSSAPI の使用

クライアントで GSSAPI メカニズムを使用する場合、ユーザー認証をインストールする必要はありませんが、Kerberos V5 セキュリティーシステムを設定する必要があります。また、暗号化された SSL 接続を使用する場合、「証明書の管理」で説明しているように、サーバー証明書を信頼します。

Procedureホスト上で Kerberos V5 を設定する

LDAP クライアントを実行するホストマシンで Kerberos V5 を設定する必要があります。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. インストール手順に従って Kerberos V5 をインストールします。

    Sun Enterprise Authentication Mechanism 1.0.1 クライアントソフトウェアをインストールすることをお勧めします。

  2. Kerberos ソフトウェアを設定します。

    Sun Enterprise Authentication Mechanism ソフトウェアを使用して、/etc/krb5 の下のファイルを設定します。この設定は、kdc サーバーを設定し、デフォルトレルムと Kerberos システムが必要とするその他の設定を定義します。

  3. kerberos_v5 に関する行が先頭になるように、必要に応じて /etc/gss/mech ファイルを編集します。

ProcedureKerberos 認証の SASL オプションを設定する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. GSSAPI メカニズムで有効にするクライアントアプリケーションを使用する前に、ユーザーの主体で Kerberos セキュリティーシステムを起動します。


    $ kinit user-principal

    ここで、user-principal は、お使いの SASL アイデンティティーです。たとえば、bjensen@example.com となります。

  2. Kerberos の使用を設定する SASL オプションを指定します。

    UNIX 環境では、SASL_PATH 環境変数を SASL ライブラリの正しいパスに設定します。Korn シェルでの設定例は次のようになります。


    $ export SASL_PATH=SASL-library

    このパスは、Directory Server が LDAP ツールが起動されたホストと同じホストにインストールされていることを前提としています。

    次に示す ldapsearch ツールの例は、-o (小文字の o) オプションを使用して Kerberos の使用を設定する SASL オプションを指定する方法を示しています。


    $ ldapsearch -h www.host1.com -p 1389 -o mech=GSSAPI -o authid="bjensen@EXAMPLE.COM" \
 -o authzid="bjensen@EXAMPLE.COM" -b "dc=example,dc=com" "(givenname=Richard)"

    authid は、kinit コマンドによって初期化された Kerberos キャッシュに含まれるので、省略することができます。authid を指定する場合、プロキシ操作を対象とする authzid は使用されませんが、authid と authzid にはどちらにも同じ値を指定する必要があります。authid の値は、アイデンティティーマッピングで使用される主体です。レルムを含み、主体はすべて完全な主体にする必要があります。「GSSAPI アイデンティティーマッピング」を参照してください。

GSSAPI と SASL を使用した Kerberos 認証の設定例

Directory Server に対する Kerberos の設定は、複雑な場合があります。最初に Kerberos のマニュアルを参照してください。

さらに詳細について知りたい場合は、次に示す手順例を参考にしてください。ただし、この手順は例であることを忘れないでください。自分の設定と環境に合わせて手順を変更してください。

Solaris OS での Kerberos の設定と使用の詳細については、『System Administration Guide: Security Services』を参照してください。このマニュアルは Solaris マニュアルセットの一部です。マニュアルページを参照することもできます。

    この例についての情報と使用する手順は、次のとおりです。

  1. 「この例の前提」

  2. 「すべてのマシン: Kerberos クライアント設定ファイルの編集」

  3. 「すべてのマシン: 管理サーバー ACL 設定ファイルの編集」

  4. 「KDC マシン: KDC サーバー設定ファイルの編集」

  5. 「KDC マシン: KDC データベースの作成」

  6. 「KDC マシン: 管理の主体と鍵タブの作成」

  7. 「KDC マシン: Kerberos デーモンの開始」

  8. 「KDC マシン: KDC マシンと Directory Server マシンに対するホスト主体の追加」

  9. 「KDC マシン: Directory Server に対する LDAP 主体の追加」

  10. 「KDC マシン: KDC へのテストユーザーの追加」

  11. 「Directory Server マシン: Directory Server のインストール」

  12. 「Directory Server マシン: GSSAPI を有効にするための Directory Server の設定」

  13. 「Directory Server マシン: Directory Server 鍵タブの作成」

  14. 「Directory Server マシン: Directory Server へのテストユーザーの追加」

  15. 「Directory Server マシン: テストユーザーとしての Kerberos チケットの取得」

  16. 「クライアントマシン: GSSAPI による Directory Server に対する認証」

この例の前提

この手順例では、1 つ目のマシンを KDC (Key Distribution Center) として操作し、2 つ目のマシンでは Directory Server を実行できるように設定する処理について説明します。この手順の結果として、ユーザーは GSSAPI によって Kerberos 認証を実行できるようになります。

同じマシン上で KDC と Directory Server の両方を実行することもできます。両方を同じマシン上で実行することを選択した場合にも同じ手順を使用できます。この場合、KDC マシンと Directory Server マシンで重複する手順は、一度行うだけで済みます。

この手順では、使用される環境に関する多くの前提条件が発生します。手順例を使用する場合は、環境に合わせて値を変更してください。前提は次のとおりです。

すべてのマシン: Kerberos クライアント設定ファイルの編集

/etc/krb5/krb5.conf 設定ファイルは、KDC と通信するために Kerberos クライアントが必要とする情報を提供しています。

Kerberos を使用して Directory Server に対する認証を行う KDC マシン、Directory Server マシン、および任意のクライアントマシン上の /etc/krb5/krb5.conf 設定ファイルを編集します。

更新された /etc/krb5/krb5.conf 設定ファイルは、次の例の内容のようになります。

例 6–1 編集後の kerberos クライアント設定ファイル /etc/krb5/krb5.conf 


#pragma ident   "@(#)krb5.conf  1.2     99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name\>__ placeholders
# with appropriate values for your network.
#

[libdefaults]
        default_realm = EXAMPLE.COM
[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }
[domain_realm]
        .example.com = EXAMPLE.COM
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log
        kdc_rotate = {

# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
                period = 1d

# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
                versions = 10
        }

[appdefaults]
        kinit = {
                renewable = true
                forwardable= true
        }
        gkadmin = {
                help_url =
 http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
        }

すべてのマシン: 管理サーバー ACL 設定ファイルの編集

/etc/krb5/kadm5.acl 設定ファイル内で、"___default_realm___" を "EXAMPLE.COM" に置き換えます。更新されたファイルは、次の例のようになります。

例 6–2 編集後の管理サーバー ACL 設定ファイル


#
# Copyright (c) 1998-2000 by Sun Microsystems, Inc.
# All rights reserved.
#
# pragma ident   "@(#)kadm5.acl  1.1     01/03/19 SMI"
*/admin@EXAMPLE.COM *

KDC マシン: KDC サーバー設定ファイルの編集

/etc/krb5/kdc.conf ファイルで、"___default_realm___" を "EXAMPLE.COM" に置き換えます。更新されたファイルは、次の例のようになります。

例 6–3 編集後の KDC サーバー設定ファイル /etc/krb5/kdc.conf 


# Copyright 1998-2002 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#ident  "@(#)kdc.conf   1.2     02/02/14 SMI"

[kdcdefaults]
        kdc_ports = 88,750

[realms]
        EXAMPLE.COM = {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                admin_keytab = /etc/krb5/kadm5.keytab
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                default_principal_flags = +preauth
        }

KDC マシン: KDC データベースの作成


$ /usr/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing database ’/var/krb5/principal’ for realm ’EXAMPLE.COM’,
master key name ’K/M@EXAMPLE.COM’
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: password
Re-enter KDC database master key to verify: password
$

KDC マシン: 管理の主体と鍵タブの作成

次のコマンドを使用して、kws/admin@EXAMPLE.COM という主体の管理ユーザーと、管理デーモンによって使用されるサービス鍵を作成します。


$ /usr/sbin/kadmin.local
kadmin.local:  add_principal kws/admin
Enter password for principal "kws/admin@EXAMPLE.COM": secret
Re-enter password for principal "kws/admin@EXAMPLE.COM": secret
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.com
Entry for principal kadmin/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab changepw/kdc.example.com

Entry for principal changepw/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  quit$

KDC マシン: Kerberos デーモンの開始

次のコマンドを実行して、KDC および管理のデーモンを開始します。


$ /etc/init.d/kdc start
$ /etc/init.d/kdc.master start
$

KDC プロセスはプロセス一覧に /usr/lib/krb5/krb5kdc と表示されます。管理デーモンは、/usr/lib/krb5/kadmind と表示されます。

Solaris 10 OS では、デーモンは SMF (Service Management Facility) フレームワークによって管理されます。Solaris 10 OS でデーモンを起動します。


$ svcadm disable network/security/krb5kdc
$ svcadm enable network/security/krb5kdc
$ svcadm disable network/security/kadmin
$ svcadm enable network/security/kadmin
$

KDC マシン: KDC マシンと Directory Server マシンに対するホスト主体の追加

KDC の Kerberos データベースと Directory Server マシンにホスト主体を追加するには、次の一連のコマンドを使用します。ホスト主体は、klist などの特定の Kerberos ユーティリティーによって使用されます。


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal -randkey host/kdc.example.com
Principal "host/kdc.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/kdc.example.com
Entry for principal host/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  add_principal -randkey host/directory.example.com
Principal "host/directory.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/directory.example.com
Entry for principal host/directory.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  quit
$

KDC マシン: Directory Server に対する LDAP 主体の追加

Directory Server で認証中のユーザーが持っている Kerberos チケットを検証できるようにするには、Directory Server が独自の主体を持っている必要があります。現在、Directory Server は ldap/fqdn@realm の主体を要求するためにハードコードされています。ここで、 fqdn は Directory Server の完全修飾ドメイン名で、realm は Kerberos レルムです。fqdn は、Directory Server のインストール時に設定される完全修飾名と一致させる必要があります。この場合、Directory Server の主体は、ldap/directory.example.com@EXAMPLE.COM となります。

Directory Server の LDAP 主体を作成するには、次の一連のコマンドを使用します。


$ /usr/sbin/kadmin -p kws/admin 
Enter Password: secret 
kadmin: add_principal -randkey ldap/directory.example.com 
Principal "ldap/directory.example.com@EXAMPLE.COM" created. 
kadmin: quit 
$

KDC マシン: KDC へのテストユーザーの追加

Kerberos 認証を実行するには、Kerberos データベース内にユーザー認証が存在している必要があります。この例では、ユーザーのユーザー名を kerberos-test にします。つまり Kerberos 主体が kerberos-test@EXAMPLE.COM になります。

この例の一連のコマンドを使用してユーザーを作成します。


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal kerberos-test
Enter password for principal "kerberos-test@EXAMPLE.COM": secret

Re-enter password for principal "kerberos-test@EXAMPLE.COM": secret

Principal "kerberos-test@EXAMPLE.COM" created.
kadmin:  quit
$

Directory Server マシン: Directory Server のインストール

Directory Server 6.0 と最新のパッチをインストールします。設定例は次のとおりです。

変数のタイプ 

値の例 

完全修飾コンピュータ名 

directory.example.com

インストールディレクトリ 

/opt/SUNWdsee

インスタンスのパス 

/local/ds

サーバーユーザー 

unixuser

サーバーグループ 

unixgroup

サーバーポート 

389

サフィックス 

dc=example,dc=com

Directory Server マシン: GSSAPI を有効にするための Directory Server の設定

最初に、ファイル /data/ds/shared/bin/gssapi.ldif を作成して、主体に基づいて認証を行う Kerberos ユーザーを識別するために Directory Server によって使用されるマッピングを定義します。次の例と同じ内容のファイルを作成します。

例 6–4 gssapi.ldif ファイルの内容


dn: cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=\$1,ou=People,dc=example,dc=com

dn: cn=SASL,cn=security,cn=config
changetype: modify
replace: dsSaslPluginsPath
dsSaslPluginsPath: /usr/lib/mps/sasl2/libsasl.so

次に、ldapmodify コマンドを使用して、適切なマッピングで GSSAPI を有効にするために Directory Server を更新します。次の例を参照してください。


$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -a -f /data/ds/shared/bin/gssapi.ldif
adding new entry cn=GSSAPI,cn=identity mapping,cn=config
adding new entry cn=default,cn=GSSAPI,cn=identity mapping,cn=config
modifying entry cn=SASL,cn=security,cn=config
$

Directory Server マシン: Directory Server 鍵タブの作成

これまでに説明したように、GSSAPI によって Kerberos ユーザーを認証するには、Directory Server は KDC 内に独自の主体が必要です。認証が正しく行われるためには、主体情報が Directory Server マシン上の Kerberos 鍵タブ内にある必要があります。この情報は、Directory Server が動作するユーザーアカウントが読み取れるファイル内にある必要があります。

正しいプロパティーを持つ鍵タブファイルを作成するには、次の一連のコマンドを使用します。


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  ktadd -k /local/ds/config/ldap.keytab ldap/directory.example.com
Entry for principal ldap/directory.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab
 WRFILE:/local/ds/config/ldap.keytab.
kadmin:  quit
$

このカスタム鍵タブのアクセス権と所有権を変更します。鍵タブを Directory Server を実行するために使用されるユーザーアカウントの所有にし、そのユーザーしか読み取れないようにします。


$ chown unixuser:unixgroup /local/ds/config /ldap.keytab
$ chmod 600 /local/ds/config/ldap.keytab
$

Directory Server は、デフォルトではファイル /etc/kerb5/krb5.keytab 内にある標準の Kerberos の鍵タブを使用しようとします。しかし、このファイルを Directory Server ユーザーが読めるようにすると、セキュリティー上のリスクが発生する可能性があります。これが、Directory Server 用のカスタム鍵タブを作成した理由です。

新しいカスタム鍵タブを使用するよう Directory Server を設定します。これは、KRB5_KTNAME 環境変数を設定して行います。

最後に Directory Server を再起動してこれらの変更を有効にします。


$ KRB5_KTNAME=/etc/krb5/ldap.keytab dsadm restart /local/ds

Directory Server マシン: Directory Server へのテストユーザーの追加

Kerberos ユーザーを Directory Server に対して認証するには、そのユーザーの Kerberos 主体に対応する、ユーザーのディレクトリエントリが必要です。

これまでの手順で、kerberos-test@EXAMPLE.COM という主体を持つテストユーザーが Kerberos データベースに追加されました。ディレクトリに追加されたアイデンティティーマッピング設定のために、そのユーザーに対応するディレクトリエントリには、uid=kerberos-test,ou=People,dc=example,dc=com という DN が必要です。

ユーザーをディレクトリに追加する前に、次の内容でファイル testuser.ldif を作成する必要があります。

例 6–5 新しい testuser.ldif ファイル


dn: uid=kerberos-test,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: kerberos-test
givenName: Kerberos
sn: Test
cn: Kerberos Test
description: An account for testing Kerberos authentication through GSSAPI

次に、ldapmodify を使用して、このエントリをサーバーに追加します。


$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f testuser.ldif
adding new entry uid=kerberos-test,ou=People,dc=example,dc=com
$

Directory Server マシン: テストユーザーとしての Kerberos チケットの取得

テストユーザーは、Kerberos データベース、Directory Server、および KDC 内に存在します。このため、Directory Server のテストユーザーとして GSSAPI を経由した Kerberos によって認証を行うことができるようになります。

まず、kinit コマンドを使用してユーザーの Kerberos チケットを取得します。次の例を参照してください。


$ kinit kerberos-test
Password for kerberos-test@EXAMPLE.COM: secret
$

次に、klist コマンドを使用して、このチケットに関する情報を表示します。


$ klist
Ticket cache: /tmp/krb5cc_0
Default principal: kerberos-test@EXAMPLE.COM

Valid starting            Expires                   Service principal
Sat Jul 24 00:24:15 2004  Sat Jul 24 08:24:15 2004  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until Sat Jul 31 00:24:15 2004
$

クライアントマシン: GSSAPI による Directory Server に対する認証

最後の手順は GSSAPI を使用した Directory Server に対する認証です。Directory Server の提供する ldapsearch ユーティリティーは、GSSAPI、DIGEST-MD5、および EXTERNAL メカニズムを含む SASL 認証をサポートしています。しかし、GSSAPI を使用してバインドするために、SASL ライブラリへのパスをクライアントに設定する必要があります。SASL_PATH 環境変数を lib/sasl ディレクトリに設定してパスを提供します。


$ SASL_PATH=SASL-library
$ export SASL_PATH
$

ldapsearch を使用して Directory Server に対して実際に Kerberos ベースの認証を実行するには、-o mech=GSSAPI 引数と -o authzid=principal 引数を含める必要があります。

また、ここで -h directory.example.com と表示している完全修飾ホスト名も指定する必要があります。これは、サーバーに対する cn=config 上の nsslapd-localhost 属性の値と一致する必要があります。GSSAPI 認証プロセスでは、クライアントから提供されたホスト名がサーバーから提供されたホスト名と一致する 必要があるため、ここでは -h オプションを使用する必要があります。

次の例では、これまでに作成した Kerberos テストユーザーアカウントとして認証を行なって、dc=example,dc=com エントリを取得しています。


$ ldapsearch -h directory.example.com -p 389 -o mech=GSSAPI \
 -o authzid="kerberos-test@EXAMPLE.COM" -b "dc=example,dc=com" -s base "(objectClass=*)"
version: 1
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
$

正常に認証されたかどうか Directory Server のアクセスログを確認します。


$ tail -12 /local/ds/logs/access

[24/Jul/2004:00:30:47 -0500] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAP 
		connection from 1.1.1.8 to 1.1.1.8
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - RESULT err=0 tag=97 
     nentries=0 etime=0 dn="uid=kerberos-test,ou=people,dc=example,dc=com"
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - SRCH base="dc=example,dc=com"
     scope=0 filter="(objectClass=*)" attrs=ALL
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - RESULT err=0 tag=101 nentries=1 
     etime=0
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=5 - UNBIND
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=-1 - closing - U1
[24/Jul/2004:00:30:48 -0500] conn=0 op=-1 msgId=-1 - closed.
$

この例は、バインドが 3 つの手順によるプロセスであることを示しています。最初の 2 つの手順で LDAP 結果 14 (SASL バインド実行中) を返し、3 番目の手順はバインドが成功したことを示します。method=sasl タグと mech=GSSAPI タグは、このバインドに GSSAPI SASL メカニズムが使用されたことを示しています。成功したバインド応答の最後の dn="uid=kerberos-test,ou=people,dc=example,dc=com" は、このバインドが適切なユーザーとして実行されたことを示しています。

パススルー認証

パススルー認証 (PTA) は、バインド要求がバインド DN によってフィルタされるメカニズムです。ある Directory Server (委任者) がバインド要求を受け取り、フィルタに基づいて別の Directory Server (被委任者) にバインド要求を認証するよう求めることができます。この機能の一部として、PTA プラグインによって委任者である Directory Server がローカルのデータベースに保存されているとは限らないエントリに対する単純なパスワードベースのバインド操作を受け入れられるようになります。

PTA プラグインは、サーバーとの非公開の通信のために DSCC にも使用されます。サーバーインスタンスが DSCC に登録されている場合、PTA プラグインが有効になり、DSCC URL が引数として追加されます。


$ dsconf get-plugin-prop -h host -p port "Pass Through Authentication" enabled argument
argument  :  ldap://DSCC_URL:DSCC_PORT/cn=dscc
enabled   :  on
注 –

可能なかぎり、PTA プラグインを変更しないようにしてください。PTA プラグインを変更すると、DSCC のアクセス問題が発生する可能性があります。

PTA プラグインを変更しなければならない場合は、次の手順に従う必要があります。

PTA プラグインが無効になったり、DSCC URL が引数から削除されると、サーバーインスタンスが DSCC 内に inaccessible として表示されます。この場合、DSCC が PTA プラグインをリセットするオプションを自動的に提供します。