パート V LDAP ネームサービスの設定と管理

ここでは、LDAP ネームサービスの概要を説明します。 また、Solaris オペレーティング環境での LDAP ネームサービスの設定、構成、管理、および障害追跡について、特に iPlanet Directory Server 5.1 の使用方法に焦点を当てて説明します。

第 12 章 LDAP ネームサービスの紹介 (概要/リファレンス)

LDAP に関する章では、iPlanet Directory Server 5.1 で動作するように Solaris ネームサービスクライアントを設定する方法を説明します。一般的なディレクトリサーバー要件については、第 18 章「一般的なリファレンス」で簡潔に説明します。

ディレクトリサーバーは LDAP サーバーである必要はありませんが、LDAP に関する章では、「ディレクトリサーバー」という語は「LDAP サーバー」の同義語として使用します。

対象読者

LDAP ネームサービスに関するこれらの章は、LDAP に関する実務上の知識を持つシステム管理者を対象としています。以下のリストは、本書を利用して Solaris ベースの LDAP ネームサービスを配備する前によく理解しておく必要のある概念の一部です。

• LDAP 情報モデル (エントリ、オブジェクトクラス、属性、タイプ、値)

• LDAP ネームモデル (ディレクトリ情報ツリー (DIT) 構造)

• LDAP 機能モデル (検索パラメータ: ベースオブジェクト (DN)、スコープ、サイズ制限、時間制限、フィルタ (iPlanet Directory Server のインデックスを表示する)、属性リスト)

• LDAP セキュリティモデル (認証方式、アクセス制御モデル)

• LDAP ディレクトリサービスの全体計画および設計 (データの計画方法、DIT、トポロジ、複製、およびセキュリティの設計方法を含む)

推奨される前提知識

前述の概念を詳しく知りたい場合、または LDAP や一般的なディレクトリサービスの配備について知りたい場合、以下のドキュメントが役に立ちます。

• 『Understanding and Deploying LDAP Directory Services 』Timothy A. Howes, Ph.D、Mark C. Smith 共著

  LDAP ディレクトリサービスの処理をはじめから終わりまで紹介するとともに、大規模な大学、大規模な多国籍企業、およびエクストラネットを備えた企業への LDAP 導入に関する有用なケーススタディが含まれています。

• 『iPlanet Directory Server 5.1 導入ガイド』。 このドキュメントは、Solaris 9 Documentation CD に含まれています。

  このドキュメントでは、基本的なディレクトリ計画 (ディレクトリ設計、スキーマ設計、ディレクトリツリー、トポロジ、複製、およびセキュリティを含む) が説明されています。最後の章では、簡単な配備に加え、世界中に存在する何百万ものユーザーをサポートする複雑な配備を行う際の参考になる、サンプルの開発シナリオを紹介しています。

• 『iPlanet Directory Server 5.1 管理者ガイド』。 このドキュメントは、Solaris 9 Documentation CD に含まれています。

その他の前提条件

NIS+ から LDAP への移行を行う場合、『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』の付録「NIS+ から LDAP への移行」を参照して移行を完了してから、本書の各章に進んでください。

iPlanet Directory Server 5.1 のインストールが必要な場合は、『iPlanet Directory Server 5.1 インストールガイド』を参照してください。

LDAP ネームサービスとその他のネームサービスの比較

以下に、FNS、DNS、NIS、NIS+、および LDAP ネームサービスの比較一覧を示します。

完全指定ドメイン名の使用

LDAP クライアントと NIS や NIS+ クライアントとの 1 つの重要な相違点は、LDAP クライアントが DNS の場合と同様、ホスト名として常に完全指定ドメイン名 (FQDN) を返すことです。たとえば、次のドメイン名を考えてみましょう。

west.example.net

この場合、ホスト名 server を検索する場合、gethostbyname() および getipnodebyname () はホスト名を FQDN で返します。

server.west.example.net

また、server-# のようなインタフェース固有の別名を使用した場合も、完全指定ホスト名の長いリストが返されます。ホスト名を使用してファイルシステムの共有や他の検査を実行する場合、この点に留意する必要があります。ローカルホストには非 FQDN を想定し、DNS 解決済み遠隔ホストにのみ FQDN を想定している場合は特に注意が必要です。DNS と異なるドメイン名を使用して LDAP を設定すると、同じホストでも検索元によって FQDN が異なることがあります。

LDAP ネームサービスの利点

• LDAP を使用すると、アプリケーション固有の情報を置き換えて情報の整理統合を実行し、管理するデータベースの数を減らすことができる

• LDAP を使用すると、マスターと複製との間でより頻繁にデータの同期を取ることができる

• LDAP では、プラットフォーム間およびベンダー間の互換性が維持されている

LDAP ネームサービスの欠点

以下に、その他のネームサービスと比較して LDAP の欠点を示します。

• Solaris 8 より前のクライアントがサポートされない

• LDAP サーバーをそのクライアントとして使用することはできない

• LDAP ネームサービスの設定および管理がより複雑なため、注意深い計画が必要である

ディレクトリサーバー (LDAP サーバー) をそのクライアントとして使用することはできません。つまり、ディレクトリサーバーソフトウェアを実行中のマシンを、LDAP ネームサーバークライアントにすることはできません。

Solaris 9 LDAP ネームサービスの新機能

• idsconfig の使用による、LDAP ディレクトリサーバー設定の簡略化

• 強力な認証、TLS 暗号化セッションをサポートする、より堅牢なセキュリティモデル。クライアントのプロキシ資格は、ディレクトリサーバー上のクライアントプロファイルには格納されていない

• ldapaddent コマンドを使用して、データをサーバー上に生成およびダンプすることができる

• サービス検索記述子および属性マップ

• 新規プロファイルスキーマ

NIS+ から LDAP への移行

NIS+ は、将来のリリースでサポートされない可能性があります。Solaris 9 オペレーティング環境には、NIS+ から LDAP への移行を支援するツールが用意されています。

詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ から LDAP への移行の詳細については、第 19 章「NIS+ から LDAP への移行」を参照してください。

LDAP ネームサービスの設定 (作業マップ)

第 13 章 基本コンポーネントおよび概念 (概要)

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

• 「LDAP データ交換フォーマット (LDIF)」

• 「デフォルトのディレクトリ情報ツリー (DIT)」

• 「デフォルトスキーマ」

• 「サービス検索記述子 (SSD) とスキーママッピング」

• 「クライアントプロファイル」

• 「ldap_cachemgr デーモン」

• 「LDAP ネームサービスのセキュリティモデル」

LDAP データ交換フォーマット (LDIF)

LDIF は、ディレクトリサービス情報を記述するために使用されるテキストベースのフォーマットです。LDIF を使用することで、ディレクトリ間で情報の移動が可能となります。以下に、各サービスの LDIF フォーマットの例を示します。この情報を表示するには、 -l オプションを指定して ldaplist を実行してください。

% ldaplist -l hosts myhost

hosts

dn: cn=myhost+ipHostNumber=7.7.7.115,ou=Hosts,dc=mydc,dc=mycom,dc=com
cn: myhost
iphostnumber: 7.7.7.115
objectclass: top
objectclass: device
objectclass: ipHost
description: host 1 - floor 1 - Lab a - building b

% % ldaplist -l passwd user1

passwd

dn: uid=user1,ou=People,dc=mydc,dc=mycom,dc=com
uid: user1
cn: user1
userpassword: {crypt}duTx91g7PoNzE
uidnumber: 199995
gidnumber: 20
gecos: Joe Smith [New York]
homedirectory: /home/user1
loginshell: /bin/csh
objectclass: top
objectclass: shadowAccount
objectclass: account
objectclass: posixAccount

% ldaplist -l services name

services

dn: cn=name+ipServiceProtocol=udp,ou=Services,dc=mydc,dc=mycom,dc=com
cn: name
cn: nameserver
ipserviceprotocol: udp
ipserviceport: 42
objectclass: top
objectclass: ipService

% ldaplist -l group mygroup

group

dn: cn=mygroup,ou=Group,dc=mydc,dc=mycom,dc=com
cn: mygroup
gidnumber: 4441
memberuid: user1
memberuid: user2
memberuid: user3
userpassword: {crypt}duTx91g7PoNzE
objectclass: top
objectclass: posixGroup

% ldaplist -l netgroup mynetgroup

netgroup

cn=mynetgroup,ou=netgroup,dc=central,dc=sun,dc=com
objectclass=nisNetgroup
objectclass=top
cn=mynetgroup
nisnetgrouptriple=(user1..mydc.mycom.com,-,)
nisnetgrouptriple=(user1.,-,)
membernisnetgroup=mylab

% ldaplist -l networks 200.20.20.0

networks

dn: ipNetworkNumber=200.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com
cn: mynet-200-20-20
ipnetworknumber: 200.20.20.0
objectclass: top
objectclass: ipNetwork
description: my Lab Network
ipnetmasknumber: 255.255.255.0

% ldaplist -l netmasks 201.20.20.0

netmasks

dn: ipNetworkNumber=201.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com
cn: net-201
ipnetworknumber: 201.20.20.0
objectclass: top
objectclass: ipNetwork
description: my net 201
ipnetmasknumber: 255.255.255.0

% ldaplist -l rpc ypserv

rpc

dn: cn=ypserv,ou=Rpc,dc=mydc,dc=mycom,dc=com
cn: ypserv
cn: ypprog
oncrpcnumber: 100004
objectclass: top
objectclass: oncRpc

% ldaplist -l protocols tcp

protocols

dn: cn=tcp,ou=Protocols,dc=mydc,dc=mycom,dc=com
cn: tcp
ipprotocolnumber: 6
description: transmission control protocol
objectclass: top
objectclass: ipProtocol

% ldaplist -l bootparams myhost

bootparams

dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com
bootparameter: root=boothost:/export/a/b/c/d/e
objectclass: top
objectclass: device
objectclass: bootableDevice
cn: myhost

% ldaplist -l ethers myhost

ethers

dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com
macaddress: 8:1:21:71:31:c1
objectclass: top
objectclass: device
objectclass: ieee802Device
cn: myhost

% ldaplist -l publickey myhost

publickey

dn: cn=myhost+ipHostNumber=200.20.20.99,ou=Hosts,dc=mydc,dc=mycom,dc=com
cn: myhost
iphostnumber: 200.20.20.99
description: Joe Smith
nispublickey: 9cc01614d929848849add28d090acdaa1c78270aeec969c9
nissecretkey: 9999999998769c999c39e7a6ed4e7afd687d4b99908b4de99
objectclass: top
objectclass: NisKeyObject
objectclass: device
objectclass: ipHost

% ldaplist -l aliases myname

aliases

dn: mail=myname,ou=aliases,dc=mydc,dc=mycom,dc=com
cn: myname
mail: myname
objectclass: top
objectclass: mailgroup
mgrprfc822mailmember: my.name

デフォルトのディレクトリ情報ツリー (DIT)

Solaris LDAP クライアントはデフォルトで、DIT がある特定の構造を持っていると想定して情報にアクセスします。LDAP サーバーがサポートするドメインごとに、想定された構造を持つ想定されたサブツリーがあります。ただしこのデフォルト構造は、サービス検索記述子 (Service Search Descriptor、SSD) を指定することで上書きできます。指定されたドメインでは、デフォルト DIT が、特定の情報タイプのエントリを含む多数のサブツリーを保持します。これらのサブツリー名については次の表を参照してください。

デフォルトスキーマ

スキーマは、LDAP ディレクトリ内にエントリとして格納可能な情報タイプの定義です。LDAP ネームサービスクライアントをサポートするために、ディレクトリサーバースキーマの拡張が必要な場合があります。IETF および Solaris 固有のスキーマの詳細については第 18 章「一般的なリファレンス」を参照してください。IETF Web サイト http://www.ietf.org から、さまざまな RFC にアクセスすることもできます。

サービス検索記述子 (SSD) とスキーママッピング

スキーママッピングは、注意深くかつ一貫した方法で使用する必要があります。

前述したように、LDAP ネームサービスはデフォルトで、DIT が特定の方法で構築されているという想定のもとに動作します。必要に応じて、DIT 内のデフォルト以外の場所を検索するように Solaris LDAP ネームサービスに指示することができます。また、デフォルトスキーマで指定された属性やオブジェクトクラスの代わりに、別の属性やオブジェクトクラスを指定して使用することもできます。デフォルトフィルタの詳細については、「LDAP ネームサービスで使用されるデフォルトフィルタ」を参照してください。

SSD

serviceSearchDescriptor 属性は、LDAP ネームサービスクライアントが特定のサービスに関する情報を検索する方法および場所を定義します。serviceSearchDescriptor には、サービス名に続き、1 つ以上のセミコロンで区切られたベース - スコープ - フィルタのセットが含まれます。これらのベース - スコープ - フィルタのセットは特定のサービス専用の検索定義に使用され、指定された順番で検索されます。特定のサービスに対して複数のベース - スコープ - フィルタが指定されている場合、このサービスは、特定のエントリを検索する際、指定されたスコープおよびフィルタを保持する各ベースを検索します。

SSD では、デフォルト位置は SSD に含められていない限り、サービス (データベース) の検索対象にはなりません。 サービスに複数の SSD が指定されている場合、予期しない結果になる場合があります。

次の例では、Solaris LDAP ネームサービスクライアントが、passwd サービスに対して、ou=west,dc=example,dc=com で 1 レベルの検索を実行し、次に ou=east,dc=example,dc=com で 1 レベルの検索を実行します。ユーザーの username に対して passwd データを検索する場合、各 BaseDN に対してデフォルトの LDAP フィルタ (&(objectClass=posixAccount)(uid=username)) が使用されます。

serviceSearchDescriptor: passwd:ou=west,dc=example,dc=com;ou=east,
dc=example,dc=com 

次の例では、Solaris LDAP ネームサービスクライアントは、ou=west,dc=example,dc=com 内でpasswd サービスのサブツリー検索を実行します。ユーザー username の passwd データを検索する場合、LDAP フィルタ (&(fulltimeEmployee=TRUE)(uid=username)) を使用して、サブツリー ou=west,dc=example,dc=com の検索がされます

serviceSearchDescriptor: passwd:ou=west,dc=example,
dc=com?sub?fulltimeEmployee=TRUE

特定のサービスタイプに複数のコンテナを関連付けることも可能です。

たとえば、次のサービス検索記述子は、3 つのコンテナ、ou=myuser,dc=example,dc=com、 ou=newuser,dc=example,dc=com、および ou=extuser,dc=example,dc=com でパスワードエントリを検索することを指定しています。末尾に「,」がある場合には、SSD の相対ベースに defaultSearchBase が付加されることを意味します。

defaultSearchBase: dc=example,dc=com
serviceSearchDescriptor: \
passwd:ou=myuser;ou=newuser,ou=extuser,dc=example,dc=com

スキーママップ

Solaris LDAP ネームサービスを使用すると、1 つ以上の属性名をいずれかのサービスに再マッピングできます(Solaris LDAP クライアントは、第 18 章「一般的なリファレンス」に記載されているよく知られている属性を使用します)。属性を対応づける場合、その属性が元の属性と同じ意味および構文を必ず保持するようにしてください。userPassword 属性を対応づけると、問題が発生する場合があります。

スキーママッピングを使用する理由として、次の 2 つが挙げられます。

• 既存のディレクトリサーバー内の属性を対応づけしたい

• 大文字小文字のみが異なるユーザー名を使用する場合、大文字小文字を無視する uid 属性を、大文字小文字を無視しない属性に対応づける必要があります。

書式は、service:attribute-name=mapped-attribute-name です。

指定されたサービスに対して複数の属性を対応づける場合は、複数の attributeMap 属性を定義できます。

次の例では、uid および homeDirectory 属性を passwd サービスで利用する場合、常に employeeName および home 属性が使用されます。

attributeMap: passwd:uid=employeeName
attributeMap: passwd:homeDirectory=home

passwd サービスの gecos 属性を複数の属性に対応づける場合、特殊なケースが 1 つ存在します。次に例を示します。

attributemap: gecos=cn sn title

上の例では、gecos 値が、空白で区切られた cn、sn、および title 属性値のリストに対応づけられます。

objectClass マップ

Solaris LDAP ネームサービスを使用すると、オブジェクトクラスを任意のサービス用に対応づけしなおすことができます。特定のサービス用に複数のオブジェクトクラスを対応づける場合、複数の objectclassMap 属性を定義できます。次の例では、posixAccount オブジェクトクラスを使用する場合、常に myUnixAccount オブジェクトクラスが使用されます。

objectclassMap: passwd:posixAccount=myUnixAccount

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

Solaris クライアントのセットアップを容易にし、各クライアントに同じ情報を再入力する手間を省くために、ディレクトリサーバー上に単一のクライアントプロファイルを作成します。この単一のプロファイルに、使用するすべてのクライアントの構成を定義します。プロファイル属性への以降の変更はすべて、定義されたリフレッシュ頻度で送信されます。

これらのクライアントプロファイルは、LDAP サーバー上のよく知られた位置に格納されます。指定されたドメインのルート DN は、 nisDomainObject のオブジェクトクラス、およびクライアントのドメインを含む nisDomain 属性を保持する必要があります。すべてのプロファイルは、このコンテナと相対的な関係にある ou=profile コンテナ内に配置されます。これらのプロファイルは、匿名で読み取り可能にする必要があります。

クライアントのプロファイル属性

次のリストに、Solaris LDAP クライアントのプロファイル属性を示します。これらのプロファイル属性は、idsconfig の実行時に自動的に設定できます。クライアントプロファイルを手動で設定する方法については、「クライアントを手動で初期設定する」 を参照してください。

ローカルのクライアント属性

次の表に、ldapclient(1M) を使用してローカルに設定可能なクライアント属性を示します。

SSD 内の BaseDN に末尾のコンマが含まれる場合、 defaultSearchBase の相対値として処理される。検索実行前に、defaultSearchBase の値が BaseDN に付加される。

ldap_cachemgr デーモン

ldap_cachemgr(1M) は、LDAP クライアントマシン上で稼働するデーモンです。このデーモンは、次の主要機能を実行します。

• root として稼働し、構成ファイルへのアクセスを取得する

• サーバー上のプロファイルに格納されたクライアント構成情報を更新して、クライアントからこのデータを引き出す

• 使用可能な LDAP サーバーのソート済みリストを管理

• さまざまなクライアントから送信される一般的な検索要求をキャッシュして、検索効率を向上させる

• ホスト検索の効率を向上させる

LDAP ネームサービスを機能させるには、ldap_cachemgr が常に実行されている必要があります。

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

LDAP ネームサービスのセキュリティモデル

はじめに

Solaris LDAP ネームサービスは、LDAP リポジトリをネームサービスと認証サービスの両方のソースとして使用します。この節では、クライアント認証、認証方式、pam_ldap と pam_unix モジュール、およびパスワード管理の概念について説明します。

LDAP リポジトリに格納された情報にアクセスする場合、クライアントは最初にディレクトリサーバーで識別情報を確立できます。この識別情報は、匿名にも、LDAP サーバーの認識するオブジェクトにもできます。クライアントの識別情報およびサーバーのアクセス制御情報 (ACI) に基づいて、LDAP サーバーはクライアントに対してディレクトリ情報の読み取りまたは書き込みを許可します。ACI の詳細については、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。

特定の要求に関して匿名以外で接続している場合、クライアントは、クライアントとサーバーの両方がサポートする認証方式でサーバーに識別情報を証明する必要があります。クライアントは識別情報を確立後に、さまざまな LDAP 要求を実行できます。

ネームサービスと認証サービス (pam_ldap) がディレクトリへの認証を行う方法には違いがあることに留意してください。ネームサービスは、事前定義された識別情報に基づくディレクトリから、さまざまなエントリおよびその属性を読み取ります。認証サービス (pam_ldap) は、ユーザーの名前とパスワードを使用して LDAP サーバーへの認証を行い、ユーザーが適正なパスワードを入力したかどうかを確認します。

Transport Layer Security (TLS)

TLS を LDAP クライアントとディレクトリサーバー間の通信のセキュリティ保護に使用すると、機密性とデータの完全性を保証することができます。TLS プロトコルは、Secure Sockets Layer (SSL) のスーパーセットです。Solaris LDAP ネームサービスは、TLS 接続をサポートします。SSL を使用すると、ディレクトリサーバーおよびクライアントに負荷がかかることに留意してください。

SSL 対応のディレクトリサーバーを設定する必要があります。SSL 対応の iPlanet Directory Server 5.1 の設定方法の詳細については、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。SSL 対応の LDAP クライアントも設定する必要があります。

Solaris LDAP ネームサービス用の TLS を使用する場合、ディレクトリサーバーは、LDAP および SSL 用にデフォルトポート 389 および 636 をそれぞれ使用する必要があります。ディレクトリサーバーがこれらのポートを使用しない場合、TLS を使用することはできません。

詳細については、「TLS セキュリティの設定」を参照してください。

クライアント資格レベルの割り当て

LDAP ネームサービスクライアントは、資格レベルに従って LDAP サーバーを認証します。LDAP クライアントには、次の 3 つの資格レベルの 1 つを割り当てて、ディレクトリサーバーへの認証を行うことができます。

• anonymous

• proxy

• proxy anonymous

Anonymous

匿名でのアクセスを利用する場合、すべてのユーザーが使用可能なデータだけにアクセスできます。また、セキュリティの問題も考慮する必要があります。ディレクトリの特定部分に匿名アクセスを許可する場合、そのディレクトリへのアクセス権を保持するユーザーはすべて、その操作を実行できることになります。資格レベルとして anonymous を使用する場合、すべての LDAP ネームエントリおよび属性に読み取りアクセスを許可する必要があります。

匿名でのディレクトリへの書き込みは、決して許可してはなりません。この書き込みを許可すると、どのユーザーでも書き込みアクセス権のある DIT 内の情報 (別のユーザーのパスワードや自分自身の識別情報など) を変更することが可能になります。

iPlanet Directory Server 5.1 を使用すると、IP アドレス、DNS 名、認証方式、および時刻に基づいてアクセスを制限できます。さらに指定を加えて、アクセスを制限することもできます。詳細については、『iPlanet Directory Server 5.1 管理者ガイド』のアクセス権の管理に関する章を参照してください。

プロキシ

クライアントは、プロキシアカウントを使用して、ディレクトリへの認証またはバインドを行います。このプロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このプロキシアカウントは、LDAP サーバー上でネームサービス機能を実行するのに十分のアクセス権を必要とします。プロキシ資格レベルを使用して、すべてのクライアントで proxyDN および proxyPassword を構成する必要があります。暗号化された proxyPassword はローカルのクライアントに格納されます。別のクライアントグループに対しては別のプロキシを設定できます。たとえば全営業クライアント用のプロキシを構成する場合、企業全体からアクセス可能なディレクトリと営業ディレクトリの両方へのアクセスを許可しつつ、給与情報を保持する人事ディレクトリへのアクセスを許可しない、という方法が可能です。最も極端な例として、各クライアントに別個のプロキシを割り当てることや、すべてのクライアントに同じプロキシを割り当てることも可能です。一般的な LDAP 配備はこの両極端の中間に位置します。選択は慎重に行なってください。プロキシエージェントが不足していると、リソースへのユーザーアクセスを制御する能力が制限されます。ただし、プロキシが多過ぎる場合、システムの設定および保守が困難になります。適切な権限をプロキシユーザーに付与する必要がありますが、その程度は環境によって大きく異なります。使用する構成に最適の認証方式を決定するための情報については、「資格の保存」を参照してください。

プロキシユーザーのパスワードを変更した場合、そのプロキシユーザーを使用するすべてのクライアントで情報を更新する必要があります。LDAP アカウントのパスワード有効期間を設定する場合、プロキシユーザーに関してはこの設定を解除してください。

プロキシ資格レベルは、指定されたマシンのすべてのユーザーおよびプロセスに適用されます。2 人のユーザーが異なるネーミングポリシーを使用する場合は、別個のマシンを使用する必要があります。

また、クライアントが認証にプロキシ資格を使用する場合、proxyDN はすべてのサーバーで同じ proxyPassword を保持する必要があります。

匿名プロキシ

匿名プロキシは複数値のエントリで、複数の資格レベルが内部に定義されています。匿名プロキシレベルを割り当てられたクライアントは、最初にそのプロキシ識別情報を使用して認証を試みます。ユーザーのロックアウト、パスワードの有効期限切れなどの何らかの理由でクライアントがプロキシユーザーとしての認証ができなかった場合、クライアントは匿名アクセスを使用します。この場合、ディレクトリの構成に応じて、別のサービスレベルに移行する可能性があります。

資格の保存

プロキシ識別情報を使用するようクライアントを設定する場合、クライアントは proxyDN および proxyPassword を /var/ldap/ldap_client_cred 内に保存します。セキュリティ保護のため、このファイルへのアクセスは root のみに許可され、 proxyPassword の値は暗号化されます。過去の LDAP 実装ではプロキシ資格はクライアントのプロファイル内に格納されましたが、Solaris 9 LDAP ネーミングサービスではこれは行われません。初期化時に ldapclient を使用して設定されたプロキシ資格は、すべてローカルに保存されます。このため、プロキシの DN およびパスワード情報に関するセキュリティが向上します。クライアントプロファイルの設定方法の詳細については、第 16 章「クライアントの設定 (手順)」を参照してください。

認証方式の選択

プロキシ資格または匿名プロキシ資格を割り当てる場合、プロキシによるディレクトリサーバーへの認証方式も選択する必要があります。デフォルトの認証方式は none (匿名によるアクセス) です。認証方式には、関連するトランスポートセキュリティオプションも含まれます。

認証方式には資格レベルと同様、複数値を指定できます。たとえば、クライアントプロファイルを設定することにより、クライアントが TLS でセキュリティ保護された simple メソッドを最初に使用してバインドを試みるようにできます。これが成功しない場合、クライアントは sasl/digest-MD5 メソッドを使用してバインドを試みます。 その後、authenticationMethod は tls:simple;sasl/digest-MD5 になります。

