test

LDAP の設定と構成

第 2 章 サーバーの設定

この章では、Solaris LDAP クライアントが名前情報を検索できるように、LDAP サーバーを設定する方法について説明します。この設定によって、Solaris LDAP クライアントは、getXbyY インタフェースまたは ldaplist(1) を使用して、LDAP サーバー上の名前情報を検索できるようになります。

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

前提条件

Solaris ネームサービスクライアントは LDAP v3 プロトコルだけで利用されている制御を使用するため、Solaris ネームサービスクライアントで名前情報の検索を行うには、サーバーが LDAP v3 プロトコルに対応している必要があります。

以下の制御は v3 だけで使用できます。

サーバーは次のいずれかの認証方式をサポートしていなければなりません。

ディレクトリが単純ページモード制御をサポートしていることを確認する

  1. ldapsearch コマンドを使用して、ディレクトリがページモード制御タイプ 1.2.840.113556.1.4.319、ページモード制御値 2.16.840.1.113730.3.4.2 の OID によって特定される単純ページモード制御をサポートしているかどうかを調べます。


    # ldapsearch -b "" -s base objectclass=\*

    たとえば、ldapsearch コマンドは次のような結果を返します。


    objectclass=top
namingcontexts=dc=sun,dc=com,o=internet
subschemasubentry=cn=schema
supportedsaslmechanisms=CRAM-MD5
supportedextension=1.3.6.1.4.1.1466.20037
supportedcontrol=1.2.840.113556.1.4.319
supportedcontrol=2.16.840.1.113730.3.4.2
supportedldapversion=2
supportedldapversion=3
ディレクトリが仮想リスト表示をサポートしていることを確認する

  1. ldapsearch コマンドを使用して、ディレクトリが VLV 制御タイプ 1.2.840.113556.1.4.473、VLV 制御値 2.16.840.1.113730.3.4.9 の OID によって特定される仮想リスト表示制御をサポートしているかどうかを調べます。


    # ldapsearch -b "" -s base objectclass=\*

    たとえば、ldapsearch コマンドは次のような結果を返します。


    objectclass=top
namingcontexts=dc=sun,dc=com
namingcontexts=o=NetscapeRoot
subschemasubentry=cn=schema
supportedcontrol=2.16.840.1.113730.3.4.2
supportedcontrol=2.16.840.1.113730.3.4.3
supportedcontrol=2.16.840.1.113730.3.4.4
supportedcontrol=2.16.840.1.113730.3.4.5
supportedcontrol=1.2.840.113556.1.4.473
supportedcontrol=2.16.840.1.113730.3.4.9
supportedcontrol=2.16.840.1.113730.3.4.12
supportedsaslmechanisms=EXTERNAL
supportedldapversion=2
supportedldapversion=3
dataversion=atitrain2.east.sun.com:389 020000605172910 
netscapemdsuffix=cn=ldap://:389,dc=atitrain2,dc=east,dc=sun,dc=com
    注 –

    ldapsearch コマンドについての詳細は、ldapsearch(1) のマニュアルページを参照してください。

スキーマ

Solaris LDAP ネームサービスクライアントをサポートするには、IETF によって定義されているスキーマといくつかの Solaris 固有のスキーマが必要です。

