Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)

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

ここでは、LDAP ネームサービスの概要を説明します。さらに、Sun ONE Directory Server 5.1 (以前の名称は iPlanet Directory Server 5.1) の使用に焦点を当てて、Solaris オペレーティング環境での LDAP ネームサービスの設定、構成、管理、そして障害の対処方法についても説明します。

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

この LDAP の章では、Sun ONE Directory Server (以前の名称は iPlanet Directory Server) で動作する Solaris LDAP ネームサービスクライアントの設定方法について説明します。 Sun ONE Directory Server の使用を推奨しますが、必須ではありません。一般的なディレクトリサーバー要件については、第 18 章「LDAP の一般的なリファレンス」で簡潔に説明します。

注 –

ディレクトリサーバーは、必ずしも LDAP サーバーである必要はありません。しかし、この章では「ディレクトリサーバー」という言葉は「LDAP サーバー」と同じ意味で使っています。

対象読者

LDAP ネームサービスに関するこれらの章は、LDAP に関する実務上の知識を持つシステム管理者を対象としています。以下のリストはこの章を読む前によく理解しておく必要のある概念の一部です。以下の概念を知らない場合は、このマニュアルを使って Solaris 環境に LDAP ネームサービスを導入することは難しいかもしれません。

LDAP 情報モデル (エントリ、オブジェクトクラス、属性、タイプ、値)
LDAP ネームモデル (ディレクトリ情報ツリー (DIT) 構造)
LDAP 機能モデル (検索パラメータ: ベースオブジェクト (DN)、スコープ、サイズ制限、時間制限、フィルタ (Sun ONE Directory Server のインデックスを表示する)、属性リスト)
LDAP セキュリティモデル (認証方式、アクセス制御モデル)
データの計画方法と DIT、トポロジ、複製、セキュリティの設計方法を含む LDAP ディレクトリサービスの計画と設計全般

推奨される前提知識

前述の概念についての詳細、また一般的な 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 に収められています。

その他の前提条件

Sun ONE Directory Server をインストールする場合は、ご使用のバージョンの Sun ONE Directory Server の『インストールガイド』を参照してください。

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

次の表は、FNS、DNS、 NIS、 NIS+ 、LDAP ネームサービスを比較したものです。

	DNS	NIS	NIS+	FNS	LDAP *
名前空間	階層	Flat	階層	階層	階層
データ記憶領域	ファイル/リソースレコード	2 列のマップ	複数列のテーブル	マップ	ディレクトリ (可変) インデックス化したデータベース
サーバー	マスター/スレーブ	マスター/スレーブ	ルートマスター/非ルートマスター主/副キャッシュ/スタブ	なし	マスター/複製マルチマスター複製
セキュリティ	なし	なし (root またはなし)	DES- 認証	なし (root またはなし)	SSL、可変
トランスポート	TCP/IP	RPC	RPC	RPC	TCP/IP
スケール	グローバル	LAN	LAN	グローバル (DNS 付)/LAN	グローバル

LDAP ネームサービスの利点

LDAP を使用すると、アプリケーション固有の情報を置き換えて情報の整理統合を実行し、管理するデータベースの数を減らすことができる
LDAP を使用すると、異なる複数のネームサービス間でデータを共有できる
LDAP により、データの集中的なリポジトリ (格納場所) が提供される
LDAP を使用すると、マスターと複製との間でより頻繁にデータの同期を取ることができる
LDAP では、プラットフォーム間およびベンダー間の互換性が維持されている

LDAP ネームサービスの欠点

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

Solaris 8 以前のクライアントはサポートしていない
LDAP サーバーをそのクライアントとして使用することはできない
LDAP ネームサービスの設定および管理がより複雑なため、注意深い計画が必要である

注 –

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

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

作業	参照先
パッチがインストールされていることの確認
ネットワークモデルの計画	ネットワークモデルの計画
DIT の計画	第 14 章「LDAP ネームサービスの計画要件 (手順)」
複製サーバーの設定	複製サーバー
セキュリティモデルの計画	セキュリティモデルの計画
クライアントプロファイルおよびデフォルト属性値の選択	クライアントプロファイルおよびデフォルト属性値の計画
データ生成の計画	データ生成の計画
LDAP ネームサービスで使用する前に Sun ONE Directory Server を構成する	サーバーの構成
LDAP ネームクライアントで使用するために Sun ONE Directory Server を設定する	第 15 章「Sun ONE Directory Server の設定 (手順)」
プリンタエントリの管理	プリンタエントリの管理
LDAP クライアントの初期化	クライアントの初期設定
プロファイルを使用したクライアントの初期化	プロファイルを使用してクライアントを初期化する
手動によるクライアントの初期化	クライアントを手動で初期設定する
クライアントの初期化解除	クライアントの初期設定を解除する
サービス検索記述子を使用した、クライアントプロファイルの変更	サービス検索記述子を使用してさまざまなサービスへのクライアントアクセスを変更する
ネームサービス情報の取得	LDAP ネームサービス情報の検出
クライアント環境のカスタマイズ	クライアント環境のカスタマイズ

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

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

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

LDIF は、ディレクトリサービスのエンティティおよびその属性を記述するためのテキストベースのフォーマットです。 LDIF フォーマットを使用することで、ldapadd や ldapmodify などのコマンドを実行して、ディレクトリ間で情報を移動できます。以下に、各サービスの LDIF フォーマットの例を示します。この情報を表示するには、-l オプションを指定して、ldaplist(1) を実行してください。

% 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

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

NIS や NIS+ クライアントと違い、 LDAP クライアントは常にホスト名として完全指定のドメイン名 (FQDN、Fully Qualified Domain Name) を返します。 LDAP のFQDN は、DNS によって返される FQDN に似ています。たとえば、次のドメイン名を考えてみましょう。

west.example.net

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

server.west.example.net

また、server-# のようなインタフェース固有のエイリアスを使用した場合も、完全指定ホスト名の長いリストが返されます。ホスト名を使用してファイルシステムを共有したり他の検査を実行する場合、この点に留意する必要があります。たとえば、ローカルホストは FQDN ではなく、遠隔 DNS で解決されるホストだけが FQDN であると想定している場合は、その違いに留意する必要があります。 DNS とは違うドメイン名で LDAP を設定する場合、参照先によって同じホストが結果的に2つの異なる FQDN になる可能性があります。

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

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

表 13–1 DIT のデフォルト位置


デフォルトコンテナ	情報タイプ
`ou=Ethers`	bootparams(4)、ethers(4)
`ou=Group`	group(4)
`ou=Hosts`	hosts(4)、ipnodes(4)、publickey (ホスト用)
`ou=Aliases`	aliases(4)
`ou=Netgroup`	netgroup(4)
`ou=Networks`	networks(4)、netmasks(4)
`ou=People`	passwd(1)、shadow(4)、user_attr(4)、audit_user(4)、publickey (ユーザー用)
`ou=printers`	printers(4)
`ou=Protocols`	protocols(4)
`ou=Rpc`	rpc(4)
`ou=Services`	services(4)
`ou=SolarisAuthAttr`	auth_attr(4)
`ou=SolarisProfAttr`	prof_attr(4)、exec_attr(4)
`ou=projects`	project
`automountMap=auto_`*	auto_*

デフォルトスキーマ

スキーマは、LDAP ディレクトリ内にエントリとして格納可能な情報タイプの定義です。 LDAP ネームサービスクライアントをサポートするために、ディレクトリサーバースキーマの拡張が必要な場合があります。 IETF および Solaris 固有のスキーマの詳細については第 18 章「LDAP の一般的なリファレンス」を参照してください。 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 章「LDAP の一般的なリファレンス」に記載されているよく知られている属性を使用します)。属性を対応づける場合、その属性が元の属性と同じ意味および構文を必ず保持するようにしてください。 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 の実行時に自動的に設定されます。クライアントプロファイルを手動で設定する方法については、クライアントを手動で初期設定すると idsconfig(1M) のマニュアルページを参照してください。

表 13–2 クライアントのプロファイル属性


属性	説明
`cn`	プロファイル名。デフォルト値なし。必須
`preferredServerList`	優先使用されるサーバーのホストアドレスの、空白で区切られたリスト。 (ホスト名は使用しない)。 `defaultServerList` 内のサーバーより「前に」、接続が成功するまで、このリスト内のサーバーへの接続が順番に試みられる。デフォルト値なし。 `preferredServerList` または `defaultServerList` に 1 つ以上のサーバーを指定する必要がある。
`defaultServerList`	デフォルトサーバーのホストアドレスの、空白で区切られたリスト (ホスト名は使用しない)。 `preferredServerlist` 内のサーバーへの接続試行後に、接続が確立されるまで、クライアントのサブネット上のデフォルトサーバーへの接続、続いて残りのデフォルトサーバーへの接続が試みられる。 `preferredServerList` または `defaultServerList` に 1 つ以上のサーバーを指定する必要がある。このリスト内のサーバーへの接続は、優先サーバーリストのサーバーへの接続試行後に試みられる。デフォルト値なし
`defaultSearchBase`	よく知られたコンテナの検索に使用する相対識別名。デフォルト値なし。ただしこの値は、`serviceSearchDescriptor` 属性で指定されたサービスで置き換えることが可能
`defaultSearchScope`	クライアントによるデータベース検索の適用範囲を定義する。この値は、`serviceSearchDescriptor` 属性で置き換えることが可能。指定可能な値は `one` または `sub`。デフォルト値は 1 レベルの検索 (値は`one`)
`authenticationMethod`	クライアントが使用する認証方式を示す。デフォルト値は `none` (匿名)。詳細については、認証方式の選択を参照
`credentialLevel`	クライアントが認証に使用する証明書タイプを示す。匿名またはプロキシを選択可能。デフォルトは匿名。
`serviceSearchDescriptor`	クライアントがネームデータベースを検索する方法および場所を定義する (例、クライアントが DIT 内の 1 つ以上の場所を検索する)。デフォルトでは、SSD は定義されていない
`serviceAuthenticationMethod`	クライアントが特定のサービスで使用する認証メソッド。デフォルトでは、サービス認証メソッドは定義されていない。サービスで `serviceAuthenticationMethod` が定義されていない場合、`authenticationMethod` の値がデフォルトになる
`attributeMap`	クライアントが使用する属性マッピング。デフォルトでは、`attributeMap` は定義されていない
`objectclassMap`	クライアントが使用するオブジェクトクラスマッピング。デフォルトでは、`objectclassMap` は定義されていない
`searchTimeLimit`	クライアントが許可する、タイムアウトまでの最長検索時間 (秒)。この値は、LDAP サーバーが許可する、検索完了までの時間に影響を及ぼさないデフォルト値は `30` 秒
`bindTimeLimit`	クライアントがサーバーとのバインドに許可する最長時間 (秒)。デフォルト値は `30` 秒
`followReferrals`	クライアントが LDAP 参照に準拠するかどうかを指定する。指定可能な値は `TRUE` または `FALSE`。デフォルト値は `TRUE`。
`profileTTL`	`ldap_cachemgr(1M)` により実行される、LDAP サーバーからのクライアントプロファイルの更新間隔。デフォルト値は `43200` 秒 (12 時間)。値が 0 の場合、プロファイルは更新されない

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

次の表に、ldapclient を使用してローカルに設定可能なクライアント属性を示します。詳細は、ldapclient(1M) のマニュアルページを参照してください。

表 13–3 ローカルのクライアント属性


属性	説明
`domainName`	クライアントのドメイン名 (クライアントマシンのデフォルトドメインになる) を指定します。デフォルト値なし。必須
`proxyDN`	プロキシの識別名。プロキシの `credentialLevel` を使用してクライアントマシンを構成する場合、`proxyDN` を指定する必要がある
`proxyPassword`	プロキシのパスワード。プロキシの `credentialLevel` を使用してクライアントマシンを構成する場合、`proxyPassword` を定義する必要がある
`certificatePath`	証明書データベースを含む、ローカルファイルシステム上のディレクトリ。 TLS を使用し、`authenticationMethod` または `serviceAuthenticationMethod` を指定してクライアントマシンを構成する場合、この属性が使用される。デフォルト値は `/var/ldap`

