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 については、第 6 章「Directory Server のアクセス制御」を参照してください。ユーザーアクセスとパスワードについては、第 7 章「Directory Server のパスワードポリシー」を参照してください。
この章の内容は次のとおりです。
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 を設定します。詳細については、第 6 章「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 での証明書設定に関する次の情報について説明します。
Directory Server インスタンスを初めて作成した場合、これには、デフォルトの自己署名付き証明書が含まれています。自己署名付き証明書は、公開鍵と非公開鍵のペアで、公開鍵が非公開鍵によって署名されています。自己署名付き証明書は、3 か月間有効です。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
Directory Server インスタンスを作成すると、デフォルトの自己署名付き証明書が自動的に用意されます。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
デフォルト設定以外の自己署名付き証明書を作成するには、次のコマンドを使用します。
$ dsadm add-selfsign-cert instance-path cert-alias |
ここで、cert-alias は、証明書を特定するために付ける名前です。
このコマンドのオプションをすべて確認するには、dsadm(1M) のマニュアルページまたはコマンド行のヘルプを参照してください。
$ dsadm add-selfsign-cert --help |
自己署名付き証明書の期限が切れた場合は、サーバーインスタンスを停止して、証明書を更新します。
dsadm stop instance-path $ dsadm renew-selfsign-cert instance-path cert-alias |
サーバーインスタンスを再起動します。
$ dsadm start instance-path |
この手順は、Directory Server とともに使用するために CA 署名付きサーバー証明書を要求し、インストールする方法を説明しています。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
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----- |
認証局証明書を入手するプロセスは、使用する認証局によって異なります。商用 CA のなかには、証明書を自動的にダウンロードできる Web サイトを備えているものもあります。その他の CA は、要求に応じて電子メールで証明書を送信します。
証明書要求を送信したら、証明書に関する CA からの回答を待つ必要があります。要求に対する回答が届くまでの時間は、状況によって異なります。たとえば、CA が社内にある場合は、要求に対する回答は 1 〜 2 日しかかからないこともあります。CA が社外にある場合は、数週間かかることもあります。
認証局から受け取った証明書を保存します。
証明書を安全な場所にバックアップします。これにより、証明書を失っても、このバックアップファイルから証明書を再インストールできます。証明書はテキストファイルに保存できます。次に、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----- |
この手順は、Directory Server で使用するために、CA 署名付きサーバー証明書と信頼できる CA 証明書をインストールする方法を説明しています。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
CA 署名付きサーバー証明書を追加します。
$ dsadm add-cert --ca instance-path cert-alias cert-file |
ここで、cert-alias は証明書を特定するために付ける名前です。cert-file は、PEM 形式の PKCS #11 証明書を含むテキストファイルです。
たとえば、CA 署名付きサーバー証明書をインストールするには、次のようなコマンドを使用します。
$ dsadm add-cert --ca /local/ds server-cert /local/safeplace/serv-cert-file |
これで、証明書がインストールされますが、まだ信頼されていません。CA 署名付きサーバー証明書を信頼するには、認証局証明書をインストールする必要があります。
信頼できる認証局証明書を追加します。
$ dsadm add-cert --ca -C instance-path cert-alias cert-file |
-C オプションは、証明書が信頼できる認証局証明書であることを示します。
たとえば、認証局からの信頼できる証明書をインストールするには、次のようなコマンドを使用します。
$ dsadm add-cert --ca -C /local/ds CA-cert /local/safeplace/ca-cert-file |
(省略可能) インストールした証明書を確認します。
サーバー証明書をすべて一覧表示して、有効期限とエイリアスを表示するには、次のように入力します。
$ 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 |
CA 署名付きサーバー証明書 (公開鍵と非公開鍵) の有効期限が切れた場合は、次の手順に従って更新します。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
認証局から更新された CA 署名付きサーバー証明書を入手します。
更新された証明書を受け取ったら、サーバーインスタンスを停止して、証明書をインストールします。
$ dsadm stop instance-path $ dsadm renew-cert instance-path cert-alias cert-file |
サーバーインスタンスを再起動します。
$ dsadm start instance-path |
場合によって、あとで証明書をインポートできるように、証明書の公開鍵と非公開鍵をエクスポートすることがあります。たとえば、別のサーバーで使用する証明書が必要な場合があります。
この手順のコマンドは、"cn=*,o=example" のようなワイルドカードを含む証明書で使用できます。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
証明書をエクスポートします。
$ 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 |
証明書をインポートします。
$ dsadm import-cert instance-path cert-file |
たとえば、host1 上のサーバーインスタンスに証明書をインポートするには、次のように入力します。
$ dsadm import-cert -h host1 /local/ds2 /tmp/first-ca-server-certificate Enter the PKCS#12 file password: |
(省略可能) サーバーに証明書をインポートしたら、インポートした証明書を使用するようサーバーを設定します。
$ dsconf set-server-prop -e -h host -p port -w - ssl-rsa-cert-name:server-cert |
デフォルトで、Directory Server は保存されたパスワードを使用して SSL 証明書データベースのパスワードを内部的に管理します。証明書を管理する場合に、ユーザーは証明書パスワードを入力したり、パスワードファイルを指定したりする必要はありません。パスワードは暗号化されているのではなく、非表示になっているだけなので、このオプションはあまり安全ではありません。
より安全に証明書を使用したい場合には、コマンド行でユーザーがパスワード入力を求められるようにサーバーを設定できます。この場合、ユーザーは autostart、 backup、disable-service、enable-service、 info、reindex、restore、および stop 以外の dsadm のすべてのサブコマンドに対して証明書データベースのパスワードを入力する必要があります。証明書データベースは、ディレクトリ instance-path/alias にあります。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
サーバーを停止します。
$ dsadm stop instance-path |
パスワードプロンプトフラグを on に設定します。
$ dsadm set-flags instance-path cert-pwd-prompt=on |
証明書に対してパスワードを設定するよう求められます。
次のように入力して、Server を起動します。
$ dsadm start instance-path |
Directory Server のインスタンスをバックアップする場合、Directory Server の設定と証明書をバックアップします。バックアップされた証明書は archive-path/alias ディレクトリに格納されます。
Directory Server のバックアップと復元の方法については、「障害回復用のバックアップを作成する」を参照してください。
この節では、SSL の有効化と無効化に関する手順について説明します。
サーバーインスタンスが作成されると、デフォルトで LDAP クリアポートとセキュア LDAP ポート (LDAPS) が作成されます。しかし、サーバーが SSL を介してのみ通信するように SSL 以外の通信を無効にする場合もあります。
SSL 接続は、デフォルトの自己署名付き証明書で有効になります。希望する場合は、自分の証明書をインストールできます。サーバーの起動後の証明書の管理と、SSL の無効化の手順については、第 5 章「Directory Server のセキュリティー」を参照してください。証明書、証明書データベース、CA 署名付きサーバー証明書の入手の概要については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』を参照してください。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
LDAP クリアポートを無効にします。
セキュリティー保護されていないポートを無効にするには、LDAP セキュアポートにバインドします。この例は、ホストサーバー host1 上のデフォルトの LDAP セキュアポート 1636 へのバインドを示しています。
$ dsconf set-server-prop -h host1 -P 1636 ldap-port:disabled |
変更内容を有効にするために、サーバーを再起動します。
$ dsadm restart /local/ds |
これで、セキュリティー保護されていないポートにバインドすることはできなくなります。
暗号化方式は、データを暗号化、復号化するために使用するアルゴリズムです。一般に、暗号化に使用するビット数が多いほど、強度と安全性は高まります。SSL の暗号化方式は、使用するメッセージ認証のタイプによっても識別されます。メッセージ認証は、データの整合性を保証するチェックサムを計算する別のアルゴリズムです。
クライアントがサーバーとの SSL 接続を開始するときは、情報の暗号化にどの暗号を使用するかについて、クライアントとサーバーが合意する必要があります。双方向の暗号化プロセスでは、必ず、送信側と受信側の両方が同じ暗号化方式を使用する必要があります。使用する暗号化方式は、サーバーが保存している暗号化方式の一覧の現在の順序によって決まります。サーバーは、その一覧内でクライアントに提示された暗号化方式に一致する最初の暗号化方式を選択します。Directory Server のデフォルトの暗号化方式値は all です。これは、背後の SSL ライブラリにサポートされている既知のセキュリティー保護されたすべての暗号化方式を意味します。ただし、この値は特定の暗号化方式のみを受け入れるように変更できます。
Directory Server で使用できる暗号化方式の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』を参照してください。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
サーバーに対して SSL が有効であることを確認します。
「SSL 通信の設定」を参照してください。
使用可能な 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 ... |
(省略可能) 暗号化されていないデータのコピーを維持する場合は、SSL 暗号化方式を設定する前にデータをエクスポートします。
「LDIF へのエクスポート」を参照してください。
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. |
(省略可能) 既存のリストに 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 |
変更内容を有効にするために、サーバーを再起動します。
$ dsadm restart /local/ds |
クライアントに適用されるセキュリティーモデルは、資格レベルと認証方法の組み合わせで定義されます。
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 メカニズムの設定に関する次の情報について説明します。
セキュリティーの設定の詳細については、「LDAP クライアントでセキュリティーを使用するための設定」を参照してください。
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 の最小値を変更しない限り、クライアント設定によって変わります。実際は、サーバーとクライアントに使用する最低レベルに最小値を設定します。サーバーとクライアントが最低要件を満たすメカニズムのネゴシエーションに失敗した場合、接続は確立されません。
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 |
DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。
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 ^D |
DIGEST-MD5 メカニズムは、クライアントによって送信されたハッシュされた値をユーザーのパスワードのハッシュと比較することによって、クライアントを認証します。ただし、このメカニズムはユーザーパスワードを読み取る必要があり、DIGEST-MD5 による認証を希望するすべてのユーザーは、ディレクトリ内に {CLEAR} パスワードを持つ必要があります。{CLEAR} パスワードをディレクトリに保存する場合に、第 6 章「Directory Server のアクセス制御」で説明されているように、パスワード値へのアクセスが ACI によって正しく制限されていることを確認する必要があります。さらに、「属性値の暗号化」で説明しているように、サフィックスで属性の暗号化を設定する必要があります。
次の手順は、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 ^D |
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 ^D |
ここで、SASL-library は次のいずれかです。
/usr/lib/mps/sasl2
install-path/dsee6/private/lib
DIGEST-MD5 のデフォルトのアイデンティティーマッピングを使用するか新規作成します。
詳細については、「DIGEST-MD5 アイデンティティーマッピング」を参照してください。
DIGEST-MD5 を使用する SSL 経由でサーバーにアクセスするすべてのユーザーのパスワードが {CLEAR} に含まれていることを確認します。
パスワード保存スキーマについては、第 7 章「Directory Server のパスワードポリシー」を参照してください。
SASL 設定エントリまたは DIGEST-MD5 アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。
SASL メカニズムの アイデンティティーマッピングは、SASL アイデンティティーの資格をディレクトリ内のユーザーエントリと一致させようとします。マッピングによって、SASL アイデンティティーに対応する DN が見つからなかったときは、認証は失敗します。このメカニズムの詳細な説明については、『Sun Java System Directory Server Enterprise Edition 6.1 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 が含まれていることを前提としています。
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 を再起動して、新しいマッピングを有効にします。
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.1 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 を再起動して、新しいマッピングを有効にします。
次に、Directory Server とセキュリティー保護された接続を確立する LDAP クライアント内で SSL を設定および使用する方法を説明します。SSL 接続では、サーバーがクライアントに証明書を送信します。クライアントは、まず最初に証明書を信頼することで、サーバーが信頼できるものであることを確認します。次に、必要に応じてクライアントは独自の証明書または SASL メカニズム (2 つのうち 1 つ) の情報を送信することで、いずれかのクライアント認証メカニズムを開始できます。SASL メカニズムは、Kerberos V5 を使用した DIGEST-MD5 および GSSAPI です。
次の各項では、SSL が有効な LDAP クライアントの例として、ldapsearch ツールを使用します。
他の LDAP クライアントに SSL 接続を設定する方法については、アプリケーションに付属するマニュアルを参照してください。
クライアントアプリケーションによっては、SSL を実装しても、信頼された証明書がサーバーにあるかどうかを検証しません。これらのクライアントアプリケーションは SSL プロトコルを使用してデータの暗号化を行いますが、機密の保護を保証することも第 3 者がユーザーとして認証されることを防止することもできません。
次の項では、セキュリティーを使用するために LDAP クライアントを設定する方法を説明します。
クライアントで 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 ツールが起動されたホストと同じホストにインストールされていることを前提としています。
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 アイデンティティーマッピングを行います。
クライアントで GSSAPI メカニズムを使用する場合、ユーザー認証をインストールする必要はありませんが、Kerberos V5 セキュリティーシステムを設定する必要があります。また、暗号化された SSL 接続を使用する場合、「証明書を管理する」で説明しているように、サーバー証明書を信頼します。
LDAP クライアントを実行するホストマシンで Kerberos V5 を設定する必要があります。
DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。
インストール手順に従って Kerberos V5 をインストールします。
Sun Enterprise Authentication Mechanism 1.0.1 クライアントソフトウェアをインストールすることをお勧めします。
Kerberos ソフトウェアを設定します。
Sun Enterprise Authentication Mechanism ソフトウェアを使用して、/etc/krb5 の下のファイルを設定します。この設定は、kdc サーバーを設定し、デフォルトレルムと Kerberos システムが必要とするその他の設定を定義します。
kerberos_v5 に関する行が先頭になるように、必要に応じて /etc/gss/mech ファイルを編集します。
DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。
GSSAPI メカニズムで有効にするクライアントアプリケーションを使用する前に、ユーザーの主体で Kerberos セキュリティーシステムを起動します。
$ kinit user-principal |
ここで、user-principal は、お使いの SASL アイデンティティーです。たとえば、bjensen@example.com となります。
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 アイデンティティーマッピング」を参照してください。
Directory Server に対する Kerberos の設定は、複雑な場合があります。最初に Kerberos のマニュアルを参照してください。
さらに詳細について知りたい場合は、次に示す手順例を参考にしてください。ただし、この手順は例であることを忘れないでください。自分の設定と環境に合わせて手順を変更してください。
Solaris OS での Kerberos の設定と使用の詳細については、『System Administration Guide: Security Services』を参照してください。このマニュアルは Solaris マニュアルセットの一部です。マニュアルページを参照することもできます。
この例についての情報と使用する手順は、次のとおりです。
「Directory Server マシン : GSSAPI を有効にするための Directory Server の設定」
この手順例では、1 つ目のマシンを KDC (Key Distribution Center) として操作し、2 つ目のマシンでは Directory Server を実行できるように設定する処理について説明します。この手順の結果として、ユーザーは GSSAPI によって Kerberos 認証を実行できるようになります。
同じマシン上で KDC と Directory Server の両方を実行することもできます。両方を同じマシン上で実行することを選択した場合にも同じ手順を使用できます。この場合、KDC マシンと Directory Server マシンで重複する手順は、一度行うだけで済みます。
この手順では、使用される環境に関する多くの前提条件が発生します。手順例を使用する場合は、環境に合わせて値を変更してください。前提は次のとおりです。
このシステムには、推奨される最新のパッチクラスタのインストールされた最新の Solaris 9 ソフトウェアをインストールします。適切な Solaris パッチがインストールされていない場合、Directory Server に対する Kerberos 認証は失敗する可能性があります。
マニュアルに記述された手順は Solaris 10 とほとんど同じですが、いくつかの違いがあります。設定ファイルの形式が少しだけ異なるため、いくつかのコマンドの出力が同じでない場合もあります。
Kerberos デーモンを実行するマシンには、kdc.example.com という完全修飾ドメイン名を付けます。このマシンは、ネームサービスに DNS を使用するように設定する必要があります。この設定は、Kerberos の要件です。file など、ほかのネームサービスを代わりに使用すると、特定の操作が失敗することもあります。
Directory Server を実行するマシンには、directory.example.com という完全修飾ドメイン名を付けます。このマシンも、ネームサービスに DNS を使用するように設定する必要があります。
Directory Server マシンは、Kerberos によって Directory Server に対する認証を行うためのクライアントシステムとしての役割を果たします。この認証は、Directory Server と Kerberos デーモンの両方と通信できる任意のシステムから実行できます。しかし、この例で必要なコンポーネントはすべて、Directory Server によって提供され、認証はこのシステムから実行されます。
Directory Server のユーザーには、uid= username,ou=People,dc=example,dc=com という形式の DN があります。対応する Kerberos 主体は、username@EXAMPLE.COM です。別のネーミングスキームを使用する場合は、別の GSSAPI アイデンティティーマッピングを使用する必要があります。
/etc/krb5/krb5.conf 設定ファイルは、KDC と通信するために Kerberos クライアントが必要とする情報を提供しています。
Kerberos を使用して Directory Server に対する認証を行う KDC マシン、Directory Server マシン、および任意のクライアントマシン上の /etc/krb5/krb5.conf 設定ファイルを編集します。
"___default_realm___" をすべて "EXAMPLE.COM" に置き換えます。
"___master_kdc___" をすべて "kdc.example.com" に置き換えます。
"___slave_kdcs___" の含まれる行を削除して、Kerberos サーバーが 1 つしか存在しないようにします。
"___domain_mapping___" を ".example.com = EXAMPLE.COM" に置き換えます (.example.com の最初のピリオドに注意)。
更新された /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 } |
/etc/krb5/kadm5.acl 設定ファイル内で、"___default_realm___" を "EXAMPLE.COM" に置き換えます。更新されたファイルは、次の例のようになります。
# # Copyright (c) 1998-2000 by Sun Microsystems, Inc. # All rights reserved. # # pragma ident "@(#)kadm5.acl 1.1 01/03/19 SMI" */admin@EXAMPLE.COM * |
/etc/krb5/kdc.conf ファイルで、"___default_realm___" を "EXAMPLE.COM" に置き換えます。更新されたファイルは、次の例のようになります。
# 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 } |
$ /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 $ |
次のコマンドを使用して、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 および管理のデーモンを開始します。
$ /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 の 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 $ |
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 $ |
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 6.0 と最新のパッチをインストールします。設定例は次のとおりです。
変数のタイプ |
値の例 |
---|---|
完全修飾コンピュータ名 |
directory.example.com |
インストールディレクトリ |
/opt/SUNWdsee |
インスタンスのパス |
/local/ds |
サーバーユーザー |
unixuser |
サーバーグループ |
unixgroup |
サーバーポート |
389 |
サフィックス |
dc=example,dc=com |
最初に、ファイル /data/ds/shared/bin/gssapi.ldif を作成して、主体に基づいて認証を行う Kerberos ユーザーを識別するために Directory Server によって使用されるマッピングを定義します。次の例と同じ内容のファイルを作成します。
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 $ |
これまでに説明したように、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 |
Kerberos ユーザーを Directory Server に対して認証するには、そのユーザーの Kerberos 主体に対応する、ユーザーのディレクトリエントリが必要です。
これまでの手順で、kerberos-test@EXAMPLE.COM という主体を持つテストユーザーが Kerberos データベースに追加されました。ディレクトリに追加されたアイデンティティーマッピング設定のために、そのユーザーに対応するディレクトリエントリには、uid=kerberos-test,ou=People,dc=example,dc=com という DN が必要です。
ユーザーをディレクトリに追加する前に、次の内容でファイル 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 $ |
テストユーザーは、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 に対する認証です。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 プラグインを変更しなければならない場合は、次の手順に従う必要があります。
enabled プロパティーは on のままにします。
argument プロパティーにほかの値を追加できますが、引数内で DSCC URL を維持します。
PTA プラグインが無効になったり、DSCC URL が引数から削除されると、サーバーインスタンスが DSCC 内に inaccessible として表示されます。この場合、DSCC が PTA プラグインをリセットするオプションを自動的に提供します。