LDAP ネームサービスは、いくつかの Simple Authentication and Security Layer (SASL) 機構をサポートします。これらの機構を使用すると、TLS なしでセキュリティ保護されたパスワードを交換できます。ただし、これらの機構はデータの完全性や機密性を保証するものではありません。SASL の詳細については、RFC 2222 を参照してください。

次の認証機構がサポートされています。

• none

  クライアントは、ディレクトリへの認証を行いません。これは、anonymous 資格レベルと等価です。

• simple

  認証方式 simple を使用する場合、クライアントマシンはユーザーのパスワードを平文で送信してサーバーへのバインドを実行します。このため、パスワードが漏洩しやすくなります。この認証方式を使用する主な利点は、すべてのディレクトリサーバーがこの方式をサポートしていること、および設定が容易であるという点です。

• sasl/digest-MD5

  認証時にクライアントのパスワードは保護されますが、セッションは暗号化されません。iPlanet Directory Server 5.1 を含むいくつかのディレクトリサーバーは、sasl/digest-MD5 認証方式もサポートします。digest-MD5 の主な利点は、認証時にパスワードが平文のままネットワーク上を流れないため、simple よりも安全であるという点です。digest-MD5 の詳細については、RFC 2831 を参照してください。digest-MD5 は、cram-MD5 のセキュリティが改善されたものと見なされます。

  sasl/digest-MD5 を使用する場合、認証はセキュリティ保護されますがセッションは保護されません。

• sasl/cram-MD5

  この場合、LDAP セッションは暗号化されませんが、 sasl/cram-MD5 を使用して認証が行われるため、認証時にクライアントのパスワードが保護されます。

  cram-MD5 認証方式の詳細については、RFC 2195 を参照してください。すべてのディレクトリサーバーがこの認証方式をサポートしているわけではありません。 たとえば、iPlanet Directory Server 5.1 は cram-MD5 をサポートしません。

• tls:simple

  クライアントは、simple を使用してバインドを行い、セッションは暗号化されます。パスワードは保護されます。

• tls: sasl/cram-MD5

  sasl/cram-MD5 を使用して、LDAP セッションの暗号化およびクライアントによるディレクトリサーバーへの認証が行われます。

• tls:sasl/digest-MD5

  sasl/digest-MD5 を使用して、LDAP セッションの暗号化およびクライアントによるディレクトリサーバーへの認証が行われます。

iPlanet Directory Server 5.1 で digest-MD5 を使用する場合、パスワードを平文で格納する必要があります。認証方式を sasl/digest-MD5 または tls:sasl/digest-MD5 に設定する場合、プロキシユーザーのパスワードを平文で格納する必要があります。平文で格納する場合には、userPassword 属性が適切な ACI を保持するようにして、読み取り不可にする必要があります。

認証とサービス

認証メソッドを特定のサービスに対して serviceAuthenticationMethod 属性に指定できます。現在この機能をサポートしているサービスを次に示します。

• passwd-cmd

  このサービスは、passwd(1) により、ログインパスワードおよびパスワード属性の変更に使用されます。

• keyserv

  このサービスは、chkey(1) および newkey(1M) ユーティリティにより、ユーザーの Diffie-Hellman 鍵ペアの作成および変更に使用されます。

• pam_ldap

  このサービスは、pam_ldap を使用したユーザーの認証に使用されます。

サービスが serviceAuthenticationMethod セットを保持しない場合、authenticationMethod 属性の値がデフォルトになります。

次に示す例は、クライアントプロファイルの 1 セクションです。ここで、ユーザーはディレクトリサーバーへの認証に sasl/digest-MD5 を使用しますが、パスワードの変更には SSL セッションを使用します。

serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5
serviceAuthenticationMethod=passwd-cmd:tls:simple

プラグイン可能な認証方式

PAM フレームワークを使用することにより、いくつかの認証サービスの中から選択できます。LDAP とともに pam_unix または pam_ldap を使用できます。

より高い柔軟性とより強力な認証方式をサポートしていることから、pam_ldap の使用をお勧めします。

pam_unix

pam.conf(4) ファイルを変更していない場合、デフォルトディレクトリ pam_unix が有効になっています。pam_unix は従来の UNIX 認証モデルに従い、次のように動作します。

1. クライアントは、ネームサービスからユーザーの暗号化されたパスワードを取得します。

2. ユーザーは、パスワードの入力を求められます。

3. ユーザーのパスワードが暗号化されます。

4. クライアントは、暗号化された 2 つのパスワードを比較して、ユーザーを認証するかどうかを決定します。

• パスワードは、平文を含む他の暗号化方式ではなく、UNIX crypt 形式で格納する必要がある

• userPassword 属性は、ネームサービスから読み取り可能でなければならない

  たとえば、資格レベルを匿名に設定する場合、すべてのユーザーに対してuserPassword 属性を読み取り可能にする必要があります。同様に、資格レベルを proxy に設定する場合、userPassword 属性の読み取りをプロキシユーザーに許可する必要があります。

pam_unix は、sasl 認証方式 digest-MD5 と互換性があります。これは、iPlanet Directory Server 5.1 では digest-MD5 を使用するためにパスワードを平文で格納する必要があるのに対し、pam_unix ではパスワードを crypt 形式で格納する必要があるためです。

pam_ldap

pam_ldap を使用する場合、ユーザーは LDAP サーバーにバインドします。認証方式は、pam_ldap の serviceAuthenticationMethod パラメタで定義されます (このパラメタが存在する場合)。それ以外の場合、authenticationMethod がデフォルトで使用されます。

pam_ldap を使用して、ユーザーの識別情報および指定されたパスワードをサーバーにバインドする場合、ユーザーが認証されます。

pam_ldap は、userPassword 属性を読み取りません。このため、pam_unix を使用する他のクライアントが存在しない限り、userPassword 属性の読み取りアクセス権を付与する必要はありません。pam_ldap は、認証方式 none をサポートしません。このため、クライアントが pam_ldap を使用できるように、serviceAuthenticationMethod または authenticationMethod attributes を定義する必要があります。

認証方式 simple を使用する場合、第三者がネットワーク上で userPassword 属性を読み取ることができます。

詳細については、「pam_ldap に対応した pam.conf ファイルの例 」を参照してください。

PAM およびパスワードの変更

パスワードの変更には、passwd(1) を使用します。パスワードを変更するには、userPassword 属性をユーザーから書き込み可能にする必要があります。passwd-cmd 用の serviceAuthenticationMethod が、この操作の authenticationMethod を無効にすることに留意してください。使用する認証によっては、現行のパスワードの暗号化解除がネットワーク上で行われる場合があります。

pam_unix の場合、UNIX crypt を使用して新規 userPassword 属性が暗号化されタグ付けされてから、LDAP への書き込みが行われます。このため、新規パスワードは、サーバーへのバインドに使用される認証方式に関係なく、ネットワーク上で暗号化されます。

pam_ldap の場合、パスワードの変更時に新規パスワードの暗号化解除が行われます。このため、機密性を保つために TLS を使用する必要があります。TLSを使用しない場合、userPassword が漏洩する危険性があります。

iPlanet Directory Server 5.1 で、pam_ldap を使用してパスワードを設定する場合、パスワードは serverStrorageScheme (タグ付けされていない状態) を使用して暗号化されます。passwordStorageScheme 属性の詳細については、『iPlanet Directory Server 5.1 管理者ガイド』のユーザーアカウントの管理に関する章を参照してください。

passwordStorageScheme 属性を設定する際、以下の点を考慮する必要があります。pam_unix を使用する NIS、NIS+、または他のクライアントがリポジトリとして LDAP を使用する場合、 passwordStorageScheme に対して crypt を実行する必要があります。また、iPlanet Directory Server 5.1 で sasl/digest-MD5 に対して pam_ldap を使用する場合、passwrodStorageScheme を平文に設定する必要があります。

パスワード管理

Solaris LDAP ネームサービスは現在、iPlanet Directory Server 5.1 のパスワード管理機能をサポートしません。

第 14 章 LDAP ネームサービスの計画

この章では、サーバーとクライアントの設定およびインストール処理を開始する前に実行する必要のある高度な計画について説明します。

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

• 「概要」

• 「ネットワークモデルの計画」

• 「ディレクトリ情報ツリー (DIT) の計画」

• 「複製サーバー」

• 「セキュリティモデルの計画」

• 「クライアントプロファイルおよびデフォルト属性値の計画」

• 「データ生成の計画」

概要

LDAP クライアントプロファイルは、LDAP クライアントが使用する構成情報の集合体です。LDAP クライアントは、このプロファイルを使用して、サポートする LDAP サーバー上の LDAP ネームサービス情報にアクセスして、LDAP ネームサービスを提供しますこの章では、LDAP 構成の主要部分を使用して、LDAP ネームサービスのさまざまな分野の計画方法を説明します。その中には、ネットワークモデル、ディレクトリ情報ツリー、セキュリティモデル、さまざまなプロファイル属性のデフォルト値、およびデータ生成の準備が含まれます。

ネットワークモデルの計画

可用性およびパフォーマンスを考慮すると、企業規模のネットワークの各サブネットが LDAP サーバーを独自に保持して、サブネット内のすべての LDAP クライアントにサービスを提供する方法が最善です。これらのサーバーの 1 つだけをマスター LDAP サーバーにする必要があります。残りはすべてマスターサーバーの複製にできます。

ネットワーク構成を計画する前に、使用可能なサーバーの数、クライアントがサーバーにアクセスする方法、複数のサーバーへのアクセス順序について考慮する必要があります。サブネットごとに 1 つのサーバーが存在する場合、defaultServerList 属性を使用してすべてのサーバーのリストを作成し、LDAP クライアントからアクセス順序をソートおよび操作できます。速度またはデータ管理上の理由から、特定の順序でサーバーにアクセスする必要がある場合は、preferredServerList 属性を使用してサーバーへの固定されたアクセス順序を定義します。マスターサーバーをこれらのリストに配置しないことで、マスターサーバーへの負荷を軽減できます。

さらに、サーバーおよびネットワーク構成を計画する際に考慮するに値する 3 つの属性があります。bindTimeLimit 属性は TCP 接続要求のタイムアウト値の設定に、searchTimeLimit 属性は LDAP 検索操作のタイムアウト値の設定に、profileTTL 属性は LDAP クライアントによるサーバーからのプロファイルのダウンロード頻度の制御に、それぞれ使用できます。速度が遅いか不安定なネットワークの場合、 bindTimeLimit および searchTimeLimit 属性にデフォルト値より大きい値を設定することが必要な場合があります。配備の初期テスト段階で、profileTTL 属性値を引き下げて、頻繁に行われる LDAP サーバー内のプロファイルの変更をクライアントが取得するようにしてもよいでしょう。

ディレクトリ情報ツリー (DIT) の計画

前の章で説明したように、LDAP ネームサービスはデフォルトのディレクトリ情報ツリー (DIT) および関連するデフォルトスキーマを保持します。たとえば、ou=people コンテナには、ユーザーアカウント、パスワード、およびシャドウ情報が含まれます。ou=hosts コンテナには、ネットワーク内のシステムに関する情報が含まれます。ou=people コンテナ内の各エントリは、 objectclass posixAccount および shadowAccount のエントリになります。デフォルト DIT は、巧みに設計されたディレクトリ構造であり、オープンな標準に基づいています。これは、ほとんどのネームサービスのニーズに応えるもので、変更せずに使用することが推奨されています。デフォルト DIT の使用を選択する場合、決定する必要があるのは、ディレクトリツリー内のどのノード (起点識別名) から、指定されたドメインのネームサービス情報を検索するかという点だけです。このノードは、defaultSearchBase 属性を使用して指定されます。さらに、defaultSearchScope 属性を設定して、ネームサービスが実行する検索範囲をクライアントに指定することもできます。検索範囲には、識別名 (DN) 内の 1 レベルだけを検索するか (one)、DN内のサブツリー全体を選択するか (sub) を指定できます。

ただし、既存の DIT を利用する場合でも、ディレクトリツリー内に散在するネームサービスデータを使用してより複雑な DIT を処理する場合でも、LDAP ネームサービスにより高度な柔軟性が求められる場合があります。たとえば、ユーザーアカウントエントリがツリーの別の場所に存在する場合があります。クライアントプロファイル内で serviceSearchDescriptor、attributeMap、および objectclassMap 属性を設定して、これらの状況に対応します。

サービス検索記述子を使用して、特定のサービスのデフォルト検索ベース、検索範囲、および検索フィルタを置き換えることができます。詳細については、「サービス検索記述子 (SSD) とスキーママッピング」を参照してください。

AttributeMap および ObjectclassMap 属性を使用して、スキーママッピングを行うことができます。これらの属性を使用すると、既存の DIT で LDAP ネームサービスを動作させることができます。posixAccount オブジェクトクラスの既存のオブジェクトクラス (myAccount など) への対応づけ、および posixAccount オブジェクトクラス内の属性の myAccount オブジェクトクラス内の属性への対応づけを実行できます。

複数のディレクトリサーバー

複数の LDAP サーバーで 1 つの DIT を構成することも可能です。たとえば、DIT のいくつかのサブツリーを、他の LDAP サーバー上に配置できます。この場合、LDAP サーバーは、既知ではあるが自身のデータベース内に存在しないネームデータを求める LDAP クライアントを、別のサーバーに委ねることができます。この種の DIT 構成を計画する場合、LDAP ネームサービスがサーバー参照に従ってネームサービス検索を続行することを示すように、クライアントのプロファイル属性 followReferrals を設定する必要があります。ただし可能であれば、指定されたドメインのネームデータすべてを単独のディレクトリサーバー上に配置するのが最善です。

クライアントが通常は読み取り専用の複製にアクセスし、必要な場合にのみ読み取り/書き込み可能なマスターサーバーへの参照を利用する場合、参照が役に立ちます。この方法では、要求が複製により処理されるため、マスターサーバーに過度の負荷がかかることはありません。

他のアプリケーションとのデータ共有

LDAP を最大限に活用するには、論理エントリごとに 1 つの LDAP エントリが存在する必要があります。たとえば、ユーザーは、企業白書に関する情報だけでなく、 Solaris アカウント情報やアプリケーション固有のデータも保持できます。posixAccount および shadowAccount は補助オブジェクトクラスであるため、これらのデータをディレクトリ内のエントリに追加できます。このため、注意深い計画、設定、および管理が必要になります。

ディレクトリ接尾辞の選択

適切なディレクトリ接尾辞の選択方法については、第 11 章「iPlanet Directory Server 5.1 の構成」を参照してください。

複製サーバー

複製サーバーを設定する場合、次の 3 つの方法が存在します。

• 単一マスター複製 (Single-master replication)

• 浮動マスター複製 (Floating-master replication)

• 複数マスター複製 (Multi-master replication)

「単一マスター」

単一マスター複製では、指定されたパーティションまたはパーティション化されていないネットワークに対して、1 つのマスターサーバーだけが、ディレクトリエントリの書き込み可能なコピーを保持します。複製サーバーは、ディレクトリエントリの読み込み専用コピーを保持します。複製とマスターの両方が検索、比較、およびバインド操作を実行できますが、書き込み操作を実行できるのはマスターサーバだけです。

単一マスター複製の不利な点は、マスターサーバーでシングルポイント障害が発生した場合です。マスターサーバーがダウンした場合、どの複製サーバーからも書き込み操作を実行できません。

「浮動マスター」

浮動マスターは、指定されたパーティション化されたネットワークまたはパーティション化されていないネットワークに対し、書き込み権限を保持するマスターサーバーは常に 1 つだけである点で、単一マスターを使用する場合と似ています。ただし浮動マスターを使用すると、マスターサーバーがダウンした場合、アルゴリズムにより複製が自動的にマスターサーバーに変化します。

浮動マスター複製の不利な点は、ネットワークがパーティション化され、どちらの側のパーティション上の複製もマスターになった場合、ネットワークを再結合する際、新規マスター間の調整が非常に複雑になり得ることです。

「複数マスター」

複数マスター複製では、ディレクトリエントリデータの独自の読み取り/書き込み複製を保持する、複数のマスターサーバーが存在します。複数マスターを使用すると、シングルポイント障害を防ぐことができますが、サーバー間で更新による競合が発生する可能性があります。つまり、2 つのマスター上でエントリの属性が同時に変更される場合、競合による障害の解決ポリシー (最後の書き込みを優先するなど) の適用が必要になります。

複製サーバーの設定方法については、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。

セキュリティモデルの計画

セキュリティモデルを計画する場合、最初に、LDAP クライアントが LDAP サーバーとの通信に使用する識別情報を考慮する必要があります。たとえば、強力な認証を使用してネットワーク上を流れるユーザーパスワードを保護するかどうか、また LDAP クライアントと LDAP サーバー間のセッションを暗号化して送信される LDAP データを保護する必要があるかなどを決定する必要があります。

セキュリティモデルの計画には、プロファイル内の credentialLevel および authenticationMethod 属性が使用されます。credentialLevel には、匿名、プロキシ、および匿名プロキシの 3 つの資格レベルのうちの 1 つを指定できます。LDAP ネームサービスのセキュリティ概念については、「LDAP ネームサービスのセキュリティモデル」 を参照してください。

セキュリティモデルを計画する際の主要な決定事項を次に示します。

• LDAP クライアントは、どの資格レベルおよび認証方式を使用するか

• TLS を使用するか

• NIS や NIS+ との下位互換性を必要とするか。言い換えれば、クライアントは pam_unix または pam_ldap を使用するか

• サーバーの passwordStorageScheme 属性をどのように設定するか

• アクセス制御情報をどのように設定するかACI の詳細については、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。

クライアントプロファイルおよびデフォルト属性値の計画

前述の計画手順 (ネットワークモデル、DIT、およびセキュリティモデル) を理解することにより、次のプロファイル属性の値についてアイデアを得ることができるでしょう。

• cn

• defaultServerList

• preferredServerList

• bindTimeLimit

• searchTimeLimit

• profileTTL

• defaultSearchBase

• defaultSearchScope

• serviceSearchDescriptor

• attributeMap

• objectclassMap

• followReferrals

• credentialLevel

• authenticationMethod

• serviceCredentialLevel

• serviceAuthenticationMethod

上記の属性の中で、必須属性は cn、 defaultServerList、および defaultSearchBase だけです。これらの属性には、デフォルト値は存在しません。残りの属性はオプションであり、デフォルト値がないオプションも存在します。

LDAP クライアントの設定の詳細については、第 16 章「クライアントの設定 (手順)」 を参照してください。

データ生成の計画

LDAP ネームサービスデータを使用して、LDAP サーバーを生成する場合、適切な DIT およびスキーマを使用して LDAP サーバーを構成した後、新規 ldapaddent ツールを使用するのが最善です。このツールは、対応する /etc ファイルから LDAP コンテナ内にエントリを作成します。このツールを使用して、次のデータタイプ用のコンテナ内にデータを生成することができます。 aliases、auto_*、bootparams、ethers、group、hosts (IPv6 アドレスを含む)、netgroup、netmasks、networks、passwd、shadow、protocols、publickey、rpc、および services。

デフォルトでは、ldapaddent は標準入力からこのデータを読み取って、コマンド行で指定されたデータベースに関連付けられた LDAP コンテナに追加します。ただし、データを読み取る入力ファイルは、-f オプションを使用して指定できます。

エントリはクライアントの構成に基づき、ディレクトリ内に格納されます。このため、LDAP ネームサービスを使用するようにクライアントを構成する必要があります。

パフォーマンスを向上させるために推奨されているデータベースのロード順序を次に示します。

1. passwd データベースの次に shadow データベース

2. networks データベースの次に netmasks データベース

3. bootparams データベースの次に ethers データベース

オートマウントエントリを追加する場合、データベース名は auto_* (たとえば auto_home) の形式で指定します。

別のホストの /etc ファイルを LDAP サーバーに追加する場合、それらすべてを 1 つの /etc ファイルにマージして、1 台のホスト上で ldapaddent を使用して追加できます。あるいは、各ホストが LDAP クライアントとして構成済みであることを想定して各ホストで ldapaddent を実行することもできます。

使用するネームサービスデータが NIS サーバー上にすでに存在し、データを LDAP ネームサービス用の LDAP サーバーに移動する場合、 ypcat (または niscat) コマンドを使用して NIS マップをファイル内にダンプします。続いて、これらのファイルに対して ldapaddent を実行してデータを LDAP サーバーに追加します。

ldapaddent は LDAP クライアント上でしか実行できません。

以下の作業は、テーブルが yp クライアントから抽出されることを想定しています。

ldapaddent を使用して host エントリを持つサーバーを生成する方法

1. idsconfig を使用し、iPlanet Directory Server 5.1 が設定されているか確認します。

2. クライアントマシン上でスーパーユーザーになります。

3. そのマシンを LDAP クライアントに設定します。

   # ldapclient init -a profileName=new -a \ domainName=west.example.com 192.168.0.0

4. データを指定してサーバーを生成します。

   # ldapaddent -h 192.168.0.0 -D directory_manager -f /etc/hosts hosts

この例では、現在 ldapaddent が simple 認証方式を使用してバインドしているように、平文で directory_manager パスワードが送られます。

rpc.nisd 内の適切な設定を使用して、NIS+ データを保持するディレクトリサーバーを生成できます。第 19 章「NIS+ から LDAP への移行」 を参照してください。

第 15 章 iPlanet Directory Server 5.1 の設定 (手順)

この章では、iPlanet Directory Server 5.1 を構成して、Solaris LDAP ネームサービスクライアントのネットワークをサポートする方法について説明します。この章の内容は、iPlanet Directory Server 5.1 に固有の情報です。

Solaris LDAP クライアントで動作するよう iPlanet Directory Server 5.1 を構成する前に、第 11 章に記載された手順をすべて実行する必要があります。

ディレクトリサーバー (LDAP サーバー) を、サーバー自身のクライアントにすることはできません。

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

• 「idsconfig を使用した iPlanet Directory Server 5.1 の構成」

• 「サービス検索記述子を使用してさまざまなサービスへのクライアントアクセスを変更する」

• 「idsconfig の実行」

• 「ldapaddent を使用したディレクトリサーバーの生成」

• 「プリンタエントリの管理」

• 「追加プロファイルを使用してサーバーを生成する」

idsconfig を使用した iPlanet Directory Server 5.1 の構成

サーバーのインストール用チェックリストの作成

サーバーのインストール処理時に定義する重要な変数を使用して、以下に示すようなチェックリストを作成してから、idsconfig を起動してください。「未記入のチェックリスト」 で提供されるチェックリストを使用できます。

以下の情報は、以降の LDAP 関連の章に示されるすべての例の基礎になります。サンプルのドメインは、全国規模で店舗を展開する部品会社である Example, Inc. のものです。例の中では、その West Coast Division (ドメインは west.example.com) を対象に説明します。

defaultServerList または preferredServerList の定義でホスト名を使用する場合、ホストの検索に LDAP を使用してはなりません。これは、/etc/nsswitch.conf の hosts 行に ldap を含めることはできないことを意味します。

クライアントプロファイルはドメインごとに定義されます。指定されたドメインで、1 つ以上のプロファイルを定義する必要があります。

属性インデックス

idsconfig が作成する次の属性リストにより 、パフォーマンスが向上します。

スキーマ定義

idsconfig(1M) により、必要なスキーマ定義が自動的に追加されます。LDAP 管理に精通しているユーザー以外、サーバースキーマを手動で変更してはなりません。LDAP ネームサービスの使用するスキーマ拡張リストについては、第 18 章「一般的なリファレンス」を参照してください。

インデックス表示の使用

インデックス表示は、iPlanet Directory Server の機能で、仮想リスト表示とも呼ばれます。クライアントは、インデックス表示を使用して、エントリのグループや番号の記載された長いリストを表示して選択を実行できます。このため、各クライアントの検索処理を短縮できます。インデックス表示により最適化かつ事前定義された検索パラメータが提供されるため、Solaris LDAP ネームクライアントは、さまざまなサービスから特定の情報により素早くアクセスできるようになります。インデックス表示を作成しない場合、サーバーが検索時間を制限するために、クライアントが指定されたタイプのエントリすべてを取得できない場合があります。また、エントリの番号を確認できない場合もあります。

インデックスはディレクトリサーバー上に構成されるため、プロキシユーザーはこれらのインデックスに読み取りアクセス権限を保持します。

iPlanet Directory Server 上でのインデックス作成の詳細、およびその使用によるパフォーマンス上のコストについては、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。

次の例では、-n オプションでエントリをインデックス化するデータベースの名前を示し、 -s オプションでディレクトリサーバーのインスタンスを示します。

idsconfig により、デフォルト VLV インデックスがすべて作成されます。

directoryserver -s ipdserver vlvindex -n userRoot -T getgrent
directoryserver -s ipdserver vlvindex -n userRoot -T gethostent
directoryserver -s ipdserver vlvindex -n userRoot -T getnetent
directoryserver -s ipdserver vlvindex -n userRoot -T getpwent
directoryserver -s ipdserver vlvindex -n userRoot -T getrpcent
directoryserver -s ipdserver vlvindex -n userRoot -T getspent

サービス検索記述子を使用してさまざまなサービスへのクライアントアクセスを変更する

サービス検索記述子 (SSD) を使用すると、LDAP 内の指定された操作のデフォルト検索要求を、ユーザーが定義した検索に変更できます。たとえば、これまでカスタマイズしたコンテナ定義や別のオペレーティングシステムで LDAP を使用してきたユーザーが、Solaris 9 に移行する場合などに、SSD は特に役に立ちます。SSD を使用すると、既存の LDAP データベースおよびデータを変更せずに、Solaris 9 LDAP ネームサービスを構成できます。

idsconfig を使用して SSD を変更する

前出の Example, Inc. が LDAP を構成済みで、ユーザーを ou=Users コンテナに格納しているものとします。これを Solaris 9 にアップグレードしましょう。定義によって、Solaris 9 LDAP は、ユーザーエントリが ou=People コンテナに格納されているものと見なします。このままでは、LDAP は passwd サービス検索時に DIT の ou=people レベルを検索するため、適切な値を検出できません。