注 –

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

`ldap_cachemgr` デーモン

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

root として稼働し、構成ファイルへのアクセスを取得する
サーバー上のプロファイルに格納されたクライアント構成情報を更新して、クライアントからこのデータを引き出す
使用可能な LDAP サーバーのソート済みリストを管理
さまざまなクライアントから送信される一般的な検索要求をキャッシュして、検索効率を向上させる
ホスト検索の効率を向上させる

注 –

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

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

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

はじめに

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

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

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

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

Transport Layer Security (TLS)

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

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

注 –

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

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

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

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

anonymous
proxy
proxy anonymous

匿名 (anonymous)

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

注意 –

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

注 –

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

プロキシ (proxy)

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

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

注 –

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

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

匿名プロキシ (anonymous proxy)

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

資格の保存

プロキシ識別情報を使用するようクライアントを設定する場合、クライアントは 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 を使用する場合、クライアントマシンはユーザーのパスワードを平文 (clear) で送信してサーバーへのバインドを実行します。このため、セッションが ipsec(7) により保護されていない限り、パスワードが漏洩しやすくなります。認証方式 simple を使用する主な利点は、すべてのディレクトリサーバーがこの方式をサポートしていること、および設定が容易であるという点です。
sasl/digest-MD5

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

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

注 –
Sun ONE Directory Server を使用している場合、パスワードをディレクトリ内に「平文」で格納する必要があります。
sasl/cram-MD5

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

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

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

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

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

注意 –

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

次の表に、さまざまな認証方式およびその特性の概要を示します。

表 13–4 認証方式


	バインド	セッション	通信時のパスワード	Sun ONE Directory Server でのパスワード	セッション
`none`	任意	暗号化しない	なし	なし	暗号化しない
`simple`	必須	暗号化しない	平文	任意	任意
`sasl/digest-MD5`	必須	暗号化しない	暗号化	平文	任意
`sasl/cram-MD5`	必須	暗号化しない	暗号化	なし	任意
`tls_simple`	必須	暗号化しない	暗号化	任意	暗号化
`tls:sasl/cram-MD5`	必須	暗号化	暗号化	なし	暗号化
`tls:sasl/digest-MD5`	必須	暗号化	暗号化	平文	暗号化

認証とサービス

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

passwd-cmd

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

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

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

pam_ldap は、アカウントの管理をサポートします。

注 –

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

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

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

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

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

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

pam_unix

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

クライアントは、ネームサービスからユーザーの暗号化されたパスワードを取得します。
ユーザーは、パスワードの入力を求められます。
ユーザーのパスワードが暗号化されます。
クライアントは、暗号化された 2 つのパスワードを比較して、ユーザーを認証するかどうかを決定します。

pam_unix を使用する場合、次の 2 つの制限が存在します。

パスワードは、平文を含む他の暗号化方式ではなく、UNIX crypt 形式で格納する必要がある
userPassword 属性は、ネームサービスから読み取り可能でなければならない

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

注 –

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

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

pam_ldap

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

pam_ldap が、ユーザーの識別情報および指定されたパスワードでサーバーにバインドできれば、ユーザーが認証されたことになります。

pam_ldap は、userPassword 属性を読み取りません。このため、pam_ldap を使用する他のクライアントが存在しない限り、userPassword 属性の読み取りアクセス権を付与する必要はありません。 pam_ldap は、認証方式 none をサポートしません。このため、クライアントが pam_ldap を使用できるように、serviceAuthenticationMethod または authenticationMethod 属性を定義する必要があります。詳細は、pam_ldap(5) のマニュアルページを参照してください。

注意 –

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

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

以下の表に、pam_unix と pam_ldap の主な相違点を示します。詳細は、pam_unix(5) と pam_ldap(5) のマニュアルページを参照してください。

表 13–5 pam_unix と pam_ldap


	`pam_unix`	`pam_ldap`
パスワードの送信	`passwd` サービス認証方式を使用	`passwd` サービス認証方式を使用
新規パスワードの送信	暗号化する	暗号化しない (TLS を使用しない場合)
新規パスワードの格納	`crypt` 形式	Sun ONE Directory Server でのデフォルト `passwd` 格納スキーマによる定義に従う
パスワードの読み取り	必須	任意
パスワード変更後の `sasl/digestMD5` の互換性	なし。パスワードは平文では格納されない。ユーザーを認証できない	あり。デフォルトのストレージスキーマが平文 (`clear`) に設定されていれば、ユーザーを認証できる

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

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

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

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

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

注 –

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

digest-MD5 での Sun ONE Directory Server の使用

Sun ONE Directory Server を digest-MD5 で使用する場合は、パスワードを変更するユーザーが何らかのパスワード管理上の理由で変更に失敗すると、変更後のパスワードを使用してログインできなくなります。

たとえば、サーバーでパスワード履歴が有効である場合、ユーザーが以前に使用していたパスワードに変更しようとすると、制約違反 (この場合は以前に使用していたパスワードを使用すること) のために pam_ldap はパスワードの変更に失敗します。 pam は pam_ldap を無視して、pam_unix に行き着きます。結果として、パスワードが平文ではなく、暗号化形式で格納されます。このため、次にユーザーが変更後のパスワードを使用してログインを試みると、ログインは失敗します。

pam_ldap が pam_unix に行き着くことを防ぐには、「すべての」クライアントの pam.conf ファイルで次の構成を使用する必要があります。

  other   password required        pam_dhkeys.so.1
  other   password requisite       pam_authtok_get.so.1
  other   password requisite       pam_authtok_check.so.1
  other   password binding         pam_authtok_store.so.1 server_policy

上記の構成には、pam_ldap.so.1 が存在しないことに留意してください。 server_policy は、pam_authtok_store.so.1 が「常に」 LDAP アカウントの平文テキストをディレクトリサーバーに送信することを指定し、サーバーが独自のパスワード暗号化スキーマに従ってパスワードを格納することを許可します。ただし、上記の構成を使用する場合、これと適合した認証構成も必要になります。たとえば、次の構成を使用します。

login     auth     binding    pam_unix_auth.so.1 server_policy
login     auth     required   pam_ldap.so.1

および

passwd     auth    binding     pam_passwd_auth.so.1    server_policy
passwd     auth    required    pam_ldap.so.1

注意 –

同じディレクトリネーミングドメイン内のすべてのクライアントが、上記の構成を使用するようにしてください。 1 つのクライアントで別の pam.conf を使用している場合でも、ユーザーがそのシステム上でパスワードを変更すると、残りのクライアントでログイン認証が失敗します。

パスワード管理

LDAP ネームサービスは、Sun ONE Directory Server でパスワードとアカウントのロックアウトポリシーをサポートする利点を有効に活用しています。 pam_ldap(5) を構成して、ユーザアカウント管理をサポートすることが可能です。 passwd(1) を正しい PAM 構成で使用すると、Sun ONE Directory Server パスワードポリシーによるパスワードの構文規則を強化します。

pam_ldap(5) により、以下のパスワード管理機能がサポートされています。これらの機能は、Sun ONE Directory Server のパスワードとアカウントのロックアウトポリシー構成を利用しています。必要な機能を必要な数だけ利用できます。

古くなったり、有効期限の切れたパスワードを通知する

パスワードは、予定にしたがって変更する必要があります。パスワードを定められた期間内に変更しないとそのパスワードは無効になります。期限切れのパスワードでは、ユーザーが認証されません。

期限切れの警告期間内のログイン時には、常に警告メッセージを表示します。メッセージには期限切れまでの日数と時間が表示されます。
パスワードの構文チェック

新規パスワードは、最小文字数の条件を満たしている必要があります。また、ユーザーのディレクトリエントリにある uid、cn、sn、および mail と同じ値をパスワードに設定することはできません。
パスワードの履歴チェック

パスワードの再利用はできません。以前使われていたパスワードに変更しようとすると、passwd(1) コマンドは失敗します。 LDAP 管理者は、サーバーの履歴リストに保持するパスワードの数を設定することができます。
ユーザーアカウントのロックアウト

認証の失敗が設定された回数に達すると、そのユーザーアカウントはロックアウトされます。管理者がアカウントを非アクティブにした場合も、そのユーザーはロックアウトされます。アカウントのロックアウト期間が経過するか、管理者が再びアカウントをアクティブにするまで、認証は成功しません。

注 –

以上のパスワード管理機能は、Solaris 9 にバンドルされたSun ONE Directory Server のバージョンでのみ有効です。サーバー上のパスワードとアカウントのロックアウトポリシーの構成についての詳細は、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』の「ユーザーアカウントの管理」の章を参照してください。また、パスワード管理のために pam_ldap を構成した pam.conf ファイル例も参照してください。 proxy アカウントでは、パスワード管理を有効にしないでください。

Sun ONE Directory Server 上でパスワードとアカウントのロックアウトポリシーを構成する前に、すべてのホスト上で pam_ldap パスワード管理に基づいた「最新の」 LDAP クライアントが使われていることを確認します。

さらに、クライアントが正しい構成の pam.conf(4) ファイルを保持していることを確認します。正しい構成ファイルを保持していない場合、 LDAP ネームサービスは proxy やユーザーパスワードが期限切れの時に動作しません。

第 14 章 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 章「Sun ONE Directory Server の構成」を参照してください。

複製サーバー

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

単一マスター複製 (Single-master replication)
浮動マスター複製 (Floating-master replication)
複数マスター複製 (Multi-master replication)

「単一マスター」

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

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

「浮動マスター」

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

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

「複数マスター」

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

複製サーバーの設定方法については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』を参照してください。

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

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

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

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

LDAP クライアントは、どの資格レベルおよび認証方式を使用するか
TLS を使用するか
NIS や NIS+ との下位互換性を必要とするか。言い換えれば、クライアントは pam_unix または pam_ldap を使用するか
サーバーの passwordStorageScheme 属性をどのように設定するか
アクセス制御情報をどのように設定するか。

ACI の詳細については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』を参照してください。

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

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

cn
defaultServerList
preferredServerList
bindTimeLimit
searchTimeLimit
profileTTL
defaultSearchBase
defaultSearchScope
serviceSearchDescriptor
attributeMap
objectclassMap
followReferrals
credentialLevel
authenticationMethod
serviceCredentialLevel
serviceAuthenticationMethod

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

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

データ生成の計画

データを使用して 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 ネームサービスを使用するようにクライアントを構成する必要があります。

パフォーマンスを向上させるため、次の順序でデータベースをロードしてください。