IETF によって定義されている LDAP スキーマで必要なものは、RFC 2307 の NIS スキーマと LDAP メールグループインターネットドラフトによるものの 2 つです。ネーム情報サービスをサポートするには、これらのスキーマ定義をディレクトリサーバーに追加する必要があります。IETF のスキーマと Solaris 固有のスキーマについての詳細は、付録 A 「スキーマ」 を参照してください。各種の RFC は、IETF のページ (http://www.ietf.org) にあります。

ディレクトリ情報ツリー

Solaris LDAP クライアントは、デフォルトの ディレクトリ情報ツリー (DIT : Directory Information Tree) 内の情報を使用します。変更された DIT をプロファイルに指定すると、この DIT がデフォルトの DIT よりも優先されます。DIT は、特定の情報タイプのエントリを含むサブツリーであるコンテナに分割されます。

検索の起点となる識別名 (baseDN) には、そのクライアントのすべての情報が格納されている DIT 内の場所を指定します。検索の起点として指定されたノードには、NisDomainObject オブジェクトクラスが存在しなければなりません。検索の起点ノードのサブツリーには、各タイプの情報のすべてのコンテナを指定します。図 2–1 を見てください。

図 2–1 ディレクトリ情報ツリー (DIT) コンテナ

Graphic

表 2–1 に、この DIT に格納されているコンテナと情報タイプを示します。

表 2–1 ディレクトリ情報ツリー (DIT)
 コンテナ 情報タイプ
 ou=Ethers bootparams(4), ethers(4)
 ou=Group group(4)
 ou=Hosts hosts(4), ipnodes(4), publickey(4)
 ou=Aliases aliases(4)
 ou=Netgroup netgroup(4)
 ou=Networks networks(4), netmasks(4)
 ou=People passwd(1), shadow(4), user_attr(4), audit_user(4), ユーザーの公開鍵
 ou=Protocols protocols(4)
 ou=Rpc rpc(4)
 ou=Services services(4)
 ou=SolarisAuthAttr auth_attr(4)
 ou=SolarisProfAttr prof_attr(4), exec_attr(4)
 ou=projects project(4)
 nismapname=auto_* auto_*

DIT 内のデフォルトコンテナを無効にする

LDAP を使用する際にデフォルトのコンテナを無効にする必要がある場合は、プロファイル内に変更されたコンテナを指定します。その際、データベースごとに代替の検索起点識別名 (baseDN) を定義できます。

たとえば、ある組織で ou=People コンテナを、ou=employee および ou=contractor コンテナに置き換えたいとします。このプロファイルエントリ (DIT 内の任意の場所に指定可能) では、代替検索識別名 (DN) を指定する必要があります。代替検索 DN を指定するには、-B オプションを使用して LDAP クライアントプロファイルを作成します。詳細は、ldap_gen_profile(1M) のマニュアルページを参照してください。属性は次のようになります。


SolarisDataSearchDN="passwd:(ou=employee,dc=mkt,dc=mystore,dc=com),
                     (ou=contractor,dc=mkt,dc=mystore,dc=com)"

NIS ドメイン

Solaris クライアントが特定ドメインのサーバーを見つけるには、nisDomainObject オブジェクトクラスの nisDomain 属性が、目的のドメインを表す DIT のルート DN エントリに定義されている必要があります。クライアントはこの情報を使用して、システムを初期化し、クライアントプロファイルを更新します。初期化時に、クライアントは目的のドメインに一致する nisDomain 属性値を持つ LDAP サーバー上のエントリを検索します。そして、そのエントリの DN を、名前情報の起点識別名 (BaseDN) として使用します。

クライアントプロファイルを更新するとき、クライアントマシン上の ldap_cachemgr は、ルート DN エントリに定義された nisDomain が目的のドメインと一致することを確認します。

このマニュアルでは、例として次の nisDomain を使用することにします。


dn: dc=mkt,dc=mainstore,dc=com
dc: mkt
objectclass: top
objectclass: domain
objectclass: nisDomainObject
nisdomain: mkt.mainstore.com

クライアントプロファイル

Solaris クライアントの設定を簡略化するには、クライアントプロファイルを定義する必要があります。このプロファイルはサーバー上に作成する必要があります。クライアントは初期化時にプロファイル名とサーバーのアドレスを指定するだけで、簡単にシステムを設定できます。クライアントプロファイルによって、システム管理者は、Solaris クライアントが使用する LDAP 環境を定義できます。

プロファイルを使用することによる顕著な効果は、マシンのインストール作業が容易になることです。しかし、プロファイルの本当の利点がわかるのは、自分の環境に変更 (たとえばサーバーの追加や削除) を加え始めたときです。詳細は、ldap_gen_profile(1M) のマニュアルページを参照してください。

次に、クライアントプロファイルに定義できる属性をまとめておきます。

クライアントプロファイルを作成するための ldap_gen_profile(1M) コマンドは、Solaris クライアントツールの一部として提供されています。このツールは LDIF ファイルを生成します。生成された LDIF ファイルを LDAP サーバーに格納するには、ldapadd(1) コマンドを使用します。次に、クライアントプロファイルの作成方法を示します。

クライアントプロファイルを作成する

  1. ldap_gen_profile(1M) を使用してクライアントプロファイルを作成します。


    # /usr/sbin/ldap_gen_profile \
-P myprofile \
-b dc=mkt,dc=mainstore,dc=com \
-a simple -w mypasswd \
-D cn=proxyagent,ou=profile,dc=mkt,dc=mainstore,dc=com \
100.100.100.100

    作成されたプロファイルの例を次に示します。


    dn: cn=myprofile,ou=profile,dc=mkt,dc=mainstore,dc=com
SolarisBindDN: cn=proxyagent,ou=profile,dc=mkt,dc=mainstore,dc=com
SolarisBindPassword: {NS1}xxxxxxxxxxxxxx
SolarisLDAPServers: 100.100.100.100
SolarisSearchBaseDN: dc=mkt,dc=mainstore,dc=com
SolarisAuthMethod: NS_LDAP_AUTH_SIMPLE
SolarisTransportSecurity: NS_LDAP_SEC_NONE
SolarisSearchReferral: NS_LDAP_FOLLOWREF
SolarisSearchScope: NS_LDAP_SCOPE_ONELEVEL
SolarisSearchTimeLimit: 30
SolarisCacheTTL: 43200
cn: myprofile
ObjectClass: top
ObjectClass: SolarisNamingProfile

  2. 作成されたプロファイルを (profile.ldif などの) ファイルに保存し、ldapadd(1) を使用して LDAP サーバーに格納します。


    # ldapadd -h ldap_server_hostname -D "cn=Directory Manager" \
-w nssecret -f profile.ldif

各クライアントマシン上の ldap_cachemgr(1M) は、LDAP 構成ファイルの内容を自動的に更新します。つまり、サーバー上のプロファイル情報を変更すると、変更内容が自動的に名前空間内のすべてのクライアントに反映されます。定期的な更新は、プロファイルの SolarisCacheTTL 属性に指定された TTL (time to live: 有効期限) の値に基づいて行われます。

セキュリティモデル

ディレクトリに格納された情報にアクセスするとき、まずクライアントはディレクトリに対して認証される必要があります。認証されると、ディレクトリにアクセス制御情報 (ACI: Access Control Information) として格納された承認情報に基づいて、ディレクトリ内の一部またはすべての情報にアクセスできるようになります。この節では、クライアントの識別情報、認証方式、PAM モジュールについて説明します。ACI についての詳細は、『iPlanet Directory Server Administrator's Guide』を参照してください。

認証の対象となる識別情報

LDAP ネームサービスは、クライアントをディレクトリに認証してもらうとき、匿名またはプロキシエージェントのいずれかの識別情報を使用するように構成できます。

認証方式

プロキシエージェントを使用する場合、システム管理者は、ディレクトリに対して認証するときの認証方式も選択する必要があります。現時点で、Solaris 8 によってサポートされている認証方式は、SIMPLE と CRAM-MD5 の 2 つです。

注 –

iPlanet Directory Server version 4.11 は、現時点では CRAM-MD5 をサポートしていません。

PAM

PAM (Pluggable Authentication Module, 接続可能な認証モジュール) を使用すれば、アプリケーションを Solaris オペレーティング環境で使用される認証方式から独立させておくことができます。PAM 層を使用すれば、アプリケーションは、システム管理者がそのクライアントにどの認証方式を定義しているかに関係なく、認証を実行できます。LDAP ネームサービスを使用するには、pam_unix(5) または pam_ldap(5) のどちらかの PAM モジュールを pam.conf に指定します。

インデックス

ほとんどの LDAP サーバーでは、インデックスを使用して検索パフォーマンスの向上を図ります。インデックスの使用法については、ディレクトリサーバーのマニュアルを参照してください。

Solaris クライアントから妥当な時間で名前情報を検索できるようにするには、基本的なインデックス付き属性に加えて、次の属性にもインデックスを付ける必要があります。


membernisnetgroup    pres,eq,sub
nisnetgrouptriple    pres,eq,sub
memberuid            pres,eq
macAddress           pres,eq
uid                  pres,eq
uidNumber            pres,eq
gidNumber            pres,eq
ipHostNumber         pres,eq
ipNetworkNumber      pres,eq
ipProtocolNumber     pres,eq
oncRpcNumber         pres,eq
ipServiceProtocol    pres,eq
ipServicePort        pres,eq
nisDomain            pres,eq
nisMapName           pres,eq
mail                 pres,eq
注 –

属性リストで使用される略語の意味は、pres が存在 (presence)、eq が等価 (equality)、sub が部分文字列 (substring) です。

さらに、サーバーで仮想リスト表示制御 (vlv) がサポートされている場合は、vlv のインデックスも作成する必要があります。ツリー内の多数のオブジェクトを含むすべてのコンテンナにインデックスを作成してください (多数であるかどうかは、ツリー内の他のオブジェクトの数との相対で判断されます)。インデックスの作成方法については、ディレクトリサーバーのマニュアルを参照してください。vlv のソート値は cn uid に設定し、vlv フィルタと範囲は次のリストのように定義します。


getpwent:      vlvFilter: (objectclass=posixAccount),     vlvScope: 1
getspent:      vlvFilter: (objectclass=posixAccount),     vlvScope: 1
getgrent:      vlvFilter: (objectclass=posixGroup),       vlvScope: 1
gethostent:    vlvFilter: (objectclass=ipHost),           vlvScope: 1
getnetent:     vlvFilter: (objectclass=ipNetwork),        vlvScope: 1
getprotoent:   vlvFilter: (objectclass=ipProtocol),       vlvScope: 1
getrpcent:     vlvFilter: (objectclass=oncRpc),           vlvScope: 1
getaliasent:   vlvFilter: (objectclass=rfc822MailGroup),  vlvScope: 1
getserviceent: vlvFilter: (objectclass=ipService),        vlvScope: 1

インデックスを作成した場合の代価

インデックスを作成すると、検索パフォーマンスが向上する反面、次のような代価も発生します。

データの読み込み

Solaris ディレクトリ拡張パッケージには、NIS から LDAP に移行するために必要なツールとマニュアルが含まれています。これらのツールは、iPlanet Advantage Software CD (Volume 1) に収録されており、iPlanet の Web サイトからも入手できます。dsimport ツールは、NIS データを ldap 形式に変換するとき使用します。このツールは、入力データ形式、環境変数などに従ってカスタマイズされたマップファイル nis.mapping を使用します。詳細は、上記の CD または iPlanet の Web サイトを参照してください。

コマンド行ツール

LDAP は、LDAP API によって実行される処理に対応するコマンド行ツールを提供しています。これらのツールでは、認証やバインド関連のパラメータなど、共通のオプションを使用できます。

ldapsearch、ldapadd、ldapmodify の各ツールは、LDAP データ交換書式 (LDIF) と呼ばれる共通の書式をサポートしています。LDIF は、ディレクトリ情報を表現するテキストベースの書式です。

LDAP データ交換書式 (LDIF)

ldapsearch ツールは、LDIF の書式で出力します。ldapadd ツールはこの書式のデータを処理します。また、ldapmodify ツールはこの LDIF を基本とした変更情報を使用します。

LDIF ファイルには、1 つ以上のエントリが含まれています。各エントリは空白行で区切られます。基本的なエントリ形式は次のとおりです。


 [id]
dn: entryDN
attrtype: attrvalue
...

attrtype: attrvalue 行は、必要なだけ繰り返すことによって、1 つのエントリのすべての属性値を指定できます。行を継続するには、次の行の先頭に 1 文字の空白または水平タブ文字を挿入します。

たとえば、5 つの属性を持つ Joe Qwerty のエントリを含む LDIF ファイルは、次のようになります (cn と objectclass は 2 つの値を持ちます)。


dn: cn=Joseph Qwerty, o=Ultra Keyboards Inc., c=US
cn: Joseph Qwerty
cn: Joe Qwerty
sn: Qwerty
mail: jqwerty@ultra.com
seeAlso: cn=Joe Qwerty, ou=Engineering Division, o=Peo
 ple, o=IEEE, c=US
objectClass: top
objectClass: person
注 –

seeAlso の値は、「ple, ...」で始まる行の先頭に 1 文字の空白を挿入することによって、2 行に分割されています。

ディレクトリを検索する

ディレクトリエントリを検索するには、ldapsearch(1) を使用します。ldapsearch は、LDAP ディレクトリサーバーへの接続を開き、そのディレクトリサーバーにバインドして、ディレクトリの検索を実行します。

  1. 米国の Ultra Keyboards 社に勤務する、IEEE のメンバーを検索します。


    % ldapsearch -L -b "o=IEEE, o=Ultra Keyboards Inc., c=US" uid=\*

検索結果は次のようになります。


dn: uid=jqwerty, o=IEEE, o=Ultra keyboards Inc., c=US
uid: jqwerty
cn: jqwerty
userpassword: {crypt}somecryptedtext
uidnumber: 12345
gidnumber: 123
gecos: Joseph Qwerty
homedirectory: /home/jqwerty
loginshell: /bin/csh
objectclass: top
objectclass: shadowAccount
objectclass: account
objectclass: posixAccount
shadowlastchange: 3455

dn: uid=bhand, o=IEEE, o=Ultra keyboards Inc., c=US
uid: bhand
cn: bhand
userpassword: {crypt}somecryptedtext
uidnumber: 12347
gidnumber: 123
gecos: William Handset
homedirectory: /home/bhand
loginshell: /bin/csh
objectclass: top
objectclass: shadowAccount
objectclass: account
objectclass: posixAccount
shadowlastchange: 3440

ディレクトリエントリを変更する

ディレクトリエントリを変更するには、ldapmodify(1) を使用します。ldapmodify は、LDAP ディレクトリサーバーとの接続を開き、そのディレクトリサーバーにバインドして、ディレクトリに対して一連の LDAP 変更処理を実行します。

  1. ディレクトリマネージャ (パスワード enigma) としてバインドし、メールアドレス eng@ultra.com を Joe Qwerty のエントリに追加します。


    % ldapmodify -D "cn=Manager, o=Ultra Keyboards Inc., \
c=US" -w enigma < modfile

modfile の内容は次のとおりです。


dn: cn=carol,ou=People,o=Ultra Keyboards Inc.,c=US
changetype: modify
replace: userpassword
userpassword: {crypt}mgq25KV6CE0p6
-
replace: objectclass
objectclass: top
objectclass: shadowAccount
objectclass: account
objectclass: posixAccount
-
add: shadowlastchange
shadowlastchange: 6447
-

dn: cn=stephen,ou=People,o=Ultra Keyboards Inc.,c=US
changetype: modify
replace: userpassword
userpassword: {crypt}w.4P1JPV3w.Zs
-
replace: objectclass
objectclass: top
objectclass: shadowAccount
objectclass: account
objectclass: posixAccount
-
add: shadowlastchange
shadowlastchange: 6447
-

dn: cn=frank,ou=People,o=Ultra Keyboards Inc.,c=US
changetype: modify
replace: userpassword
userpassword: {crypt}mMBEaHRlf5rJQ
-
replace: objectclass
objectclass: top
objectclass: shadowAccount
objectclass: account
objectclass: posixAccount
-
add: shadowlastchange
shadowlastchange: 9712
-
注 –

ハイフンだけの行は、同一ディレクトリエントリに対する一連の変更コマンドを区切ります。空白行は、異なるディレクトリエントリを区切ります。

正常に終了すると、ldapmodify は次のようなメッセージを表示します。


# ldapmodify -D "cn=Directory Manager" -w nssecret -f domain.ldif
modifying entry dc=sun,dc=com

処理が正常に終了しなかった場合は、エラーメッセージが表示されます。

ディレクトリにエントリを追加する

ディレクトリにエントリを追加するには、ldapadd(1) を使用します。ldapadd は、LDAP ディレクトリサーバーへの接続を開き、そのディレクトリサーバーにバインドして、ディレクトリに対して一連の LDAP 追加処理を実行します。

  1. ディレクトリマネージャ (パスワード enigma) としてバインドし、Penny Gold と Amy Lamb のエントリを追加します。


    % ldapadd -D "cn=Manager, o=Ultra Keyboards Inc., \
c=US" -w enigma < addfile

addfile の内容は次のとおりです。


dn: cn=Penny Gold, o=Ultra Keyboards Inc., c=US
changetype: add
objectclass: top
objectclass: person
objectclass: inetOrgPerson
cn: Penny Gold
sn: Gold
mail: pgold@ultra.com
 
dn: cn=Amy Lamb, o=Ultra Keyboards Inc., c=US
changetype: add
objectclass: top
objectclass: person
objectclass: inetOrgPerson
cn: Amy Lamb
sn: Lamb
mail: alamb@ultra.com

ディレクトリからエントリを削除する

ディレクトリからエントリを削除するには、ldapdelete(1) を使用します。ldapdelete は、LDAP ディレクトリサーバーへの接続を開き、そのディレクトリサーバーにバインドして、ディレクトリに対して 1 つ以上の LDAP エントリ削除処理を実行します。

  1. ディレクトリマネージャ (パスワード enigma) としてバインドし、Penny Gold のエントリを削除します。


    % ldapdelete -D "cn=Manager, o=Ultra Keyboards Inc., \
c=US" -w enigma "cn=Penny Gold, o=Ultra Keyboards Inc., c=US"

ldapdelete は、正常終了時には何も表示しません。異常終了時にはエラーメッセージを表示します。

ディレクトリエントリの名前を変更する

既存のディレクトリエントリの名前を変更するには、ldapmodrdn(1) を使用します。ldapmodrdn は、LDAP ディレクトリサーバーへの接続を開き、そのディレクトリサーバーにバインドして、ディレクトリに対して 1 つ以上の LDAP RDN 変更 (名前変更) 処理を実行します。

  1. ディレクトリマネージャ (パスワード enigma) としてバインドし、RDN cn 値を、User Interface から Ergonomic に変更します。


    % ldapmodrdn -r -D "cn=Manager, o=Ultra Keyboards Inc., \
c=US" -w enigma "cn=User Interface, o=Ultra Keyboards Inc., \
c=US" "cn=Ergonomic"

ldapmodrdn は、正常終了時には何も表示しません。異常終了時にはエラーメッセージを表示します。