この章では、Solaris LDAP クライアントが名前情報を検索できるように、LDAP サーバーを設定する方法について説明します。この設定によって、Solaris LDAP クライアントは、getXbyY インタフェースまたは ldaplist(1) を使用して、LDAP サーバー上の名前情報を検索できるようになります。
この章の内容は次のとおりです。
Solaris ネームサービスクライアントは LDAP v3 プロトコルだけで利用されている制御を使用するため、Solaris ネームサービスクライアントで名前情報の検索を行うには、サーバーが LDAP v3 プロトコルに対応している必要があります。
単純ページモード (RFC 2696)
仮想リスト表示制御
サーバーは次のいずれかの認証方式をサポートしていなければなりません。
anonymous (匿名)
SIMPLE (平文パスワード)
SASL CRAM-MD5
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 |
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 に格納されているコンテナと情報タイプを示します。
表 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_* |
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)" |
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 サーバー IP アドレスのリストです。IP アドレスの後に、クライアントが使用するポート番号をコロンで区切って指定できます。このパラメータにデフォルト値はありません。少なくとも 1 つの LDAP サーバーを定義する必要があります。複数のサーバーを定義すると、最初のサーバーから応答がないときには、次のサーバーが使用されます。
名前情報が格納される LDAP ネーム起点識別名です。
クライアントが認証処理で使用する LDAP の識別情報です。通常は、プロキシエージェントの DN です。デフォルトは NULL 文字列です。
SIMPLE 認証および CRAM_MD5 認証を使用するときの SolarisBindDN のパスワードです。デフォルトは NULL 文字列です。
クライアントが使用する認証方式の順序付きリストです。使用可能な認証方式として、NONE、SIMPLE、CRAM_MD5 があります。デフォルトは NONE です。複数の認証方式を指定すると、資格以外の理由で最初の方式による認証に失敗したとき、次の認証方式が試されます。
クライアントが使用する安全な通信方法です。デフォルトは NONE です。現在のところ、NONE しか指定できません。
名前情報を検索するときの代替の起点識別名 (baseDN) です。この属性を指定することによって、デフォルトの名前情報タイプを無効にできます。代替 baseDN の書式は次のとおりです。
database:alternate-baseDN-list |
database は nsswitch.conf ファイルに定義された情報タイプ、alternate-baseDN-list は代替 baseDN のリストです。リストの各要素はコンマで区切り、リスト全体を括弧で囲みます。各データベースは、このパラメータに指定された順序で検索されます。デフォルトは、どのコンテナでも NULL です。
名前情報を検索するときに適用する検索範囲です。指定可能な値は、Base、One level、Subtree のいずれかです。デフォルトは One level です。
名前情報を検索するときの LDAP 検索時間の上限 (秒) です。デフォルトは 30 秒です。
クライアントが自身のプロファイル情報をサーバーから取得して更新するまでの有効期限です。ldap_cachemgr による自動更新を行いたくないときは、client_TTL に 0 (ゼロ) を設定します。指定できる値は、ゼロ (期限切れなし)、または正の整数 (秒) です。デフォルトは 43200 (12 時間) です。
SolarisSearchReferral
名前情報を検索するときの参照の扱いを指定します。参照に従うまたは参照に従わないのいずれかを指定できます。デフォルトでは常に参照に従います。
クライアントプロファイルを作成するための ldap_gen_profile(1M) コマンドは、Solaris クライアントツールの一部として提供されています。このツールは LDIF ファイルを生成します。生成された LDIF ファイルを LDAP サーバーに格納するには、ldapadd(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 |
作成されたプロファイルを (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 ネームサービスは、クライアントをディレクトリに認証してもらうとき、匿名またはプロキシエージェントのいずれかの識別情報を使用するように構成できます。
認証とは識別情報を確認する作業全般を意味し、anonymous はその特殊な場合と考えることができます。anonymous はどのレベルのセキュリティも提供しません。つまり、ディレクトリに対するすべての非認証接続による、すべてのネットワーク情報レコード (パスワードやシャドウの情報も含む) の参照/読み取りが可能です。セキュリティはまったく提供されませんが、状況によってはこれが適切になる場合があります。
プロキシエージェントを識別情報とする場合、クライアントは、ディレクトリ内のプロキシアカウントを使用してディレクトリに対して認証を行います。プロキシアカウントとしては、ディレクトリにバインドすることが許可されているすべてのエントリ (iPlanet Directory Server の場合は、userPassword 属性を持っているすべてのエントリ) を使用できます。
ディレクトリ内の部分的な情報に対するアクセス制御は、プロキシの識別情報に基づき、各種の権限を制限または許可する適切な ACI (アクセス制御情報) を設定することによって行います。プロキシエージェントの数とクライアントの数には何の関係もないため、2 つを自由に組み合わせることができます。2 つの例を考えてみます。1 つは、すべてのクライアントに 1 つのプロキシエージェントを対応させ、そのプロキシに、名前情報を持っている DIT 全体に対する読み取り権を与えることができます。もう 1 つは、各クライアントが異なるプロキシエージェントを使用して認証を行うようにサーバーを設定し、クライアントごとに異なるアクセス制限を行う ACI を設定することもできます。この 2 つは、プロキシエージェントを使用した認証の両極端な例です。通常は、この 2 つの中間的な設定になります。アクセス制御の細かさはディレクトリ設計者が決定することで、慎重に考慮する必要があります。プロキシエージェントが少なすぎると、システム管理者はリソースへのアクセスを制御する力が制限されてしまいます。エージェントの数が多すぎると、必要なプロファイルの数も多くなり、システムの設定と保守が複雑になります。
クライアント構成はプロファイル内に格納されるため、使用するプロキシの数と定義する必要のあるプロファイル数には直接的な関係があります。
プロキシエージェントを使用する場合、システム管理者は、ディレクトリに対して認証するときの認証方式も選択する必要があります。現時点で、Solaris 8 によってサポートされている認証方式は、SIMPLE と CRAM-MD5 の 2 つです。
SIMPLE を選択した場合、クライアントは、LDAP サーバーに単純なバインド要求を送信し、そのサーバーに対して認証を行います。この認証方式ではパスワードがネットワーク上を平文で流れるため、パスワードが漏洩しやすくなります。一方、LDAP 標準で定義されている必須の認証方式なので、すべてのディレクトリサーバーでサポートされているという利点があります。
一部のディレクトリサーバーは、SASL (Simple Authentication and Security Layer) を介してチャレンジ-応答認証方式 (CRAM-MD5) もサポートしています。CRAM-MD5 の主な利点は、認証のときパスワードが平文のままネットワーク上を流れないため、SIMPLE よりも安全であるという点です。CRAM-MD5 についての詳細は、RFC 2195 を参照してください。SASL については、RFC 2222 を参照してください。
iPlanet Directory Server version 4.11 は、現時点では CRAM-MD5 をサポートしていません。
PAM (Pluggable Authentication Module, 接続可能な認証モジュール) を使用すれば、アプリケーションを Solaris オペレーティング環境で使用される認証方式から独立させておくことができます。PAM 層を使用すれば、アプリケーションは、システム管理者がそのクライアントにどの認証方式を定義しているかに関係なく、認証を実行できます。LDAP ネームサービスを使用するには、pam_unix(5) または pam_ldap(5) のどちらかの PAM モジュールを pam.conf に指定します。
pam_unix を使用すると、従来の UNIX 認証モデルが使用されます。このモデルでは、ユーザーの暗号化されたパスワードをローカルマシンでディレクトリから取得し、ユーザーにパスワードの入力を求めます。そして入力されたパスワードを暗号化し、それをディレクトリから取得した暗号化されたパスワードと比較することによって、ユーザーの認証を行います。LDAP を使用しているクライアントがこのモジュールを使用するように構成されている場合は、そのクライアントが使用している ID (anonymous または構成されたプロキシエージェント) で userPassword 属性を読み取ることができなければなりません。また、この認証モデルには次の 2 つの制限があります。
パスワードを userPassword 属性に格納する必要がある。
パスワードを UNIX crypt 形式で格納する必要がある (平文、他の暗号方式によって暗号化されたパスワードは使えない)。
LDAP ディレクトリを使用する場合、pam_unix による従来の認証方式は必ずしも最善の方法ではないため、Solaris 8 では、ディレクトリに対して直接ユーザーの認証を実行する新しい PAM モジュールが追加されました。このモジュールを使用すると、Solaris クライアントは、ディレクトリサーバーがサポートしている新しい高度な認証方式を使用できます。当然、pam_ldap を使用しているクライアントは、パスワード属性に対する読み取り権を必要としません。また、パスワードを特定の形式でディレクトリに格納する必要もありません。
さらに、pam_ldap はディレクトリサーバーに対して直接ユーザーの認証を実行するため、ユーザーレベルのアクセス制御を適切に設定しておけば、ACI (アクセス制御情報) を使用して各ユーザーの認証を制御できます。
pam_unix を使用するときと同様に、パスワードを変更するには passwd コマンドを使用します。
ほとんどの 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 は、ディレクトリ情報を表現するテキストベースの書式です。
ldapsearch ツールは、LDIF の書式で出力します。ldapadd ツールはこの書式のデータを処理します。また、ldapmodify ツールはこの LDIF を基本とした変更情報を使用します。
LDIF ファイルには、1 つ以上のエントリが含まれています。各エントリは空白行で区切られます。基本的なエントリ形式は次のとおりです。
[id] dn: entryDN attrtype: attrvalue ... |
id
数字のエントリ識別子 (省略可能。LDAP ツールでは使用されない)。
ディレクトリエントリの LDAP 識別名 (DN)。
LDAP 属性タイプ。cn や telephoneNumber など。
attrtype の値。
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 ディレクトリサーバーへの接続を開き、そのディレクトリサーバーにバインドして、ディレクトリの検索を実行します。
米国の 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 変更処理を実行します。
ディレクトリマネージャ (パスワード 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 追加処理を実行します。
ディレクトリマネージャ (パスワード 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 エントリ削除処理を実行します。
ディレクトリマネージャ (パスワード 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 変更 (名前変更) 処理を実行します。
ディレクトリマネージャ (パスワード 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 は、正常終了時には何も表示しません。異常終了時にはエラーメッセージを表示します。