passwd データベースの次に shadow データベース
networks データベースの次に netmasks データベース
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` エントリを持つサーバーを生成する方法

idsconfig を使用し、Sun ONE Directory Server が設定されていることを確認します。

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

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

# ldapclient init -a profileName=new \

-a domainName=west.example.com 192.168.0.1

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

# ldapaddent -D “cn=directory manager” -f /etc/hosts hosts

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

第 15 章 Sun ONE Directory Server の設定 (手順)

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

注 –

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

注 –

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

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

`idsconfig` を使用した Sun ONE Directory Server の構成

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

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

注 –

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

表 15–1 サーバーで定義する変数


変数	サンプルネットワークの定義
インストールしたディレクトリサーバーインスタンスのポート番号 (デフォルト = 389)	`default`
サーバー名	`myserver` (完全指定ドメイン名 ipdserver.west.example.com または 192.168.0.0)
複製サーバー (IP 番号: ポート番号)	`192.168.0.1` [ipdrep.west.example.com 用]
ディレクリマネージャ [`dn: cn=directory manager`]	`default`
サービスされるドメイン名	`west.example.com`
クライアント要求の処理がタイムアウトするまでの時間 (秒)	`–1`
各検索要求で返されるエントリの最大数	`–1`

注 –

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

表 15–2 クライアントプロファイルで定義する変数


変数	サンプルネットワークの定義
プロファイル名	`WestUserProfile`
サーバーリスト (デフォルトはローカルサブネット)	west.example.com または `192.168.0.0`
優先されるサーバーリスト (優先順に記載)	`none`
検索範囲 (検索するディレクトリツリーレベルの数、「`One`」 (デフォルト) または「`Sub`」)	`one` (デフォルト)
サーバーへのアクセスに使用する資格。デフォルトは `anonymous`	`proxy`
参照に従うか (メインサーバーが使用できない場合の別のサーバーへのポインタ)。デフォルトは `no`	`Y`
検索時にサーバーが情報を返すまでの待機時間の制限 (デフォルトは 30)	`default`
サーバーとの通信時のバインド時間の制限 (デフォルトは 10 秒)。デフォルトは秒	`2`
認証方式。デフォルトは `none`	`simple`

注 –

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

属性インデックス

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

membernisnetgroup: pres,eq,sub
nisnetgrouptriple: pres,eq,sub
memberuid: pres,eq
uidNumber: pres,eq
gidNumber: pres,eq
ipHostNumber: pres,eq
ipNetworkNumber: pres,eq
ipProtocolNumber: pres,eq
oncRpcNumber: pres,eq

スキーマ定義

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

インデックス表示の使用

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

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

Sun ONE Directory Server 上でインデックス表示を構成する前に、これらのインデックスの使用に関連したパフォーマンスのコストを検討してください。詳細については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』を参照してください。

次の例では、-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 を使用して、Sun ONE Directory Server の構成時に必要な 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 は、ディレクトリマネージャのパスワードを平文で送信します。これを防ぐには、idsconfig をクライアント上ではなくディレクトリサーバー上で実行する必要があります。

`idsconfig` を使用して Sun ONE Directory Server を構成する方法

ターゲットの Sun ONE Directory Server が起動して実行中であることを確認してください。

idsconfig を実行します。
# /usr/lib/ldap/idsconfig

表示される質問に答えます。

ユーザー入力のデフォルトは「no」です。質問の詳細を表示する場合は、
h
と入力します。すると、簡単なヘルプが表示されます。

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

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

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

# usr/lib/ldap/idsconfig
It is strongly recommended that you BACKUP the directory server
before running idsconfig.

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 directory server's 
hostname to setup: myserver

Enter the port number for  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 iDS (current=3600): [-1]

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

Enter the size limit for iDS (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  iDS Time Limit                : -1
 11  iDS 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:
      west.example.com.getgrent vlv_index   Entry created
      west.example.com.gethostent vlv_index   Entry created
      west.example.com.getnetent vlv_index   Entry created
      west.example.com.getpwent vlv_index   Entry created
      west.example.com.getrpcent vlv_index   Entry created
      west.example.com.getspent vlv_index   Entry created

idsconfig: Setup of directory 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 west.example.com.getgrent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.gethostent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.getnetent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.getpwent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.getrpcent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.getspent

注 –

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

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

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

注 –

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

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

注 –

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

`ldapaddent` を使ったユーザーパスワードデータによる Sun ONE Directory Server の生成方法

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` を使った追加プロファイルによるディレクトリサーバーの生成方法

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

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

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

# ldapadd –h 192.168.0.0 —D “cn=directory manager” —f myprofile.ldif

ディレクトリサーバーを構成してパスワード管理を有効にする

pam_ldap が正しく動作するには、パスワードとアカウントのロックアウトポリシーがサーバー上で正しく構成されている必要があります。ディレクトリサーバーコンソールまたは ldapmodify を使用して、LDAP ディレクトリのパスワード管理ポリシーを構成できます。手順と詳細については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』の「ユーザーアカウントの管理」の章を参照してください。

proxy ユーザー用のパスワードは、期限が切れてはいけません。 proxy パスワードが期限切れになった場合、 proxy 資格レベルを使用するクライアントはサーバーからネームサービス情報を取り出すことができません。 proxy ユーザーのパスワードの期限が切れないことを保証するために、以下のスクリプトを記述して proxy アカウントを変更します。

# ldapmodify -h ldapserver —D administrator DN \
-w  administrator password <<EOF 
dn: proxy user DN
DNchangetype: modify
replace: passwordexpirationtime
passwordexpirationtime: 20380119031407Z
EOF

注 –

pam_ldap のパスワード管理は、Sun ONE Directory Server をもとに古くなったパスワードやアカウントの期限切れ情報を維持し、ユーザーに知らせます。ディレクトサーバーは、ユーザーアカウントを有効にするシャドウエントリから対応するデータを解釈しません。しかし、pam_unix がシャドウデータを調査して、アカウントがロックされているか、パスワードが古くなっているかを判断します。 LDAP ネームサービスやディレクトリサーバーはシャドウデータを最新の状態に維持しているわけではないので、pam_unix はシャドウデータにもとづいたアクセスを許可するべきではありません。シャドウデータは proxy 識別情報を使って検出します。そのため、proxy ユーザーに userPassword 属性へ読み取りアクセスを許可しないでください。 proxy ユーザーを userPassword へ読み取りアクセスさせないことにより、 pam_unix が無効なアカウントの検証を行わないようになります。

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

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

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

クライアント設定の前提条件

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

クライアントのドメイン名が LDAP サーバーによって処理される
nsswitch.conf ファイルが、必要なサービスの LDAP を指している
クライアントが、その動作を定義するための特定のパラメータをすべて使って構成されている
ldap_cachemgr がクライアントで実行されている
クライアントが構成されているサーバーが 1 つ以上起動され、実行されている

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

クライアントの初期設定

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

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

「プロファイル」

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

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

注 –

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

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

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

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

init -a を指定して ldapclient を実行します。

# ldapclient init -a profileName=new \

-a domainName=west.example.com 192.168.0.1
System successfully configured

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

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

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

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

# ldapclient init -a profileName=pit1 \
-a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \
-a domainName=west.example.com \
-a proxyPassword=test1234 192.168.0.1

System successfully configured

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

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

注 –

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

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

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

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

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

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.1

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

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

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

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

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

# ldapclient mod -a authenticationMethod=simple

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

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

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

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

ldapclient を実行します。

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

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

たとえば、Netscape Communicator^TM を使用して必要な 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 は、パスワード管理機能あり、またはなしで構成できます。以下の 2 つのオプションから構成に適した手順を選択してください。

パスワード管理機能なしで`pam_ldap` を使う

パスワード管理機能なしで pam_ldap を使うときは、pam_ldap に対応した pam.conf ファイルの例のサンプルの pam.conf ファイルにしたがってください。 pam_ldap.so.1 を含む行をクライアントの /etc/pam.conf ファイルに追加します。詳細については、pam.conf(4)のマニュアルページを参照してください。

パスワード管理機能のために `pam_ldap` を構成する

パスワード管理機能のために pam_ldap を構成する場合は、パスワード管理のために pam_ldap を構成した pam.conf ファイル例のサンプルの pam.conf ファイルをコピーします。次に、 pam_ldap.so.1 を含む行をクライアントの /etc/pam.conf ファイルに追加します。さらに、サンプルの pam.conf ファイルの中でいずれかの PAM が binding 管理フラグと server_policy オプションを定義している場合は、クライアントの /etc/pam.conf ファイルの対応するモジュールに、同じフラグとオプションを記述します。また、サービスモジュール pam_authtok_store.so.1 を含む行に、server_policy オプションを追加します。

binding 管理フラグ

binding 管理フラグを使うことにより、遠隔 (LDAP) パスワードよりローカルパスワードが優先されます。たとえば、ローカルファイルと LDAP 名前空間の両方にユーザーアカウントが見つかった場合、遠隔パスワードよりローカルアカウントのパスワードの方が優先されます。したがって、ローカルパスワードの期限が切れているときは、たとえ LDAP パスワードがまだ有効であっても認証に失敗します。
server_policy オプション

server_policy オプションを使うことにより、pam_unix は LDAP 名前空間で見つかったユーザーを使わず、pam_ldap は認証やアカウントの検証を行います。 pam_authtok_store.so.1 は、新しいパスワードを暗号化せずに LDAP サーバーに渡します。そのため、パスワードはサーバー上で構成されるパスワードの暗号化方式にもとづいたディレクトリに保存されます。詳細は、 pam.conf(4) と pam_ldap(5) のマニュアルページを参照してください。

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

ldaplist ユーティリティを使用して、LDAP ネームサービスについての情報を取得できます。この LDAP ユーティリティは、LDAP サーバーから取得したネームサービス情報を LDIF フォーマットで表示します。このユーティリティは、障害追跡に役立ちます。詳細については、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

すべての属性を表示する場合は、-1 オプションを指定して 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

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

以降の節では、クライアント環境をカスタマイズする方法について説明します。

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

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

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

DNS の有効化

/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 を -l オプションを付けて実行します。

# ldapclient -l
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 形式ですが、バイナリに変更される可能性があるため、このファイルを連結すると問題が発生する可能性があります。この情報へのアクセスにサポートされている方式は、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() や getaddrinfo() の場合と同様、完全指定ホスト名を返します。格納済みの名前が指定されている (1 つ以上のドットが含まれている) 場合、クライアントはその名前をそのまま返します。たとえば、格納されている名前が hostB.eng であれば、返される名前も hostB.eng です。

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

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

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

ログインできない

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

/etc/nsswitch.conf ファイル内の passwd サービスが ldap を使用しない
プロキシエージェントが、サーバーリスト上のユーザーの userPassword 属性を読み取ることができない。プロキシエージェントが比較のためにパスワードをクライアントに返すので、少なくともプロキシエージェントはパスワードを読めなければならない。 pam_ldap に関しては、パスワードへの読み取りアクセスを必要としない
プロキシエージェントが適切なパスワードを保持していない
該当するエントリに shadowAccount オブジェクトクラスが定義されていない
パスワードが定義されていない

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

サーバーの状態を確認します。
# /usr/lib/ldap/ldap_cachemgr -g
pam.conf の構成が不正である
LDAP 名前空間でユーザーが定義されていない
pam_unix で NS_LDAP_CREDENTIAL_LEVEL が anonymous に設定されており、匿名ユーザーが userPassword を使用できない
パスワードが crypt 形式で格納されていない
pam_ldap が構成され、パスワード管理をサポートしている場合は、以下のいずれかの原因でログインに失敗します。
- ユーザーのパスワード期限が切れている
- ログインを何回も行ったために、ユーザーアカウントがロックされる
- 管理者がユーザーアカウントを非アクティブにした

検索が遅い

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

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

-p オプションを使用しているときに、ldapclient がクライアントの初期化に失敗しました。考えられる失敗の原因は以下のとおりです。

コマンド行で不正なドメイン名が指定された
指定されたクライアントドメインのエントリポイントを表す nisDomain 属性が DIT (ディレクトリ情報ツリー) 内に設定されていない
アクセス制御情報がサーバー上で適正に設定されていないため、LDAP データベース内の匿名検索が許可されない
ldapclient コマンドに渡されたサーバーアドレスが間違っている。 ldapsearch を使用してサーバーのアドレスを確認する
ldapclient コマンドに渡されたプロファイル名が間違っている。 ldapsearch を使用して、DIT 内のプロファイル名を確認する
クライアントのネットワークインタフェースに対して snoop を実行して外向きのトラフィックを検査して、どのサーバーにアクセスしているかを確認する

デバッグに `ldap_cachemgr` を使用する

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

# ldap_cachemgr -g

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

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

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

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

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

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

記入用のチェックリスト

表 18–1 サーバーで定義する変数


変数	_______ ネットワークの定義
インストールしたディレクトリサーバーインスタンスのポート番号 (389)
サーバー名
複製サーバー(IP 番号: ポート番号)
ディレクトリマネージャ [`dn: cn=directory manager`]
サービスされるドメイン名
クライアント要求の処理がタイムアウトするまでの時間 (秒)
各検索要求で返されるエントリの最大数

表 18–2 クライアントプロファイルで定義する変数