この問題を解決する手のかかる方法の 1 つは、Example, Inc. の既存の DIT を完全に置き換え、Example, Inc. のネットワーク上の既存アプリケーションすべてを書き換えて、新規 LDAP ネームサービスとの互換性を持たせる方法です。別のはるかに望ましい解決策は、SSD を使用して、LDAP に対しユーザー情報をデフォルトの ou=people コンテナ内ではなく ou=Users コンテナ内で検索するよう指示する方法です。

idsconfig を使用して、iPlanet Directory Server 5.1 の構成時に必要な SSD を定義できます。プロンプト行は次のようになります。

Do you wish to setup Service Search Descriptors (y/n/h? y
  A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] a
Enter the service id: passwd
Enter the base: service ou=user,dc=west,dc=example,dc=com
Enter the scope: one[default]
  A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] p

Current Service Search Descriptors:
==================================
Passwd:ou=Users,ou=west,ou=example,ou=com?

Hit return to continue.

  A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] q

idsconfig の実行

idsconfig の実行には特別な権限は不要であり、LDAP ネームサービスクライアントになる必要もありません。idsconfig を実行する準備として、「サーバーのインストール用チェックリストの作成」 で説明したチェックリストを作成してください。idsconfig を、サーバーまたは LDAP ネームサービスクライアントマシンから 実行する必要はありません。ネットワーク上の任意の Solaris マシンから idsconfig を実行できます。

idsconfig は、Directory Manager のパスワードを平文で送信します。これを防ぐには、 idsconfig をクライアント上ではなく ディレクトリサーバー上で実行する必要があります。

idsconfig を使用して iPlanet Directory Server を構成する方法

1. ターゲットの iPlanet Directory Server 5.1 が起動済みで実行中であることを確認します。

2. idsconfig を実行します。

   # /usr/lib/ldap/idsconfig

3. 表示される質問に答えます。ユーザー入力のデフォルトは「no」です。質問の詳細を表示する場合は次のように入力します。

   h

   すると、簡潔なヘルプが表示されます。

以下の idsconfig の実行例を参照する際、この章の冒頭の 「サーバーのインストール用チェックリストの作成」 で示したサーバーおよびクライアントのチェックリスト内の定義を使用してください。以下は、デフォルト設定の多くを変更しない単純な設定の例です。クライアントプロファイルを変更する最も複雑な方法は、SSD を作成する方法です。詳細については、「サービス検索記述子を使用してさまざまなサービスへのクライアントアクセスを変更する」を参照してください。

プロンプトの後のキャリッジリターンは、Enter キーを押してデフォルトの設定を受け入れたことを意味します。

例 15-1 Example, Inc. ネットワークでの idsconfig の実行

(sysadmin@test) [3:10pm] ns_ldap [31] % sh idsconfig.sh

It is strongly recommended that you BACKUP the directory server
before running idsconfig.sh.

Hit Ctrl-C at any time before the final confirmation to exit.

Do you wish to continue with server setup (y/n/h)? [n] Y

Enter the iPlanet Directory Server's (iPlanet Directory Server) 
hostname to setup: IPDSERVER

Enter the port number for iPlanet Directory Server (h=help): [389] 
Enter the directory manager DN: [cn=Directory Manager] 
Enter passwd for cn=Directory Manager : 
Enter the domainname to be served (h=help): [west.example.com] 
Enter LDAP Base DN (h=help): [dc=west,dc=example,dc=com] 
Enter the profile name (h=help): [default] 
Default server list (h=help): [192.168.0.0] 
Preferred server list (h=help): 
Choose desired search scope (one, sub, h=help):  [one] 
The following are the supported credential levels:
  1  anonymous
  2  proxy
  3  proxy anonymous
Choose Credential level [h=help]: [1] 2

The following are the supported Authentication Methods:
  1  none
  2  simple
  3  sasl/DIGEST-MD5
  4  tls:simple
  5  tls:sasl/DIGEST-MD5
Choose Authentication Method (h=help): [1] 2

Current authenticationMethod: simple

Do you want to add another Authentication Method? N

Do you want the clients to follow referrals (y/n/h)? [n] Y

Do you want to modify the server timelimit value (y/n/h)? [n] Y

Enter the time limit for iPlanet Directory Server (current=3600): [-1]

Do you want to modify the server sizelimit value (y/n/h)? [n] Y

Enter the size limit for iPlanet Directory Server (current=2000): [-1]

Do you want to store passwords in "crypt" format (y/n/h)? [n] Y

Do you want to setup a Service Authentication Methods (y/n/h)? [n]
Client search time limit in seconds (h=help): [30] 
Profile Time To Live in seconds (h=help): [43200] 

Bind time limit in seconds (h=help): [10] 2

Do you wish to setup Service Search Descriptors (y/n/h)? [n] 
 
              Summary of Configuration

  1  Domain to serve               : west.example.com
  2  Base DN to setup              : dc=west,dc=example,dc=com
  3  Profile name to create        : default
  4  Default Server List           : 192.168.0.0
  5  Preferred Server List         : 
  6  Default Search Scope          : one
  7  Credential Level              : proxy
  8  Authentication Method         : simple
  9  Enable Follow Referrals       : TRUE
 10  iPlanet Directory Server Time Limit                : -1
 11  iPlanet Directory Server Size Limit                : -1
 12  Enable crypt password storage : TRUE
 13  Service Auth Method pam_ldap  : 
 14  Service Auth Method keyserv   : 
 15  Service Auth Method passwd-cmd: 
 16  Search Time Limit             : 30
 17  Profile Time to Live          : 43200
 18  Bind Limit                    : 2
 19  Service Search Descriptors Menu

Enter config value to change: (1-19 0=commit changes) [0] 
Enter DN for proxy agent:[cn=proxyagent,ou=profile,dc=west,dc=example,dc=com]
Enter passwd for proxyagent: 
Re-enter passwd: 
 

WARNING: About to start committing changes. (y=continue, n=EXIT) Y

1. Changed timelimit to -1 in cn=config.
  2. Changed sizelimit to -1 in cn=config.
  3. Changed passwordstoragescheme to "crypt" in cn=config.
  4. Schema attributes have been updated.
  5. Schema objectclass definitions have been added.
  6. Created DN component dc=west.
  7. NisDomainObject added to dc=west,dc=example,dc=com.
  8. Top level "ou" containers complete.
  9. Nis maps: auto_home auto_direct auto_master auto_shared processed.
  10. ACI for dc=west,dc=example,dc=com modified to disable self modify.
  11. Add of VLV Access Control Information (ACI).
  12. Proxy Agent cn=proxyagent,ou=profile,dc=west,dc=example,dc=com added.
  13. Give cn=proxyagent,ou=profile,dc=west,dc=example,dc=com read permission for 
password.
  14. Generated client profile and loaded on server.
  15. Processing eq,pres indexes:
      ipHostNumber (eq,pres)   Finished indexing.                  
      uidNumber (eq,pres)   Finished indexing.                  
      ipNetworkNumber (eq,pres)   Finished indexing.                  
      gidnumber (eq,pres)   Finished indexing.                  
      oncrpcnumber (eq,pres)   Finished indexing.                  
  16. Processing eq,pres,sub indexes:
      membernisnetgroup (eq,pres,sub)   Finished indexing.                  
      nisnetgrouptriple (eq,pres,sub)   Finished indexing.                  
  17. Processing VLV indexes:
      getgrent vlv_index   Entry created
      gethostent vlv_index   Entry created
      getnetent vlv_index   Entry created
      getpwent vlv_index   Entry created
      getrpcent vlv_index   Entry created
      getspent vlv_index   Entry created

idsconfig.sh: Setup of iPlanet Directory Server server ipdserver is complete.


Note: idsconfig has created entries for VLV indexes.  Use the 
      directoryserver(1m) script on ipdserver to stop
      the server and then enter the following vlvindex
      sub-commands to create the actual VLV indexes:

  directoryserver -s ipdserver vlvindex -n userRoot -T getgrent
  directoryserver -s ipdserver vlvindex -n userRoot -T gethostent
  directoryserver -s ipdserver vlvindex -n userRoot -T getnetent
  directoryserver -s ipdserver vlvindex -n userRoot -T getpwent
  directoryserver -s ipdserver vlvindex -n userRoot -T getrpcent
  directoryserver -s ipdserver vlvindex -n userRoot -T getspent

サマリー画面で空欄になっているパラメータは設定されません。

idsconfig によるディレクトリの設定が完了したら、サーバー設定を完了してサーバーをクライアント対応にする前に、サーバー上で指定されたコマンドを実行する必要があります。

ldapaddent を使用したディレクトリサーバーの生成

pam_unix を使用している場合、データを使用してディレクトリサーバーを生成する前に、パスワードを Unix Crypt 形式で格納するようにサーバーを構成する必要があります。pam_ldap を使用している場合、任意の形式でパスワードを格納できます。UNIX crypt 形式でパスワードを設定する方法については、iPlanet Directory Server のドキュメントを参照してください。

ldapaddent(1M) は、LDAP ネームサービス用に構成済みのクライアントでのみ実行できます。

ldapaddent は、標準入力から (/etc/filename passwd など) データを読み取り、このデータをサービスに関連付けられたコンテナに配置します。クライアント構成により、デフォルトのデータ書き込み方法が決定されます。

次に示す例では、 ldapaddent にデータを指定してサーバーを生成します。

例 15-2 ldapaddent およびユーザーパスワードデータを使用して iPlanet Directory Server 5.1 を生成する方法

1. ldapaddent コマンドを使用して、 /etc/passwd エントリをサーバーに追加します。

   # ldapaddent -D "cn=directory manager" -f /etc/passwd passwd

ldapaddent(1M) のマニュアルページを参照してください。LDAP セキュリティおよび Directory Server への書き込みアクセスの詳細については、第 13 章「基本コンポーネントおよび概念 (概要) 」を参照してください。

プリンタエントリの管理

プリンタの追加

プリンタエントリを LDAP ディレクトリに追加する場合、 printmgr 構成ツールまたは lpset -n ldap コマンド行ユーティリティを使用します。詳細については、lpset(1M) のマニュアルページを参照してください。ディレクトリに追加されるプリンタオブジェクトは、プリンタの印刷システムクライアントが必要とする接続パラメータのみを定義することに留意してください。ローカルのプリントサーバー構成データはファイル内に保持されます。典型的なプリンタエントリは、次のようになります。

printer-uri=myprinter,ou=printers,dc=mkg,dc=example,dc=com
objectclass=top
objectclass=printerService
objectclass=printerAbstract
objectclass=sunPrinter
printer-name=myprinter
sun-printer-bsdaddr=printsvr.example.com,myprinter,Solaris
sun-printer-kvp=description=HP LaserJet (PS)
printer-uri=myprinter

lpget の使用

lpget(1M) を使用して、LDAP クライアントの LDAP ディレクトリが認識するプリンタエントリすべてをリスト表示できます。LDAP クライアントの LDAP サーバーが複製サーバーの場合、更新複製規約 (update replication agreement) によって、リスト表示されたプリンタはマスター LDAP サーバーのプリンタと同じ場合も同じでない場合もあります。詳細については、lpget(1M) のマニュアルページを参照してください。

たとえば、指定されたベース DN のプリンタすべてを一覧表示するには、次のように入力します。

# lpget -n ldap list

myprinter:
	dn=myprinter,ou=printers,dc=mkt,dc=example,dc=com
	bsdaddr=printsvr.example.com,myprinter,Solaris
	description=HP LaserJet (PS)

追加プロファイルを使用してサーバーを生成する

ldapclient を genprofile オプションとともに使用すると、指定された属性に基づいて、構成プロファイルの LDIF 表現を作成できます。次に、作成したプロファイルを LDAP サーバーにロードして、クライアントプロファイルとして使用できます。クライアントは、ldapclient init を使用してこのファイルをダウンロードできます。

ldapclient genprofile の使用方法の詳細については、ldapclient(1M) のマニュアルページを参照してください。

以下の例では、ldapclient とともに追加プロファイルを指定して、サーバーを生成します。

例 15-3 追加プロファイルを使用してサーバーを生成する方法

1. スーパーユーザーになります。

2. ldapclient コマンドを genprofile コマンドとともに使用します。

   # ldapclient genprofile -a profileName=myprofile \

   -a defaultSearchBase=dc=west,dc=example,dc=com \

   -a "defaultServerList=192.168.0.0 192.168.0.1:386" \

   > myprofile.ldif

3. 新規プロファイルをサーバーにアップロードします。

   # ldapadd -h 192.168.0.0 -D "cn=directory manager" -f myprofile.ldif

第 16 章 クライアントの設定 (手順)

この章では、Solaris LDAP ネームサービスクライアントの設定方法について説明します。

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

• 「前提条件」

• 「クライアントの初期設定」

• 「プロファイルを使用してクライアントを初期化する」

• 「プロキシの資格を使用する」

• 「クライアントを手動で初期設定する」

• 「手動によるクライアント構成を変更する」

• 「クライアントの初期設定を解除する」

• 「TLS セキュリティの設定」

前提条件

Solaris クライアントで LDAP をネームサービスとして使用するためには、次の要件が満たされている必要があります。

• クライアントのドメイン名が LDAP サーバーによって処理される

• nsswitch.conf ファイルが、必要なサービスの LDAP を指している。nsswitch.conf ファイルについては、第 2 章「ネームサービススイッチ (概要)」を参照

• クライアントが、その動作を定義するための特定のパラメータをすべて使って構成されている

• ldap_cachemgr がクライアントで実行されている

• クライアントが構成されているサーバーが 1 つ以上起動され、実行されている

ldapclient ユーティリティは、サーバーの起動を除き、上記の手順をすべて実行するので、LDAP クライアントを設定するための鍵となります。この章の後半では、ldapclient ユーティリティを使用して LDAP クライアントを設定する方法や、それ以外の各種 LDAP ユーティリティを使用して LDAP クライアントに関する情報を取得したり LDAP クライアントの状態をチェックしたりする方法について、例を挙げて説明します。

クライアントの初期設定

ldapclient(1M) は、Solaris オペレーティング環境で LDAP クライアントを設定するためのユーティリティです。ldapclient ユーティリティでは、サーバーがすでに適切なクライアントプロファイルで構成されていることを前提としています。サーバーをインストールして、適切なプロファイルで構成してからクライアントを設定する必要があります。

ldapclient を使用してクライアントを設定するには、次の 2 つの方法があります。

• 「プロファイル」

  少なくとも、使用するプロファイルとドメインを含むサーバーアドレスを指定する必要があります。プロファイルが指定されていない場合は、デフォルトのプロファイルが使用されます。プロキシと認証データベースの情報を除いて、必要な情報はサーバーから入手できます。クライアントの資格レベルがプロキシまたは匿名プロキシである場合は、プロキシのバインド DN とパスワードを入力する必要があります。詳細については、「クライアント資格レベルの割り当て」を参照してください。

• 「手動」

  クライアント自体でプロファイルを設定します。つまり、コマンド行からすべてのパラメータを定義します。このため、プロファイル情報はキャッシュファイルに格納されサーバーによってリフレッシュされることはありません。

クライアントを手動で構成することも可能ですが、お勧めしません。構成用のプロファイルを使用すると、クライアントの管理が容易になりコストも削減できます。

プロファイルを使用してクライアントを初期化する

プロファイルを使用してクライアントを初期化する方法

1. スーパーユーザーになります。

2. init を指定して ldapclient を実行します。

   # ldapclient init -a profileName=new -a \

   domainName=west.example.com 192.168.0.0

   System successfully configured

プロキシの資格を使用する

プロキシの資格を使用してクライアントを初期化する方法

1. スーパーユーザーになります。

2. ldapclient を実行します (プロキシ値を定義します)。

   # ldapclient init -a proxyDn=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com -a domainname=west.example.com -a profilename=pit1 -a proxypassword=test1234 192.168.0.0

   System successfully configured

使用するプロファイルがプロキシ用に設定されている場合は、-a proxyDn と -a proxypassword が必須です。 サーバーに保存されているプロファイルにはこの資格情報が含まれていないため、クライアントを初期設定するときは資格情報を入力する必要があります。この方法は、プロキシの資格情報をサーバーに保存していた従来の方法に比べて安全性が高くなります。

プロキシ情報は /var/ldap/ldap_client_cred の作成に使用され、それ以外の情報は/var/ldap/ldap_client_file に格納されます。

どちらのクライアント構成ファイルも直接編集しないでください。これらのファイルの内容を作成または変更する場合は、ldapclient を使用してください。

クライアントを手動で初期設定する

スーパーユーザーは、クライアントの構成を手動で行うことができます。ただし、この処理では多数のチェックが省略されるため、システムを正しく構成できないことがよくあります。また、プロファイルを使用するときのように一括に設定するのではなく、「マシンごとに」設定を変更する必要があります。

クライアントを手動で初期設定する方法

1. スーパーユーザーになります。

2. ldapclient manual を実行します。

   # ldapclient manual -a domainName=dc=west.example.com \

   -a credentialLevel=proxy -a defaultSearchBase=dc=west, dc=example, dc=com \

   -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \

   -a proxyPassword=testtest 192.168.0.0

3. ldapclient list を使用して確認します。

   NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 192.168.0.0 NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com NS_LDAP_CREDENTIAL_LEVEL= proxy

手動によるクライアント構成を変更する

手動による構成を変更する方法

1. スーパーユーザーになります。

2. ldapclient mod を実行して、認証方法を simple に変更します。

   # ldapclient mod -a authenticationMethod=simple

3. ldapclient list を実行して、更新が行われたことを確認します。

   # ldapclient list

   NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 192.168.0.0 NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com NS_LDAP_AUTH= simple NS_LDAP_CREDENTIAL_LEVEL= proxy

クライアントの初期設定を解除する

クライアントの初期設定を解除する方法

1. スーパーユーザーになります。

2. ldapclient uninit を実行します。

   # ldapclient uninit

   System successfully recovered

ldapclient uninit コマンドは、クライアントのネームサービスを元の状態 (init、modify、または manual の最後の操作が行われる前の状態) に復元します。言い換えれば、最後に行われた手順を「元に戻します」。たとえば、profile1 を使用するようにクライアントを設定した後で profile2 を使用するように変更した場合、ldapclient uninit を実行すると、クライアントで profile1 を使用するように設定が元に戻ります。

TLS セキュリティの設定

cert7.db と key3.db の各ファイルには、どのユーザーも読み取り権が必要です。key3.db ファイルに非公開鍵を含めないようにしてください。

TLS を使用する場合は、必要なセキュリティデータベースをインストールしなければなりません。特に、cert7.db と key3.db の両ファイルは必須です。cert7.db ファイルには、信頼できる認証のデータベースが入ります。key3.db ファイルには、クライアントの鍵が入ります。LDAP ネームサービスクライアントではクライアントの鍵を使用しませんが、このファイルは必要です。

ldapclient を実行する前に、この節に記述されている必要なセキュリティデータベースファイルを設定およびインストールしておく必要があります。

これらのファイルを作成および管理する方法については、『iPlanet Directory Server 5.1 管理者ガイド』のLDAP クライアントの構成に関する節を参照してください。これらのファイルを構成したら、LDAP ネームサービスクライアントで使用できるように所定の場所にそれらを格納する必要があります。この場所を判断するために、属性 certificatePath が使用されます。この属性はデフォルトで /var/ldap です。

たとえば、Netscape Communicator を使用して必要な cert7.db ファイルと key3.db ファイルを設定した後で、それらのファイルをデフォルトの位置にコピーします。

# cp $HOME/.netscape/cert7.db /var/ldap

# cp $HOME/.netscape/key3.db /var/ldap

次に、すべてのユーザーに読み取り権を付与します。

# chmod 444 /var/ldap/cert7.db

# chmod 444 /var/ldap/key3.db

Netscape では、cert7.db とkey3.db の各ファイルを $HOME/.netscape ディレクトリで管理します。このため、それらのセキュリティデータベースを LDAP ネームサービスクライアントで使用する場合は、そのコピーをローカルファイルシステム上に格納する必要があります。

PAM を構成する

pam_ldap を使用する場合は、「pam_ldap に対応した pam.conf ファイルの例 」に説明されている pam.conf ファイルの例に従って、pam_ldap.so.1 が含まれる行をクライアントの /etc/pam.conf ファイルに追加します。pam_ldap.so.1 が含まれる行がすべて必要なわけではありません。pam_ldap を必要とするコマンド、ログイン、パスワードなどに関するセクションだけが変更の対象となります。詳細については、pam.conf(4) のマニュアルページを参照してください。

ネームサービス情報の検出

ldaplist を使用する

ldaplist は、LDAP サーバーから取得したネームサービス情報を LDIF フォーマットで表示する LDAP ユーティリティです。このユーティリティは、障害追跡に役立ちます。詳細については、ldaplist(1) のマニュアルページを参照してください。

すべての LDAP コンテナを表示する

ldaplist は、レコードを空行で区切って出力を表示します。この表示方法は、複数行にまたがる大きなレコードに有効です。

ldaplist の出力は、クライアントの構成によって変わります。たとえば、ns_ldap_search の値が one ではなく sub である場合は、ldaplist によって現在の検索 baseDN の下にあるエントリがすべて表示されます。

以下に ldaplist の出力例を示します。

# ldaplist

dn: ou=people,dc=west,dc=example,dc=com

dn: ou=group,dc=west,dc=example,dc=com

dn: ou=rpc,dc=west,dc=example,dc=com

dn: ou=protocols,dc=west,dc=example,dc=com

dn: ou=networks,dc=west,dc=example,dc=com

dn: ou=netgroup,dc=west,dc=example,dc=com

dn: ou=aliases,dc=west,dc=example,dc=com

dn: ou=hosts,dc=west,dc=example,dc=com

dn: ou=services,dc=west,dc=example,dc=com

dn: ou=ethers,dc=west,dc=example,dc=com

dn: ou=profile,dc=west,dc=example,dc=com

dn: automountmap=auto_home,dc=west,dc=example,dc=com

dn: automountmap=auto_direct,dc=west,dc=example,dc=com

dn: automountmap=auto_master,dc=west,dc=example,dc=com

dn: automountmap=auto_shared,dc=west,dc=example,dc=com

すべてのユーザーエントリ属性を表示する

ユーザーの passwd エントリなど特定の情報を表示する場合は、次のように getent を使用します。

# getent passwd user1

user1::30641:10:Joe Q. User:/home/user1:/bin/csh

すべての属性を表示する場合は、-l オプションを指定して ldaplist コマンドを実行します。

# ldaplist -l passwd user1

dn: uid=user1,ou=People,dc=west,dc=example,dc=com
        uid: user1
        cn: user1
        uidNumber: 30641
        gidNumber: 10
        gecos: Joe Q. User
        homeDirectory: /home/user1
        loginShell: /bin/csh
        objectClass: top
        objectClass: shadowAccount
        objectClass: account
        objectClass: posixAccount
        shadowLastChange: 6445
        userPassword: {crypt}J6vlYXRU.sW8c

クライアント環境のカスタマイズ

クライアント環境では、必要に応じて 2 種類のカスタマイズを行うことができます。

nsswitch.conf ファイルを変更する

/etc/nsswitch.conf ファイルを変更して、各サービスが情報を取得する場所をカスタマイズできます。デフォルトの設定は /etc/nsswitch.ldap に保存されており、クライアントの初期化時に ldapclient がこのファイルを使って /etc/nsswitch.conf ファイルを作成します。

/etc/resolv.conf ファイルを設定して DNS を使用可能にする場合は、次に示すように、DNS をhosts 行に追加します。

hosts:      ldap dns [NOTFOUND=return] files

どのサービスも変更できますが注意が必要です。変更したサービスのデータがサーバー上に生成されない場合、カスタマイズは無効になります。さらに、ファイルがデフォルトで設定されない場合もあります。

第 17 章 LDAP 構成に関する障害追跡

この章では、LDAP の構成で発生する問題とその解決方法を示します。

クライアントステータスの監視

この節では、LDAP クライアント環境の状態判定に使用するさまざまなコマンドを紹介します。詳細については、一般的な問題とその解決方法について解説した、障害追跡に関する節を参照してください。使用可能なオプションの詳細については、マニュアルページも参照してください。

ldap_cachemgr が実行中であることを確認する

ldap_cachemgr デーモンは、常に実行中で適切に機能している必要があります。このデーモンが機能していない場合、意図した動作はまったく実行されません。ldap_cachemgr の動作を確認するには、次の 2 つの方法があります。

• ps -ef を使用する

  # ps -ef | grep ldap_cachemgr

• -g オプションを ldap_cachemgr に渡す

  この操作により、次の状態情報がダンプされます。この情報は問題を診断する際に役立ちます。

  # /usr/lib/ldap/ldap_cachemgr -g

  cachemgr configuration: server debug level 0 server log file "/var/ldap/cachemgr.log" number of calls to ldapcachemgr 19 cachemgr cache data statistics: Configuration refresh information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:43:28 Server information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:36:08 server: 192.168.0.0, status: UP server: 192.168.0.1, status: ERROR error message: Can't connect to the LDAP server Cache data information: Maximum cache entries: 256 Number of cache entries: 2

現在のプロファイル情報の確認

スーパーユーザーになり、ldapclient を list オプションを付けて実行します。

# ldapclient list

NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com
NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f
NS_LDAP_SERVERS= 192.168.0.0, 192.168.0.1
NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_REF= TRUE
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_SERVER_PREF= 192.168.0.0
NS_LDAP_PROFILE= pit1
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:ou=group,dc=west,dc=example,dc=com?one
NS_LDAP_BIND_TIME= 5

/var/ldap ファイルは現在 ASCII 形式ですが、バイナリに変更される可能性があるため、このファイルに対して cat コマンドを実行すると問題が発生する可能性があります。この情報へのアクセスにサポートされている方式は、ldapclient list です。

