| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
Directory Serverは、ネットワークを介してセキュリティが確保された、信頼できる通信を行ういくつかのメカニズムをサポートしています。LDAPSは、SSL(Secure Socket Layer)上で実行される標準のLDAPプロトコルです。LDAPSはデータを暗号化し、オプションとして証明書を使用して認証を行います。この章でSSLという用語を使用する場合、サポートされているプロトコルSSL2、SSL3およびTLS 1.0を指します。
Directory ServerはStart TLS(Start Transport Layer Security)拡張処理もサポートしているため、元は暗号化されていないLDAP接続でもTLSを有効にできます。
さらには、SASL(Simple Authentication and Security Layer)を介したGSSAPI(Generic Security Service API)にも対応しています。GSSAPIにより、SolarisおよびLinuxオペレーティング・システムでKerberos Version 5セキュリティ・プロトコルを利用できます。アイデンティティ・マッピング・メカニズムによって、Kerberos主体とディレクトリ内のアイデンティティが関連付けられます。
セキュリティ情報の詳細は、http://www.mozilla.org/projects/security/pki/nss/のNSSのWebサイトを参照してください。
この章では、SSLによってセキュリティを構成する手順について説明します。ACIについては、第6章「Directory Serverのアクセス制御」を参照してください。ユーザー・アクセスとパスワードについては、第8章「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についての説明およびdsconfについての説明のマニュアル・ページを参照してください。
この節では、Directory Serverでの証明書の構成に関する次の情報について説明します。
Directory Serverインスタンスを初めて作成した場合、これには、デフォルトの自己署名付き証明書が含まれています。自己署名付き証明書は、公開鍵と秘密鍵のペアで、公開鍵が秘密鍵によって署名されています。自己署名付き証明書は、24か月間有効です。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
デフォルトの自己署名付き証明書を表示するには、次のコマンドを使用します。
$ dsadm show-cert instance-path defaultCert
Directory Serverインスタンスを作成すると、デフォルトの自己署名付き証明書が自動的に用意されます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
デフォルト設定以外の自己署名付き証明書を作成するには、次のコマンドを使用します。
$ dsadm add-selfsign-cert instance-path cert-alias
ここで、cert-aliasは、証明書を特定するために付ける名前です。
このコマンドのオプションをすべて確認するには、dsadmについての説明のマニュアル・ページまたはコマンドラインのヘルプを参照してください。
$ dsadm add-selfsign-cert --help
自己署名付き証明書の期限が切れた場合は、サーバー・インスタンスを停止して、証明書を更新します。
$ dsadm stop instance-path $ dsadm renew-selfsign-cert instance-path cert-alias
サーバー・インスタンスを再起動します。
$ dsadm start instance-path
この手順は、Directory Serverで使用するCA署名付きサーバー証明書をリクエストし、インストールする方法を説明しています。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
CA署名付きサーバー証明書リクエストを生成します。
$ dsadm request-cert [-i] [-W cert-pwd-file] {-S DN | --name name [--org org] \ [--org-unit org-unit] [--city city] [--state state] [--country country]} \ [--phone PHONE] [--email EMAIL] [--dns DOMAIN] [--keysize KEYSIZE] \ [--sigalg SIGALG] [-F format] [-o output-file] instance-path
たとえば、Example社のCA署名付きサーバー証明書をリクエストするには、次のコマンドを使用します。
$ dsadm request-cert --name host1 --org Example --org-unit Marketing \ -o my_cert_request_file /local/dsInst
サーバーを完全に特定するために、認証局はこの例で示す属性すべてを必要とする場合があります。各属性の説明については、dsadmのマニュアル・ページを参照してください。
dsadm request-certを使用して証明書をリクエストすると、出力形式としてASCIIを指定しないかぎり、作成される証明書リクエストはバイナリ証明書リクエストになります。ASCIIを指定すると、作成される証明書リクエストは、PEM形式のPKCS #10証明書リクエストになります。PEM(Privacy Enhanced Mail)は、RFC 1421から1424(http://www.ietf.org/rfc/rfc1421.txt)で指定されている形式で、base64でエンコードされた証明書リクエストをUS-ASCII文字で表すために使用されます。リクエストの内容は、次の例のようになります。
-----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証明書をインストールする方法を説明しています。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
CA署名付きサーバー証明書を追加します。
$ dsadm add-cert instance-path cert-alias cert-file
ここで、cert-aliasは証明書を特定するために付ける名前です。cert-fileは、PEM形式のPKCS #11証明書を含むテキスト・ファイルです。
たとえば、CA署名付きサーバー証明書をインストールするには、次のようなコマンドを使用します。
$ dsadm add-cert /local/dsInst server-cert /local/safeplace/serv-cert-file
これで、証明書がインストールされますが、まだ信頼されていません。CA署名付きサーバー証明書を信頼するには、認証局証明書をインストールする必要があります。
信頼できる認証局証明書を追加します。
$ dsadm add-cert --ca instance-path cert-alias cert-file
--caオプションは、証明書が信頼できる認証局証明書であることを示します。
たとえば、認証局からの信頼できる証明書をインストールするには、次のようなコマンドを使用します。
$ dsadm add-cert --ca /local/dsInst 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 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署名付きサーバー証明書(公開鍵と秘密鍵)の有効期限が切れた場合は、次の手順に従って更新します。
Webインタフェースの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"のようなワイルドカードを含む証明書で使用できます。
Webインタフェースの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
たとえば、サーバー・インスタンスに証明書をインポートするには、次のように入力します。
$ dsadm import-cert /local/ds2 /tmp/first-ca-server-certificate Enter the PKCS#12 file password:
サーバーに証明書をインポートしたら、インポートした証明書を使用するようサーバーを構成します。
$ 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にあります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
サーバーを停止します。
$ dsadm stop instance-path
パスワード・プロンプト・フラグをonに設定します。
$ dsadm set-flags instance-path cert-pwd-prompt=on
新しい証明書のパスワードを選択するよう求められます。
サーバーを起動します。
$ dsadm start instance-path
Directory Serverのインスタンスをバックアップする場合、Directory Serverの構成と証明書をバックアップします。バックアップされた証明書はarchive-path/aliasディレクトリに格納されます。
Directory Serverのバックアップとリストアの方法については、「障害時リカバリ用のバックアップを作成するには:」を参照してください。
この項では、暗号化方式を選択する手順について説明します。
サーバー・インスタンスが作成されると、デフォルトでLDAPクリア・ポートとセキュアLDAPポート(LDAPS)が作成されます。しかし、サーバーがSSLを介してのみ通信するようにSSL以外の通信を無効にする場合もあります。
SSL接続は、デフォルトの自己署名付き証明書で有効になります。希望する場合は、自分の証明書をインストールできます。サーバーの起動後の証明書の管理と、SSLの無効化の手順については、第5章「Directory Serverのセキュリティ」を参照してください。証明書、証明書データベース、CA署名付きサーバー証明書の入手の概要については、Oracle Directory Server Enterprise Editionのリファレンスを参照してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
LDAPクリア・ポートを無効にします。
セキュアでないポートを無効にするには、LDAPセキュア・ポートにバインドする必要があります。この例は、ホスト・サーバーhost1上のデフォルトのLDAPセキュア・ポート1636へのバインドを示しています。
$ dsconf set-server-prop -h host1 -P 1636 ldap-port:disabled
変更内容が反映されるようにサーバーを再起動します。
$ dsadm restart /local/dsInst
これで、セキュアでないポート1389にバインドできなくなります。
暗号化方式は、データを暗号化、復号化するために使用するアルゴリズムです。一般に、暗号化に使用するビット数が多いほど、強度と安全性は高まります。SSLの暗号化方式は、使用するメッセージ認証のタイプによっても識別されます。メッセージ認証は、データの整合性を保証するchecksumを計算する別のアルゴリズムです。
クライアントがサーバーとのSSL通信を開始するときは、情報の暗号化に使用する暗号について、クライアントとサーバーが合意する必要があります。双方向の暗号化プロセスでは、送信側と受信側の両方が同じ暗号化方式を使用する必要があります。使用する暗号化方式は、サーバーが保存している暗号化方式のリストの現在の順序によって決まります。サーバーは、そのリスト内でクライアントに提示された暗号化方式に一致する最初の暗号化方式を選択します。Directory Serverのデフォルトの暗号化方式値はallです。これは、背後のSSLライブラリにサポートされている既知のセキュアなすべての暗号化方式を意味します。ただし、この値は特定の暗号化方式のみを受け入れるように変更できます。
Directory Serverで使用できる暗号化方式の詳細は、Oracle Directory Server Enterprise Editionのリファレンスを参照してください。
Webインタフェースの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/dsInst
クライアントに適用されるセキュリティ・モデルは、資格レベルと認証方式の組合せで定義されます。
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およびdsSaslMaxSSFは、暗号化鍵の長さを示し、これらは、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の両方の値を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メカニズムは、クライアントによって送信されたハッシュされた値をユーザーのパスワードのハッシュと比較することによって、クライアントを認証します。ただし、このメカニズムはユーザー・パスワードを読み取る必要があり、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
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は、次となります。
install-path/lib/private/
DIGEST-MD5のデフォルトのアイデンティティ・マッピングを使用するか新規作成します。
詳細は、「DIGEST-MD5アイデンティティ・マッピング」を参照してください。
DIGEST-MD5を使用するSSL経由でサーバーにアクセスするすべてのユーザーのパスワードが{CLEAR}で格納されていることを確認します。
パスワード保存スキーマについては、第8章「Directory Serverのパスワード・ポリシー」を参照してください。
SASL構成エントリまたはDIGEST-MD5アイデンティティ・マッピング・エントリの1つを変更した場合は、Directory Serverを再起動します。
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が含まれていることを前提としています。
このタスクの実行には、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およびLinuxオペレーティング・システムで使用できます。Sun Enterprise Authentication Mechanism(SEAM)サーバーにKerberos V5実装をインストールすることをお薦めします。
サーバーは、GSSAPIを使用してユーザーのアイデンティティを検証します。次に、SASLメカニズムはGSSAPIマッピング・ルールを適用して、この接続中のすべての操作のバインドDNとなるDNを取得します。
製造元の指示に従って、Kerberosソフトウェアを構成します。Sun Enterprise Authentication Mechanism 1.0.1サーバーを使用している場合、次の手順を使用します。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
開始する前に
Solaris上では、デフォルトでKerberos 5パッケージがインストールされます。
Linux上では、次のKerberos 5パッケージがインストールされていることを確認してください。
krb-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を使用するようDirectory Serverを構成する方法を説明しています。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
「GSSAPIアイデンティティ・マッピング」での説明に従って、GSSAPIのデフォルト・アイデンティティ・マッピングと任意のカスタム・マッピングを作成します。
サービス・キーを保存するために鍵タブを作成します。
LDAPサービス・キーは、鍵タブに保存されます。
鍵タブは必ずDirectory Serverユーザーのみが読み取れるようにします。
鍵タブを保存するための専用ファイルを作成します。例:/var/dsee7/ds7.keytab
ファイル名をデフォルトの鍵タブファイル名から変更します。
デフォルトの鍵タブではなく、必ず新しい鍵タブが使用されるように、環境変数KRB5_KTNAMEを設定します。
SASL構成エントリまたはGSSAPIアイデンティティ・マッピング・エントリの1つを変更した場合は、Directory Serverを再起動します。
DNSは、ホスト・マシンに構成されている必要があります。
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マッピングは定義されていません。デフォルトのマッピングを定義し、使用する主体をクライアントがどのように定義するかに応じてカスタム・マッピングを定義する必要があります。
このタスクの実行には、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を再起動して、新しいマッピングを有効にします。
次に、Directory Serverとセキュアな接続を確立するLDAPクライアント内でSSLを構成および使用する方法を説明します。SSL接続では、サーバーがクライアントに証明書を送信します。クライアントは、最初に証明書を信頼することで、サーバーが信頼できるものであることを確認します。次に、必要に応じてクライアントは独自の証明書またはSASLメカニズム(2つのうち1つ)の情報を送信することで、いずれかのクライアント認証メカニズムを開始できます。SASLメカニズムは、Kerberos V5を使用したDIGEST-MD5およびGSSAPIです。
次の各項では、SSLが有効なLDAPクライアントの例として、ldapsearchツールを使用します。
他のLDAPクライアントにSSL接続を構成する方法については、アプリケーションに付属するマニュアルを参照してください。
|
注意: クライアント・アプリケーションによっては、SSLを実装しても、信頼できる証明書がサーバーにあるかどうかを検証しません。これらのクライアント・アプリケーションはSSLプロトコルを使用してデータの暗号化を行いますが、機密の保護を保証することも第三者がユーザーとして認証されることを防止することもできません。 |
次の項では、セキュリティを使用するために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
このパスは、LDAPツールが起動されたホストと同じホストにDirectory Serverがインストールされていることを前提としています。
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オプションを指定しています。realmは省略できますが、指定する場合は、サーバー・ホスト・マシンの完全修飾ドメイン名を指定する必要があります。プロキシ操作を対象とする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
このパスは、LDAPツールが起動されたホストと同じホストにDirectory Serverがインストールされていることを前提としています。
次に示す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の構成と使用の詳細は、システム管理ガイド: セキュリティ・サービスを参照してください。このマニュアルはSolarisマニュアル・セットの一部です。マニュアル・ページを参照することもできます。
この例についての情報と使用する手順は、次のとおりです。
この手順例では、1台目のマシンをKDC(Key Distribution Center)として操作し、2台目のマシンではDirectory Serverを実行できるように構成する処理について説明します。この手順の結果として、ユーザーはGSSAPIによってKerberos認証を実行できるようになります。
同じマシン上でKDCとDirectory Serverの両方を実行することもできます。両方を同じマシン上で実行することを選択した場合にも同じ手順を使用できます。この場合、KDCマシンとDirectory Serverマシンで重複する手順は、一度行うのみですみます。
この手順では、使用される環境に関する多くの前提条件が発生します。手順例を使用する場合は、環境に合わせて値を変更してください。前提は次のとおりです。
このシステムには、推奨される最新のパッチ・クラスタのインストールされた最新のSolaris 9ソフトウェアがインストールされている。適切なSolarisパッチがインストールされていない場合、Directory Serverに対するKerberos認証は失敗する可能性があります。
マニュアルに記述された手順はSolaris 10およびLinuxとほとんど同じですが、いくつかの違いがあります。構成ファイルの形式が多少異なり、コマンドおよび構成ファイルのパスは異なり、いくつかのコマンドの出力が同じでない場合もあります。
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アイデンティティ・マッピングを使用する必要があります。
Kerberosクライアント構成ファイルは、KDCと通信するためにKerberosクライアントが必要とする情報を提供しています。
/etc/krb5/krb5.conf
/etc/krb5.conf
Kerberosを使用してDirectory Serverに対する認証を行うKDCマシン、Directory Serverマシンおよび任意のクライアント・マシン上のKerberos構成ファイルを編集します。
"___default_realm___"をすべて"EXAMPLE.COM"に置き換えます。
"___master_kdc___"をすべて"kdc.example.com"に置き換えます。
"___slave_kdcs___"の含まれる行を削除して、Kerberosサーバーが1つしか存在しないようにします。
"___domain_mapping___"を".example.com = EXAMPLE.COM"に置き換えます(.example.comの最初のピリオドに注意)。
Solaris上で更新されたKerverosクライアント構成ファイルは、次の例の内容のようになります。
例5-1 編集後のSolaris上の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
}
/etc/krb5/kadm5.acl構成ファイル内で"___default_realm___"を"EXAMPLE.COM"に置き換えます。更新されたファイルは、次の例のようになります。
/etc/krb5/kdc.confファイルを編集して、"___default_realm___"を"EXAMPLE.COM"に置き換えます。更新されたファイルは、次の例のようになります。
例5-3 編集後のSolaris上の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
}
$ 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:passwordRe-enter KDC database master key to verify:password$
次のコマンドを使用して、kws/admin@EXAMPLE.COMという主体の管理ユーザーと、管理デーモンによって使用されるサービス鍵を作成します。
$ 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ユーティリティによって使用されます。
$ 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主体を作成するには、次の一連のコマンドを使用します。
$ 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になります。
この例の一連のコマンドを使用してユーザーを作成します。
$ 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 $
Oracle Directory Server Enterprise Edition 11g R1 (11.1.1.6)と最新のパッチをインストールします。設定例は次のとおりです。
| 変数タイプ | 値の例 |
|---|---|
|
完全修飾コンピュータ名 |
|
|
インストール・ディレクトリ |
|
|
インスタンスのパス |
|
|
サーバーのユーザー |
|
|
サーバー・グループ |
|
|
サーバー・ポート |
|
|
接尾辞 |
|
最初に、ファイル/data/ds/shared/bin/gssapi.ldifを作成して、主体に基づいて認証を行うKerberosユーザーを識別するためにDirectory Serverによって使用されるマッピングを定義します。次の例と同じ内容のファイルを作成します。
例5-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: SASL-library
ここでSASL-libraryは、次となります。
install-path/lib/private/
次に、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が動作するユーザー・アカウントが参照できるファイル内にある必要があります。
正しいプロパティを持つ鍵タブ・ファイルを作成するには、次の一連のコマンドを使用します。
$ kadmin -p kws/admin Enter Password: secret kadmin: ktadd -k /local/dsInst/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/dsInst/config/ldap.keytab. kadmin: quit $
このカスタム鍵タブのアクセス権と所有権を変更します。鍵タブをDirectory Serverを実行するために使用されるユーザー・アカウントの所有にし、そのユーザーしか参照できないようにします。
$ chown unixuser:unixgroup /local/dsInst/config /ldap.keytab $ chmod 600 /local/dsInst/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/dsInst
KerberosユーザーをDirectory Serverに対して認証するには、そのユーザーのKerberos主体に対応する、ユーザーのディレクトリ・エントリが必要です。
これまでの手順で、kerberos-test@EXAMPLE.COMという主体を持つテスト・ユーザーがKerberosデータベースに追加されました。ディレクトリに追加されたアイデンティティ・マッピング構成のために、そのユーザーに対応するディレクトリ・エントリには、uid=kerberos-test,ou=People,dc=example,dc=comというDNが必要です。
ユーザーをディレクトリに追加する前に、次の内容でファイルtestuser.ldifを作成する必要があります。
例5-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
$
テスト・ユーザーは、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/dsInst/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" argument : ldap://dscc_host:3998/cn=dscc depends-on-named : depends-on-type : desc : pass through authentication plugin enabled : on feature : passthruauth init-func : passthruauth_init lib-path : install-path/lib/passthru-plugin.so type : preoperation vendor : Sun Microsystems, Inc. version : 7.0
|
注意: サーバーがDSCCに登録されており、PTAを使用する必要がある場合、PTAプラグインを変更する際に次の設定を保存する必要があります。 |
enabledプロパティはonのままにします。
DSCC URLは引数で保持しますが、他の値はargumentプロパティに追加できます。
PTAプラグインが無効な場合、またはDSCC URLが引数から削除されている場合、サーバー・インスタンスはDSCCでinaccessibleと示されます。その場合、DSCCではPTAプラグインをリセットするオプションが自動的に与えられます。
また、DSCCでDirectory Serverインスタンスを登録解除してから登録しなおすことで、この問題を解決できることもあります。この操作を実行するには、DSCCを使用するか、dsccreg remove-serverコマンドおよびdsccreg add-serverコマンドを使用します。dsccregコマンドの詳細は、dsccregを参照してください。
PTAプラグインの構成情報は、PTAサーバー上のcn=Pass Through Authentication,cn=plugins,cn=configエントリに指定されます。
PTAプラグインはシステム・プラグインであり、デフォルトでは無効です。これを有効にして設定するには、dsconfコマンドを使用するかDSCCを使用します。
次のdsconfコマンドを実行します。
$ dsconf enable-plugin -h PTAhost -p port "Pass Through Authentication" $ dsconf set-plugin-prop -h PTAhost -p port "Pass Through Authentication" \ argument:"ldap[s]://authenticatingHost[:port]/PTAsubtree options"
プラグインの引数は、認証ディレクトリ・サーバーのホスト名、オプション・ポートおよびPTAサブツリーを特定するLDAP URLを指定します。ポートを指定しない場合のデフォルト・ポートは、LDAPが389、LDAPSが636です。また、後述するオプションの接続パラメータを設定することもできます。PTAhostにPTAsubtreeが存在する場合、プラグインはバインド・リクエストをauthenticatingHostに渡さず、バインドはパススルーなしでローカルに処理されます。
「Directory Serverインスタンスの起動、停止および再起動」で説明している手順を実行してサーバーを再起動します。
PTAプラグインは、パスワードを含むバインド資格証明情報を認証ディレクトリに送信する必要があるため、セキュアな接続を使用することをお薦めします。PTAディレクトリがSSLを経由して認証ディレクトリと通信するように構成するには:
第5章「Directory Serverのセキュリティ」で説明している方法で、PTAディレクトリと認証ディレクトリの両方でSSLを構成し、有効にします。
PTAプラグインの構成を、たとえば次のように作成または変更し、LDAP URL中のLDAPSとセキュアなポートを使用できるようにします。
ldaps://host:secure-port/subtree
PTAプラグインの引数には、LDAP URLの後にオプションの接続パラメータのセットを指定できます。
http[s]://host:port/subtree [maxconns,maxops,timeout,ldapver,connlife]
パラメータは、前述の順序で指定する必要があります。これらのパラメータはオプションですが、いずれか1つを指定するときは、すべてを指定する必要があります。すべてのパラメータをカスタマイズする必要がない場合は、次のデフォルト値を指定します。subtreeパラメータとオプションパラメータの間には、必ず空白文字を挿入してください。
各LDAP URLプラグインに対して、次のオプション・パラメータを構成できます。
maxconns - PTAサーバーが認証サーバーに対して同時に開ける接続の最大数。このパラメータは、認証サーバーにパススルーできる同時バインドの最大数を制限します。デフォルト値は3です。
maxops - 単一の接続中に、PTAディレクトリ・サーバーが認証ディレクトリ・サーバーに同時に送信できるバインド・リクエストの最大数。このパラメータは、同時パススルー認証の数をさらに制限します。デフォルト値は5です。
timeout - PTAサーバーが認証サーバーからのレスポンスを待つ最大遅延時間(秒単位)。デフォルト値は300秒(5分)です。
ldapver - PTAサーバーが認証サーバーへの接続に使用するLDAPプロトコルのバージョン。LDAPv2の場合は2、LDAPv3の場合は3を指定します。デフォルト値は3です。
connlife - PTAサーバーが認証サーバーとの接続を再利用できる制限時間(秒単位)。この制限時間が過ぎてからクライアントがPTAサブツリー内のバインドをリクエストした場合は、サーバーはPTA接続を閉じてから新しいPTA接続を開きます。バインド・リクエストが開始され、サーバーによってタイムアウトが超過していると判断されないかぎり、サーバーは接続を切断しません。このオプションを指定しない場合、またはLDAP URLに指定されている認証サーバーが1つのみの場合、制限時間は適用されません。複数のホストが指定されている場合、デフォルトは300秒(5分)になります。
|
注意:
dsconf set-plugin-prop -h PTAhost -p port "Pass Through Authentication"\ argument:"ldaps://eastbak.example.com/ou=East,ou=People,dc=example,dc=com\ 3,5,300,3,300" |
PTAプラグインを複数の引数で構成することで、複数の認証サーバー、複数のPTAサブツリー、またはその両方を指定できます。各引数には1つのLDAP URLが含まれ、それぞれに接続オプションのセットを設定できます。
同じPTAサブツリーに対して複数の認証サーバーが存在するときは、認証サーバーはフェイルオーバー・サーバーとして機能します。PTA接続のタイムアウト制限に達すると、プラグインはリストに指定されている順序でサーバーに接続します。すべての接続がタイムアウトになった場合は認証が失敗します。
複数のPTAサブツリーが定義されている場合、プラグインはバインドDNに基づいて、対応するサーバーに認証リクエストをパススルーします。次の例は、2つのPTAサブツリーを定義する4つのPTAプラグイン引数を示しています。それぞれのサブツリーには、認証のためのフェイルオーバー・サーバーと、サーバー固有の接続パラメータが指定されています。
$ dsconf set-plugin-prop -h PTAhost -p port "Pass Through Authentication"\ argument:"ldaps://configdir.example.com/o=example.com\ 10,10,60,3,300" $ dsconf set-plugin-prop -h PTAhost -p port "Pass Through Authentication"\ argument+:"ldaps://configbak.example.com/o=example.com\ 10,10,60,3,300" $ dsconf set-plugin-prop -h PTAhost -p port "Pass Through Authentication"\ argument+:"ldaps://east.example.com/ou=East,ou=People,dc=example,dc=com\ 10,10,60,3,300" $ dsconf set-plugin-prop -h PTAhost -p port "Pass Through Authentication"\ argument+:"ldaps://eastbak.example.com/ou=East,ou=People,dc=example,dc=com\ 10,10,60,3,300"