変数	________ ネットワークの定義
プロファイル名
サーバーリスト (デフォルトはローカルサブネット)
優先されるサーバーリスト (優先順に記載)
検索範囲 (検索するディレクトリツリーレベルの数、「`One`」または「`Sub`」)
サーバーへのアクセスに使用する資格。デフォルトは匿名
参照に従うか。 (メインサーバーが利用不可能な場合に使用される、別のサーバーへのポインタ)。デフォルトは `no`
検索時にサーバーが情報を返すまでの待機制限時間 (秒、デフォルトは `30`)
サーバーとの通信時のバインド制限時間 (秒、デフォルトは `30`)。デフォルトは秒
認証方式。デフォルトは `none`

アップグレード情報

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

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

もう 1 つの変更点は、Solaris ネームサービスクライアントでは ldap_cachemgr() の実行が推奨されていましたが、必須ではありませんでした。 ldap_cachemgr() は、常に実行する必要があります。このデーモンは、クライアントが適正に動作するために「必須」です。

新しい `automount` スキーマ

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

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

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) と呼ばれる、ディレクトリ情報を表現する共通のテキストベースの書式をサポートしています。

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

表 18–3 ツール (セクション 1 のマニュアルページより)


ツール	機能
`ldapaddent(1M)`	LDAP コンテナ内に、`/etc` 内のファイルに対応するエントリを作成する。このツールを使用して、ファイルからディレクトリを生成できる。たとえば、`/etc/passwd` 形式のファイルを読み込んで、ディレクトリ内に `passwd` エントリを生成する
`ldaplist(1)`	ディレクトリから、さまざまなサービスの内容をリスト表示するのに使用する
`idsconfig(1M)`	LDAP ネームサービスクライアント対応の Sun ONE Directory Server の設定に使用する