基本的なクライアント/サーバー間通信の検証

クライアントが LDAP サーバーに対して通信を行なっていることを確認する最善の方法は、ldaplist コマンドを使用することです。引数を付けずに ldaplist だけを指定して実行すると、サーバー上のすべてのコンテナがダンプされます。この方法はコンテナが存在している限り可能で、コンテナを生成する必要がありません。最初の手順が成功したら、ldaplist passwd username または ldaplist hosts hostname を実行できますが、大量のデータが含まれている場合には、生成量の少ないサービスを選ぶか、head や more コマンドを使用してデータをパイプ処理することもできます。

クライアント以外のマシンからのサーバーデータの確認

前述のコマンドの大半は、LDAP クライアントであることを前提としています。クライアントを作成していない状態でサーバー上のデータをチェックする場合は、ldapsearch コマンドを使用します。次の例では、すべてのコンテナをリスト表示します。

# ldapsearch -h server1 -b "dc=west,dc=example,dc=com" -s one "objectclass=*"

構成で発生する問題とその解決方法

LDAP の構成で発生する問題とそれらの解決方法について説明します。

未解決のホスト名

Solaris オペレーティング環境 LDAP クライアントのバックエンドは、ホストの検索で、gethostbyname(3N) や getipnodebyname(3N) の場合と同様、完全指定ホスト名を返します。格納済みの名前が指定されている (1 つ以上のドットが含まれている) 場合、クライアントはその名前をそのまま返します。たとえば、格納されている名前が hostB.eng であれば、返される名前も hostB.eng です。

LDAP ディレクトリに格納された名前が指定されていない (ドットが 1 つも含まれない) 場合、クライアントのバックエンドは、その名前にドメイン部分を追加します。たとえば、格納されている名前が hostA であれば、返される名前は hostA.domainname となります。

LDAP ドメイン内のシステムに遠隔アクセスできない

DNS ドメイン名が LDAP ドメイン名とは異なる場合、格納されたホスト名が完全指定でない限り LDAP ネームサービスをホスト名に対して使用することはできません。

ログインできない

LDAP クライアントは、ログイン時に pam(3) モジュールを使用してユーザーを認証します。UNIX^TM 標準の PAM モジュールでは、パスワードをサーバーから読み込みクライアント側で検査します。この動作は、次のいずれかの理由で失敗する場合があります。

1. /etc/nsswitch.conf ファイル内の passwd サービスが ldap を使用しない

2. プロキシエージェントが、サーバーリスト上のユーザーの userPassword 属性を読み取ることができない。プロキシエージェントが比較のためにパスワードをクライアントに返すので、少なくともプロキシエージェントはパスワードを読めなければならない。pam_ldap に関しては、パスワードへの読み取りアクセスを必要としない

3. プロキシエージェントが適切なパスワードを保持していない

4. 該当するエントリに shadowAccount オブジェクトクラスが定義されていない

5. ユーザーの定義済みパスワードが存在しない

   ldapaddent を使用する場合、 -p オプションを使用してパスワードをユーザーエントリに確実に追加する必要があります。ldapaddent を -p オプションなしで実行した場合、ldapaddent を使用して /etc/shadow ファイルを追加しない限り、ユーザーのパスワードはディレクトリに格納されません。

6. どの LDAP サーバーにもアクセスできない

   サーバーの状態を確認します。

   # /usr/lib/ldap/ldap_cachemgr -g

7. pam_conf の構成が不正である

8. LDAP 名前空間でユーザーが定義されていない

9. pam_unix で NS_LDAP_CREDENTIAL_LEVEL が anonymous に設定されており、匿名ユーザーが userPassword 属性を使用できない

10. パスワードが crypt 形式で格納されていない

検索が遅い

LDAP データベースは、パフォーマンス向上にインデックスを使用します。インデックスが正しく作成されていない場合、大幅にパフォーマンスが低下することがあります。このマニュアルの中に、インデックス付けが必要な一連の属性をまとめてあります。また、独自のインデックスを追加して、パフォーマンスの向上を図ることができます。

ldapclient がサーバーにバインドできない

init プロファイルオプションを使用しているときに、ldapclient がクライアントの初期化に失敗しました。これには、いくつかの原因が考えられます。

1. コマンド行で不正なドメイン名が指定された

2. 指定されたクライアントドメインのエントリポイントを表す nisDomain 属性が DIT (ディレクトリ情報ツリー) 内に設定されていない

3. アクセス制御情報がサーバー上で適正に設定されていないため、LDAP データベース内の匿名検索が許可されない

4. ldapclient コマンドに渡されたサーバーアドレスが間違っている。ldapsearch(1) を使用してサーバーのアドレスを確認する

5. ldapclient コマンドに渡されたプロファイル名が間違っている。ldapsearch(1) を使用して、DIT 内のプロファイル名を確認する

6. クライアントのネットワークインタフェースに対して snoop(1M) を実行して外向きのトラフィックを検査し、どのサーバーと通信しているかを確認する

デバッグに ldap_cachemgr を使用する

ldap_cachemgr を -g オプションをつけて使用すると、現在のクライアント構成および統計を表示できるため、デバッグするのに便利です。たとえば、次のように指定します。

# ldap_cachemgr -g

この結果、すでに説明したように、すべての LDAP サーバーの状態を含む現在のクライアント構成および統計が標準出力に出力されます。このコマンドを実行するのに、スーパーユーザーになる必要はありません。

セットアップ中に ldapclient がハングアップする

ldapclient コマンドがハングアップした場合、Ctrl-C キーを押すと以前の環境を復元した後で終了します。この状況が発生する場合、サーバーが動作していることをサーバー管理者に確認してください。

プロファイルまたはコマンド行に指定されたサーバーリスト属性で、サーバー情報が適正であることを確認してください。

FAQ (よくある質問)

以前の Solaris リリースで LDAP ネームサービスを使用できますか

現在のところ、LDAP は Solaris 8 および Solaris 9 でのみサポートされています。Solaris 8 と Solaris 9 との相違点については、「Solaris 9 LDAP ネームサービスの新機能」 を参照してください。

Solaris LDAP ネームサービスでの DIT のデフォルト位置を教えてください

「デフォルトのディレクトリ情報ツリー (DIT)」を参照してください。

第 18 章 一般的なリファレンス

1. 「未記入のチェックリスト」

2. 「アップグレード情報」

3. 「LDAP コマンド」

4. 「pam_ldap に対応した pam.conf ファイルの例 」

5. 「IETF スキーマ」

6. 「ディレクトリユーザーエージェントのプロファイル (DUAProfile) スキーマ」

7. 「Solaris スキーマ」

8. 「Internet Printing Protocol 情報」

9. 「汎用ディレクトリサーバーの要件」

10. 「LDAP ネームサービスで使用されるデフォルトフィルタ」

未記入のチェックリスト

アップグレード情報

Solaris 9 クライアントは、Solaris 8 クライアント用に設定されたディレクトリサーバーと完全な互換性があります。ldapclient(1M) は、この種のプロファイルをダウンロードしてバージョン 1 のプロファイルを使用してクライアントを構成できます。ただし、Solaris 9 の新機能を利用して新規セキュリティモデルを使用するには、バージョン 2 のプロファイルを使用する必要があります。

サーバーは、旧クライアントと新クライアントの混在環境に対応します。このため、スキーママッピングが無効でバージョン 2 のプロファイルが serviceSearchDescriptors 内の特殊フィルタを使用しない構成になっている限り、どちらのクライアントでも同じ結果を得ることができます。サーバーがデフォルトスキーマを使用しない場合、Solaris 8 クライアントはスキーマを任意に対応づけできないため、旧クライアントはそのサーバーを利用できません。

考慮する必要のあるもう 1 つの追加変更は、Solaris 8 では ldap_cachemgr() を実行するクライアントは推奨されず、オプションであったのに対し、Solaris 9 では ldap_cachemgr() を「常に実行する必要がある」という点です。このデーモンは、クライアントが適正に動作するために「必須」です。

新しい自動マウントスキーマ

Solaris 9 はデフォルトで、Solaris 8 クライアントの使用する汎用の NIS マップスキーマではなく、自動マウントエントリ用の新規スキーマを使用します。このため Solaris 9 ツールを使用してサーバーを設定した場合、Solaris 8 クライアントから自動マウントエントリを表示できなくなります。サイトで Solaris 9 と Solaris 8 クライアントの両方に対応するサーバーを設定する場合、自動マウントエントリを追加する前に、プロファイルを作成してスキーマを以前のスキーマに対応づけてください。この操作により、ldapaddent(1M) が、以前のスキーマを使用してエントリを追加することが保証されます。ただし、すべての Solaris 9 クライアントで、自動マウント用スキーマが対応づけされたプロファイルを使用する必要があることに注意してください。

このマッピングを有効にするため、次のマッピング属性をプロファイルに追加する必要があります。

attributeMap: 		automount:automountMapName=nisMapName
attributeMap: 		automount:automountKey=cn
attributeMap: 		automount:automountInformation=nisMapEntry
objectclassMap: 	  automount:automountMap=nisMap
objectclassMap: 	  automount:automount=nisObject

LDAP コマンド

Solaris には、LDAP 関連のコマンドセットが 2 つ存在します。1 つのセットは一般的な LDAP ツールで、LDAP ネームサービスを使用してクライアントを構成する必要はありません。もう 1 つのセットはクライアント上の共通 LDAP 構成を使用するため、クライアントがネームサービスに LDAP を使用する場合にのみ使用できます。

一般的な LDAP ツール

LDAP コマンド行ツールは、認証やバインドパラメータを含む、一般的なオプションセットをサポートします。

これらのコマンドを使用して、ディレクトリエントリを直接操作できます。ldapsearch(1)、ldapmodify(1)、ldapadd(1)、ldapdelete(1) の各ツールは、LDAP データ交換フォーマット (LDIF) と呼ばれる共通の書式をサポートしています。LDIF は、ディレクトリ情報を表現するテキストベースの書式です。

LDAP ネームサービスを必要とする LDAP ツール

pam_ldap に対応した pam.conf ファイルの例

#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login   auth required           pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_dial_auth.so.1
login   auth sufficient         pam_unix_auth.so.1
login   auth required           pam_ldap.so.1 try_first_pass
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin  auth sufficient         pam_rhosts_auth.so.1
rlogin  auth required           pam_authtok_get.so.1
rlogin  auth required           pam_dhkeys.so.1
rlogin  auth sufficient         pam_unix_auth.so.1
rlogin  auth required           pam_ldap.so.1 try_first_pass
#
# rsh service (explicit because of pam_rhost_auth)
#
rsh     auth sufficient         pam_rhosts_auth.so.1
rsh     auth required           pam_authtok_get.so.1
rsh     auth required           pam_dhkeys.so.1
rsh     auth sufficient         pam_unix_auth.so.1
rsh     auth required           pam_ldap.so.1 try_first_pass
#
# PPP service (explicit because of pam_dial_auth)
#
ppp     auth required           pam_authtok_get.so.1
ppp     auth required           pam_dhkeys.so.1
ppp     auth required           pam_dial_auth.so.1
ppp     auth sufficient         pam_unix_auth.so.1
ppp     auth required           pam_ldap.so.1 try_first_pass
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authenctication

#
other   auth required           pam_authtok_get.so.1
other   auth required           pam_dhkeys.so.1
other   auth sufficient         pam_unix_auth.so.1
other   auth required           pam_ldap.so.1 try_first_pass
#
# passwd command (explicit because of a different authentication module)

#
passwd  auth sufficient         pam_passwd_auth.so.1
passwd  auth required           pam_ldap.so.1  try_first_pass
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron    account required        pam_projects.so.1
cron    account required        pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account
management
#
other   account requisite       pam_roles.so.1
other   account required        pam_projects.so.1
other   account required        pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session
management
#
other   session required        pam_unix_session.so.1
#
# Default definition for  Password management
# Used when service name is not explicitly mentioned for password
management
#
other   password required       pam_dhkeys.so.1
other   password required       pam_authtok_get.so.1
other   password required       pam_authtok_check.so.1
other   password sufficient     pam_authtok_store.so.1
other   password required       pam_ldap.so.1
#
# Support for Kerberos V5 authentication (uncomment to use Kerberos)
#
#rlogin         auth optional           pam_krb5.so.1 try_first_pass
#login          auth optional           pam_krb5.so.1 try_first_pass
#other          auth optional           pam_krb5.so.1 try_first_pass
#cron           account optional        pam_krb5.so.1
#other          account optional        pam_krb5.so.1
#other          session optional        pam_krb5.so.1
#other          password optional       pam_krb5.so.1 try_first_pass

IETF スキーマ

スキーマは、サーバーのディレクトリ内にエントリとして格納可能な情報タイプを記述した定義です。

ディレクトリサーバーが Solaris 9 LDAP ネームサービスクライアントをサポートするには、クライアントのスキーママッピング機能を使用してスキーマをマッピングしていない限り、この章で定義されたスキーマをサーバー内で構成する必要があります。

IETF により定義された 4 つの必須 LDAP スキーマ (RFC 2307 ネットワーク情報サービススキーマ、LDAP メールグループインターネットドラフト、および LDAP Internet Printing Protocol (IPP) ドラフトスキーマ) が存在します。ネーム情報サービスをサポートするには、これらのスキーマ定義をディレクトリサーバーに追加する必要があります。IETF Web サイト http://www.ietf.org で、さまざまな RFC にアクセスできます。

インターネットドラフトとは、最長 6 ヶ月間有効なドラフトの文書で、他の文書によっていつでも更新または廃止される可能性があります。

RFC 2307 ネットワーク情報サービススキーマ

LDAP サーバーは改訂版 RFC 2307 をサポートするように構成する必要があります。

nisSchema OID は 1.3.6.1.1 です。RFC 2307 属性を次に示します。

( nisSchema.1.0 NAME 'uidNumber'
DESC 'An integer uniquely identifying a user in an
		administrative domain'
EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.1 NAME 'gidNumber'
DESC 'An integer uniquely identifying a group in an
		administrative domain'
EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.2 NAME 'gecos'
DESC 'The GECOS field; the common name'
EQUALITY caseIgnoreIA5Match
SUBSTRINGS caseIgnoreIA5SubstringsMatch
SYNTAX 'IA5String' SINGLE-VALUE )
 