`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 authentication

#
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

パスワード管理のために `pam_ldap` を構成した `pam.conf` ファイル例

# PAM configuration
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login  auth     requisite pam_authtok_get.so.1
login  auth     required  pam_dhkeys.so.1
login  auth     required  pam_dial_auth.so.1
login  auth     binding   pam_unix_auth.so.1 server_policy
login  auth     required  pam_ldap.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin  auth     sufficient pam_rhosts_auth.so.1
rlogin  auth     requisite  pam_authtok_get.so.1
rlogin  auth     required   pam_dhkeys.so.1
rlogin  auth     binding    pam_unix_auth.so.1 server_policy
rlogin  auth     required   pam_ldap.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh     auth sufficient         pam_rhosts_auth.so.1
rsh     auth required           pam_unix_auth.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp     auth requisite          pam_authtok_get.so.1
ppp     auth required           pam_dhkeys.so.1
ppp     auth required           pam_dial_auth.so.1
ppp     auth binding            pam_unix_auth.so.1 server_policy
ppp     auth required           pam_ldap.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other   auth requisite          pam_authtok_get.so.1
other   auth required           pam_dhkeys.so.1
other   auth binding            pam_unix_auth.so.1 server_policy
other   auth required           pam_ldap.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd auth     binding   pam_passwd_auth.so.1 server_policy
passwd auth     required  pam_ldap.so.1
#
# 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  binding   pam_unix_account.so.1 server_policy
other  account  required  pam_ldap.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 requisite pam_authtok_get.so.1
other  password requisite pam_authtok_check.so.1
other  password required  pam_authtok_store.so.1 server_policy
#
# 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 LDAP ネームサービスクライアントをサポートするには、クライアントのスキーママッピング機能を使用してスキーマをマッピングしていない限り、この章で定義されたスキーマをサーバー内で構成する必要があります。

IETF により定義された必須 LDAP スキーマは以下の 3 つです。 RFC 2307 ネットワーク情報サービススキーマ、LDAP メールグループインターネットドラフト、および LDAP Internet Pint 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 と Sun プリンタの属性と ObjectClasses について説明します。

Internet PrintingProtocol (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))
--------------

表 18–4 getXbyY 呼び出しで使用される LDAP フィルタ


フィルタ	定義
`bootparamByName`	`(&(objectClass=bootableDevice)(cn=%s))`
`etherByHost`	`(&(objectClass=ieee802Device)(cn=%s))`
`etherByEther`	`(&(objectClass=ieee802Device)(macAddress=%s))`
`groupByName`	`(&(objectClass=posixGroup)(cn=%s))`
`groupByGID`	`(&(objectClass=posixGroup)(gidNumber=%ld))`
`groupByMember`	`(&(objectClass=posixGroup)(memberUid=%s))`
`hostsByName`	`(&(objectClass=ipHost)(cn=%s))`
`hostsByAddr`	`(&(objectClass=ipHost)(ipHostNumber=%s))`
`keyByUID`	`(&(objectClass=nisKeyObject)(uidNumber=%s))`
`keyByHost`	`(&(objectClass=nisKeyObject)(cn=%s))`
`netByName`	`(&(objectClass=ipNetwork)(cn=%s))`
`netByAddr`	`(&(objectClass=ipNetwork)(ipNetworkNumber=%s))`
`nisgroupMember`	`(membernisnetgroup=%s)`
`maskByNet`	`(&(objectClass=ipNetwork)(ipNetworkNumber=%s))`
`printerByName`	`(&(objectClass=sunPrinter)(printer-name=%s))`
`projectByName`	`(&(objectClass=SolarisProject)(SolarisProjectName=%s))`
`projectByID`	`(&(objectClass=SolarisProject)(SolarisProjectID=%ld)`)
`protoByName`	`(&(objectClass=ipProtocol)(cn=%s))`
`protoByNumber`	`(&(objectClass=ipProtocol)(ipProtocolNumber=%d))`
`passwordByName`	`(&(objectClass=posixAccount)(uid=%s))`
`passwordByNumber`	`(&(objectClass=posixAccount)(uidNumber=%ld))`
`rpcByName`	`(&(objectClass=oncRpc)(cn=%s))`
`rpcByNumber`	`(&(objectClass=oncRpc)(oncRpcNumber=%d))`
`serverByName`	`(&(objectClass=ipService)(cn=%s))`
`serverByPort`	`(&(objectClass=ipService)(ipServicePort=%ld))`
`serverByNameAndProto`	`(&(objectClass=ipService)(cn=%s)(ipServiceProtocol=%s))`
`specialByNameserver`	`(ipServiceProtocol=%s))`
`ByPortAndProto`	`(&(objectClass=shadowAccount)(uid=%s))`
`netgroupByTriple`	`(&(objectClass=nisNetGroup)(nisnetgrouptriple=(%s,%s,%s)))`
`netgroupByMember`	`(&(objectClass=nisNetGroup)(\|(membernisnetgroup=%s)`
`authName`	`(&(objectClass=SolarisAuthAttr)(cn=%s))`
`auditUserByName`	`(&(objectClass=SolarisAuditUser)(uid=%s))`
`execByName`	`(&(objectClass=SolarisExecAttr)(cn=%s) (SolarisKernelSecurityPolicy=%s)(SolarisProfileType=%s))`
`execByPolicy`	`(&(objectClass=SolarisExecAttr)(SolarisProfileId=%s) (SolarisKernelSecurityPolicy=%s)(SolarisProfileType=%s))`
`profileByName`	`(&(objectClass=SolarisProfAttr)(cn=%s))`
`userByName`	`(&(objectClass=SolarisUserAttr)(uid=%s))`

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

表 18–5 getent 属性フィルタ


フィルタ	定義
`aliases`	`(objectClass=rfc822MailGroup)`
`auth_attr`	`(objectClass=SolarisAuthAttr)`
`audit_user`	`(objectClass=SolarisAuditUser)`
`exec_attr`	`(objectClass=SolarisExecAttr)`
`group`	`(objectClass=posixGroup)`
`hosts`	`(objectClass=ipHost)`
`networks`	`(objectClass=ipNetwork)`
`prof_attr`	`(objectClass=SolarisProfAttr)`
`protocols`	`(objectClass=ipProtocol)`
`passwd`	`(objectClass=posixAccount)`
`printers`	`(objectClass=sunPrinter)`
`rpc`	`(objectClass=oncRpc)`
`services`	`(objectClass=ipService)`
`shadow`	`(objectclass=shadowAccount)`
`project`	`(objectClass=SolarisProject)`
`usr_attr`	`(objectClass=SolarisUserAttr)`

第 19 章 NIS から LDAP への移行 (概要と手順)

この章では、LDAP ディレクトリに格納されたネーム情報を使用する NIS クライアントの、サポートを有効にする方法について説明します。この章の手順に従うことで、NIS ネームサービスから LDAP ネームサービスへ移行できます。

LDAP への移行の利点を判定するには、LDAP ネームサービスとその他のネームサービスの比較を参照してください。

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

NIS から LDAP への移行サービス (概要)

NIS から LDAP への移行サービス(「N2L サービス」) を有効にするには、NIS マスターサーバー上の NIS デーモンを、再構成する必要があります。 N2L サービスは、デーモンが NIS から LDAP への移行用マッピングファイルをマスターサーバー上で見つけると有効になります。マッピングファイルでは、NIS マップエントリと、LDAP での同等なディレクトリ情報ツリー (DIT) との間のマッピングを指定します。この移行を完了した NIS マスターサーバーは、「N2L サーバー」と呼ばれます。スレーブサーバーには、NISLDAPmapping ファイルはありません。したがって、引き続きそのまま動作します。スレーブサーバーのデータは、N2L サーバーから、通常の NIS マスターからと同様に、定期的に更新されます。

N2L サービスの動作は、構成ファイル ypserv および NISLDAPmapping によって制御されます。スクリプト inityp2l は、これらの構成ファイルの作成を支援します。いったん N2L サーバーが確立された後は、構成ファイルを直接編集して N2L を管理できます。

N2L サービスは、以下の操作をサポートします。

LDAP ディレクトリ情報ツリー (DIT) 内に NIS マップをインポートする
NIS の速度および拡張性を維持しつつ、クライアントから DIT 情報にアクセスする

あらゆるネームシステムで、1 つのソースの情報だけが正規のソースになります。従来の NIS では、正規の情報は NIS ソースです。 N2L サービスを使用する場合、LDAP ディレクトリが正規のデータソースになります。ディレクトリは、第 13 章「基本コンポーネントおよび概念 (概要)」で説明するディレクトリ管理ツールを使用して管理されます。

NIS ソースは、緊急時のバックアップまたはバックアウト (LDAP に移行するのではなく、NIS の使用をやめる) にのみ使用します。 N2L サービスを使い始めてから、NIS クライアントを徐々に減らすことができます。最終的に、すべての NIS クライアントを Solaris LDAP ネームサービスクライアントに置き換えることができます。

以下の節では、さらに概要情報を説明します。

この章の対象読者

この章の手順を実行するには、NIS および LDAP の概念、用語、および ID を理解する必要があります。 NIS および LDAP のネームサービスについての詳細は、このマニュアルの以下の節を参照してください。

NIS の概要については、第 7 章「ネットワーク情報サービス (NIS) (概要)」。
LDAP の概要については、第 12 章「LDAP ネームサービスの紹介 (概要/リファレンス)」。

N2L サービスを使用しない場合

以下の状況では、N2L サービスを使用しないでください。

NIS と LDAP ネームサービスクライアント間でデータを共有する予定がない環境。

このような環境では、N2L サーバーは、過度に複雑な NIS マスターサーバーとして機能します。
NIS ソースファイルを変更するツール (yppasswd 以外のツール) で NIS マップを管理している環境。

DIT マップから NIS ソースを再生成する処理は、必ずしも正確ではないため、生成されたマップを手動で確認する必要があります。いったん N2L サービスを使用し始めた後は、NIS ソースの再生成は NIS をバックアウトするため、または NIS に戻すためにだけ提供されます。
NIS クライアントのない環境。

このような環境では、Solaris LDAP ネームサービスクライアントおよびそれに対応するツールを使用してください。

N2L サービスのユーザーへの影響

N2L サービスに関連するファイルをインストールするだけでは、NIS サーバーのデフォルトの動作は変更されません。インストール時に、サーバー上の NIS のマニュアルページの一部が変更され、N2L のヘルパースクリプト inityp2l および ypmap2src が追加されます。しかし、NIS サーバー上で inityp2l を実行したり、N2L 構成ファイルを手動で作成したりしないと、NIS コンポーネントは従来の NIS モードで起動し、通常通りに機能します。

inityp2l の実行後に、サーバーとクライアントの動作が少し変更されます。以下の表に、NIS および LDAP のユーザータイプと、N2L サービスの配備後に各タイプのユーザーが注意しなければならない部分の説明を示します。

ユーザータイプ	N2L サービスの影響
NIS マスターサーバー管理者	NIS マスターサーバーは、N2L サーバーに変換される。構成ファイル `NISLDAPmapping` および `ypserv` が、N2L サーバー上にインストールされる。 N2L サーバーの確立後は、LDAP コマンドを使用してネーム情報を管理できる。
NIS スレーブサーバー管理者	N2L の変換後も、NIS スレーブサーバーは NIS を通常の方法で動作する。 `ypmake` によって `yppush` が呼び出されると、N2L サーバーは、更新された NIS マップをスレーブサーバーに転送する。 `ypmake(1M)` のマニュアルページを参照してください。
NIS クライアント	NIS の読み取り動作は、従来の NIS と同様です。 Solaris LDAP ネームサービスクライアントが DIT 内の情報を変更すると、情報が NIS マップ内にコピーされます。コピー操作は、変更可能なタイムアウトの期限が切れると完了します。このような動作は、クライアントが NIS スレーブサーバーに接続された場合の通常の NIS クライアントの動作と同じです。 N2L サーバーが読み取りのために LDAP サーバーにバインドできない場合、N2L サーバーはローカルにキャッシュされたコピーから情報を返します。また、N2L サーバーは内部サーバーエラーを返す場合もあります。 N2L サーバーの構成によって、どちらの方法で応答することも可能です。詳細については、`ypserv(1M)` のマニュアルページを参照してください。
すべてのユーザー	NIS クライアントがパスワードの変更を要求すると、N2L マスターサーバーとネイティブの LDAP クライアントに変更がただちに反映されます。 NIS クライアントでのパスワードの変更を試みて、LDAP サーバーが利用できない場合は、変更は拒絶され N2L サーバーは内部サーバーエラーを返します。この動作によって、キャッシュに誤った情報が書き込まれることを防止します。

NIS から LDAP への移行で使用される用語

N2L サービスの実装に関連する用語を以下に挙げます。

表 19–1 N2L の移行の関連用語


用語	説明
N2L 構成ファイル	`/var/yp/NISLDAPmapping` および `/var/yp/ypserv` ファイル。`ypserv` デーモンが N2L モードでマスターサーバーを起動するために使用する。詳細は、`NISLDAPmapping(4)` および `ypserv(4)` のマニュアルページを参照。
マップ	N2L サービスでは、「マップ」は、以下の 2 とおりの意味で使用される。 NIS が特定の種類の情報を格納するデータベースファイル LDAP DIT との間の NIS 情報のマッピングプロセス
マッピング	LDAP DIT エントリとの間の NIS エントリの変換プロセス
マッピングファイル	`NISLDAPmapping` ファイル。NIS と LDAP の間のエントリのマッピング方法を確立する。
標準マップ	通常使用される NIS マップ。マッピングファイルへの手動修正が不要で、N2L サービスによってサポートされる。サポートされる標準マップのリストは、サポートされる標準マッピングを参照。
非標準マップ	標準の NIS マップであるが、RFC 2307 やその後継で指定されたマッピング以外の、NIS と LDAP DIT 間のマッピングを使用するようにカスタマイズされたマップ。
カスタムマップ	標準のマップではないマップ。したがって、NIS から LDAP への移行時にはマッピングファイルの手動修正が必要。
LDAP クライアント	従来の LDAP クライアント。LDAP サーバーとの間で読み書きを行う。従来の LDAP クライアントは、任意の LDAP サーバーに対して読み取りおよび書き込みを行うシステム。 Solaris LDAP ネームサービスクライアントは、カスタマイズされたネーム情報のサブセットを処理する。
LDAP ネームサービスクライアント	Solaris LDAP クライアント。カスタマイズされたネーム情報のサブセットを処理する。
N2L サーバー	N2L サービスを使用して、N2L サーバーとして再構成された NIS マスターサーバー。新しい構成ファイルによって、再構成が実現する。

N2L のコマンドとファイル

N2L の移行に関連するコマンドとファイルは、次のとおりです。

表 19–2 N2L のコマンドとファイル


コマンドまたはファイル	説明
`/usr/lib/netsvc/yp/inityp2l`	`NISLDAPmapping` および `ypserv` の構成ファイルの作成を支援するユーティリティ。このユーティリティは、これらのファイルを管理するための汎用ツールではありません。熟練したユーザーは、`inityp2l` の出力をテキストエディタを使って検証したりカスタマイズしたりすることで、N2L 構成ファイルを管理したり、カスタムマッピングを作成したりできます。 `inityp2l(1M)` のマニュアルページを参照してください。
`/usr/lib/netsvc/yp/ypmap2src`	標準の NIS マップを同等な NIS ソースファイルに近似したファイルに変換するユーティリティです。 `ypmap2src` の主要な用途は、N2L の移行サーバーから従来の NIS への変換です。 `ypmap2src(1M)` のマニュアルページを参照してください。
`/var/yp/NISLDAPmapping`	NIS マップエントリと、これと同等な LDAP でのディレクトリ情報ツリー (DIT) エントリとの間のマッピングを指定する構成ファイルです。 `NISLDAPmapping(4)` のマニュアルページを参照してください。
`/var/yp/ypserv`	NIS から LDAP への移行用デーモンの構成情報を指定するファイルです。 `ypserv(4)` のマニュアルページを参照してください。

サポートされる標準マッピング

デフォルトでは、N2L サービスは以下のリストのマップと RFC 2307 (またはその後継) LDAP エントリとの間のマッピングをサポートします。これらの標準マップでは、マッピングファイルへの手動修正は不要です。システム上で以下のリストにないマップは、カスタムマップと見なされ、マッピングファイルの手動修正が必要です。

また、N2L サービスは、auto.* マップの自動マッピングもサポートします。ただし、ほとんどの auto.* ファイル名とそのコンテンツは、各ネットワーク構成に固有なので、このリストではこれらのファイルは指定していません。例外は、auto.home マップと auto.master マップです。これらは標準マップとしてサポートされます。

audit_user
auth_attr
auto.home
auto.master
bootparams
ethers.byaddr ethers.byname
exec_attr
group.bygid group.byname group.adjunct.byname
hosts.byaddr hosts.byname
ipnodes.byaddr ipnodes.byname
mail.byaddr mail.aliases
netgroup netgroup.byprojid netgroup.byuser netgroup.byhost
netid.byname
netmasks.byaddr
networks.byaddr networks.byname
passwd.byname passwd.byuid passwd.adjunct.byname
printers.conf.byname
prof_attr
project.byname project.byprojectid
protocols.byname protocols.bynumber
publickey.byname
rpc.bynumber
services.byname services.byservicename
timezone.byname
user_attr

NIS から LDAP への移行 (作業マップ)

以下の表に、標準およびカスタムの NIS から LDAP への変換マッピングによって、N2L サービスをインストールし管理するために必要な手順を示します。

作業	説明	参照先
すべての前提条件の完了	NIS サーバーと Sun ONE Directory Server (LDAP サーバー) を正しく構成すること	NIS から LDAP への移行のための前提条件
N2L サービスの設定	NIS マスターサーバーで、`inityp2l` を実行して、以下のいずれかのマッピングを設定する
	標準マッピング	標準マッピングを使用して N2L サービスを設定する方法
	カスタムまたは非標準マッピング	カスタムマッピングまたは非標準マッピングを使用して N2L サービスを設定する方法
マップのカスタマイズ	N2L の移行のためのカスタムマップの作成方法の例を参照する	カスタムマップの例
N2L のための Sun ONE Directory Server の構成	N2L 移行のための、LDAP サーバーとして Sun ONE Directory Server を構成し調整する	Sun ONE Directory Server を使用した N2L の最良の実施例
システムの障害追跡	一般的な N2L の問題を特定し解決する	N2L の障害追跡
NIS に戻す方法	以下のいずれか適切なマップを使用して NIS に戻す
	以前の NIS ソースファイルに基づくマップ	以前のソースファイルに基づくマップに戻す方法
	現在の DIT に基づくマップ	現在の DIT 内容に基づくマップに戻す方法

NIS から LDAP への移行のための前提条件

N2L サービスを実装する前に、以下の項目をチェックし、完了する必要があります。

inityp2l スクリプトを実行して N2L モードを有効にする前に、システムが従来の NIS サーバーで動作するように設定されていること
システムで LDAP ディレクトリサーバーを構成していること

NIS から LDAP への移行ツールでは、Sun ONE Directory Server (以前の名称は iPlanet Directory Server) と、Sun から提供されるその互換バージョンのディレクトリサーバーがサポートされています。 Sun ONE Directory Server を使用している場合は、N2L サービスを設定する前に、idsconfig コマンドを使用してサーバーを構成してください。 idsconfig についての詳細は、第 15 章「Sun ONE Directory Server の設定 (手順)」と idsconfig(1M) のマニュアルページを参照してください。

その他の (サードパーティの) LDAP サーバーが、N2L サービスで動作する場合もありますが、Sun はそれらをサポートしていません。 Sun ONE Directory Server または Sun 互換サーバー以外の LDAP サーバーを使用している場合は、N2L サービスを設定する前に、RFC 2307 (またはその後継) スキーマをサポートするようにサーバーを手動で構成する必要があります。
nsswitch.conf ファイルで少なくとも hosts エントリおよび ipnodes エントリに対して、検索順序として nis の前に files がリストされていることを確認すること
N2L マスターサーバーと LDAP サーバーのアドレスが、N2L マスターサーバー上の hosts ファイルまたは ipnodes ファイルに存在することを確認すること。ローカルホスト名を解決するためのシステムの構成方法に応じて、サーバーアドレスは hosts ファイル、ipnodes ファイル、またはその両方にリストされる必要があります。

代わりに、ypserv で、ホスト名ではなく LDAP サーバーのアドレスをリストする方法もあります。このことは、LDAP サーバーのアドレスが別の場所にもリストされていることを意味しています。したがって、LDAP サーバーと N2L マスターサーバーのどちらかのアドレスを変更するには、別のファイルの修正も必要です。

N2L サービスの設定

以下の 2 つの手順に示すように、標準のマッピングとカスタムマッピングのどちらかを使用して、N2L サービスを設定できます。

NIS から LDAP への変換作業の一部として、inityp2l コマンドを実行する必要があります。このコマンドは、対話型で、構成情報を入力するスクリプトを実行します。以下のリストに、構成に必要な情報の種類を示します。これらの属性の詳細については、ypserv(1M) のマニュアルページを参照してください。

作成する構成ファイルの名前 (デフォルト = /etc/default/ypserv)
LDAP の構成情報を格納する DN (デフォルト = ypserv)
LDAP との間でデータをマッピングするための優先サーバーリスト
LDAP との間でデータをマッピングするための認証方式
LDAP との間でデータをマッピングするための TLS (Transport Layer Security)
LDAP との間でデータを読み書きするためのプロキシのユーザーバインド DN
LDAP との間でデータを読み書きするためのプロキシのユーザーパスワード
LDAP バインド動作のタイムアウト値 (秒単位)
LDAP 検索動作のタイムアウト値 (秒単位)
LDAP 変更動作のタイムアウト値 (秒単位)
LDAP 追加動作のタイムアウト値 (秒単位)
LDAP 削除動作のタイムアウト値 (秒単位)
LDAP サーバーでの検索動作の制限時間 (秒単位)
LDAP サーバーでの検索動作の制限サイズ (バイト単位)
N2L が LDAP 照会に従うかどうか
LDAP 検索のエラー処理、検索試行回数、および各試行間のタイムアウト (秒単位)
格納のエラー処理、検索試行回数、および各試行間のタイムアウト (秒単位)
マッピングファイル名
auto.* マップのマッピング情報を生成するかどうか

スクリプトは、マッピングファイル内の適切な位置にカスタムマップについての情報を配置します。
ネーミングコンテキスト
パスワードの変更を有効にするかどうか
任意のマップのデフォルトの TTL 値を変更するかどうか

注 –

sasl/cram-md5 認証は、Sun ONE Directory Server を含むほとんどの LDAP サーバーではサポートされません。

標準マッピングを使用して N2L サービスを設定する方法

サポートされる標準マッピングにリストされているマップを移行する場合は、この手順に従います。カスタムマップまたは非標準マップを使用している場合は、カスタムマッピングまたは非標準マッピングを使用して N2L サービスを設定する方法を参照してください。

LDAP サーバーの設定が終わったら、inityp2l スクリプトを実行して、プロンプトに従って構成情報を入力します。 inityp2l は構成を行い、標準マップのためのマッピングファイルを設定します。

NIS から LDAP への移行のための前提条件にリストされた前提条件の手順を完了します。

NIS マスターサーバーで、スーパーユーザーまたは同等の権限を持つユーザーになります。

NIS マスターサーバーを N2L サーバーに変換します。
# inityp2l
NIS マスターサーバーで inityp2l スクリプトを実行して、プロンプトに従います。指定が必要な情報のリストは、N2L サービスの設定を参照してください。

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

LDAP ディレクトリ情報ツリー (DIT) が完全に初期化されているかどうかを判定します。

NISLDAPmapping ファイルにリストされたすべてのマップの配備に必要な情報がすでに DIT 内に存在する場合、DIT は完全に初期化されています。
- 初期化されていない場合、手順 5 を続行して手順 6 をスキップします。
- 初期化されている場合、手順 5 をスキップして手順 6 に進みます。

NIS ソースファイルから移行するため、DIT を初期化します。

DIT が完全に初期化されていない場合に限って、以下の手順を実行してください。
1. 以前の NIS マップが最新の状態になっていることを確認してください。
  # cd /var/yp # make
  詳細については、ypmake(1M) のマニュアルページを参照してください。
2. NIS デーモンを停止します。
  # ypstop
3. 以前のマップを DIT にコピーしてから、マップ用の N2L サポートを初期化します。
  # ypserv -Ir
  ypserv が終了するまで待ちます。
  
  ヒント –
  元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。
4. NIS デーモンを再起動し、デーモンが新しいマップを使用していることを確認します。
  # ypstart
  これで、標準マップでの N2L サービスの設定を完了します。手順 6 を行う必要はありません。

NIS マップを初期化します。

DIT が完全に初期化され、手順 5 をスキップした場合に限って、以下の手順を実行してください。
1. NIS デーモンを停止します。
  # ypstop
2. DIT 内の情報に従って NIS マップを初期化します。
  # ypserv -r
  ypserv が終了するまで待ちます。
  
  ヒント –
  元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。
3. NIS デーモンを再起動し、デーモンが新しいマップを使用していることを確認します。
  # ypstart

カスタムマッピングまたは非標準マッピングを使用して N2L サービスを設定する方法

以下の状況に適合する場合、この手順を実行してください。

サポートされる標準マッピングにリストされていないマップがある
RFC 2307 とは異なるマッピングで LDAP にマップしたい標準の NIS マップがある

NIS から LDAP への移行のための前提条件にリストされた前提条件の手順を完了します。

NIS マスターサーバーで、スーパーユーザーまたは同等の権限を持つユーザーになります。

NIS マスターサーバーを N2L サーバーに構成します。
# inityp2l
NIS マスターサーバーで inityp2l スクリプトを実行して、プロンプトに従います。指定が必要な情報のリストは、N2L サービスの設定を参照してください。

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

/var/yp/NISLDAPmapping ファイルを修正します。

マッピングファイルの修正方法の例は、カスタムマップの例を参照してください。

LDAP ディレクトリ情報ツリー (DIT) が完全に初期化されているかどうかを判定します。

NISLDAPmapping ファイルにリストされたすべてのマップの配備に必要な情報がすでに DIT 内に存在する場合、DIT は完全に初期化されています。
- 初期化されていない場合、手順 6、手順 8、および手順 9 を完了します。
- 初期化されている場合、手順 6 をスキップして、手順 7、手順 8、および手順 9 を完了します。

NIS ソースファイルから移行するため、DIT を初期化します。
1. 以前の NIS マップが最新の状態になっていることを確認してください。
  # cd /var/yp # make
  詳細については、ypmake(1M) のマニュアルページを参照してください。
2. NIS デーモンを停止します。
  # ypstop
3. 以前のマップを DIT にコピーしてから、マップ用の N2L サポートを初期化します。
  # ypserv -Ir
  ypserv が終了するまで待ちます。
  
  ヒント –
  元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。
4. NIS デーモンを再起動し、デーモンが新しいマップを使用していることを確認します。
  # ypstart
5. 手順 7 をスキップして、手順 8 から続行します。

NIS マップを初期化します。

DIT が完全に初期化されている場合に限って、この手順を実行します。
1. NIS デーモンを停止します。
  # ypstop
2. DIT 内の情報に従って NIS マップを初期化します。
  # ypserv -r
  ypserv が終了するまで待ちます。
  
  ヒント –
  元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。
3. NIS デーモンを再起動し、デーモンが新しいマップを使用していることを確認します。
  # ypstart

LDAP エントリが正しいことを確認します。

エントリが間違っている場合、LDAP ネームサービスクライアントからはそのエントリを見つけられません。
# ldapsearch -h server -s sub -b "ou=servdates, dc=..." \ "objectclass=servDates"

LDAP_ マップの内容を確認しします。

以下に、makedbm を使用して servdate.bynumber マップの内容を確認する方法の例を示します。
# makedbm -u LDAP_servdate.bynumber plato: 1/3/2001 johnson: 2/4/2003,1/3/2001 yeats: 4/4/2002 poe: 3/3/2002,3/4/2000
出力結果が期待どおりの内容であれば、NIS から LDAP への移行は成功です。

元の NIS dbm ファイルは上書きされないことに注意してください。したがって、いつでもこれらのファイルは回復できます。詳細については、NIS に戻す方法を参照してください。

カスタムマップの例

以下の 2 つの例に、マップをカスタマイズする方法を示します。必要に応じて、任意のテキストエディタを使用して、/var/yp/NISLDAPmapping ファイルを修正します。ファイルの属性と構文についての詳細は、NISLDAPmapping(4) のマニュアルページと第 13 章「基本コンポーネントおよび概念 (概要)」の LDAP ネームサービス情報を参照してください。

例 1-ホストエントリの移動

この例では、DIT でデフォルトの位置から別の (非標準の) 位置にホストエントリを移動する方法を示します。

NISLDAPmapping ファイルの nisLDAPobjectDN 属性を、新しいベース LDAP 識別名 (DN) に変更します。この例では、LDAP オブジェクトの内部構造は変更されません。したがって、objectClass エントリは変更されません。

変更前:

nisLDAPobjectDN hosts: \
                        ou=hosts,?one?, \
                        objectClass=device, \
                        objectClass=ipHost

変更後:

nisLDAPobjectDN hosts: \
                        ou=newHosts,?one?, \
                        objectClass=device, \
                        objectClass=ipHost

この変更によって、エントリは以下のようにマッピングされます。

dn: ou=newHosts, dom=domain1, dc=sun, dc=com

元は、以下のようでした。

dn: ou=hosts, dom=domain1, dc=sun, dc=com.

例 2-カスタムマップの実装

この例では、カスタムマップの実装方法を示します。

仮想のマップ「servdate.bynumber」には、システムのサービス日付についての情報が含まれます。このマップには、マシンのシリアル番号でインデックスが付けられます。この例では、123 です。各エントリは、マシンの所有者名、コロン、およびサービス日付のコンマ区切りのリストで構成されます。たとえば、John Smith:1/3/2001,4/5/2003 のようになります。

古いマップ構造は、以下の形式の LDAP エントリにマップされます。

dn: number=123,ou=servdates,dc=... \
                 number: 123 \
                 userName: John Smith \
                 date: 1/3/2001 \
                 date: 4/5/2003 \
                  .
                  .
                  .
                 objectClass: servDates

NISLDAPmapping ファイルを調べると、必要なパターンに最も近いマッピングが group であることがわかります。カスタムマッピングは group マッピングを参考にできます。マップは 1 つだけなので、nisLDAPdatabaseIdMapping 属性は不要です。 NISLDAPmapping に追加される属性は、以下のとおりです。

nisLDAPentryTtl servdate.bynumber:1800:5400:3600

nisLDAPnameFields servdate.bynumber: \
                        ("%s:%s", uname, dates)

nisLDAPobjectDN servdate.bynumber: \
                        ou=servdates, ?one? \
                        objectClass=servDates:

nisLDAPattributeFromField servdate.bynumber: \
                        dn=("number=%s,", rf_key), \
                        number=rf_key, \
                        userName=uname, \
                        (date)=(dates, ",")

nisLDAPfieldFromAttribute servdate.bynumber: \
                        rf_key=number, \
                        uname=userName, \
                        dates=("%s,", (date), ",")

Sun ONE Directory Server を使用した N2L の最良の実施例

N2L サービスは、Sun ONE Directory Server (以前の名称は iPlanet Directory Server) と、Sun の提供するその互換バージョンのディレクトリサーバーをサポートしています。その他の (サードパーティーの) LDAP サーバーが、N2L サービスで動作する場合もありますが、Sun はそれらをサポートしていません。 Sun ONE Directory Server または Sun の互換サーバー以外の LDAP サーバーを使用している場合は、RFC 2307 (またはその後継スキーマ) に準拠するように、サーバーを手動で構成する必要があります。

Sun ONE Directory Server を使用すれば、ディレクトリサーバーを強化してパフォーマンスを改善できます。これらの強化を行うには、Sun ONE Directory Server 上に LDAP の管理者権限が必要です。また、ディレクトリサーバーのリブートが必要な場合もあります。リブートは、サーバーの LDAP クライアントとの間で調整が必要な作業です。 Web サイト docs.sun.com で、iPlanet Directory Server 5.1 のドキュメントを入手できます。

Sun ONE Directory Server を使用した仮想リスト表示インデックスの作成

大規模なマップでは、LDAP の仮想リスト表示 (VLV) インデックスを使用して、LDAP の検索から正しい結果が得られることを保証しなければなりません。 Sun ONE Directory Server での VLV インデックスの設定についての詳細は、docs.sun.com Web サイトの Sun ONE Directory Server のドキュメントを参照してください。

VLV の検索結果では、固定ページサイズ 50000 を使用します。Sun ONE Directory Server で VLV を使用する場合は、LDAP サーバーと N2L サーバーの両方でこのサイズの転送を処理できる必要があります。すべてのマップがこの制限より小規模であることが明らかな場合は、VLV インデックスを使用する必要はありません。ただし、マップがこのサイズ制限より大きい場合、またはすべてのマップのサイズが明確な場合以外には、VLV インデックスを使用して、結果が不完全となることを防止しなければなりません。

VLV インデックスを使用している場合は、以下のように適切なサイズ制限を設定します。

Sun ONE Directory Server では、 nsslapd-sizelimit 属性を 50000 以上、または -1 に設定する必要があります。詳細は、idsconfig(1M) のマニュアルページを参照してください。
N2L サーバーでは、 nisLDAPsearchSizelimit 属性を 50000 以上、または 0 に設定する必要があります。詳細は、NISLDAPmapping(4) のマニュアルページを参照してください。

VLV インデックスが作成されたら、Sun ONE Directory Server で vlvindex オプションを付けて directoryserver を実行してインデックスを有効にします。詳細は、directoryserver(1M) のマニュアルページを参照してください。

標準マップ用 VLV

以下の状況に適合する場合、Sun ONE Directory Server の idsconfig コマンドを使用して、VLV を設定してください。

Sun ONE Directory Server を使用している場合
標準マップを RFC 2307 LDAP エントリにマッピングしている場合

VLV はドメイン固有です。よって、idsconfig を実行するたびに、1 つの NIS ドメインに VLV が作成されます。したがって、NIS から LDAP への移行中に、NISLDAPmapping ファイルに含まれる各 nisLDAPdomainContext 属性に対して、idsconfig を 1 回実行しなければなりません。

カスタムマップおよび非標準マップ用 VLV

以下の状況に適合する場合、マップ用に新しい Sun ONE Directory Server の VLV を手動で作成するか、既存の VLV インデックスをコピーして修正しなければなりません。

Sun ONE Directory Server を使用している場合
大規模なカスタムマップがあるか、非標準の DIT 位置にマップされる標準のマップがある場合

既存の VLV インデックスを表示するには、以下のように入力します。

# ldapsearch -h hostname -s sub -b "cn=ldbm database,cn=plugins,cn=config" \
"objectClass=vlvSearch"

Sun ONE Directory Server によるサーバーのタイムアウトの防止

N2L サーバーがマップをリフレッシュすると、その結果、大規模な LDAP ディレクトリアクセスが行われる場合があります。 Sun ONE Directory Server が正しく構成されていない場合、リフレッシュ動作は完了前にタイムアウトになることがあります。ディレクトリサーバーのタイムアウトを防止するには、以下の Sun ONE Directory Server の属性を手動で修正するか、idsconfig コマンドを実行します。

たとえば、サーバーでの検索リクエストの実行にかかる最小時間を秒単位で増やすには、以下の属性を修正します。

dn: cn=config
nsslapd-timelimit: -1

テストのためには、属性値として -1 を使用できます。この値は、制限がないことを示しています。最適な制限値が決まったら、属性値を変更します。稼働サーバーに、-1 の属性値が設定されていてはなりません。制限がないと、サーバーがサービス妨害攻撃に無防備になる場合があります。

LDAP での Sun ONE Directory Server の構成についての詳細は、このマニュアルのパート IVを参照してください。

Sun ONE Directory Server 使用時のバッファーオーバーランの防止

バッファーオーバーランを防止するには、Sun ONE Directory Server の属性を手動で修正するか、idsconfig コマンドを実行します。

たとえば、クライアント検索照会に返されるエントリの最大数を増やすには、以下の属性を修正します。
dn: cn=config nsslapd-sizelimit: -1
クライアント検索照会で確認されるエントリの最大数を増やすには、以下の属性を修正します。
dn: cn=config, cn=ldbm database, cn=plugins, cn=config nsslapd-lookthroughlimit: -1

VLV を使用している場合は、sizelimit 属性値をSun ONE Directory Server を使用した仮想リスト表示インデックスの作成での定義に従う必要があります。 VLV を使用していない場合、最も大きなコンテナを格納できるようにサイズ制限を設定する必要があります。

Sun ONE Directory Server の構成についての詳細は、このマニュアルのパート IVを参照してください。

N2L の制限

N2L サーバーの設定が完了すると、以降 NIS ソースファイルは使用されません。したがって、N2L サーバーで ypmake を実行しないでください。既存の cron ジョブなどで誤って ypmake を実行した場合、N2L サービスは影響を受けません。ただし、yppush を明示的に呼び出すことを推奨する警告がログに記録されます。

N2L の障害追跡

この節では、障害追跡の 2 つの領域を説明します。

よくある LDAP エラーメッセージ

N2L サーバーが LDAP 内部の問題に関連するエラーをログに記録して、LDAP 関連のエラーメッセージが表示される場合があります。エラーは致命的なものではありませんが、調査すべき問題を示しています。たとえば、N2L サーバーは動作を継続していても、返される結果が古かったり、不完全になる場合があります。

以下のリストに、N2L サービスを実装するときに発生する可能性のある、よくある LDAP エラーメッセージをいくつか示します。エラーの説明、考えられる原因、およびエラーの対策も含みます。

Administrative limit exceeded

エラー番号: 11

原因 : ディレクトリサーバーの nsslapd-sizelimit 属性で許可されたものより大きな LDAP 検索が実行されました。情報の一部だけが返されます。

対策 : nsslapd-sizelimit 属性の値を増やすか、失敗した検索に VLV インデックスを実装します。

Invalid DN Syntax

エラー番号: 34

原因 : 不正な文字を含む DN を使用して LDAP エントリの書き込みが試みられました。 N2L サーバーは、DN 内で生成される + 記号などの不正な文字のエスケープを試みます。

対策 : LDAP サーバーのエラーログをチェックして、どのような不正な DN が書き込まれたかを調べます。それから、不正な DN を生成した NISLDAPmapping ファイルを修正します。

Object class violation

エラー番号: 65

原因 : 無効な LDAP エントリの書き込みが試みられました。通常、以下のいずれかの状況で生じる MUST 属性が見つからないことがこのエラーの原因です。

見つからない属性のエントリを作成する NISLDAPmapping ファイルのバグ
存在しないオブジェクトへの AUXILIARY 属性の追加の試み

たとえば、ユーザー名がまだ passwd.byxxx マップから作成されていない場合、そのユーザーに対する補足情報の追加の試みは失敗します。

対策 : NISLDAPmapping ファイルのバグである場合は、LDAP サーバーエラーログへの書き込みをチェックして、問題の原因を判断します。

Can't contact LDAP server

エラー番号: 81

原因 : ypserv ファイルが正しく構成されず、間違った LDAP ディレクトリサーバーを指定していることがあります。または、ディレクトリサーバーが稼働していません。

対策 :

ypserv ファイルを再構成して、正しい LDAP ディレクトリサーバーを指定します。
LDAP サーバーが実行中であることを確認するには、ディレクトリサーバーでスーパーユーザーになって、以下のように入力します。
# pgrep -l slapd

Timeout

エラー番号: 85

原因 : LDAP 動作がタイムアウトしました。多くの場合、DIT からマップを更新している間に発生します。古い情報がマップに含まれている可能性があります。

対策 : ypserv 構成ファイルの各 nisLDAPxxxTimeout 属性を増やします (xxx の部分は何種類かある)。

N2L の問題

N2L サーバーの実行中に、以下の問題が発生する場合があります。考えられる原因と対策を説明します。

`NISLDAPmapping` ファイルのデバッグ

マッピングファイル NISLDAPmapping は複雑なファイルです。多くの潜在的なエラーによって、マッピングが予期しない動作をする場合があります。以下の方法を用いて、この問題を解決してください。

ypserv -ir (または -Ir) を実行したときのコンソールメッセージの表示

問題 : コンソールに簡単なメッセージが表示され、サーバーが終了します (詳細な説明は、syslog に書き込まれます)。

原因 : マッピングファイルの構文が間違っている場合があります。

対策 : NISLDAPmapping ファイルの構文をチェックして修正します。

起動時に NIS デーモンが終了する

問題 : ypserv またはその他の NIS デーモンを実行すると、LDAP 関連のエラーメッセージがログに記録され、デーモンが終了します。

原因 : 原因は以下のいずれかが考えられます。

LDAP サーバーと通信できない
NIS マップまたは DIT 内のエントリが、指定されたマッピングと互換性がない
LDAP サーバーへの読み書きの試みがエラーを返す

対策 : LDAP サーバーのエラーログを調査します。よくある LDAP エラーメッセージにリストされた LDAP エラーを参照してください。

NIS 動作からの予期しない結果

問題 : NIS 動作が予期した結果を返さず、エラーはログに記録されません。

原因 : 間違ったエントリが LDAP または NIS マップに存在する場合があります。この結果、マッピングが期待したとおりに完了しません。

対策 : LDAP DIT と NIS マップの N2L バージョンのエントリをチェックして、修正します。

LDAP DIT に正しいエントリが存在するかをチェックしてから、必要に応じてエントリを修正します。

Sun ONE Directory Server を使用している場合は、directoryserver startconsole を実行して管理コンソールを起動します。
新しく生成されたマップと元のマップを比較して、/var/yp ディレクトリの N2L バージョンの NIS マップに期待どおりのエントリが含まれていることをチェックします。必要に応じてエントリを修正します。
# cd /var/yp/domainname # makedbm -u test.byname # makedbm -u LDAP_test.byname
マップの出力をチェックする場合は、以下に注意してください。
- 両方のファイルでのエントリの順序が異なる可能性
  
  出力を比較する前に、sort コマンドを使用します。
- 両方のファイルでの空白の使い方が異なる可能性
  
  出力を比較するときに、diff -b コマンドを使用します。

NIS マップの処理順序

問題 : オブジェクトクラス違反が発生しています。

原因 : ypserv -i コマンドを実行すると、各 NIS マップが読み取られ、その内容が DIT に書き込まれます。複数のマップが、同一の DIT オブジェクトに属性を提供する場合もあります。通常、オブジェクトは、1 つのマップによってそのオブジェクトの MUST 属性のすべてを含む大部分を生成されます。他のマップは、他の MAY 属性を提供します。

マップは、NISLDAPmapping ファイルに定義されている nisLDAPobjectDN 属性と同じ順序で処理されます。 MAY 属性を含むマップが MUST 属性を含むマップより先に処理されると、オブジェクトクラス違反が発生します。このエラーについての詳細は、よくある LDAP エラーメッセージのエラー 65 を参照してください。

対策 : マップが正しい順序で処理されるように、nisLDAPobjectDN 属性の順序を変更します。

一時的に問題を回避するには、ypserv - i コマンドを複数回実行します。コマンドを実行するたびに、より多くの LDAP エントリが作られます。

注 –

1 つのマップからオブジェクトのすべての MUST 属性を作成できないマッピングはサポートされていません。

N2L サーバーのタイムアウトの問題

問題 : サーバーがタイムアウトします。

原因 : N2L サーバーがマップをリフレッシュすると、その結果、大規模な LDAP ディレクトリアクセスが行われる場合があります。 Sun ONE Directory Server が正しく構成されていない場合、この動作は完了前にタイムアウトになることがあります。

対策 : ディレクトリサーバーのタイムアウトを防止するには、Sun ONE Directory Server の属性を手動で修正するか、idsconfig コマンドを実行します。詳細は、よくある LDAP エラーメッセージと Sun ONE Directory Server を使用した N2L の最良の実施例を参照してください。

N2L のロックファイルの問題

問題 : ypserv コマンドは起動しますが、NIS リクエストに応答しません。

原因 : N2L サーバーのロックファイルが、NIS マップへのアクセスと正しく同期していません。このような状況が発生してはなりません。

対策 : N2L サーバーで以下のコマンドを入力します。

# ypstop
# rm /var/run/yp_maplock /var/run/yp_mapupdate
# ypstart

N2L のデッドロックの問題

問題 : N2L サーバーがデッドロックします。

原因 : N2L マスターサーバーのアドレスと LDAP サーバーのアドレスが hosts、ipnodes、または ypserv ファイルに正しくリストされていない場合、デッドロックの発生することがあります。 N2L の正しいアドレス構成についての詳細は、NIS から LDAP への移行のための前提条件を参照してください。

デッドロックの発生する例として、以下の一連の事柄を考えてみてください。

NIS クライアントが IP アドレスの検索を試みます。
N2L サーバーが、hosts エントリは最新ではないことを検出します。
N2L サーバーが LDAP からの hosts エントリの更新を試みます。
N2L サーバーは、ypserv から LDAP サーバーの名前を取得してから、libldap を使用して検索を実行します。
libldap は、ネームサービススイッチを呼び出して、LDAP サーバー名の IP アドレスへの変換を試みます。
ネームサービススイッチの設定に基づき、N2L サーバーへの NIS 呼び出しを行い、デッドロックが発生します。

対策 : N2L マスターサーバー上の hosts ファイルまたは ipnodes ファイルに N2L マスターサーバーと LDAP サーバーのアドレスをリストします。 hosts ファイルおよび ipnodes ファイルがローカルホスト名を解決するためにどのようにして構成されているかに応じて、サーバーアドレスは、各ファイルに、またはその両方にリストされなければなりません。また、nsswitch.conf ファイルの hosts および ipnodes エントリで、検索順序として nis の前に files をリストしていることをチェックしてください。

別の方法として、このデッドロックに対して、ypserv ファイルでホスト名ではなく LDAP サーバーアドレスを記述する方法もあります。これは、LDAP サーバーアドレスが別の場所に記述されていることを意味しています。したがって、LDAP サーバーと N2L サーバーのどちらかでアドレスを変更する場合には、さらに少し作業が必要になります。

NIS に戻す方法

N2L サービスを使用して NIS から LDAP に移行したサイトでは、すべての NIS クライアントを Solaris LDAP ネームサービスクライアントに徐々に置き換えていくことが求められます。最終的には、NIS クライアントに対するサポートは不要になります。ただし、必要に応じて、N2L サービスは、以下の 2 つの手順に示すように、従来の NIS に復帰するための 2種類の方法を提供します。

ヒント –

従来の NIS は、N2L バージョンの NIS マップが存在しても、それを無視します。 NIS に戻した後で、サーバー上の N2L バージョンのマップをそのままにしておいた場合でも問題を起こしません。したがって、後で再度 N2L を有効にしたい場合に備えて、N2L マップを保管しておくことができます。ただし、マップの保管はディスクスペースを消費します。

以前のソースファイルに基づくマップに戻す方法

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

NIS デーモンを停止します。
# ypstop

N2L を無効にします。

このコマンドは、N2L マッピングファイルをバックアップして、移動します。
# mv /var/yp/NISLDAPmapping backup_filename

NOPUSH 環境変数を設定して、ypmake によって新しいマップが転送されないようにします。
# NOPUSH=1

以前のソースに基づいて、NIS マップの新しいセットを作成します。
# cd /var/yp # make

(オプション) N2L バージョンの NIS マップを削除します。
# rm /var/yp/domainname/LDAP_*

NIS デーモンを再起動します。
# ypstart

現在の DIT 内容に基づくマップに戻す方法

この手順を実行する前に、従来の NIS ソースファイルをバックアップします。

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

NIS デーモンを停止します。
# ypstop

DIT に基づいてマップを更新します。
# ypserv -r
ypserv が終了するまで待ちます。

N2L を無効にします。

このコマンドは、N2L マッピングファイルをバックアップして、移動します。
# mv /var/yp/NISLDAPmapping backup_filename

NIS ソースファイルを再生成します。
# ypmap2src

再生成された NIS ソースファイルの内容と構造が正しいことを手動でチェックしてください。

再生成された NIS ソースファイルを適切なディレクトリに移動します。

(オプション) N2L バージョンのマッピングファイルを削除します。
# rm /var/yp/domainname/LDAP_*

NIS デーモンを再起動します。
# ypstart

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

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

NIS+ からLDAP への移行の概要

NIS+ サーバーデーモン rpc.nisd は、 /var/nis/data ディレクトリにある独自フォーマットファイルに NIS+ データを保存します。 NIS+ データは、LDAP と同期化することができます。従来は、そのために外部エージェントが必要でした。しかし、新しい NIS+ デーモンでは、LDAP サーバーを NIS+ データのデータリポジトリとして使用できるようになりました。これにより、NIS+ および LDAP クライアントが同一のネームサービス情報を共有できるため、メインネームサービスを NIS+ から 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 で対応づけられる

構成ファイル

2 つのを使用して、rpc.nisd 処理を制御します。

/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 オプションに構成属性を指定することもできます。複数の場所で同じ属性が指定されている場合、優先順位 (高から低) は次のとおりです。

rpc.nisd -x オプション
構成ファイル
LDAP *

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

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

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

この方法は、Sun ONE Directory Server で機能します。また、その他の 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

必要に応じて、SSL を使用し、証明書ファイルの場所を指定します。詳細については、SSL の使用を参照してください。

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 秒に設定されます。

同様に、次の場合は、テーブルオブジェクトが最初に読み込まれたときに、1800 - 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 とすると、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 に変換する方法

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+ に変換する方法

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 サーバーのマニュアルを参照してください。

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

# nisbackup -a /nisbackup

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

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

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

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

# pkill rpc.nisd

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

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

-x nisplusLDAPinitialUpdateAction=from_ldap \

-x nisplusLDAPinitialUpdateOnly=yes

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

# /usr/sbin/rpc.nisd

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

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

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

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

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

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

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

# nisaddent -m -f /after/group group

マージ後のテーブルから、不要な 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 にリダイレクトします。

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

/tmp/delete-dn /dev/null

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

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

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

# pkill rpc.nisd

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

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

-x nisplusLDAPinitialUpdateAction=to_ldap \

-x nisplusLDAPinitialUpdateOnly=yes

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+ マスター上のデータと異なる
複製は、ローカルな NIS+ データベースであるキャッシュにデータを格納している。このキャッシュは期限切れではないが、LDAP と同期がとれていない。

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

ディレクトリサーバー

LDAP マッピング (rpc.nisd デーモンの) では、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 との間でアカウント情報を完全に共有することはできません。

Sun ONE Directory Server の構成

Sun ONE Directory Server のインストール、設定、および管理の詳細については、Sun ONE Directory Server collection を参照してください。

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

注 –

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

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

/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) を組み合わせることができます。

パフォーマンスとインデックス処理

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 に追加するには

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 ) )

関連するテーブルの 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

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

マッピングの変更を有効にするために、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")), \
  から
  (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 ) )

新しく作成した nisplusNetname 属性および nisplusPrincipalName 属性を使用するために cred.org_dir マッピングを有効にします。テンプレートマッピングファイル /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+ で使用される編成と大きく異なるときは、エントリの追加が複雑になることがあります。ここでは簡単な例を挙げます。

エントリ以外のオブジェクトを対応づけるには

対応づけるオブジェクトの完全指定名を検索します。

このオブジェクト名が nisplusLDAPbaseDomain 属性で指定されるドメイン名に存在する場合は、nisplusLDAPbaseDomain 値に等しい部分は省略できます。

たとえば、nisplusLDAPbaseDomain の値が some.domain. で、マッピング先のオブジェクトが nodeinfo.some.domain. と呼ばれるテーブルの場合、オブジェクト名は nodeinfo に短縮できます。

オブジェクトを識別するデータベース 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

オブジェクトの 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

オブジェクトデータを 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 はマスターおよび複製の両方に対して使用できます。

(マッピング先の NIS+ オブジェクトがまだ NIS+ に作成されていない場合は、この手順を省略できます。) オブジェクトデータを LDAP に格納します。この操作には、rpc.nisd デーモンを使用できます。ただし、nisldapmaptest(1M) ユーティリティを使用すると、より簡単に行うことができます。この場合、rpc.nisd デーモンを停止する必要はありません。

# nisldapmaptest -m /var/nis/NIS+LDAPmapping -o -t nodeinfo -r

—o オプションには、テーブルエントリではなく、テーブルオブジェクト自体を指定します。

オブジェクトデータが 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

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 オブジェクトクラス (この例のための仮想クラスで、RFC では定義されていません) の MUST 属性が cn で、MAY 属性が nodeInventory と nodeOwner であるとします。

既存の nodeinfo データを LDAP にアップロードするときは、別のファイルに新しいマッピング属性を作成すれば、簡単に行うことができます。たとえば、/var/nis/tmpmapping を使用します。

マッピング先の NIS+ テーブルを識別するデータベース ID を作成します。
nisplusLDAPdatabaseIdMapping nodeinfo:nodeinfo
nodeinfoテーブルのエントリに TTL を設定します。この情報はほとんど変更されないため、TTL を 12 時間に設定します。 rpc.nisd デーモンがディスクから nodeinfo テーブルを最初に読み取ると、テーブルエントリの TTL が 6〜12 時間からランダムに選択されます。
nisplusLDAPentryTtl nodeinfo:21600:43200:43200
既存のマッピングから、作成するマッピングに似ているものを選択します。この例では、属性値の割り当ては簡単で、直接割り当てるだけです。ただし、既存のコンテナに LDAP データを格納する処理が複雑です。このため、nodeinfo データの削除は、慎重に行う必要があります。 ou=Hosts エントリ全体を削除せずに、nodeInventory および nodeOwner 属性だけを削除します。このため、特別の削除ルールが必要になります。

つまり、コンテナを共有し削除ルールを持つマッピングを探します。この候補として、netmasks マッピングがあります。このマッピングは、ou=Networks コンテナを共有し、削除ルールを持っています。
/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
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

LDAP のデータを NIS+ にマッピングするときは、netmasks エントリのテンプレートは次のようになります。

nisplusLDAPcolumnFromAttribute \
		netmasks:	addr=ipNetworkNumber, \
				mask=ipNetmaskNumber, \
				comment=description

属性および列名を代入すると、次のようになります。

nisplusLDAPcolumnFromAttribute \
		nodeinfo:	cname=cn, \
				inventory=nodeInventory, \
				owner=nodeOwner

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=
マッピング情報はこれで完了です。このマッピングを有効にするために、rpc.nisd デーモンを停止してから、再起動します。

# pkill rpc.nisd
NIS+ nodeinfo テーブルにすでにデータが存在する場合は、そのデータを LDAP にアップロードします。新しい nodeinfo マッピング情報を、別のファイル /var/nis/tmpmapping に格納します。

# /usr/sbin/rpc.nisd -D -m /var/nis/tmpmapping \

-x nisplusLDAPinitialUpdateAction=to_ldap \

-x nisplusLDAPinitialUpdateOnly=yes
一時ファイル /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

注 –
二重矢印「>>」はリダイレクトを示します。矢印「>」は、対象ファイルの上書きを示します。
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 $ nisplusLDAPTLSCertificateDBPate
$ 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, searchBasenisplusNumberOfServiceThreads: 32

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

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

対象読者

推奨される前提知識

その他の前提条件

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

LDAP ネームサービスの利点

LDAP ネームサービスの欠点

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

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

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

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

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

デフォルトスキーマ

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

SSD の説明

スキーママップ

objectClass マップ

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

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

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

ldap_cachemgr デーモン

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

はじめに

Transport Layer Security (TLS)

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

資格の保存

認証方式の選択

認証とサービス

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

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

digest-MD5 での Sun ONE Directory Server の使用

パスワード管理

第 14 章 LDAP ネームサービスの計画要件 (手順)

計画の概要

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

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

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

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

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

複製サーバー

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

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

データ生成の計画

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

第 15 章 Sun ONE Directory Server の設定 (手順)

idsconfig を使用した Sun ONE Directory Server の構成

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

属性インデックス

スキーマ定義

インデックス表示の使用

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

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

idsconfig の実行

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

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

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

ldapaddent を使ったユーザーパスワードデータによる Sun ONE Directory Server の生成方法

プリンタエントリの管理

プリンタの追加

lpget の使用

追加プロファイルを使用してディレクトリサーバーを生成する

ldapclient を使った追加プロファイルによるディレクトリサーバーの生成方法

ディレクトリサーバーを構成してパスワード管理を有効にする

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

クライアント設定の前提条件

クライアントの初期設定

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

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

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

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

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

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

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

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

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

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

TLS のセキュリティの設定

PAM を構成する

パスワード管理機能なしでpam_ldap を使う

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

`objectClass` マップ

`ldap_cachemgr` デーモン

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

`idsconfig` を使用した Sun ONE Directory Server の構成

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

`idsconfig` の実行

`idsconfig` を使用して Sun ONE Directory Server を構成する方法

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

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

`ldapaddent` を使ったユーザーパスワードデータによる Sun ONE Directory Server の生成方法

`lpget` の使用

`ldapclient` を使った追加プロファイルによるディレクトリサーバーの生成方法

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

パスワード管理機能なしで`pam_ldap` を使う

パスワード管理機能のために `pam_ldap` を構成する

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

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

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

デバッグに `ldap_cachemgr` を使用する

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

新しい `automount` スキーマ

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

パスワード管理のために `pam_ldap` を構成した `pam.conf` ファイル例

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

Internet Printing Protocol (IPP) `ObjectClasses`

Sun プリンタ `ObjectClasses`