( nisSchema.1.3 NAME 'homeDirectory'
DESC 'The absolute path to the home directory'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' SINGLE-VALUE )
 
( nisSchema.1.4 NAME 'loginShell'
DESC 'The path to the login shell'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' SINGLE-VALUE )
 
( nisSchema.1.5 NAME 'shadowLastChange'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.6 NAME 'shadowMin'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.7 NAME 'shadowMax'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.8 NAME 'shadowWarning'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.9 NAME 'shadowInactive'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.10 NAME 'shadowExpire'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.11 NAME 'shadowFlag'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.12 NAME 'memberUid'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String' )
 
( nisSchema.1.13 NAME 'memberNisNetgroup'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String' )
 
( nisSchema.1.14 NAME 'nisNetgroupTriple'
DESC 'Netgroup triple'
SYNTAX 'nisNetgroupTripleSyntax' )
 
( nisSchema.1.15 NAME 'ipServicePort'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.16 NAME 'ipServiceProtocol'
SUP name )
 
( nisSchema.1.17 NAME 'ipProtocolNumber'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.18 NAME 'oncRpcNumber'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )

( nisSchema.1.19 NAME 'ipHostNumber'
DESC 'IP address as a dotted decimal, eg. 192.168.1.1
	     omitting leading zeros'
SUP name )
 
( nisSchema.1.20 NAME 'ipNetworkNumber'
DESC 'IP network as a dotted decimal, eg. 192.168,
     	omitting leading zeros'
SUP name SINGLE-VALUE )
 
( nisSchema.1.21 NAME 'ipNetmaskNumber'
DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
	      omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )
 
( nisSchema.1.22 NAME 'macAddress'
DESC 'MAC address in maximal, colon separated hex
      notation, eg. 00:00:92:90:ee:e2'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' )
 
( nisSchema.1.23 NAME 'bootParameter'
DESC 'rpc.bootparamd parameter'
SYNTAX 'bootParameterSyntax' )
 
( nisSchema.1.24 NAME 'bootFile'
DESC 'Boot image name'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' )
 
( nisSchema.1.26 NAME 'nisMapName'
SUP name )
 
( nisSchema.1.27 NAME 'nisMapEntry'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String{1024}' SINGLE-VALUE )
 
( nisSchema.1.28 NAME 'nisPublicKey'
DESC 'NIS public key'
SYNTAX 'nisPublicKeySyntax' )
 
( nisSchema.1.29 NAME 'nisSecretKey'
DESC 'NIS secret key'
SYNTAX 'nisSecretKeySyntax' )
 
( nisSchema.1.30 NAME 'nisDomain'
DESC 'NIS domain'
SYNTAX 'IA5String' )

( nisSchema.1.31 NAME 'automountMapName'
DESC 'automount Map Name'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

( nisSchema.1.32 NAME 'automountKey'
DESC 'Automount Key value'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

( nisSchema.1.33 NAME 'automountInformation'
DESC 'Automount information'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

nisSchema OID は 1.3.6.1.1 です。RFC 2307 objectClasses を次に示します。

( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY
  DESC 'Abstraction of an account with POSIX attributes'
  MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
  MAY ( userPassword $ loginShell $ gecos $ description ) )
 
( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY
  DESC 'Additional attributes for shadow passwords'
  MUST uid
  MAY ( userPassword $ shadowLastChange $ shadowMin
        shadowMax $ shadowWarning $ shadowInactive $
        shadowExpire $ shadowFlag $ description ) )
 
( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
  DESC 'Abstraction of a group of accounts'
  MUST ( cn $ gidNumber )
  MAY ( userPassword $ memberUid $ description ) )
 
( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL
  DESC 'Abstraction an Internet Protocol service.
        Maps an IP port and protocol (such as tcp or udp)
        to one or more names; the distinguished value of
        the cn attribute denotes the service's canonical
        name'
  MUST ( cn $ ipServicePort $ ipServiceProtocol )
  MAY ( description ) )
 
( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
  DESC 'Abstraction of an IP protocol. Maps a protocol number
        to one or more names. The distinguished value of the cn
        attribute denotes the protocol's canonical name'
  MUST ( cn $ ipProtocolNumber )
  MAY  description )
 
( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL
  DESC 'Abstraction of an Open Network Computing (ONC)
        [RFC1057] Remote Procedure Call (RPC) binding.
        This class maps an ONC RPC number to a name.
        The distinguished value of the cn attribute denotes
        the RPC service's canonical name'
  MUST ( cn $ oncRpcNumber $ description )
  MAY  description )
 
( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY
  DESC 'Abstraction of a host, an IP device. The distinguished
        value of the cn attribute denotes the host's canonical
        name. Device SHOULD be used as a structural class'
  MUST ( cn $ ipHostNumber )
  MAY ( l $ description $ manager $ userPassword ) )
 
( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
  DESC 'Abstraction of a network. The distinguished value of
        the cn attribute denotes the network's canonical name'
  MUST ipNetworkNumber
  MAY ( cn $ ipNetmaskNumber $ l $ description $ manager ) )
 
( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
  DESC 'Abstraction of a netgroup. May refer to other netgroups'
  MUST cn
  MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )

( nisSchema.2.9 NAME 'nisMap' SUP top STRUCTURAL
  DESC 'A generic abstraction of a NIS map'
  MUST nisMapName
  MAY description )
 
( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL
  DESC 'An entry in a NIS map'
  MUST ( cn $ nisMapEntry $ nisMapName )
  MAY description )

( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY
  DESC 'A device with a MAC address; device SHOULD be
        used as a structural class'
  MAY macAddress )
 
( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY
  DESC 'A device with boot parameters; device SHOULD be
  used as a structural class'
  MAY ( bootFile $ bootParameter ) )
 
( nisSchema.2.14 NAME 'nisKeyObject' SUP top AUXILIARY
  DESC 'An object with a public and secret key'
  MUST ( cn $ nisPublicKey $ nisSecretKey )
  MAY ( uidNumber $ description ) )
 
( nisSchema.2.15 NAME 'nisDomainObject' SUP top AUXILIARY
  DESC 'Associates a NIS domain with a naming context'
  MUST nisDomain )

( nisSchema.2.16 NAME 'automountMap' SUP top STRUCTURAL
  MUST ( automountMapName )
  MAY description )

( nisSchema.2.17 NAME 'automount' SUP top STRUCTURAL
  DESC 'Automount information'
  MUST ( automountKey $ automountInformation )
  MAY description )

メール別名スキーマ

メール別名情報は、LDAP メールグループインターネットドラフト (正式には draft-steinback-ldap-mailgroups として知られる) で定義されたスキーマを使用します。新しいスキーマが使用可能になるまで、Solaris LDAP クライアントは、このメール別名情報のスキーマの使用を続けます。

インターネットドラフトに定義された LDAP メールグループスキーマには、多数の属性とオブジェクトクラスが含まれています。このうち、Solaris クライアントが使用するのは、2 つの属性と 1 つのオブジェクトクラスだけです。以下にその内容を示します。

メール別名属性を次に示します。

( 0.9.2342.19200300.100.1.3
  NAME 'mail'
  DESC 'RFC822 email address for this person'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String(256)'
  SINGLE-VALUE )
 
( 2.16.840.1.113730.3.1.30
  NAME 'mgrpRFC822MailMember'
  DESC 'RFC822 mail address of email only member of group'
  EQUALITY CaseIgnoreIA5Match
  SYNTAX 'IA5String(256)' )

メール別名 objectClass を次に示します。

( 2.16.840.1.113730.3.2.4
  NAME 'mailGroup'
  SUP top
  STRUCTURAL
  MUST mail
  MAY ( cn $ mailAlternateAddress $ mailHost $ mailRequireAuth $
   mgrpAddHeader $ mgrpAllowedBroadcaster $ mgrpAllowedDomain $
   mgrpApprovePassword $ mgrpBroadcasterModeration $ mgrpDeliverTo $
   mgrpErrorsTo $ mgrpModerator $ mgrpMsgMaxSize $
   mgrpMsgRejectAction $ mgrpMsgRejectText $ mgrpNoMatchAddrs $
   mgrpRemoveHeader $ mgrpRFC822MailMember ))

ディレクトリユーザーエージェントのプロファイル (DUAProfile) スキーマ

DUAConfSchemaOID は、1.3.6.1.4.1.11.1.3.1 です。

DESC 'Default LDAP server host address used by a DUA'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.1 NAME 'defaultSearchBase'
            DESC 'Default LDAP base DN used by a DUA'
            EQUALITY distinguishedNameMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.2 NAME 'preferredServerList'
            DESC 'Preferred LDAP server host addresses to be used by a
            DUA'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.3 NAME 'searchTimeLimit'
            DESC 'Maximum time in seconds a DUA should allow for a
            search to complete'
            EQUALITY integerMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.4 NAME 'bindTimeLimit'
            DESC 'Maximum time in seconds a DUA should allow for the
            bind operation to complete'
            EQUALITY integerMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.5 NAME 'followReferrals'
            DESC 'Tells DUA if it should follow referrals
            returned by a DSA search result'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.6 NAME 'authenticationMethod'
            DESC 'A keystring which identifies the type of
            authentication method used to contact the DSA'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.7 NAME 'profileTTL'
            DESC 'Time to live, in seconds, before a client DUA
            should re-read this configuration profile' 
				'serviceSearchDescriptor'
            DESC 'LDAP search descriptor list used by a DUA'
            EQUALITY caseExactMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

          ( DUAConfSchemaOID.1.9 NAME 'attributeMap'
            DESC 'Attribute mappings used by a DUA'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

          ( DUAConfSchemaOID.1.10 NAME 'credentialLevel'
            DESC 'Identifies type of credentials a DUA should
            use when binding to the LDAP server'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.11 NAME 'objectclassMap'
            DESC 'Objectclass mappings used by a DUA'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

          ( DUAConfSchemaOID.1.12 NAME 'defaultSearchScope' SINGLE-VALUE )

          ( DUAConfSchemaOID.1.13 NAME 'serviceCredentialLevel'
            DESC 'Identifies type of credentials a DUA
            should use when binding to the LDAP server for a
            specific service'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

          ( DUAConfSchemaOID.1.15 NAME 'serviceAuthenticationMethod'
            DESC 'Authentication Method used by a service of the DUA'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

			  ( DUAConfSchemaOID.2.4 NAME 'DUAConfigProfile'
			  	 SUP top STRUCTURAL
				 DESC 'Abstraction of a base configuration for a DUA'
				 MUST ( cn )
				 MAY ( defaultServerList $ preferredServerList $
                defaultSearchBase $ defaultSearchScope $
                searchTimeLimit $ bindTimeLimit $
                credentialLevel $ authenticationMethod $
                followReferrals $ serviceSearchDescriptor $
                serviceCredentialLevel $ serviceAuthenticationMethod $
                objectclassMap $ attributeMap $
                profileTTL ) )  	

Solaris スキーマ

Solaris オペレーティング環境に必要なスキーマを次に示します。

• Solaris プロジェクトスキーマ

• アクセス制御および実行プロファイルスキーマに基づく役割

• プリンタスキーマ

Solaris プロジェクトスキーマ

/etc/project は、プロジェクトと関連のある属性のローカルソースです。詳細については、project(4) を参照してください。

プロジェクト属性を次に示します。

( 1.3.6.1.4.1.42.2.27.5.1.1 NAME 'SolarisProjectID'
  DESC 'Unique ID for a Solaris Project entry'
  EQUALITY integerMatch
  SYNTAX INTEGER SINGLE )

( 1.3.6.1.4.1.42.2.27.5.1.2 NAME 'SolarisProjectName'
  DESC 'Name of a Solaris Project entry'
  EQUALITY caseExactIA5Match
  SYNTAX IA5String SINGLE )

( 1.3.6.1.4.1.42.2.27.5.1.3 NAME 'SolarisProjectAttr'
  DESC 'Attributes of a Solaris Project entry'
  EQUALITY caseExactIA5Match
  SYNTAX IA5String )

( 1.3.6.1.4.1.42.2.27.5.1.30 NAME 'memberGid'
  DESC 'Posix Group Name'
  EQUALITY caseExactIA5Match
  SYNTAX 'IA5String' )

プロジェクト objectClass を次に示します。

( 1.3.6.1.4.1.42.2.27.5.2.1 NAME 'SolarisProject'
  SUP top STRUCTURAL
  MUST ( SolarisProjectID $ SolarisProjectName )
  MAY ( memberUid $ memberGid $ description $ SolarisProjectAttr ) )

役割ベースのアクセス制御と実行プロファイルスキーマ

ユーザーと役割に関する拡張属性のシステムごとの設定は、/etc/user_attr に置かれます。詳細については、user_attr(4) のマニュアルページを参照してください。

役割ベースのアクセス制御属性を次に示します。

( 1.3.6.1.4.1.42.2.27.5.1.4 NAME 'SolarisAttrKeyValue'
  DESC 'Semi-colon separated key=value pairs of attributes'
  EQUALITY caseIgnoreIA5Match
  SUBSTRINGS caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.7 NAME 'SolarisAttrShortDesc'
  DESC 'Short description about an entry, used by GUIs'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.8 NAME 'SolarisAttrLongDesc'
  DESC 'Detail description about an entry'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.9 NAME 'SolarisKernelSecurityPolicy'
  DESC 'Solaris  kernel security policy'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.10 NAME 'SolarisProfileType'
  DESC 'Type of object defined in profile'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.11 NAME 'SolarisProfileId'
  DESC 'Identifier of object defined in profile'
  EQUALITY caseExactIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.12 NAME 'SolarisUserQualifier'
  DESC 'Per-user login attributes'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.13 NAME 'SolarisReserved1'
  DESC 'Reserved for future use'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.14 NAME 'SolarisReserved2'
  DESC 'Reserved for future use'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )

役割ベースのアクセス制御 objectClassses を次に示します。

( 1.3.6.1.4.1.42.2.27.5.2.3 NAME 'SolarisUserAttr' SUP top AUXILIARY
  DESC 'User attributes'
  MAY ( SolarisUserQualifier $ SolarisAttrReserved1 $ \
        SolarisAttrReserved2 $ SolarisAttrKeyValue ) )
 
( 1.3.6.1.4.1.42.2.27.5.2.4 NAME 'SolarisAuthAttr' SUP top STRUCTURAL
  DESC 'Authorizations data'
  MUST cn
  MAY ( SolarisAttrReserved1 $ SolarisAttrReserved2 $ \
        SolarisAttrShortDesc $ SolarisAttrLongDesc $ \
        SolarisAttrKeyValue ) )
 
( 1.3.6.1.4.1.42.2.27.5.2.5 NAME 'SolarisProfAttr' SUP top STRUCTURAL
  DESC 'Profiles data'
  MUST cn
  MAY ( SolarisAttrReserved1 $ SolarisAttrReserved2 $ \
        SolarisAttrLongDesc $ SolarisAttrKeyValue ) )
 
( 1.3.6.1.4.1.42.2.27.5.2.6 NAME 'SolarisExecAttr' SUP top AUXILIARY
  DESC 'Profiles execution attributes'
  MAY ( SolarisKernelSecurityPolicy $ SolarisProfileType $ \
        SolarisAttrReserved1 $ SolarisAttrReserved2 $ \
        SolarisProfileId $ SolarisAttrKeyValue ) )

Internet Printing Protocol 情報

Internet Printing Protocol (IPP) 属性

( 1.3.18.0.2.4.1140 
NAME 'printer-uri' 
DESC 'A URI supported by this printer.  
This URI SHOULD be used as a relative distinguished name (RDN).  
If printer-xri-supported is implemented, then this URI value 
MUST be listed in a member value of printer-xri-supported.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

( 1.3.18.0.2.4.1107 
NAME 'printer-xri-supported' 
DESC 'The unordered list of XRI (extended resource identifiers) supported 
by this printer.  
Each member of the list consists of a URI (uniform resource identifier) 
followed by optional authentication and security metaparameters.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

( 1.3.18.0.2.4.1135 
NAME 'printer-name' 
DESC 'The site-specific administrative name of this printer, more end-user 
friendly than a URI.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}  SINGLE-VALUE )

( 1.3.18.0.2.4.1119 
NAME 'printer-natural-language-configured' 
DESC 'The configured language in which error and status messages will be 
generated (by default) by this printer.  
Also, a possible language for printer string attributes set by operator, 
system administrator, or manufacturer.  
Also, the (declared) language of the "printer-name", "printer-location", 
"printer-info", and "printer-make-and-model" attributes of this printer. 
For example: "en-us" (US English) or "fr-fr" (French in France) Legal values of 
language tags conform to [RFC3066] "Tags for the Identification of Languages".' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}  SINGLE-VALUE )

( 1.3.18.0.2.4.1136 
NAME 'printer-location' 
DESC 'Identifies the location of the printer. This could include
things like: "in Room 123A", "second floor of building XYZ".' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} SINGLE-VALUE )

( 1.3.18.0.2.4.1139 
NAME 'printer-info' 
DESC 'Identifies the descriptive information about this printer.  
This could include things like: "This printer can be used for 
printing color transparencies for HR presentations", or 
"Out of courtesy for others, please print only small (1-5 page) 
jobs at this printer", or even "This printer is going away on July 1, 1997, 
please find a new printer".' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} 
SINGLE-VALUE )

( 1.3.18.0.2.4.1134 
NAME 'printer-more-info' 
DESC 'A URI used to obtain more information about this specific printer.  
For example, this could be an HTTP type URI referencing an HTML page 
accessible to a Web Browser.  
The information obtained from this URI is intended for end user consumption.' 
EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

( 1.3.18.0.2.4.1138 
NAME 'printer-make-and-model' 
DESC 'Identifies the make and model of the device.  
The device manufacturer MAY initially populate this attribute.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}  SINGLE-VALUE )

( 1.3.18.0.2.4.1133 
NAME 'printer-ipp-versions-supported' 
DESC 'Identifies the IPP protocol version(s) that this printer supports, 
including major and minor versions, 
i.e., the version numbers for which this Printer implementation meets 
the conformance requirements.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1132 
NAME 'printer-multiple-document-jobs-supported' 
DESC 'Indicates whether or not the printer supports more than one 
document per job, i.e., more than one Send-Document or Send-Data 
operation with document data.' 
EQUALITY booleanMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )

( 1.3.18.0.2.4.1109 
NAME 'printer-charset-configured' 
DESC 'The configured charset in which error and status messages will be 
generated (by default) by this printer.  
Also, a possible charset for printer string attributes set by operator, 
system administrator, or manufacturer.  
For example: "utf-8" (ISO 10646/Unicode) or "iso-8859-1" (Latin1).  
Legal values are defined by the IANA Registry of Coded Character Sets and 
the "(preferred MIME name)" SHALL be used as the tag.  
For coherence with IPP Model, charset tags in this attribute SHALL be 
lowercase normalized.  
This attribute SHOULD be static (time of registration) and SHOULD NOT be
dynamically refreshed attributetypes: (subsequently).' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63} SINGLE-VALUE )

( 1.3.18.0.2.4.1131 
NAME 'printer-charset-supported' 
DESC 'Identifies the set of charsets supported for attribute type values of 
type Directory String for this directory entry.  
For example: "utf-8" (ISO 10646/Unicode) or "iso-8859-1" (Latin1).  
Legal values are defined by the IANA Registry of Coded Character Sets and 
the preferred MIME name.' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63} )

( 1.3.18.0.2.4.1137 
NAME 'printer-generated-natural-language-supported' 
DESC 'Identifies the natural language(s) supported for this directory entry.  
For example: "en-us" (US English) or "fr-fr" (French in France).  
Legal values conform to [RFC3066], Tags for the Identification of Languages.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63} )

( 1.3.18.0.2.4.1130 
NAME 'printer-document-format-supported' 
DESC 'The possible document formats in which data may be interpreted 
and printed by this printer.  
Legal values are MIME types come from the IANA Registry of Internet Media Types.' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1129 
NAME 'printer-color-supported' 
DESC 'Indicates whether this printer is capable of any type of color printing 
at all, including highlight color.' 
EQUALITY booleanMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.7  SINGLE-VALUE )

( 1.3.18.0.2.4.1128 
NAME 'printer-compression-supported' 
DESC 'Compression algorithms supported by this printer.  
For example: "deflate, gzip".  Legal values include; "none", "deflate" 
attributetypes: (public domain ZIP), "gzip" (GNU ZIP), "compress" (UNIX).' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1127 
NAME 'printer-pages-per-minute' 
DESC 'The nominal number of pages per minute which may be output by this 
printer (e.g., a simplex or black-and-white printer).  
This attribute is informative, NOT a service guarantee.  
Typically, it is the value used in marketing literature to describe this printer.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1126 NAME 'printer-pages-per-minute-color' 
DESC 'The nominal number of color pages per minute which may be output by this 
printer (e.g., a simplex or color printer).  
This attribute is informative, NOT a service guarantee.  
Typically, it is the value used in marketing literature to describe this printer.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1125 NAME 'printer-finishings-supported' 
DESC 'The possible finishing operations supported by this printer. 
Legal values include; "none", "staple", "punch", "cover", "bind", "saddle-stitch", 
"edge-stitch", "staple-top-left", "staple-bottom-left", "staple-top-right", 
"staple-bottom-right", "edge-stitch-left", "edge-stitch-top", "edge-stitch-right", 
"edge-stitch-bottom", "staple-dual-left", "staple-dual-top", "staple-dual-right", 
"staple-dual-bottom".' 
EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1124 NAME 'printer-number-up-supported' 
DESC 'The possible numbers of print-stream pages to impose upon a single side of 
an instance of a selected medium. Legal values include; 1, 2, and 4.  
Implementations may support other values.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27 )

( 1.3.18.0.2.4.1123 NAME 'printer-sides-supported' 
DESC 'The number of impression sides (one or two) and the two-sided impression 
rotations supported by this printer.  
Legal values include; "one-sided", "two-sided-long-edge", "two-sided-short-edge".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1122 NAME 'printer-media-supported' 
DESC 'The standard names/types/sizes (and optional color suffixes) of the media 
supported by this printer.  
For example: "iso-a4",  "envelope", or "na-letter-white".  
Legal values  conform to ISO 10175, Document Printing Application (DPA), and any 
IANA registered extensions.'
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1117 NAME 'printer-media-local-supported' 
DESC 'Site-specific names of media supported by this printer, in the language in 
"printer-natural-language-configured".  
For example: "purchasing-form" (site-specific name) as opposed to 
(in "printer-media-supported"): "na-letter" (standard keyword from ISO 10175).' 
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1121 NAME 'printer-resolution-supported' 
DESC 'List of resolutions supported for printing documents by this printer.  
Each resolution value is a string with 3 fields:  
1) Cross feed direction resolution (positive integer), 2) Feed direction 
resolution (positive integer), 3) Resolution unit.  
Legal values are "dpi" (dots per inch) and "dpcm" (dots per centimeter).  
Each resolution field is delimited by ">".  For example:  "300> 300> dpi>".' 
EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1120 NAME 'printer-print-quality-supported' 
DESC 'List of print qualities supported for printing documents on this printer.  
For example: "draft, normal".  Legal values include; "unknown", "draft", "normal", 
"high".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1110 NAME 'printer-job-priority-supported' 
DESC 'Indicates the number of job priority levels supported.  
An IPP conformant printer which supports job priority must always support a 
full range of priorities from "1" to "100" 
(to ensure consistent behavior), therefore this attribute describes the 
"granularity". 
 Legal values of this attribute are from "1" to "100".' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1118 
NAME 'printer-copies-supported' 
DESC 'The maximum number of copies of a document that may be printed as a single job.  
A value of "0" indicates no maximum limit.  
A value of "-1" indicates unknown.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1111 
NAME 'printer-job-k-octets-supported' 
DESC 'The maximum size in kilobytes (1,024 octets actually) incoming print job that 
this printer will accept.  
A value of "0" indicates no maximum limit.  A value of "-1" indicates unknown.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1113 
NAME 'printer-service-person' 
DESC 'The name of the current human service person responsible for servicing this 
printer.  
It is suggested that this string include information that would enable other humans 
to reach the service person, such as a phone number.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}  
SINGLE-VALUE )

( 1.3.18.0.2.4.1114 
NAME 'printer-delivery-orientation-supported' 
DESC 'The possible delivery orientations of pages as they are printed and ejected 
from this printer.  
Legal values include; "unknown", "face-up", and "face-down".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1115 
NAME 'printer-stacking-order-supported' 
DESC 'The possible stacking order of pages as they are printed and ejected from 
this printer. 
Legal values include; "unknown", "first-to-last", "last-to-first".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1116 
NAME 'printer-output-features-supported' 
DESC 'The possible output features supported by this printer. 
Legal values include; "unknown", "bursting", "decollating", "page-collating", 
"offset-stacking".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1108 
NAME 'printer-aliases' 
DESC 'Site-specific administrative names of this printer in addition the printer 
name specified for printer-name.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.6.1.4.1.42.2.27.5.1.63 
NAME 'sun-printer-bsdaddr' 
DESC 'Sets the server, print queue destination name and whether the client generates 
protocol extensions. 
"Solaris" specifies a Solaris print server extension. The value is represented b the 
following value: server "," destination ", Solaris".' 
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )

( 1.3.6.1.4.1.42.2.27.5.1.64 
NAME 'sun-printer-kvp' 
DESC 'This attribute contains a set of key value pairs which may have meaning to the 
print subsystem or may be user defined. 
Each value is represented by the following: key "=" value.' 
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )

Internet Printing Protocol (IPP) ObjectClasses

objectclasses: ( 1.3.18.0.2.6.2549 
NAME 'slpService' 
DESC 'DUMMY definition' 
SUP 'top' MUST (objectclass) MAY ())

objectclasses: ( 1.3.18.0.2.6.254 
NAME 'slpServicePrinter' 
DESC 'Service Location Protocol (SLP) information.' 
AUXILIARY SUP 'slpService')

objectclasses: ( 1.3.18.0.2.6.258 
NAME 'printerAbstract' 
DESC 'Printer related information.' 
ABSTRACT SUP 'top' MAY ( printer-name 
$ printer-natural-language-configured 
$ printer-location 
$ printer-info 
$ printer-more-info 
$ printer-make-and-model 
$ printer-multiple-document-jobs-supported 
$ printer-charset-configured 
$ printer-charset-supported 
$ printer-generated-natural-language-supported 
$ printer-document-format-supported 
$ printer-color-supported 
$ printer-compression-supported 
$ printer-pages-per-minute 
$ printer-pages-per-minute-color 
$ printer-finishings-supported 
$ printer-number-up-supported 
$ printer-sides-supported 
$ printer-media-supported 
$ printer-media-local-supported 
$ printer-resolution-supported 
$ printer-print-quality-supported 
$ printer-job-priority-supported 
$ printer-copies-supported 
$ printer-job-k-octets-supported 
$ printer-current-operator 
$ printer-service-person 
$ printer-delivery-orientation-supported 
$ printer-stacking-order-supported $ printer! -output-features-supported ))

objectclasses: ( 1.3.18.0.2.6.255 
NAME 'printerService' 
DESC 'Printer information.' 
STRUCTURAL SUP 'printerAbstract' MAY ( printer-uri 
$ printer-xri-supported ))

objectclasses: ( 1.3.18.0.2.6.257 
NAME 'printerServiceAuxClass' 
DESC 'Printer information.' 
AUXILIARY SUP 'printerAbstract' MAY ( printer-uri $ printer-xri-supported ))

objectclasses: ( 1.3.18.0.2.6.256 
NAME 'printerIPP' 
DESC 'Internet Printing Protocol (IPP) information.' 
AUXILIARY SUP 'top' MAY   ( printer-ipp-versions-supported $ 
printer-multiple-document-jobs-supported ))

objectclasses: ( 1.3.18.0.2.6.253 
NAME 'printerLPR' 
DESC 'LPR information.' 
AUXILIARY SUP 'top' MUST ( printer-name ) MAY ( printer-aliases))

objectclasses: ( 1.3.6.1.4.1.42.2.27.5.2.14 
NAME 'sunPrinter' 
DESC 'Sun printer information' 
SUP 'top' AUXILIARY MUST (objectclass $ printer-name)  MAY 
(sun-printer-bsdaddr $ sun-printer-kvp))

Sun プリンタ属性

ATTRIBUTE ( 1.3.6.1.4.1.42.2.27.5.1.63
NAME sun-printer-bsdaddr
DESC 'Sets the server, print queue destination name and whether the 
     client generates protocol extensions. "Solaris" specifies a 
     Solaris print server extension.  The value is represented by 
     the following value: server "," destination ", Solaris".'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15   
SINGLE-VALUE
)


ATTRIBUTE ( 1.3.6.1.4.1.42.2.27.5.1.64
NAME sun-printer-kvp
DESC 'This attribute contains a set of key value pairs which may have
      meaning to the print subsystem or may be user defined.  Each
      value is represented by the following: key "=" value.'
EQUALITY caseIgnoreIA5Match 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15  )

Sun プリンタ ObjectClasses

OBJECTCLASS ( 1.3.6.1.4.1.42.2.27.5.2.14
NAME sunPrinter
DESC 'Sun printer information'
SUP  top
AUXILIARY
MUST ( printer-name )
MAY  ( sun-printer-bsdaddr $ sun-printer-kvp ))

汎用ディレクトリサーバーの要件

Solaris 9 LDAP クライアントをサポートする場合、サーバーの種類に関係なく、LDAP v3 プロトコル、複合ネーミングおよび補助オブジェクトクラスをサポートする必要があります。また、次の制御を 1 つ以上サポートする必要があります。

• 単純ページモード (RFC 2696)

• 仮想リスト表示制御

  サーバーは、次の認証方式を 1 つ以上サポートする必要があります。

  • anonymous
  • simple
  • sasl/cram-MD5
  • sasl/digest-MD5

pam_unix を使用する場合、サーバーは UNIX 暗号形式 (crypt) でのパスワード保管をサポートする必要があります。

TLS を使用する場合、サーバーは SSL または TLS をサポートする必要があります。

LDAP ネームサービスで使用されるデフォルトフィルタ

SSD を使用して個々のサービスにパラメータを手動で指定しないと、デフォルトフィルタが使用されます。特定のサービスのデフォルトフィルタを表示するには、-v オプションを指定して ldaplist を実行してください。

以下の例では、filter=(&(objectclass=iphost)(cn=abcde) によってデフォルトフィルタが定義されます。

database=hosts
filter=(&(objectclass=iphost)(cn=abcde)
user data=(&(%s) (cn=abcde))

ldaplist は、以下に示す一連のデフォルトフィルタを生成します (%s は文字列を意味し、%d は数値を意味する)。

hosts
(&(objectclass=iphost)(cn=%s))
--------------
passwd
(&(objectclass=posixaccount)(uid=%s))
--------------
services
(&(objectclass=ipservice)(cn=%s))
--------------
group
(&(objectclass=posixgroup)(cn=%s))
--------------
netgroup
(&(objectclass=nisnetgroup)(cn=%s))
--------------
networks
(&(objectclass=ipnetwork)(ipnetworknumber=%s))
--------------
netmasks
(&(objectclass=ipnetwork)(ipnetworknumber=%s))
--------------
rpc
(&(objectclass=oncrpc)(cn=%s))
--------------
protocols
(&(objectclass=ipprotocol)(cn=%s))
--------------
bootparams
(&(objectclass=bootableDevice)(cn=%s))
--------------
ethers
(&(objectclass=ieee802Device)(cn=%s))
--------------
publickey
(&(objectclass=niskeyobject)(cn=%s))
or
(&(objectclass=niskeyobject)(uidnumber=%d))
--------------
aliases
(&(objectclass=mailGroup)(cn=%s))
--------------

次の表に getent 属性フィルタの一覧を示します。

第 19 章 NIS+ から LDAP への移行

この章では、NIS+ ネームサービスから LDAP ネームサービスへの移行方法について説明します。

概要

NIS+ サーバーデーモン rpc.nisd は、NIS+ データを /var/nis/data ディレクトリ内の NIS+ 固有の書式ファイルに格納します。 NIS+ データは、LDAP と同期化することができます。従来は、そのために外部エージェントが必要でした。しかし、新しい NIS+ デーモンでは、LDAP サーバーを NIS+ データのデータリポジトリとして使用できるようになりました。これにより、NIS+ および LDAP クライアントが同一のネームサービス情報を共有できるため、メインネームサービスを NIS+ から LDAP に移行する作業がより簡単になりました。LDAP をネームサービスとして使用する場合の詳細は、第 12 章「LDAP ネームサービスの紹介 (概要/リファレンス)」を参照してください。

デフォルトの rpc.nisd デーモンは、従来と同様に機能し、/var/nis/data の NIS+ データベースにデータを格納します。システム管理者は、必要に応じて、NIS+ データベースの一部の権限を LDAP サーバーに譲渡し、NIS+ データのリポジトリとして使用することができます。この場合、/var/nis/data ファイルは rpc.nisd デーモンのキャッシュとして機能するため、LDAP ルックアップトラフィックが減少します。また、LDAP サーバーが一時的に使用できなくなった場合でも、 rpc.nisd デーモンは動作を継続できます。NIS+ および LDAP は常に同期化されるだけでなく、NIS+ および LDAP 間でデータをアップロードまたはダウンロードすることができます。

LDAP に対するデータのマッピングは、構成ファイルの柔軟な構文を使用して行います。client_info.org_dir および timezone.org_dir 以外のすべての標準 NIS+ テーブルは、テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template で対応できます。ほとんどの NIS+ インストールのテーブルは、変更する必要がないか、わずかな変更で済みます(client_info.org_dir と timezone.org_dir については、「client_info および timezone テーブル」 を参照)。 NIS+ データは、LDAP ディレクトリ情報ツリー (DIT) に配置されます。また、マッピングファイルでは、LDAP から入力された NIS+ データに対して生存期間 (TTL) を設定できます。多くの場合、NIS+ 列値および LDAP 属性値は 1 対 1 で対応づけられますが、マッピングファイルはより複雑な関係にも対応できます。

新しい /etc/default/rpc.nisd ファイルは、LDAP サーバーと認証を選択するときに使用し、rpc.nisd の一般的な動作をいくつか制御します。rpc.nisd(4) のマニュアルページを参照してください。マッピングの詳細は、/var/nis/NIS+LDAPmapping ファイルを使用して指定します。詳細については、NIS+LDAPmapping(4) のマニュアルページを参照してください。このファイルの名前を変更するときは、rpc.nisd に -m コマンド行オプションを指定して使用します。詳細については、rpc.nisd(1M) のマニュアルページを参照してください。

この章では、次の用語を使用します。

• コンテナ

  すべての関連エントリが格納される LDAP DIT 内の場所。たとえば、ユーザーアカウント情報は、多くの場合、 ou=People コンテナに格納される。また、ホストアドレス情報は、 ou=Hosts コンテナに格納される

• ネット名

  認証可能な SecureRPC 内のエンティティ (ユーザーまたはマシン)。

• マッピング

  NIS+ オブジェクトと LDAP エントリとの関係。たとえば、 passwd.org_dir NIS+ テーブルの name 列のデータ (アカウントのユーザー名など) が、ou=People コンテナ内の posixAccount オブジェクトクラスの LDAP uid 属性に対応しているとする。構成によって、name 列および uid 属性が対応づけられる。 name 列が uid 属性に対応づけられる (またはその逆) とも表現できる

• 主体

  認証可能な NIS+ のエンティティ (ユーザーまたはマシン) 。通常、ネット名と主体名は 1 対 1 で対応づけられる

構成ファイル

rpc.nisd の処理は、2 つの構成ファイルを使用して制御します。

• /etc/default/rpc.nisd

  LDAP サーバーと認証、NIS+ ベースドメイン、LDAP デフォルト検索ベース、例外処理、および rpc.nisd の一般的な構成に関する情報を含みます。このファイルは、LDAP マッピングが有効であるかどうかにかかわらず適用されます。

• /var/nis/NIS+LDAPmapping

  NIS+ データと LDAP との間のマッピング情報を含みます。テンプレートファイル (/var/nis/NIS+LDAPmapping.template) は、client_info.org_dir と timezone.org_dir 以外のすべての標準 NIS+ オブジェクトに対応しています。 「client_info および timezone テーブル」とNIS+LDAPmapping(4) のマニュアルページを参照してください。

構成とは、値を定義済みの属性に割り当てることです。構成ファイル以外に、構成属性を LDAP から読み込むこともできます (「構成情報を LDAP に格納する」 を参照)。また、rpc.nisd コマンドの -x オプションに構成属性を指定することもできます。複数の場所で同じ属性が指定されている場合、優先順位 (高から低) は次のとおりです。

1. rpc.nisd -x オプション

2. 構成ファイル

3. LDAP

属性とオブジェクトクラスの作成

NIS+ と LDAP のマッピングの構成によっては、新しい LDAP 属性とオブジェクトクラスをいくつか作成しなければならないことがあります。次の例では、これらの作成方法として、 ldapadd コマンドの入力として使用できる LDIF データを指定する方法を示します。LDIF データを含むファイルを作成してから、ldapadd(1) を起動します。

# ldapadd -D bind-DN-f ldif -file

この方法は、iPlanet^TM Directory Server 5.1 およびほかの LDAP サーバーでも使用します。

ただし、defaultSearchBase、 preferredServerList、および authenticationMethod 属性を除き、この章で使用されているオブジェクト識別子 (OID) は、SYNTAX 仕様と同様に、説明用に挙げているだけです。OID の基準はありません。任意の OID を使用できます。

開始前に必要な処置

NIS+ データを LDAP リポジトリに格納するために必要な構成の概要については、NIS+LDAPmapping(4) のマニュアルページを参照してください。 ここでは、構成ファイルの編成について詳細に説明します。

/etc/default/rpc.nisd

/etc/default/rpc.nisd ファイルに値を割り当てるときは、すべて attributeName=value タイプとします。

一般的な構成

次の属性は、 rpc.nisd の一般的な構成を制御します。また、LDAP マッピングが有効かどうかにかかわらず、アクティブになります。 これらの属性は通常、デフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。

• nisplusNumberOfServiceThreads

• nisplusThreadCreationErrorAction

• nisplusThreadCreationErrorAttempts

• nisplusThreadCreationErrorTimeout

• nisplusDumpErrorAction

• nisplusDumpErrorAttempts

• nisplusDumpErrorTimeout

• nisplusResyncService

• nisplusUpdateBatching

• nisplusUpdateBatchingTimeout

LDAP からの構成データ

次の属性は、LDAP からのその他の構成属性の読み込みを制御します。これらの属性自体を LDAP に常駐させることはできません。コマンド行または構成ファイルから読み込む必要があります。詳細については、rpc.nisd(4) のマニュアルページを参照してください。

• nisplusLDAPconfigDN

• nisplusLDAPconfigPreferredServerList

• nisplusLDAPconfigAuthenticationMethod

• nisplusLDAPconfigTLS

• nisplusLDAPconfigTLSCertificateDBPath

• nisplusLDAPconfigProxyUser

• nisplusLDAPconfigProxyPassword

サーバーの選択

• preferredServerList

  LDAP サーバーとポート番号を指定します。

  # LDAP server can be found at port 389 # LDAP server can be found at port 389 on the local machine # preferredServerList=127.0.0.1 # Could also be written # preferredServerList=127.0.0.0.1:389 LDAP server on the machine at IP # address "1.2.3.4", at port 65042 # preferredServerList=1.2.3.4:65042

認証とセキュリティ

• authenticationMethod

• nisplusLDAPproxyUser

• nisplusLDAPproxyPassword

認証方式と、その方式に適切なプロキシユーザー (バインド識別名 DN) とパスワード (鍵またはその他の共有された機密情報)。これらは、 rpc.nisd デーモンと LDAP サーバーの間で使用されます。詳細については、「セキュリティと認証」 を参照してください。

• nisplusLDAPTLS

• nisplusLDAPTLSCertificateDBPath

LDAP および NIS+ 内のデフォルトの場所

• defaultSearchBase

  LDAP DIT 内で、RFC 2307 に準拠したネームサービスデータのコンテナが配置される場所。コンテナ DN の完全な検索ベースを個別に指定しなかった場合は、この場所がデフォルトで使用されます。詳細については、「nisplusLDAPobjectDN」 を参照してください。

• nisplusLDAPbaseDomain

  NIS+ オブジェクト仕様 (「nisplusLDAPdatabaseIdMapping」 を参照) を完全指定しなかった場合は、このデフォルト NIS+ ドメイン名が使用されます。

LDAP 通信のタイムアウト制限、サイズ制限、および参照アクション

• nisplusLDAPbindTimeout

• nisplusLDAPmodifyTimeout

• nisplusLDAPaddTimeout

• nisplusLDAPdeleteTimeout

上のパラメータ (順番に、ldap bind、modify、add、および delete 操作) でタイムアウトを設定します。これらのパラメータは通常、デフォルトのままにしておきます。

• nisplusLDAPsearchTimeout

• nisplusLDAPsearchTimeLimit

上のパラメータには、LDAP 検索処理のタイムアウトを設定します。下のパラメータでは、サーバー側の検索時間制限を要求します。nisplusLDAPsearchTimeLimit では、LDAP サーバーが検索要求に使用する時間を制御します。このため、nisplusLDAPsearchTimeLimit には nisplusLDAPsearchTimeout 以上の値を設定してください。NIS+ サーバー、LDAP サーバー、および 2 つのサーバー間の接続のパフォーマンスに応じて、検索制限をデフォルト値より大きくしなければならないことがあります。rpc.nisd から送信されたタイムアウトに関するシステムログメッセージを基にして、これらの値を大きくするかどうかを判断します。

• nisplusLDAPsearchSizeLimit

  このパラメータでは、LDAP 検索要求に対して返される LDAP データ量に対する制限を要求します。デフォルトでは、制限は要求しません。この制限は、サーバー側に適用されます。LDAP サーバーでは、最大データ量に対して制限を適用することがあります。データ量の制限は、使用されているプロキシユーザー (バインド DN) に関連づけられることがあります。最も大きいコンテナに対して十分なデータが送信されるように、LDAP サーバーで rpc.nisd を設定してください。ただし、最も大きなコンテナの場所は、環境によって異なります。多くの場合、passwd.org_dir、mail_aliases.org_dir 、または netgroup.org_dir のコンテナが使用されます。詳細については、LDAP サーバーのマニュアルを参照してください。

• nisplusLDAPfollowReferral

  このパラメータには、LDAP の処理中に別の LDAP サーバーへの参照が発生したときに、実行する処理を指定します。デフォルトでは、参照は行いません。参照を希望するか必要な場合は、参照を有効にします。参照は便利ですが、参照要求が発生するたびに rpc.nisd と複数の LDAP サーバーが対話する必要があるため、処理速度が遅くなることがあります。rpc.nisd には通常、発行する可能性のあるすべての LDAP 要求を処理できる LDAP サーバーを直接指定してください。

エラー処理

次のパラメータには、LDAP 処理中にエラーが発生したときに、実行する処理を指定します。これらのパラメータは通常、デフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。

• nisplusLDAPinitialUpdateAction

• nisplusLDAPinitialUpdateOnly

• nisplusLDAPretrieveErrorAction

• nisplusLDAPretrieveErrorAttempts

• nisplusLDAPretrieveErrorTimeout

• nisplusLDAPstoreErrorAction

• nisplusLDAPstoreErrorAttempts

• nisplusLDAPstoreErrorTimeout

• nisplusLDAPrefreshErrorAction

• nisplusLDAPrefreshErrorAttempts

• nisplusLDAPrefreshErrorTimeout

一般的な LDAP 処理の制御

• nisplusLDAPmatchFetchAction

  このパラメータでは、NIS+ 照合処理のために、LDAP データを事前に取得するかどうかを決定します。ほとんどの場合、この値はデフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。

/var/nis/NIS+LDAPmapping

この構成の名前は、rpc.nisd(1M) の -m オプションを使用して変更できます。NIS+LDAPmapping ファイルは、NIS+ および LDAP マッピングのマスタースイッチとして機能します。

マッピングファイルに対してデフォルト以外の名前を使用する場合は、/etc/init.d/rpc ブートスクリプトを編集して、rpc.nisd 起動行にそのマッピングファイル名を指定する必要があります。

LDAP に対応づける NIS+ オブジェクトごとに、 NIS+LDAPmapping ファイルに 2 - 5 個の属性を指定します。指定する属性値は、オブジェクトとデフォルト値によって異なります。

nisplusLDAPdatabaseIdMapping

別名は、オブジェクトがほかのマッピング属性で使用されるときに設定する必要があります。NIS+ オブジェクト名が完全指定されていない場合 (ドットで終わっていない場合) は 、nisplusLDAPbaseDomain の値が付加されます。

たとえば、次のようになります。

nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir

このパラメータでは、データベース ID rpc を NIS+ rpc.org_dir テーブルの別名として定義しています。

NIS+ テーブルオブジェクトを 2 つの異なるデータベース ID ごとに 2 回定義する場合、テーブルオブジェクト自体 (このオブジェクトを LDAP に対応づける必要がある場合) として定義し、次にテーブルエントリとして定義します。たとえば、次のようになります。

nisplusLDAPdatabaseIdMapping	rpc_table:rpc.org_dir
nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir

まず、データベース ID rpc_table と rpc を、rpc.org_dir テーブルの別名として定義します。次に、rpc_table を rpc.org_dir テーブルオブジェクトに使用し、rpc をそのテーブルのエントリに使用することを定義します。

nisplusLDAPentryTtl

rpc.nisd デーモンのローカルデータベースは、メモリ内およびディスク上で LDAP データのキャッシュとして機能します。nisplusLDAPentryTtl 属性を使用すれば、そのキャッシュ内のエントリの生存期間 (TTL) 値を設定できます。各データベース ID には、3 つの TTL があります。最初の 2 つの TTL は、rpc.nisd が、対応する NIS+ オブジェクトデータをディスクから最初に読み込むときの初期 TTL を制御します。3 番目の TTL は、NIS+ オブジェクトデータを LDAP から読み込んだとき (更新したとき) にオブジェクトに割り当てられます。

たとえば、次の場合、rpc.org_dir テーブルオブジェクトは、21600 - 43200 秒の範囲からランダムに選択された初期 TTL を取得します。

nisplusLDAPentryTtl	rpc_table:21600:43200:43200

初期 TTL の生存期間が切れると、テーブルオブジェクトが LDAP から再度読み込まれ、TTL が 43200 秒に設定されます。

同様に、次の場合は、テーブルオブジェクトが最初に読み込まれたときに、800 - 3600 秒から選択された初期 TTL が、 rpc.org_dir テーブルのエントリに割り当てられます。

nisplusLDAPentryTtl	rpc:1800:3600:3600

各エントリは、指定された範囲からランダムに選択された TTL を取得します。テーブルエントリが期間切れになり、更新されると、TTL は 3600 秒に設定されます。

TTL 値を選択するときは、パフォーマンスと整合性のバランスを考慮してください。rpc.nisd によって LDAP データがキャッシュされているときは、その TTL が大きい場合、rpc.nisd に LDAP データとの関連付けを設定していない場合とパフォーマンスは同じになります。しかし、rpc.nisd 以外のエンティティによって LDAP データが変更されると、変更が NIS+ に反映されるまでにかなりの時間がかかります。

逆に、小さな値 (またはゼロ) を TTL に設定すると、LDAP データに対する変更が NIS+ にすばやく反映されますが、パフォーマンスが低下する可能性があります。通常、NIS+ 上で LDAP データの読み込みまたは書き込みを行うときは、LDAP 通信を行わない場合と比較して、2 〜 3 倍の時間に加えて LDAP ルックアップの時間がかかります。パフォーマンスはハードウェアリソースによって大きく異なりますが、大きな LDAP コンテナ (数万 〜 数十万のエントリ) を走査して、更新が必要な NIS+ エントリを識別するのは、かなりの時間を必要とします。rpc.nisd デーモンは、この走査をバックグラウンドで実行して、走査の実行中も可能なデータを供給し続けます。しかし、バックグラウンドで走査している場合でも、NIS+ サーバーの CPU とメモリは消費されます。

NIS+ データと LDAP を同期化する重要性を十分に考慮して、適用可能な最も長い TTL を NIS+ オブジェクトごとに選択してください。デフォルト (nisplusLDAPentryTtl を指定しないとき) は 1 時間です。テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template を適用すると、テーブルエントリ以外のオブジェクトの TTL が 12 時間に変更されます。ただし、テーブルエントリ以外のオブジェクトは自動的に認識されないため、テーブルエントリ以外のオブジェクトのマッピングを追加すると、TTL はデフォルトの 1 時間に設定されます。

存在しないオブジェクトには 、TTL はありません。このため、NIS+ テーブル内で LDAP に対応づけられたエントリの TTL を有効にしても、NIS+ に存在しないエントリを要求すると、常に LDAP を照会してそのエントリを取得しようとします。

nisplusLDAPobjectDN

nisplusLDAPobjectDN には、対応づけられた NIS+ オブジェクトごとに、オブジェクトデータが常駐する LDAP DIT 内の対応する場所を設定します。また、LDAP エントリが削除されたときに実行する処理も指定できます。nisplusLDAPobjectDN 値は、3 つの部分から構成されます。最初の部分には、LDAP データの読み込み元を指定します。2 番目の部分には、LDAP データの書き込み先を指定します。3 番目の部分には、LDAP データが削除されたときの処理を指定します。次の例を参照してください。

nisplusLDAPobjectDN	rpc_table:\ 
										cn=rpc,ou=nisPlus,?base?\
													objectClass=nisplusObjectContainer:\ 
										cn=rpc,ou=nisPlus,?base?\ 
													objectClass=nisplusObjectContainer,\ 
														objectClass=top

この例では、rpc.org_dir テーブルオブジェクトが DN cn=rpc,ou=nisPlus から読み込まれます。このとき、DN 値がコンマで終了しているため、defaultSearchBase 属性 (検索範囲) の値として base が付加されます。また、ObjectClass 属性の値が nisplusObjectContainer であるエントリが選択されます。

このテーブルオブジェクトは、読み込み元と同じ場所に書き込まれます。削除については指定されていないため、デフォルトの処理が実行されます。NIS+ テーブルオブジェクトが削除されると、LDAP エントリ全体も削除されます。

データを読み込むだけで LDAP に書き込まない場合は、書き込み部分を省略し、読み込み部分との区切り文字であるコロンも省略します。

nisplusLDAPobjectDN	rpc_table:\
										cn=rpc,ou=nisPlus,?base?\
										objectClass=nisplusObjectContainer

nisplusObjectContainer オブジェクトクラスは、RFC 2307 に準拠していません。 このオブジェクトクラスを使用するには、LDAP サーバーを 「テーブルエントリ以外の NIS+ オブジェクトのマッピング」 で説明するように構成する必要があります。

rpc.org_dir テーブルエントリには、次の例も使用できます。

nisplusLDAPobjectDN rpc:ou=Rpc,?one?objectClass=oncRpc:\
											ou=Rpc,?one?objectClass=onRpc,objectClass=top

この例では、テーブルエントリの読み込みおよび書き込みが、ベース ou=Rpc に対して行われます。コンマで終了しているため、 defaultSearchBase 値が付加されます。objectClass 属性の値が oncRpc であるエントリを選択してください。LDAP の ou=Rpc コンテナ内にエントリを作成するときは、objectClass の値として top も指定する必要があります。

デフォルト以外の削除を指定する場合は、次の例を参照してください。

nisplusLDAPobjectDN	user_attr:\
										ou=People,?one?objectClass=SolarisUserAttr,\
											solarisAttrKeyValue=*:\
										ou=People,?one?objectClass=SolarisUserAttr:\
											dbid=user_attr_del

user_attr.org_dir データは、ou=People LDAP コンテナに存在します。このコンテナは、ほかのソース (passwd.org_dir NIS+ テーブルなど) のアカウント情報も入ります。

そのコンテナ内のエントリから、solarisAttrKeyValue 属性を持つものが選択されます。user_attr.org_dir データが、これらのエントリにだけ含まれるためです。nisplusLDAPobjectDN の dbid=user_attr_del 部分の定義によって、user_attr.org_dir NIS+ テーブル内のエントリが削除されると、対応する LDAP エントリが存在する場合は、データベース ID が user_attr_del のルールセットのルールに基づいて 削除されます。 詳細については、「nisplusLDAPcolumnFromAttribute」 を参照してください。

nisplusLDAPattributeFromColumn

nisplusLDAPattributeFromColumn には、NIS+ データを LDAP に対応づけるときのルールを指定します。LDAP から NIS+ データへのマッピングルールは、nisplusLDAPcolumnFromAttribute に指定します。

nisplusLDAPcolumnFromAttribute

nisplusLDAPcolumnFromAttribute には、LDAP データを NIS+ に対応づけるときのルールを指定します。

エントリマッピングの完全な構文については、 NIS+LDAPmapping(4) のマニュアルページを参照してください。ここでは、わかりやすい例をいくつか挙げます。

NIS+ rpc.org_dir テーブルには、cname、name、numbe、および comment という列が含まれます。たとえば、NIS+ RPC プログラム番号 (100300) に対して、正規名として nisd が指定され、別名として rpc.nisd と nisplusd が指定されているとします。このエントリは、rpc.org_dir の次の NIS+ エントリを使用して表現できます。

nisd nisd 100300	NIS+ server
nisd rpc.nisd 100300	NIS+ server
nisd nisplusd 100300	NIS+ server

defaultSearchBase の値を dc=some,dc=domain と想定します。対応する LDAP は、ldapsearch(1) を実行すると次のように表示されます。

cn=nisd,ou=Ppc,dc=some,dc=domain
cn=nisd
cn=rpc.nsid
cn=nisplusd
oncrocnumber=100300
description=NIS+ server
objectclass=oncRpc
objectclass=top

この例は、NIS+ および LDAP が単純に 1 対 1 で対応づけられている場合です。この場合、NIS+ から LDAP へのマッピング属性値は、次のようになります。

nisplusLDAPattributeFromColumn \ 
rpc:		dn=("cn=%s,", name), \ 
				cn=cname, \
				cn=name, \
				oncRpcNumber=number, \
				description=comment

このエントリの DN として、cn=%s が構成されます。cname 列の値が %s に代入されます。

cn=nisd,

値がコンマで終了しているため、 nisplusObjectDN の読み込みベース値が付加され、次のようになります。

cn=nisd,ou=Rpc,dc=some,dc=domain

oncRpcNumber 属性および description 属性の値には、対応する NIS+ 列の値が代入されます。rpc.nisd によって、複数の NIS+ エントリが 1 つの LDAP エントリに収集され、異なる name 列値を表す複数の cn 値が生成されます。

同様に、LDAP から NIS+ へのマッピングは、次のようになります。

nisplusLDAPcolumnFromAttribute \ 
 					rpc:		cname=cn, \
			 						(name)=(cn), \
									number=oncRpcNumber, \
									comment=description

この例では、oncRpcNumber および description の値が、対応する NIS+ 列に割り当てられます。 (cn) で示される複数値列 cn は、(name) で示される name 列値にマップされています。name 列は複数値列でないため、rpc.nisd によって cn 値ごとに 1 つの NIS+ エントリが作成されます。

最後に、削除に使用するルールセットの例を、nisplusLDAPattributeFromColumn 値を使って説明します。

nisplusLDAPattributeFromColumn \
user_attr_del:	dn=("uid=%s,", name), \
						SolarisUserQualifier=, \
						SolarisAttrReserved1=, \
 						SolarisAttrReserved2=, \
						SolarisAttrKeyValue= 

すでに述べたように、user_attr.org_dir データは、 ほかのテーブル (passwd.org_dir など) のアカウント情報と、 ou=People コンテナを共有しています。user_attr.org_dir テーブルのエントリが削除されたときに、 ou=People エントリ全体を削除したいとはおそらく考えないでしょう。この例ではエントリ全体を削除する代わりに、user_attr.org_dir エントリが削除されたときに、SolarisUserQualifier 、SolarisAttrReserved1、SolarisAttrReserved2 、および SolarisAttrKeyValue 属性が存在する場合、次のルールに指定されている ou=People エントリから削除されます。

dn=("uid=%s,", name)

これ以外の LDAP エントリは変更されません。

NIS+ から LDAP への移行シナリオ

NIS+ から LDAP への移行シナリオの例を挙げます。

• すべての NIS+ クライアントを 1 回の操作で LDAP に変換する場合。rpc.nisd デーモンを使用すれば、LDAP に存在しないすべての NIS+ データをアップロードできます。「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」 を参照してください。

• NIS+ から LDAP に段階的に移行する場合。まず、NIS+ データを LDAP に変換します (「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」 を参照)。 NIS+ クライアントと LDAP クライアントで、同じネームサービスを共有することができます。NIS+ および LDAP のデータは、rpc.nisd によって自動的に同期化されます。移行の初期段階では場合によって、NIS+ が認証されたサーバーとして機能し、LDAP サーバーは、NIS+ データを複製して、LDAP クライアントに提供します。適切な段階で、LDAP を認証されたネームサービスに移行します。NIS+ サービスは、段階的に処理を停止していき、NIS+ クライアントの移行が完了した時点で完全になくなります。

• LDAP がすでにネームサービスとして使用されている場合。NIS+ データと LDAP データをマージする必要があります。次の 3 つのマージ方法があります。

  • NIS+ データを LDAP に追加する方法。NIS+ に存在するが LDAP に存在しないエントリが、LDAP に追加されます。エントリが NIS+ および LDAP の両方に存在するが、データが異なる場合は、NIS+ データが優先されます。「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」 を参照してください。

  • NIS+ データを LDAP データで上書きする方法。NIS+ に存在するが LDAP に存在しないエントリが、NIS+ から削除されます。 NIS+ および LDAP の両方に存在するエントリでは、 LDAP データが優先されます。「すべての LDAP データを 1 回の操作で NIS+ に変換する方法」 を参照してください。

  • NIS+ データと LDAP データをマージする方法。衝突が発生した場合は、個別に解決します。「NIS+ データと LDAP データのマージ」 を参照してください。

すべての NIS+ データを 1 回の操作で LDAP に変換する方法

1. rpc.nisd を使用して、LDAP に存在しない NIS+ データをすべてアップロードします。

   NIS+ と LDAP のすべてのデータマッピングが、デフォルトの場所 (/var/nis/NIS+LDAPmapping) に設定されている場合は、次のコマンドを使用します。

   # /usr/sbin/rpc.nisd -D \

   -x nisplusLDAPinitialUpdateAction=to_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

   上記のコマンドによって、rpc.nisd デーモンによりデータが LDAP にアップロードされて、変換が終了します。この処理を実行しても、NIS+ データは変更されません。

   rpc.nisd(4) のマニュアルページの nisplusLDAPinitialUpdateAction 属性を参照してください。

すべての LDAP データを 1 回の操作で NIS+ に変換する方法

1. rpc.nisd を使用して、すべての LDAP データを NIS+ にダウンロードし、既存の NIS+ データを上書きします。

   NIS+ と LDAP のすべてのデータマッピングが、デフォルトの場所 (/var/nis/NIS+LDAPmapping) に設定されている場合は、次のコマンドを使用します。

   # /usr/sbin/rpc.nisd -D \

   -x nisplusLDAPinitialUpdateAction=from_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

   上記のコマンドによって、rpc.nisd デーモンによりデータが LDAP からダウンロードされて、変換が終了します。この処理を実行しても、LDAP データは変更されません。

   rpc.nisd(4) のマニュアルページの nisplusLDAPinitialUpdateAction 属性を参照してください。

NIS+ データと LDAP データのマージ

NIS+ および LDAP 間でデータの衝突が発生したときは、NIS+ または LDAP データのどちらかを正式なものとして解決しなければなりません。「NIS+ から LDAP への移行シナリオ」 では、NIS+ データと LDAP データを同期化する方法について説明しています。データをマージするときは、ほかの方法と比べて複雑な手順が必要になります。

この節で挙げた手順では、次の点を前提としています。

• NIS+ データのバックアップを /nisbackup ディレクトリに作成する

• 有効なマッピング構成が /etc/default/rpc.nisd および /var/nis/tmpmap (テーブルをマージする場合) にすでに存在する

• マージ前の NIS+ データのフラットファイル表現を /before に格納し、マージ後は /after に格納する。

• niscat は、nisaddent(1M) でサポートされないカスタム NIS+ テーブルを、フラットファイル表現でダンプするときに使用する。このようなカスタムテーブルを、NIS+ からまたは NIS+ にダンプして読み込むために、独自のコマンドまたはスクリプトを作成することがある。この場合は、niscat に優先して、独自のコマンドまたはスクリプトを使用する。niscat コマンドには、フラットファイル表現のデータを NIS+ に戻す便利な方法がないためである

  niscat(1) を使用してデータをダンプした場合は、nistbladm(1) を使用すれば、エントリ単位に NIS+ に戻すことができる

• コマンドパスに /usr/lib/nis (nisaddent(1M) が存在する場所) を含める

NIS+ データと LDAP データをマージする方法

手順 4 のダウンロードデータと、手順 10 のアップロードデータが一致しない場合は、アップロードデータによって変更が上書きされます。このため、この手順を実行しているときは、LDAP データの変更はできるだけ避けてください。詳細については、LDAP サーバーのマニュアルを参照してください。

1. nisbackup コマンドを使用して、すべての NIS+ データをバックアップします。

   # nisbackup -a /nisbackup

2. LDAP とマージするデータが含まれる NIS+ テーブルを特定します。これらのテーブルの内容をフラットファイルにダンプします。たとえば、次のように nisaddent を使用して、group.org_dir の内容をダンプします。

   # nisaddent -d group | sort> /before/group

   パイプを使って nisaddent の出力を sort の入力として渡すと、比較処理が簡単になります。

3. rpc.nisd デーモンを停止します。

   # pkill rpc.nisd

4. LDAP データを NIS+ にダウンロードします。

   # /usr/sbin/rpc.nisd -D -m tmpmap \

   -x nisplusLDAPinitialUpdateAction=from_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

5. rpc.nisd デーモンを起動します。

   # /usr/sbin/rpc.nisd

   rpc.nisd デーモンが、LDAP からダウンロードしたデータを提供するようになります。解決を必要とする衝突を NIS+ クライアント上で発生させないようにする必要がある場合は、これ以降の手順は、ほとんどまたはすべての NIS+ クライアントが動作していないときに実行してください。

6. 影響を受けるテーブルの NIS+ データをダンプします。

   次の例では、 group.org_dir テーブルをダンプします。

   # nisaddent -d group | sort> /after/group

7. 任意のファイルマージ手順を使用して、マージしたテーブルを作成します。diff(1) 以外のツールを使用できない場合は、このコマンドを使用して /before ファイルと /after ファイルとの相違点を収集し、テキストエディタを使用して手動でマージすることができます。

   次の例では、マージ後のテーブルが /after に格納されていることを前提としています。

8. マージ後のデータを NIS+ に読み込みます。次の例では、 group テーブルを読み込みます。

   # nisaddent -m -f /after/group group

9. マージ後のテーブルから、不要な LDAP エントリを削除します。

   A . マージ後の NIS+ データ内に存在しない LDAP エントリが、アップロード後の LDAP に必要がない場合、これらの LDAP エントリは削除する必要があります。

   LDAP サーバーには、コンテナのすべてのエントリを削除する方法など、複数のエントリを削除する便利な方法が提供されていることがあります。提供されていない場合は、ldapsearch(1) を使用して、各コンテナのエントリの一覧を生成することができます。たとえば、ou=Rpc コンテナに含まれるすべてのエントリの一覧を生成するには、ldapsearch(1) を次のように使用します。

   # ldapsearch -h server-address -D bind-DN -w password \

   -b ou=Rpc,search-base 'objectClass=*' dn | \

   grep -i ou=Rpc | grep -v -i \^ou=Rpc> \

   /tmp/delete-dn

   メタ引数 (server-address、 bind-DN など) については、「パフォーマンスとインデックス処理」 を参照してください。

   B. 結果ファイル (/tmp/delete-dn) を編集して、削除するエントリだけを指定します。コンテナのすべてのエントリを削除する場合は、該当するファイルは操作しないで、NIS+ アップロードを使用して LDAP データを復元することもできます。どちらの方法を使用する場合でも、LDAP データをバックアップしてから、次の ldapdelete 操作を実行してください。

   C. ldapdelete を使用して、LDAP エントリを削除します。stdout (通常は、削除したエントリごとに空白行が 1 行ずつ出力される) は、/dev/null にリダイレクトします。

   # ldapdelete -h server-address -D bind-DN -w password \

   /tmp/delete-dn /dev/null

   D. 削除するエントリが 1 つ以上含まれるコンテナごとに、前述の手順を繰り返します。

10. これで NIS+ には、マージされたデータが生成されます。このデータは、LDAP にアップロードできます。 次の操作を実行します。

    rpc.nisd デーモンを停止します。

    # pkill rpc.nisd

    アップロードを実行します。

    # /usr/sbin/rpc.nisd -D -m tmpmap \

    -x nisplusLDAPinitialUpdateAction=to_ldap \

    -x nisplusLDAPinitialUpdateOnly=yes

11. rpc.nisd デーモンを再起動します。

    • rpc.nisd デーモンが LDAP リポジトリを使用する場合は、適切なマッピングファイルを指定します。

    • rpc.nisd デーモンを NIS (YP) エミュレーションに対応させる場合は、-Y オプションを指定します。

    # /usr/sbin/rpc.nisd -m mappingfile [ -Y ]

    手順 10 のアップロードコマンドから、-x nisplusLDAPinitialUpdateOnly=yes を省略することもできます。省略した場合、アップロードが完了すると、rpc.nisd デーモンは NIS+ データの提供を開始します。

マスターと複製

NIS+ マスターだけが、データを LDAP に書き込むことができます。NIS+ 複製は、NIS+ マスターから更新を取得するか (LDAP から取得する場合を含む) 、LDAP サーバーから直接データを読み込みます。この 2 つの方法を組み合わせることもできます。つまり、NIS+ 複製を使用するときは、主に 2 つの方法があります。

• NIS+ 複製は変更せずに使用し、更新データは NIS+ マスターから取得する

  この方法の場合は、NIS+ マスター以外は、LDAP サーバーと接続する必要がないため、構成が単純になります。従来の複製関係も変更されません。つまり、 新しいデータはまずマスターに反映され、次に複製に反映されます。ネームサービスのデータを従来どおり NIS+ が管理するときは、ほとんどの場合、この方法が最も便利な方法です。ただし、LDAP と NIS+ 複製サーバーとの間のパスが長くなります。

• NIS+ 複製は、更新データを NIS+ マスターから取得しないで、LDAP から直接取得する

  この場合、複製のデータの更新は、LDAP から取得したデータのルックアップトラフィックおよび TTL に基づいて、NIS+ マスターの更新前または更新後に行われます。この方法はより複雑ですが、LDAP がネームサービスリポジトリを管理するときは、便利な方法です。NIS+ データに対する直接の更新は、ほとんどまたはまったく発生しません。

複製タイムスタンプ

NIS+ 複製が特定の NIS+ ディレクトリに含まれる 1 つ以上のオブジェクトのデータを LDAP から取得しているときは、nisping(1M) によって出力される更新タイムスタンプが NIS+ マスターおよび NIS+ 複製間のデータの整合性を示しているとは限りません。たとえば、NIS+ ディレクトリ dir1 に table1 および table2 テーブルが含まれているとします。 複製が table1 および table2 のデータを NIS+ マスターから取得しているときは、次のようなタイムスタンプが出力されます。

# nisping dir1

Master server is "master.some.domain."
Last update occurred at Mon Aug  5 22:11:09 2002

Replica server is "replica.some.domain." 		
	Last Update seen was Mon Aug  5 22:11:09 2002

これらのタイムスタンプは、マスターおよび複製のデータが完全に一致していることを示しています。しかし、複製が table1 または table2、あるいはその両方のデータを LDAP から取得しているとします。この場合、この出力には、複製がマスターから NIS_PING を受け取り、再同期化のタイムスタンプをシステム管理用に更新したことだけが示されます。LDAP に対応づけられているテーブルのデータは、次のどちらかの場合、NIS+ マスター上のデータと異なることがあります。

• LDAPデータが NIS+ マスター上のデータと異なる

• 期限切れではないが、LDAP と同期がとれていない複製のキャッシュに NIS+ データベースのデータが格納されている

このようなデータの不一致を許容できない場合は、NIS+ 複製が常に NIS+ マスターからデータを取得するようにします。NIS+ マスターが常に LDAP からデータを取得するように構成した場合は、複製を変更する必要はありません。

ディレクトリサーバー

rpc.nisd デーモンの LDAP マッピングでは、LDAP プロトコルバージョン 3 を使用して LDAP サーバーと対話します。 デフォルトのマッピング構成 ( /var/nis/NIS+LDAPmapping.template) では、LDAP サーバーが RFC 2307 の拡張版 に準拠していることを前提としています。RFC は、 http://www.ietf.org/rfc.html から入手できます。 NIS+ データと LDAP データとのマッピングは、NIS+LDAPmapping(4) を使用して変更できます。ただし、LDAP のデータ編成が RFC 2307 の規定に準拠していることを、基本的な前提としています。

たとえば、LDAP クライアントと NIS+ クライアントとの間でアカウント情報を共有するには、UNIX crypt 書式のアカウント (ユーザー) パスワードを LDAP サーバーに格納できるようにする必要があります。LDAP サーバーをこのように構成できない場合でも、アカウントを含む NIS+ データを LDAP に格納することはできます。 その場合、NIS+ ユーザーと LDAP bindDN との間でアカウント情報を完全に共有することはできません。

iPlanet Directory Server 5.1 の構成

iPlanet Directory Server 5.1 のインストール、設定、および管理の詳細については、「iPlanet^TM Directory Server 5.1 Collection」を参照してください。

iPlanet Directory Server バージョン 5.1 を構成して、LDAP クライアントが LDAP をネームサービスとして使用できる ようにするには、idsconfig(1M) を使用します。idsconfig(1M) を使用して設定した構成は、NIS+ で LDAP データリポジトリを使用する場合にも適しています。

iPlanet Directory Server 5.1 以外の LDAP サーバーを使用している場合は、RFC 2307 に準拠するように、サーバーを手動で構成する必要があります。

idsconfig の詳細については、マニュアルページを参照してください。

サーバーアドレスとポート番号の割り当て

/etc/default/rpc.nisd ファイルは、ローカル LDAP サーバーをポート 389 で使用するように設定されています。この設定が現在の構成に適していない場合は、preferredServerList 属性に新しい値を設定します。たとえば、LDAP サーバーを IP アドレス 192.0.0.1 とポート 65535 で使用するには、次のように指定します。

preferredServerList=192.0.0.1:65535

セキュリティと認証

NIS+ クライアントおよび NIS+ サーバー間の認証は、NIS+ サーバーが LDAP からデータを取得する場合でも、影響することはありません。ただし、NIS+ データを LDAP に格納するときの整合性を保持するには、rpc.nisd デーモンおよび LDAP サーバー間の認証を必要に応じて設定する必要があります。LDAP サーバーの機能に応じて、さまざまなタイプの認証を利用できます。

rpc.nisd デーモンでは、次の LDAP 認証を利用できます。

• none

  none は、デフォルトの認証方式です。none には、固有の設定は必要ありません。ただし、セキュリティは保証されません。セキュリティを考慮する必要がない環境だけで使用してください。

  none 認証を使用するときは、 authenticationMethod 属性に次の値を設定してください。

  authenticationMethod=none

この認証方式を利用するときに一定のセキュリティを保証するには、多くの場合、共有された機密情報 (パスワードまたは鍵) と LDAP の DN を関連付ける必要があります。rpc.nisd デーモンで使用する DN は一意なものであり、ほかの目的で使用することもできます。予測される LDAP トラフィックに対応するために、DN には適切な権限を割り当てる必要があります。たとえば、rpc.nisd デーモンが LDAP にデータを書き込む場合は、NIS+ データに使用されるコンテナ内で LDAP データを追加、更新、および削除する権限を、選択した DN に割り当てる必要があります。また、LDAP サーバーでは、リソースの使用方法がデフォルトで制限されている場合があります (検索時間制限、検索結果のサイズ制限など) 。この制限がある場合は、必要な数の NIS+ データコンテナをサポートできるように、選択した DN に対して必要な設定をする必要があります。

• simple

  simple 認証方式では、暗号化されていないパスワード文字列が交換されます。パスワードは、LDAP クライアント (rpc.nisd デーモン) および LDAP サーバー間をプレーンテキストとして送信されます。このため、simple 方式は、NIS+ と LDAP サーバー間の情報交換が別の方式で保護されている場合にだけ使用してください。

  たとえば、LDAP トラフィックのトランポート層を暗号化するときに使用します。また、NIS+ サーバーと LDAP サーバーが同一システム上にあり、NIS+ および LDAP のトラフィックがカーネル内で処理され、認証されていないユーザーから保護されている場合にも使用できます。

  simple 認証を使用するときは、rpc.nisd デーモンで使用する DN と パスワードの構成を変更してください。たとえば、DN が cn=nisplusAdmin、ou=People、dc=some、dc=domain で、パスワードが aword の場合は、次のように設定します。

  authenticationMethod=simple nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  パスワードが格納されている場所は、認証されないアクセスから確実に保護する必要があります。パスワードを rpc.nisd コマンド行で指定した場合は、ps(1) などのコマンドを使ってシステム上の任意のユーザーに見られる可能性があります。

• sasl/digest-md5

  sasl/digest-md5 認証方式では、digest/md5 アルゴリズムを使用して認証が行われます。

  digest-md5 で使用する認証 ID を設定する方法と、/etc/default/rpc.nisd ファイルに認証 ID とその パスワードを指定する方法については、LDAP サーバーのマニュアルを参照してください。

  authenticationMethod=sasl/digest-md5 nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  パスワードが格納されているファイルは、認証されないアクセスから確実に保護する必要があります。

• sasl/cram-md5

  cram/md5 アルゴリズムを使用した認証方式。通常は、現在使用されていない SunDS LDAP サーバー以外では使用されません。

  cram-md5 を使用してバインド DN を設定する方法と、/etc/default/rpc.nisd ファイルにバインド DN とそのパスワードを指定する方法については、LDAP サーバーのマニュアルを参照してください。

  authenticationMethod=sasl/cram-md5 nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  承認されていないアクセスからパスワードを格納するファイルを確実に保護してください。

SSL の使用

rpc.nisd デーモンは、SSL を使用した LDAP トラフィックのトランスポート層の暗号化にも対応しています。LDAP サーバー認証用の SSL 証明書の生成については、LDAP サーバーのマニュアルを参照してください。SSL 証明書は、NIS+ サーバー上のファイル (/var/nis/cert7.db など) に格納します。/etc/default/rpc.nisd は、次のように変更します。

nisplusLDAPTLS=ssl 
nisplusLDAPTLSCertificateDBPath=/var/nis/cert7.db 

SSL 証明書は、承認されていないアクセスから確実に保護する必要があります。この例では、セッションの暗号化と LDAP サーバーの認証が rpc.nisd に提供されます。 SSL 証明書では、LDAP サーバーに対する rpc.nisd の認証は提供されません。この証明書には、この LDAP クライアント (rpc.nisd ) の識別情報が含まれていないためです。ただし、rpc.nisd と LDAP サーバーが相互に認証するには、SSL と別の認証方式 (simple、sasl/digest-md5) を組み合わせることができます。

LDAP のセキュリティの詳細については、「LDAP ネームサービスのセキュリティモデル」を参照してください。

パフォーマンスとインデックス処理

niscat(1) などを使用して、LDAP に対応づけられた NIS+ テーブルの列挙を rpc.nisd デーモンに 要求すると、テーブル内のエントリの TTL が 1 つでも期限切れになっている場合は、対応する LDAP コンテナが列挙されます。コンテナの列挙はバックグラウンドで実行されるため、LDAP のパフォーマンスはそれほど重要ではありません。ただし、LDAP にインデックスを設定すれば、コンテナが大きい場合でもすばやく列挙することができます。

特定のコンテナの列挙に必要な時間を見積もるには、次のようなコマンドを使用します。

% /bin/time ldapsearch -h server-address -D bind-DN -w password \

-b container, search-base 'cn=*' /dev/null

ここで

• server-address

  /etc/default/rpc.nisd の preferredServerList 値の IP アドレス部分

• bind-DN

  /etc/default/rpc.nisd の nisplusLDAPproxyUser 値

• password

  /etc/default/rpc.nisd の nisplusLDAPproxyPassword 値

• container

  RFC 2307 に準拠したコンテナ名 (ou=Services、 ou=Rpc など)

• search-base

  /etc/default/rpc.nisd の defaultSearchBase 値

/bin/time から出力される実際の値は、経過時間です。この値が、対応するテーブルエントリの TTL を 25 パーセント以上占めている場合は (「認証とセキュリティ」 を参照)、LDAP コンテナにインデックスを設定すると有効です。

rpc.nisd では、simple page と VLV インデックス方式がサポートされます。ご使用の LDAP サーバーでサポートされているインデックス方式、およびそのインデックスの作成方法については、LDAP サーバーのマニュアルを参照してください。

テーブルエントリ以外の NIS+ オブジェクトのマッピング

テーブルエントリ以外の NIS+ オブジェクトを LDAP に格納できます。ただし、NIS+ 複製が LDAP からこれらの NIS+ オブジェクトを取得しない限り、LDAP に格納しても値は設定されません。次の方法をお勧めします。

• 複製がない場合、または複製が NIS+ オブジェクトを NIS+ マスターだけから取得する場合。

  マッピング構成ファイル ( NIS+LDAPmapping(4) のマニュアルページを参照) を編集して、テーブルエントリ以外のオブジェクトから次の属性値を削除します。

  nisplusLDAPdatabaseIdMapping nisplusLDAPentryTtl nisplusLDAPobjectDN

  たとえば、/var/nis/NIS+LDAPmapping.template ファイルの場合は、次のセクションを削除するか、コメントにして無効にします。

  # Standard NIS+ directories nisplusLDAPdatabaseIdMapping basedir: . . .

  nisplusLDAPdatabaseIdMapping user_attr_table:user_attr.org_dir

  nisplusLDAPdatabaseIdMapping audit_user_table:audit_user.org_dir # Standard NIS+ directories nisplusLDAPentryTtl basedir:21600:43200:43200 . . .

  nisplusLDAPentryTtl user_attr_table:21600:43200:43200 nisplusLDAPentryTtl audit_user_table:21600:43200:43200 # Standard NIS+ directories nisplusLDAPobjectDN basedir:cn=basedir,ou=nisPlus,?base?\

  objectClass=nisplusObjectContainer:\ cn=basedir,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer,\ objectClass=top . . .

  nisplusLDAPobjectDN audit_user_table:cn=audit_user,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer:\ cn=audit_user,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer,\ objectClass=top

• NIS+ 複製が NIS+ オブジェクトを LDAP サーバーから取得する場合。

  nisplusObject の属性と nisplusObjectContainer のオブジェクトクラスを以下の例にしたがって作成します。LDIF データは ldapadd(1) に適しています。属性とオブジェクトクラス OID は、例としてあげているだけです。

  dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.1.0 NAME 'nisplusObject' \ DESC 'An opaque representation of an NIS+ object' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )

  dn: cn=schema changetype: modify add: objectclasses

  objectclasses(1.3.6.1.4.1.42.2.27.5.42.42.2.0 NAME'nisplusObjectContainer'\

  SUP top STRUCTURAL DESC 'Abstraction of an NIS+ object MUST ( cn $ nisplusObject ) )

  NIS+ オブジェクトのコンテナも作成する必要があります。次の LDIF 構文は、ou=nisPlus,dc=some,dc=domain コンテナの作成方法を示しています。このコンテナは、ldapadd(1) の入力として使用できます。

  dn: ou=nisPlus,dc=some,dc=domain ou: nisPlus objectClass: top objectClass: organizationalUnit

NIS+ エントリの所有者、グループ、アクセス権、および TTL

NIS+ テーブルエントリを LDAP データから作成するときは、そのエントリオブジェクトが存在するテーブルオブジェクトの対応する値を使用して、所有者、グループ、アクセス権、および TTL を初期化する必要があります。環境によっては、これらの NIS+ エントリ属性を個別に設定する必要があります。たとえば、rpc.nispasswdd(1M) デーモンを使用しない環境では、この操作が必要になります。ユーザー自身が NIS+ パスワードを変更して、cred.org_dir テーブルに格納されている Diffie-Hellman キーを再暗号化できるようにするには、passwd.org_dir および cred.org_dir エントリの所有者をそのユーザーに設定し、その所有者に変更権限を割り当てる必要があります。

1 つ以上の NIS+ テーブルエントリの所有者、グループ、アクセス権、または TTL を LDAP に格納するには、次の操作を実行する必要があります。

エントリ属性を LDAP に追加するには

1. LDAP サーバーのマニュアルを参照して、次の新しい属性とオブジェクトクラスを作成します。LDIF データは、ldapadd に適用できます。属性とオブジェクトクラス OID は、例として挙げています。

   dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.0 NAME 'nisplusEntryOwner' \ DESC 'Opaque representation of NIS+ entry owner' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.1 NAME 'nisplusEntryGroup' \ DESC 'Opaque representation of NIS+ entry group' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.2 NAME 'nisplusEntryAccess' \ DESC 'Opaque representation of NIS+ entry access' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.3 NAME 'nisplusEntryTtl' \ DESC 'Opaque representation of NIS+ entry TTL' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   dn: cn=schema changetype: modify add: objectclasses

   objectclasses:(1.3.6.1.4.1.42.2.27.5.42.42.5.0 NAME 'nisplusEntryData'\ SUP top STRUCTURAL DESC 'NIS+ entry object non-column data'\

   MUST ( cn ) MAY ( nisplusEntryOwner $ nisplusEntryGroup $\ nisplusEntryAccess $ nisplusEntryTtl ) )

2. 関連するテーブルの nisplusLDAPobjectDN 属性値を変更して、新しく作成した nisplusEntryData オブジェクトクラスを書き込み部分に含めます。

   たとえば、passwd.org_dir テーブルの場合、 /var/nis/NIS+LDAPmapping.template をベースにしたテンプレートファイルを使用しているときは、次のように編集します。

   nisplusLDAPobjectDN passwd:ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount:\ ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount,\ objectClass=account,objectClass=top

   属性値を次のように編集します。

   nisplusLDAPobjectDN passwd:ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount:\ ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount,\ objectClass=nisplusEntryData,\ objectClass=account,objectClass=top

3. nisplusLDAPattributeFromColumn 属性値および nisplusLDAPcolumnFromAttribute 属性値を編集して、所有者、グループ、アクセス権、または TTL を必要に応じて指定します。

   手順 2 で、これらの値を格納する LDAP 属性を作成しました。NIS+ には、zo_owner 、zo_group、zo_access、および zo_ttl と呼ばれる定義済みの擬似列名が、あらかじめ定義されています。たとえば、passwd.org_dir エントリの所有者、グループ、およびアクセス権を LDAP に格納するには、次の nisplusLDAPattributeFromColumn 値を変更します。

   nisplusLDAPattributeFromColumn \ passwd: dn=("uid=%s,", name), \ cn=name, \ uid=name, \ userPassword=("{crypt$}%s", passwd), \ uidNumber=uid, \ gidNumber=gid, \ gecos=gcos, \ homeDirectory=home, \ loginShell=shell, \ (shadowLastChange,shadowMin,shadowMax, \ shadowWarning, shadowInactive,shadowExpire)=\ (shadow, ":")

   次のように編集します。

   nisplusLDAPattributeFromColumn \ passwd: dn=("uid=%s,", name), \ cn=name, \ uid=name, \ userPassword=("{crypt$}%s", passwd), \ uidNumber=uid, \ gidNumber=gid, \ gecos=gcos, \ homeDirectory=home, \ loginShell=shell, \ (shadowLastChange,shadowMin,shadowMax, \ shadowWarning, shadowInactive,shadowExpire)=\ (shadow, ":"), \ nisplusEntryOwner=zo_owner, \ nisplusEntryGroup=zo_group, \ nisplusEntryAccess=zo_access

   同様に、 NIS+ エントリの所有者、グループ、LDAP データからのアクセス権を passwd.org_dir テーブルに設定するには、次の値を変更します。

   nisplusLDAPcolumnFromAttribute \ passwd: name=uid, \ ("{crypt$}%s", passwd)=userPassword, \ uid=uidNumber, \ gid=gidNumber, \ gcos=gecos, \ home=homeDirectory, \ shell=loginShell, \ shadow=("%s:%s:%s:%s:%s:%s", \ shadowLastChange, \ shadowMin, \ shadowMax, \ shadowWarning, \ shadowInactive, \ shadowExpire)

   次のように編集します。

   nisplusLDAPcolumnFromAttribute \ passwd: name=uid, \ ("crypt$%s", passwd)=authPassword, \ uid=uidNumber, \ gid=gidNumber, \ gcos=gecos, \ home=homeDirectory, \ shell=loginShell, \ shadow=("%s:%s:%s:%s:%s:%s", \ shadowLastChange, \ shadowMin, \ shadowMax, \ shadowWarning, \ shadowInactive, \ shadowExpire), \ zo_owner=nisplusEntryOwner, \ zo_group=nisplusEntryGroup, \ zo_access=nisplusEntryAccess

4. マッピングの変更を有効にするために、rpc.nisd デーモンを再起動します。

   まず、所有者、グループ、アクセス権、および TTL エントリデータを LDAP にアップロードする必要があります。アップロード方法については、「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」 を参照してください。

主体名とネット名

NIS+ 認証は、主体名 (ドメイン名で修飾されたユーザー名またはホスト名) とネット名 (SecureRPC での主体名) に基づいて認証可能なエンティティ (主体) を一意に識別します。RFC 2307 では、NIS+ 認証に使用する Diffie-Hellman 鍵の格納場所は規定していますが、主体名またはネット名の格納場所は規定していません。

/var/nis/NIS+LDAPmapping.template ファイルでは、この問題を回避するために、cred.org_dir テーブルの所有者名 (主体名) から主体名およびネット名のドメイン部分を派生します。つまり、NIS+ ドメインが x.y.z. で、cred.org_dir テーブルの所有者が aaa.x.y.z. の場合、LDAP データから作成された NIS+ エントリの主体名は、次の形式になります。

user or system.x.y.z.

ネット名は次の形式になります。

unix.uid@x.y.z.

unix.nodename@x.y.z.

ほとんどの NIS+ インストールでは、主体名とネット名を作成するときは、この方式でかまいません。ただし、次のような場合は、この方式では成功しません。

• cred.org_dir テーブルの所有者名が属しているドメインが、cred.org_dir テーブル内の主体名およびネット名によって共有されるドメインと一致していない場合。所有者が親ドメインの主体である場合は、サブドメインの cred.org_dir テーブルも同様です。この問題は、次のいずれかの方法で解決できます。

  • cred.org_dir テーブルの所有者を変更して、テーブルエントリのドメインと一致させます。

  • cred.org_dir データベース ID のマッピングルールを変更して、ほかの NIS+ オブジェクトの所有者を使用します。適切なオブジェクトが存在しない場合は、この目的のために NIS+ オブジェクトを作成します。

    たとえば、 sub.dom.ain ドメイン内の cred.org_dir テーブルを master.dom.ain. が所有し、 cred.org_dir.sub.dom.ain. の主体とネット名が sub.dom.ain に属している場合は、次のようなリンクオブジェクトを作成します。

    # nisln cred.org_dir.sub.dom.ain. \

    credname.sub.dom.ain.

    リンクオブジェクトの所有者を、次のように sub.dom.ain. 内の適切な主体に設定します。

    # nischown trusted.sub.dom.ain. credname.sub.dom.ain.

    マッピングファイルを編集します。次の箇所を

    (nis+:zo_owner[]cred.org_dir, "*.%s")), \

    to

    (nis+:zo_owner[]credname.sub.dom.ain., "*.%s")), \

    ここで使用しているリンクオブジェクト credname は、例として挙げています。エントリオブジェクト以外の、任意の有効なオブジェクトタイプとオブジェクト名が使用できます。オブジェクトの所有者に正しいドメイン名を設定することが重要です。

  • 主体およびネット名に使用されるドメインの主体に対して、特別な目的のオブジェクトであってもその所有権を与えたくない場合は、次に示すように nisplusPrincipalName 属性と nisplusNetname 属性を作成します。

• cred.org_dir テーブルに、複数のドメインに属している主体とネット名が設定されている場合。

  LDAP サーバーのマニュアルを参照して、 nisplusPrincipalName 属性および nisplusNetname 属性と、nisplusAuthName オブジェクトクラスを作成します。以下のデータは ldapadd への LDIF データになっています。属性とオブジェクトクラス OID は、例として挙げています。

  dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.7.0 NAME 'nisplusPrincipalName' \ DESC 'NIS+ principal name' \ SINGLE-VALUE \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

  attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.9.0 NAME 'nisplusNetname' \ DESC 'Secure RPC netname' \ SINGLE-VALUE \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.42.2.27.5.42.42.10.0 NAME 'nisplusAuthName' \ SUP top AUXILLIARY DESC 'NIS+ authentication identifiers' \ MAY ( nisplusPrincipalName $ nisplusNetname ) )

  cred.org_dir マッピングで、新しく作成した nisplusNetname 属性および nisplusPrincipalName 属性を使用できるようにする必要があります。テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template では、この目的に対応した行がコメントになっています。 credlocal、creduser、および crednode データベース ID については、 nisplusObjectDN、nisplusLDAPattributeFromColumn 属性、および nisplusLDAPcolumnFromAttribute 属性の値を参照してください。マッピングファイルの編集が終了したら、 rpc.nisd デーモンを再起動します。マッピングファイルがデフォルトでない場合は、-m オプションを追加してください。また、rpc.nisd デーモンを NIS (YP) エミュレーションに対応させる場合は、 -Y オプションを追加してください。

  # pkill rpc.nisd

  # /usr/sbin/rpc.nisd -m mapping-file [-Y]

client_info および timezone テーブル

RFC 2307 では、NIS+ の client_info.org_dir および timezone.org_dir テーブルに保存する情報は規定していません。このため、これらのテーブルのマッピングは、テンプレートマッピングファイル (/var/nis/NIS+LDAPmapping.template) ではデフォルトで無効になっています。client_info および timezone の情報を LDAP に保存する場合は、LDAP サーバーのマニュアルを参照しながら、以降の節で説明する新しい属性とオブジェクトクラスを作成します。

client_info 属性とオブジェクトクラス

次のような属性とオブジェクトクラスを作成し、client_info データのコンテナを作成します。推奨コンテナ名は ou=ClientInfo です。LDIF データは ldapadd(1) に適用します。属性とオブジェクトクラス OID は、例として挙げています。

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.0 \
		  NAME 'nisplusClientInfoAttr' \
		  DESC 'NIS+ client_info table client column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.1 \
		  NAME 'nisplusClientInfoInfo' \
		  DESC 'NIS+ client_info table info column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.2 \
		  NAME 'nisplusClientInfoFlags' \
		  DESC 'NIS+ client_info table flags column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.13.0 \
		  NAME 'nisplusClientInfoData' \
		  DESC 'NIS+ client_info table data' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( nisplusClientInfoAttr $ nisplusClientInfoInfo $ nisplusClientInfoFlags ) )

コンテナを作成するには、次の LDIF データをファイルに入力します。実際の検索ベースを searchBase に代入します。

dn: ou=ClientInfo, searchBase

objectClass: organizationalUnit

ou: ClientInfo

objectClass: top

ou=ClientInfo コンテナを作成するために、上記のファイルを ldapadd コマンドの入力として使用します。たとえば、LDAP 管理者の DN が cn=directory manager で、LDIF データが含まれるファイルが cifile の場合は、次のコマンドを実行します。

# ldapadd -D cn="directory manager" -f cifile

必要な認証によっては、ldapadd コマンドを実行すると、パスワードプロンプトが表示されることがあります。

/var/nis/NIS+LDAPmapping.template ファイルでは、client_info.org_dir テーブルの定義はコメントになっています。これらの定義を実際のマッピングファイルにコピーし、コメント文字「#」を削除して定義を有効にしてから、rpc.nisd デーモンを再起動します。必要に応じて、NIS+ データと LDAP データを同期化します。方法については、「NIS+ から LDAP への移行シナリオ」 を参照してください。

timezone 属性とオブジェクトクラス

次のような属性とオブジェクトクラスを作成し、タイムゾーンデータのコンテナを作成します。推奨コンテナ名は ou=Timezone です。LDIF データは ldapadd(1) に適用できます。属性とオブジェクトクラス OID は、例として挙げています。

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.15.0 NAME 'nisplusTimeZone' \
		  DESC 'tzone column from NIS+ timezone table' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.16.0 NAME 'nisplusTimeZoneData' \
		  DESC 'NIS+ timezone table data' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( nisplusTimeZone $ description ) )

ou=Timezone コンテナを作成するには、次の LDIF データをファイルに入力します。実際の検索ベースを searchBase に代入します。

dn: ou=Timezone,searchBase ou: Timezone objectClass: top

objectClass: organizationalUnit

ou=Timezone コンテナを作成するために、上記のファイルを ldapadd(1) の入力として使用します。たとえば、LDAP 管理者の DN が cn=directory manager で、LDIF データが含まれるファイルが tzfile の場合は、次のコマンドを実行します。

# ldapadd -D cn="directory manager" -f tzfile

必要な認証によっては、ldapadd コマンドを実行すると、パスワードプロンプトが表示されることがあります。

/var/nis/NIS+LDAPmapping.template ファイルでは、timezone.org_dir テーブルの定義はコメントになっています。これらの定義を実際のマッピングファイルにコピーし、コメント文字「#」を削除して定義を有効にしてから、rpc.nisd デーモンを再起動します。必要に応じて、NIS+ データと LDAP データを同期化します。方法については、「NIS+ から LDAP への移行シナリオ」 を参照してください。

新しいオブジェクトマッピングの追加

テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template には、すべての標準 NIS+ オブジェクトのマッピング情報が含まれます。サイトまたはアプリケーション固有のオブジェクトのマッピングをサポートするには、新しいマッピングエントリを追加する必要があります。エントリ以外のオブジェクト (ディレクトリ、グループ、リンク、またはテーブル) の場合は、簡単に追加できます。しかし、エントリオブジェクトの場合、対応するエントリデータの LDAP 編成が NIS+ で使用される編成と大きく異なるときは、エントリの追加が複雑になることがあります。ここでは簡単な例を挙げます。

エントリ以外のオブジェクトを対応づけるには

1. 対応づけるオブジェクトの完全指定名を検索します。

   このオブジェクト名が nisplusLDAPbaseDomain 属性で指定されるドメイン名に存在する場合は、nisplusLDAPbaseDomain 値に等しい部分は省略できます。

   たとえば、nisplusLDAPbaseDomain の値が some.domain. で、マッピング先のオブジェクトが nodeinfo.some.domain. と呼ばれるテーブルの場合、オブジェクト名は nodeinfo に短縮できます。

2. オブジェクトを識別するデータベース ID を作成します。

   データベース ID は、使用するマッピング構成に対して一意でなければなりません。一意でない場合は解釈されません。LDAP データには、データベース ID がありません。エントリオブジェクトのマッピングと混同しないように、テーブルエントリではなくテーブルオブジェクト自体を識別するデータベース ID を作成します。ID の末尾には、_table などのわかりやすい文字列を付加します。

   たとえば、データベース ID nodeinfo_table を使用して、データベース ID とオブジェクトの接続を標準のマッピングファイルの場所 (/var/nis/NIS+LDAPmapping) で確立するには、以下を追加します。

   nisplusLDAPdatabaseIdMapping nodeinfo_table:nodeinfo.some.domain.

   nisplusLDAPbaseDomain が some.domain. の場合は、以下も機能します。

   nisplusLDAPdatabaseIdMapping nodeinfo_table:nodeinfo

3. オブジェクトの TTL を決定します。

   TTL とは、 rpc.nisd デーモンがオブジェクトのローカルコピーを有効とみなす期間のことです。TTL が期限切れになると、オブジェクトが次に参照されるときに LDAP ルックアップが初期化され、オブジェクトが更新されます。

   2 つの TTL 値があります。1 番目の TTL は、リブートまたは再起動したあとに、 rpc.nisd デーモンがディスクからオブジェクトを最初に読み込んだときに設定されます。2 番目の TTL は、LDAP から更新されたときに設定されます。1 番目の TTL は、設定した範囲からランダムに選択されます。たとえば、 nodeinfo_table の生存期間を、最初に読み込まれたときには 1 - 3 時間、次回以降に読み込まれたときは 12 時間に設定する場合は、次のように指定します。

   nisplusLDAPentryTtl nodeinfo_table:3600:10800:43200

4. オブジェクトデータを LDAP のどこに格納するかを決定します。

   テンプレートマッピングファイルでは、エントリ以外のオブジェクトの格納先が ou=nisPlus コンテナに設定されています。

   この設定を使用する場合に、適切な属性、オブジェクトクラス、およびコンテナをまだ作成していないときは、「テーブルエントリ以外の NIS+ オブジェクトのマッピング」 を参照してください。

   たとえば、nodeinfo オブジェクトを ou=nisPlus,dc=some,dc=domain コンテナに格納し、その LDAP エントリを cn nodeinfo にするとします。 次の nisplusLDAPobjectDN を作成してください。

   nisplusLDAPobjectDN nodeinfo_table:\ cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?\ objectClass=nisplusObjectContainer:\ cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?\ objectClass=nisplusObjectContainer,\ objectClass=top

   NIS+ 複製は LDAP にデータを書き込まないため、この nisplusLDAPobjectDN はマスターおよび複製の両方に対して使用できます。

5. マッピング先の NIS+ オブジェクトがまだ NIS+ に作成されていない場合は、この手順を省略できます。オブジェクトデータを LDAP に格納します。この操作には、rpc.nisd デーモンを使用できます。ただし、 nisldapmaptest(1M) ユーティリティを使用すると、より簡単に行うことができます。この場合、rpc.nisd デーモンを停止する必要はありません。

   # nisldapmaptest -m /var/nis/NIS+LDAPmapping -o -t nodeinfo -r

   -o オプションには、テーブルエントリではなく、テーブルオブジェクト自体を指定します。

6. オブジェクトデータが LDAP に格納されたことを確認します。この例では、LDAP サーバーがローカルマシンのポート 389 で動作していることを前提としています。

   # ldapsearch -b ou=nisPlus,dc=some,dc=domain cn=nodeinfo

   出力は次のようになります。

   cn=nodeinfo,ou=nisPlus,dc=some,dc=domain nisplusobject=NOT ASCII objectclass=nisplusObjectContainer objectclass=top cn=nodeinfo

7. rpc.nisd デーモンを再起動すると、新しいマッピング情報が有効になります。マッピングファイルがデフォルト以外の名前の場合には、必ず -m オプションを指定してください。rpc.nisd デーモンを NIS (YP) サービスに対応させる場合は、 -Y オプションを追加します。

   # pkill rpc.nisd

   # /usr/sbin/rpc.nisd -m mappingfile [-Y]

エントリオブジェクトの追加

NIS+LDAPmapping(4) には、テーブルエントリマッピングの構文および意味論が詳細に指定されています。また、構文要素ごとの使用例も提供されています。ただし、多くの場合、既存のマッピングから目的のマッピングに近いものを選択し、そのマッピングをコピーして変更すれば、最も簡単に行うことができ、エラーも少なくなります。

たとえば、ノードの在庫一覧と所有者情報を格納する nodeinfo という NIS+ テーブルを想定します。NIS+ テーブルは、次のコマンドを使って作成されたとします。

# nistbladm -c -D access=og=rmcd,nw=r -s : nodeinfo_tbl \

cname=S inventory=S owner= nodeinfo.`domainname`.

cname 列には、ノードの正式名が格納されます。つまり、ノードの hosts.org_dir テーブルの cname 列と同じ値が格納されます。

また、対応する情報が LDAP の ou=Hosts コンテナに格納され、nodeInfo オブジェクトクラスの必須属性が cn で、オプション属性が nodeInventory と nodeOwner であるとします。nodeInfo オブジェクトクラスは、この例のための仮想クラスで、RFC では定義されていません。

既存の nodeinfo データを LDAP にアップロードするときは、別のファイルに新しいマッピング属性を作成すれば、簡単に行うことができます。たとえば、/var/nis/tmpmapping を使用します。

1. マッピング先の NIS+ テーブルを識別するデータベース ID を作成します。

   nisplusLDAPdatabaseIdMapping nodeinfo:nodeinfo

2. nodeinfoテーブルのエントリに TTL を設定します。この情報はほとんど変更されないため、TTL を 12 時間に設定します。rpc.nisd デーモンがディスクから nodeinfo テーブルを最初に読み込むと、テーブルエントリの TTL が 6 - 12 時間からランダムに選択されます。

   nisplusLDAPentryTtl nodeinfo:21600:43200:43200

3. 既存のマッピングから、作成するマッピングに似ているものを選択します。この例では、属性値の割り当ては簡単で、直接割り当てるだけです。ただし、既存のコンテナに LDAP データを格納する処理が複雑です。このため、nodeinfo データの削除は、慎重に行う必要があります。ou=Hosts エントリ全体を削除せずに、nodeInventory および nodeOwner 属性だけを削除します。このため、特別の削除ルールが必要になります。

   つまり、コンテナを共有し削除ルールを持つマッピングを探します。この候補として netmasks マッピングがあります。このマッピングは、ou=Networks コンテナを共有し、削除ルールを持っています。

4. /var/nis/NIS+LDAPmapping.template の netmasks テンプレートマッピングでは、次のマッピングがデフォルトになっています。

   nisplusLDAPobjectDN netmasks:ou=Networks,?one?objectClass=ipNetwork,\ ipNetMaskNumber=*:\ ou=Networks,?one?objectClass=ipNetwork: dbid=netmasks_del

   このテンプレートマッピングを nodeinfo の新しいマッピングにコピーし、データベース ID を nodeinfo、コンテナを ou=Hosts、オブジェクトクラスを nodeInfo に変更します。つまり、nodeinfo マッピングの最初の行は、次のようになります。

   nisplusLDAPobjectDN nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,\

   netmasks マッピングの 2 行目は、検索フィルタ部分になっています。ipNetMaskNumber 属性を含む ou=Networks エントリだけを選択します。この例では、次の nodeInventory 属性を持つ ou=Hosts エントリを選択します。

   nodeInventory=*:\

   3、4 行目は、nisplusLDAPobjectDN の書き込み部分になっています。LDAP nodeinfo データの書き込み先と、nodeinfo データを削除するときのルールが指定されています。ここでは、データベース ID が nodeinfo_del の削除ルールを作成します。ou=Hosts の既存のエントリに常に書き込むため、次のように nodeinfo データ自体のオブジェクトクラスを指定するだけです。

   ou=Hosts,?one?objectClass=nodeInfo:\ dbid=nodeinfo_del

   この結果、nisplusLDAPobjectDN は次のようになります。

   nisplusLDAPobjectDN nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,\ nodeInventory=*:\ ou=Hosts,?one?objectClass=nodeInfo:\ dbid=nodeinfo_del

5. nodeinfo データを NIS+ から LDAP に対応づけるマッピングルールを作成します。netmasks を使用するテンプレートは、次のようになります。

   nisplusLDAPattributeFromColumn \ netmasks: dn=("ipNetworkNumber=%s,", addr), \ ipNetworkNumber=addr, \ ipNetmaskNumber=mask, \ description=comment

   ここでは、ou=Hosts コンテナはより複雑な構成になります。RFC 2307 の規定では、dn に IP アドレスを含める必要があるためです。しかし、IP アドレスは nodeinfo テーブルに格納されないため、別の方法で取得する必要があります。テンプレートファイルの crednode マッピングには、IP アドレスの取得方法が記述されています。

   nisplusLDAPattributeFromColumn \ crednode: dn=("cn=%s+ipHostNumber=%s,", \ (cname, "%s.*"), \ ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))), \

   crednodeマッピングの部分をコピーできます。ただし、ここでは、cname 列値は主体名ではなく実際のホスト名です。cname の一部を抽出する必要はありません。属性および列名を完全な名前の代入に変更します。nodeinfo マッピングは次のようになります。

   nisplusLDAPattributeFromColumn \ nodeinfo: dn=("cn=%s+ipHostNumber=%s,", cname, \ ldap:ipHostNumber:?one?("cn=%s", cname)), \ nodeInventory=inventory, \ nodeOwner=owner

6. LDAP のデータを NIS+ にマッピングするときは、 netmasks エントリのテンプレートは次のようになります。

   nisplusLDAPcolumnFromAttribute \ netmasks: addr=ipNetworkNumber, \ mask=ipNetmaskNumber, \ comment=description

   属性および列名を代入すると、次のようになります。

   nisplusLDAPcolumnFromAttribute \ nodeinfo: cname=cn, \ inventory=nodeInventory, \ owner=nodeOwner

7. netmasks の削除ルールは、次のようになっています。

   nisplusLDAPattributeFromColumn \ netmasks_del: dn=("ipNetworkNumber=%s,", addr), \ ipNetmaskNumber=

   この例では、NIS+ の netmasks エントリが削除されると、対応する ou=Networks LDAP エントリの ipNetmaskNumber 属性が削除されます。ここでは、 nodeInventory および nodeOwner 属性を削除します。つまり、手順 (5) の dn 指定を使用して、次のように編集します。

   nisplusLDAPattributeFromColumn \ nodeinfo_del: dn=("cn=%s+ipHostNumber=%s,", cname, \ ldap:ipHostNumber:?one?("cn=%s", cname)), \ nodeInventory=, \ nodeOwner=

8. マッピング情報はこれで完了です。このマッピングを有効にするために、rpc.nisd デーモンを停止してから、再起動します。

   # pkill rpc.nisd

9. NIS+ nodeinfo テーブルにすでにデータが存在する場合は、そのデータを LDAP にアップロードします。新しい nodeinfo マッピング情報を、別のファイル /var/nis/tmpmapping に格納します。

   # /usr/sbin/rpc.nisd -D -m /var/nis/tmpmapping \

   -x nisplusLDAPinitialUpdateAction=to_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

10. 一時ファイル /var/nis/tmpmapping のマッピング情報を実際のマッピングファイルに追加します。エディタを使用するか、次の方法でデータを追加します。対象のマッピングファイルは、 /var/nis/NIS+LDAPmapping とします。

    # cp -p /var/nis/NIS+LDAPmapping \

    /var/nis/NIS+LDAPmapping.backup

    # cat /var/nis/tmpmapping>> /var/nis/NIS+LDAPmapping

    ---

    注 -

    二重矢印 「>>」はリダイレクトを示します。矢印「>」は、対象ファイルの上書きを示します。

    ---

11. rpc.nisd デーモンを再起動します。 rpc.nisd デーモンが次のように NIS(YP) データも提供する場合は、-Y オプションを追加します。

    # /usr/sbin/rpc.nisd -m /var/nis/NIS+LDAPmapping

構成情報を LDAP に格納する

NIS+ および LDAP の構成情報は、構成ファイルとコマンド行で格納できますが、構成属性は LDAP にも格納できます。構成情報が多くの NIS+ サーバーによって共有され、定期的に変更される場合は、LDAP に格納すると便利です。

構成属性を LDAP に格納するには、LDAP サーバーのマニュアルを参照して、次の新しい属性とオブジェクトクラスを作成します。構成情報は、 rpc.nisd コマンド行または /etc/default/rpc.nisd の nisplusLDAPconfigDN 値に指定された場所に存在することが前提となっています。また、cn が nisplusLDAPbaseDomain 値であることも前提です (LDAP から構成情報を読み込む前に、rpc.nisd デーモンに認識されているため)。

LDIF データは、ldapadd(1) に適用できます。属性とオブジェクトクラス OID は、例として挙げています。

defaultSearchBase、preferredServerList 、およびauthenticationMethod 属性は、「DUA config」スキーマの原案に準拠しています。このスキーマは、IETF 標準となる見込みです。NIS+LDAPmapping(4) で使用する場合は、次の定義で十分です。

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' \
		  DESC 'Default LDAP base DN used by a DUA' \
		  EQUALITY distinguishedNameMatch \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' \
		  DESC 'Preferred LDAP server host addresses to be used by a DUA' \
		  EQUALITY caseIgnoreMatch \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' \
		  DESC 'Identifies the authentication method used to connect to the DSA'\
		  EQUALITY caseIgnoreMatch \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

NIS+ および LDAP の構成属性は、次のようになっています。

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.0 \
		  NAME 'nisplusLDAPTLS' \
		  DESC 'Transport Layer Security' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.1 \
		  NAME 'nisplusLDAPTLSCertificateDBPath' \
		  DESC 'Certificate file' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.2 \
		  NAME 'nisplusLDAPproxyUser' \
		  DESC 'Proxy user for data store/retrieval' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.3 \
		  NAME 'nisplusLDAPproxyPassword' \
		  DESC 'Password/key/shared secret for proxy user' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.4 \
		  NAME 'nisplusLDAPinitialUpdateAction' \
		  DESC 'Type of initial update' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.5 \
		  NAME 'nisplusLDAPinitialUpdateOnly' \
		  DESC 'Exit after update ?' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.6 \
		  NAME 'nisplusLDAPretrieveErrorAction' \
		  DESC 'Action following an LDAP search error' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.7 \
		  NAME 'nisplusLDAPretrieveErrorAttempts' \
		  DESC 'Number of times to retry an LDAP search' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.8 \
		  NAME 'nisplusLDAPretrieveErrorTimeout' \
		  DESC 'Timeout between each search attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.9 \
		  NAME 'nisplusLDAPstoreErrorAction' \
		  DESC 'Action following an LDAP store error' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.10 \
		  NAME 'nisplusLDAPstoreErrorAttempts' \
		  DESC 'Number of times to retry an LDAP store' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.11 \
		  NAME 'nisplusLDAPstoreErrorTimeout' \
		  DESC 'Timeout between each store attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.12 \
		  NAME 'nisplusLDAPrefreshErrorAction' \
		  DESC 'Action when refresh of NIS+ data from LDAP fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.13 \
		  NAME 'nisplusLDAPrefreshErrorAttempts' \
		  DESC 'Number of times to retry an LDAP refresh' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.14 \
		  NAME 'nisplusLDAPrefreshErrorTimeout' \
		  DESC 'Timeout between each refresh attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.15 \
		  NAME 'nisplusNumberOfServiceThreads' \
		  DESC 'Max number of RPC service threads' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.16 \
		  NAME 'nisplusThreadCreationErrorAction' \
		  DESC 'Action when a non-RPC-service thread creation fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.17 \
		  NAME 'nisplusThreadCreationErrorAttempts' \
		  DESC 'Number of times to retry thread creation' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.18 \
		  NAME 'nisplusThreadCreationErrorTimeout' \
		  DESC 'Timeout between each thread creation attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.19 \
		  NAME 'nisplusDumpErrorAction' \
		  DESC 'Action when an NIS+ dump fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.20 \
		  NAME 'nisplusDumpErrorAttempts' \
		  DESC 'Number of times to retry a failed dump' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.21 \
		  NAME 'nisplusDumpErrorTimeout' \
		  DESC 'Timeout between each dump attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.22 \
		  NAME 'nisplusResyncService' \
		  DESC 'Service provided during a resync' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.23 \
		  NAME 'nisplusUpdateBatching' \
		  DESC 'Method for batching updates on master' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.24 \
		  NAME 'nisplusUpdateBatchingTimeout' \
		  DESC 'Minimum time to wait before pinging replicas' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.25 \
		  NAME 'nisplusLDAPmatchFetchAction' \
		  DESC 'Should pre-fetch be done ?' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.26 \
		  NAME 'nisplusLDAPbaseDomain' \
		  DESC 'Default domain name used in NIS+/LDAP mapping' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.27 \
		  NAME 'nisplusLDAPdatabaseIdMapping' \
		  DESC 'Defines a database id for an NIS+ object' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.28 \
		  NAME 'nisplusLDAPentryTtl' \
		  DESC 'TTL for cached objects derived from LDAP' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.29 \
		  NAME 'nisplusLDAPobjectDN' \
		  DESC 'Location in LDAP tree where NIS+ data is stored' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.30 \
		  NAME 'nisplusLDAPcolumnFromAttribute' \
		  DESC 'Rules for mapping LDAP attributes to NIS+ columns' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.31 \
		  NAME 'nisplusLDAPattributeFromColumn' \
		  DESC 'Rules for mapping NIS+ columns to LDAP attributes' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.19.0 NAME 'nisplusLDAPconfig' \
		  DESC 'NIS+/LDAP mapping configuration' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( preferredServerList $ defaultSearchBase $ 
authenticationMethod $ nisplusLDAPTLS $ nisplusLDAPTLSCertificateDBPath 
$ nisplusLDAPproxyUser $ nisplusLDAPproxyPassword $ nisplusLDAPinitialUpdateAction 
$ nisplusLDAPinitialUpdateOnly $ nisplusLDAPretrieveErrorAction 
$ nisplusLDAPretrieveErrorAttempts $ nisplusLDAPretrieveErrorTimeout 
$ nisplusLDAPstoreErrorAction $ nisplusLDAPstoreErrorAttempts 
$ nisplusLDAPstoreErrorTimeout $ nisplusLDAPrefreshErrorAction 
$ nisplusLDAPrefreshErrorAttempts $ nisplusLDAPrefreshErrorTimeout 
$ nisplusNumberOfServiceThreads $nisplusThreadCreationErrorAction 
$ nisplusThreadCreationErrorAttempts $ nisplusThreadCreationErrorTimeout 
$ nisplusDumpErrorAction $ nisplusDumpErrorAttempts 
$ nisplusDumpErrorTimeout $ nisplusResyncService $ nisplusUpdateBatching 
$ nisplusUpdateBatchingTimeout $ nisplusLDAPmatchFetchAction 
$ nisplusLDAPbaseDomain $ nisplusLDAPdatabaseIdMapping $ nisplusLDAPentryTtl 
$ nisplusLDAPobjectDN $ nisplusLDAPcolumnFromAttribute !
$ nisplusLDAPattributeFromColumn ) )

次の LDIF データを含むファイルを作成します。実際の検索ベースを searchBase に、完全指定ドメイン名を domain に代入します。

dn: cn=domain,searchBase

cn:domain

objectClass: top objectClass: nisplusLDAPconfig

上のファイルを ldapadd(1) の入力として使用し、NIS+ および LDAP の構成エントリを作成します。最初は、エントリは空になっています。ldapmodify(1) を使用して、構成属性を追加します。たとえば、nisplusNumberOfServiceThreads 属性に「32」を設定するには、ldapmodify(1) の入力として次のファイルを作成します。

dn: cn=domain, searchBase nisplusNumberOfServiceThreads: 32