ここでは、LDAP ネームサービスの概要を説明します。 さらに、SunTM ONE Directory Server 5.1 (以前の名称は iPlanetTM Directory Server 5.1) の使用に焦点を当てて、 Solaris オペレーティング環境での LDAP ネームサービスの設定、構成、管理、そして障害の対処方法についても説明します。
この章では、 SunTM ONE Directory Server 5.1 (以前の名称は、 iPlanetTM Directory Server 5.1) 上で動作する Solaris LDAP ネームサービスクライアントの設定方法について説明します。一般的なディレクトリサーバー要件については、第 18 章「LDAP の一般的なリファレンス」で簡潔に説明します。
ディレクトリサーバーは、必ずしも LDAP サーバーである必要はありません。しかし、この章では「ディレクトリサーバー」という言葉は 「LDAP サーバー」と同じ意味で使っています。
LDAP ネームサービスに関するこれらの章は、LDAP に関する実務上の知識を持つシステム管理者を対象としています。以下のリストはこの章を読む前によく理解しておく必要のある概念の一部です。以下の概念を知らない場合は、このマニュアルを使って Solaris 環境に LDAP ネームサービスを導入することは難しいかもしれません。
LDAP 情報モデル (エントリ、オブジェクトクラス、属性、タイプ、値)
LDAP ネームモデル (ディレクトリ情報ツリー (DIT) 構造)
LDAP 機能モデル (検索パラメータ: ベースオブジェクト (DN)、スコープ、サイズ制限、時間制限、フィルタ (Sun ONE Directory Server のインデックスを表示する)、属性リスト)
LDAP セキュリティモデル (認証方式、アクセス制御モデル)
データの計画方法と DIT、トポロジ、複製、セキュリティの設計方法を含む LDAP ディレクトリサービスの計画と設計全般
前述の概念についての詳細、また一般的な LDAP とディレクトリサービスの導入について知りたい場合は、以下の文書を参照してください。
Timothy A. Howes, Ph.D、Mark C. Smith 共著『Understanding and Deploying LDAP Directory Services』
この本には LDAP ディレクトリサービスの扱い方に関する詳細だけでなく、LDAP を配備する上で役に立つケーススタディが書かれています。配備事例には、大規模な大学、多国籍企業、そしてエクストラネットを使った企業などがあります。
『iPlanet Directory Server 5.1 導入ガイド』。 このドキュメントは、Solaris 9 Documentation CD に含まれています。
このドキュメントでは、基本的なディレクトリ計画 (ディレクトリ設計、スキーマ設計、ディレクトリツリー、トポロジ、複製、およびセキュリティを含む) が説明されています。最後の章では、単純で小規模な配備計画と、複雑な世界に広がる配備計画の両方のシナリオを説明しています。
『iPlanet Directory Server 5.1 管理者ガイド』。 このドキュメントは、Solaris 9 Documentation CD に含まれています。
NIS+ から LDAP の使用への移行については、 第 19 章「NIS+ から LDAP への移行」を参照してください。これらの章に進む前に、移行を完了させてください。
Sun ONE Directory Server 5.1 をインストールする場合は、『iPlanet Directory Server 5.1 インストールガイド』を参照してください。
次の表は、FNS、DNS、 NIS、 NIS+ 、LDAP ネームサービスを比較したものです。
|
DNS |
NIS |
NIS+ |
FNS |
LDAP |
---|---|---|---|---|---|
名前空間 |
階層 |
フラット |
階層 |
階層 |
階層 |
データ記憶領域 |
ファイル/リソースレコード |
2 列のマップ |
複数列のテーブル |
マップ |
ディレクトリ (可変) インデックス化したデータベース |
サーバー |
マスター/スレーブ |
マスター/スレーブ |
ルートマスター/ 非ルートマスター主/ 副キャッシュ/スタブ |
なし |
マスター/複製 マルチマスター複製 |
セキュリティ |
なし |
なし (root または、なし) |
DES- 認証
|
なし (root またはなし) |
SSL、可変 |
トランスポート |
TCP/IP |
RPC |
RPC |
RPC |
TCP/IP |
スケール |
グローバル |
LAN |
LAN |
グローバル (DNS 付)/LAN |
グローバル |
NIS や NIS+ クライアントと違い、 LDAP クライアントは常にホスト名として完全指定のドメイン名 (FQDN、Fully Qualified Domain Name) を返します。LDAP のFQDN は、DNS によって返される FQDN に似ています。たとえば、次のドメイン名を考えてみましょう。
west.example.net |
ホスト名 server を検索する場合、gethostbyname() および getipnodebyname() はホスト名を FQDN で返します。
server.west.example.net |
また、server-# のようなインタフェース固有の別名を使用した場合も、完全指定ホスト名の長いリストが返されます。ホスト名を使用してファイルシステムを共有したり他の検査を実行したりする場合、この点に留意する必要があります。たとえば、ローカルホストは FQDN ではなく、リモートの DNS で解決されるホストだけが FQDN であると想定している場合は、その違いに留意する必要があります。DNS とは違うドメイン名で LDAP を設定する場合、参照先によって同じホストが結果的に2つの異なる FQDN になる可能性があります。
LDAP を使用すると、アプリケーション固有の情報を置き換えて情報の整理統合を実行し、管理するデータベースの数を減らすことができる
LDAP を使用すると、マスターと複製との間でより頻繁にデータの同期を取ることができる
LDAP では、プラットフォーム間およびベンダー間の互換性が維持されている
以下に、その他のネームサービスと比較して LDAP の欠点を示します。
Solaris 8 以前のクライアントはサポートしていない
LDAP サーバーをそのクライアントとして使用することはできない
LDAP ネームサービスの設定および管理がより複雑なため、注意深い計画が必要である
ディレクトリサーバー (LDAP サーバー) をそのクライアントとして使用することはできません。つまり、ディレクトリサーバーソフトウェアを実行中のマシンを、LDAP ネームサーバークライアントにすることはできません。
LDAP ディレクトリサーバー構成は、 idsconfig を使うことにより簡単に設定することができます。
強力な認証と暗号化されたセッションのトランスポートレイヤーセキュリティ (Transport Layer Security, TLS) をサポートするより堅牢なセキュリティモデルクライアントのプロキシ資格は、ディレクトリサーバー上のクライアントプロファイルには格納されていない
ldapaddent コマンドを使用して、データをサーバー上に生成およびダンプすることができる
サービス検索記述子と属性の割り当て
新規プロファイルスキーマ
NIS+ は、将来のリリースでサポートされない可能性があります。Solaris 9 オペレーティング環境には、NIS+ から LDAP への移行を支援するツールが用意されています。
詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。
NIS+ から LDAP への移行の詳細については、 第 19 章「NIS+ から LDAP への移行」を参照してください。
作業 |
参照先 |
ネットワークモデルの計画 | |
DIT の計画 | |
複製サーバーの設定 | |
セキュリティモデルの計画 | |
クライアントプロファイルおよびデフォルト属性値の選択 | |
データ生成の計画 | |
Sun ONE Directory Server 5.1 を構成して、LDAP ネームサービスから使用可能にする | |
Sun ONE Directory Server 5.1 を設定して、LDAP ネームクライアントから使用可能にする | 第 15 章「Sun ONE Directory Server 5.1 の設定 (手順)」 |
プリンタエントリの管理 | |
LDAP クライアントの初期化 | クライアントの初期設定 |
プロファイルを使用したクライアントの初期化 | |
手動によるクライアントの初期化 | |
クライアントの初期化解除 | |
サービス検索記述子を使用した、クライアントプロファイルの変更 | |
ネームサービス情報の取得 | |
クライアント環境のカスタマイズ |
この章の内容は次のとおりです。
LDIF は、ディレクトリサービス情報を記述するために使用されるテキストベースのフォーマットです。LDIF を使用することで、ディレクトリ間で情報の移動が可能となります。以下に、各サービスの 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 |
|
Solaris LDAP クライアントはデフォルトで、DIT がある特定の構造を持っていると想定して情報にアクセスします。LDAP サーバーがサポートするドメインごとに、想定された構造を持つ想定されたサブツリーがあります。ただしこのデフォルト構造は、サービス検索記述子 (Service Search Descriptor、SSD) を指定することで上書きできます。指定されたドメインでは、デフォルト DIT が、特定の情報タイプのエントリを含む多数のサブツリーを保持します。これらのサブツリー名については次の表を参照してください。
表 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 にアクセスすることもできます。
スキーママッピングは、注意深くかつ一貫した方法で使用する必要があります。
前述したように、LDAP ネームサービスはデフォルトで、DIT が特定の方法で構築されているという想定のもとに動作します。必要に応じて、DIT 内のデフォルト以外の場所を検索するように Solaris LDAP ネームサービスに指示することができます。また、デフォルトスキーマで指定された属性やオブジェクトクラスの代わりに、別の属性やオブジェクトクラスを指定して使用することもできます。デフォルトフィルタの詳細については、LDAP ネームサービスで使用されるデフォルトフィルタを参照してください。
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 属性値のリストに対応づけられます。
Solaris LDAP ネームサービスを使用すると、オブジェクトクラスを任意のサービス用に対応づけしなおすことができます。特定のサービス用に複数のオブジェクトクラスを対応づける場合、複数の objectclassMap 属性を定義できます。次の例では、posixAccount オブジェクトクラスを使用する場合、常に myUnixAccount オブジェクトクラスが使用されます。
objectclassMap: passwd:posixAccount=myUnixAccount |
Solaris クライアントのセットアップを容易にし、各クライアントに同じ情報を再入力する手間を省くために、ディレクトリサーバー上に単一のクライアントプロファイルを作成します。この単一のプロファイルに、使用するすべてのクライアントの構成を定義します。プロファイル属性への以降の変更はすべて、定義されたリフレッシュ頻度で送信されます。
これらのクライアントプロファイルは、LDAP サーバー上のよく知られた位置に格納されます。指定されたドメインのルート DN は、 nisDomainObject のオブジェクトクラス、およびクライアントのドメインを含む nisDomain 属性を保持する必要があります。すべてのプロファイルは、このコンテナと相対的な関係にある ou=profile コンテナ内に配置されます。これらのプロファイルは、匿名で読み取り可能にする必要があります。
次のリストに、Solaris LDAP クライアントのプロファイル属性を示します。これらのプロファイル属性は、 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(1M) を使用してローカルに設定可能なクライアント属性を示します。
表 13–3 ローカルのクライアント属性
属性 |
説明 |
---|---|
domainName |
クライアントのドメイン名 (クライアントマシンのデフォルトドメインになる) を指定します。デフォルト値なし。必須 |
proxyDN |
プロキシの識別名。プロキシの credentialLevel を使用してクライアントマシンを構成する場合、 proxyDN を指定する必要がある |
proxyPassword |
プロキシのパスワード。プロキシの credentialLevel を使用してクライアントマシンを構成する場合、proxyPassword を定義する必要がある |
certificatePath |
証明書データベースを含む、ローカルファイルシステム上のディレクトリ。TLS を使用し、authenticationMethod または serviceAuthenticationMethod を指定してクライアントマシンを構成する場合、この属性が使用される。 デフォルト値は /var/ldap |
SSD 内の BaseDN に末尾のコンマが含まれる場合、 defaultSearchBase の相対値として処理される。検索実行前に、defaultSearchBase の値が BaseDN に付加される。
ldap_cachemgr(1M) は、LDAP クライアントマシン上で稼働するデーモンです。このデーモンは、次の主要機能を実行します。
サーバー上のプロファイルに格納されたクライアント構成情報を更新して、クライアントからこのデータを引き出す
使用可能な LDAP サーバーのソート済みリストを管理
さまざまなクライアントから送信される一般的な検索要求をキャッシュして、検索効率を向上させる
ホスト検索の効率を向上させる
LDAP ネームサービスを機能させるには、ldap_cachemgr が常に実行されている必要があります。
詳細については、ldap_cachemgr(1M) のマニュアルページを参照してください。
Solaris LDAP ネームサービスは、LDAP リポジトリをネームサービスと認証サービスの両方のソースとして使用します。この節では、クライアント認証、認証方式、 pam_ldap(5) と pam_unix(5) モジュール、およびパスワード管理の概念について説明します。
LDAP リポジトリに格納された情報にアクセスする場合、クライアントは最初にディレクトリサーバーで識別情報を確立できます。この識別情報は、匿名にも、LDAP サーバーの認識するオブジェクトにもできます。クライアントの識別情報およびサーバーのアクセス制御情報 (ACI) に基づいて、LDAP サーバーはクライアントに対してディレクトリ情報の読み取りまたは書き込みを許可します。ACI の詳細については、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。
特定の要求に関して匿名以外で接続している場合、クライアントは、クライアントとサーバーの両方がサポートする認証方式でサーバーに識別情報を証明する必要があります。クライアントは識別情報を確立後に、さまざまな LDAP 要求を実行できます。
ネームサービスと認証サービス (pam_ldap) がディレクトリへの認証を行う方法には違いがあることに留意してください。ネームサービスは、事前定義された識別情報に基づくディレクトリから、さまざまなエントリおよびその属性を読み取ります。認証サービス (pam_ldap(5)) は、ユーザーの名前とパスワードを使用して LDAP サーバーへの認証を行い、ユーザーが適正なパスワードを入力したかどうかを確認します。
TLS を LDAP クライアントとディレクトリサーバー間の通信のセキュリティ保護に使用すると、機密性とデータの完全性を保証することができます。TLS プロトコルは、Secure Sockets Layer (SSL) のスーパーセットです。Solaris LDAP ネームサービスは、TLS 接続をサポートします。SSL を使用すると、ディレクトリサーバーおよびクライアントに負荷がかかることに留意してください。
SSL 対応のディレクトリサーバーを設定する必要があります。SSL 対応の Sun ONE Directory Server 5.1 の設定方法の詳細については、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。SSL 対応の LDAP クライアントも設定する必要があります。
Solaris LDAP ネームサービス用の TLS を使用する場合、ディレクトリサーバーは、LDAP および SSL 用にデフォルトポート 389 および 636 をそれぞれ使用する必要があります。ディレクトリサーバーがこれらのポートを使用しない場合、TLS を使用することはできません。
詳細については、TLS のセキュリティの設定を参照してください。
LDAP ネームサービスクライアントは、資格レベルに従って LDAP サーバーを認証します。LDAP クライアントには、次の 3 つの資格レベルの 1 つを割り当てて、ディレクトリサーバーへの認証を行うことができます。
anonymous
proxy
proxy anonymous
匿名
匿名でのアクセスを利用する場合、すべてのユーザーが使用可能なデータだけにアクセスできます。また、セキュリティの問題も考慮する必要があります。ディレクトリの特定部分に匿名アクセスを許可する場合、そのディレクトリへのアクセス権を保持するユーザーはすべて、その操作を実行できることになります。資格レベルとして anonymous を使用する場合、すべての LDAP ネームエントリおよび属性に読み取りアクセスを許可する必要があります。
匿名でのディレクトリへの書き込みは、決して許可してはなりません。この書き込みを許可すると、どのユーザーでも書き込みアクセス権のある DIT 内の情報 (別のユーザーのパスワードや自分自身の識別情報など) を変更することが可能になります。
Sun ONE Directory Server 5.1 を使用すると、IP アドレス、DNS 名、認証方式、および時刻に基づいてアクセスを制限できます。さらに指定を加えて、アクセスを制限することもできます。詳細については、『iPlanet Directory Server 5.1 管理者ガイド』のアクセス権の管理に関する章を参照してください。
プロキシ
クライアントは、プロキシアカウントを使用して、ディレクトリへの認証またはバインドを行います。このプロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このプロキシアカウントは、LDAP サーバー上でネームサービス機能を実行するのに十分のアクセス権を必要とします。プロキシ資格レベルを使用して、すべてのクライアントで proxyDN および proxyPassword を構成する必要があります。暗号化された proxyPassword はローカルのクライアントに格納されます。別のクライアントグループに対しては別のプロキシを設定できます。たとえば全営業クライアント用のプロキシを構成する場合、企業全体からアクセス可能なディレクトリと営業ディレクトリの両方へのアクセスを許可しつつ、給与情報を保持する人事ディレクトリへのアクセスを許可しない、という方法が可能です。最も極端な例として、各クライアントに別個のプロキシを割り当てることや、すべてのクライアントに同じプロキシを割り当てることも可能です。一般的な LDAP 配備はこの両極端の中間に位置します。選択は慎重に行なってください。プロキシエージェントが不足していると、リソースへのユーザーアクセスを制御する能力が制限されます。ただし、プロキシが多過ぎる場合、システムの設定および保守が困難になります。適切な権限をプロキシユーザーに付与する必要がありますが、その程度は環境によって大きく異なります。使用する構成に最適の認証方式を決定するための情報については、資格の保存を参照してください。
プロキシユーザーのパスワードを変更した場合、そのプロキシユーザーを使用するすべてのクライアントで情報を更新する必要があります。LDAP アカウントのパスワード有効期間を設定する場合、プロキシユーザーに関してはこの設定を解除してください。
プロキシ資格レベルは、指定されたマシンのすべてのユーザーおよびプロセスに適用されます。2 人のユーザーが異なるネーミングポリシーを使用する場合は、別個のマシンを使用する必要があります。
また、クライアントが認証にプロキシ資格を使用する場合、proxyDN はすべてのサーバーで同じ proxyPassword を保持する必要があります。
匿名プロキシ
匿名プロキシは複数値のエントリで、複数の資格レベルが内部に定義されています。匿名プロキシレベルを割り当てられたクライアントは、最初にそのプロキシ識別情報を使用して認証を試みます。ユーザーのロックアウト、パスワードの有効期限切れなどの何らかの理由でクライアントがプロキシユーザーとしての認証ができなかった場合、クライアントは匿名アクセスを使用します。この場合、ディレクトリの構成に応じて、別のサービスレベルに移行する可能性があります。
プロキシ識別情報を使用するようクライアントを設定する場合、クライアントは proxyDN および proxyPassword を /var/ldap/ldap_client_cred 内に保存します。セキュリティ保護のため、このファイルへのアクセスは root のみに許可され、 proxyPassword の値は暗号化されます。過去の LDAP 実装ではプロキシ資格はクライアントのプロファイル内に格納されましたが、Solaris 9 LDAP ネーミングサービスではこれは行われません。初期化時に ldapclient を使用して設定されたプロキシ資格は、すべてローカルに保存されます。このため、プロキシの DN およびパスワード情報に関するセキュリティが向上します。クライアントプロファイルの設定方法の詳細については、第 16 章「クライアントの設定手順 (手順)」を参照してください。
プロキシ資格または匿名プロキシ資格を割り当てる場合、プロキシによるディレクトリサーバーへの認証方式も選択する必要があります。デフォルトの認証方式は none (匿名によるアクセス) です。認証方式には、関連するトランスポートセキュリティオプションも含まれます。
認証方式には資格レベルと同様、複数値を指定できます。たとえば、クライアントプロファイルを設定することにより、クライアントが TLS でセキュリティ保護された simple メソッドを最初に使用してバインドを試みるようにできます。これが成功しない場合、クライアントは sasl/digest-MD5 メソッドを使用してバインドを試みます。 その後、authenticationMethod は tls:simple;sasl/digest-MD5 になります。
LDAP ネームサービスは、いくつかの Simple Authentication and Security Layer (SASL) 機構をサポートします。これらの機構を使用すると、TLS なしでセキュリティ保護されたパスワードを交換できます。ただし、これらの機構はデータの完全性や機密性を保証するものではありません。SASL の詳細については、RFC 2222 を参照してください。
次の認証機構がサポートされています。
none
クライアントは、ディレクトリへの認証を行いません。これは、anonymous 資格レベルと等価です。
認証方式 simple を使用する場合、クライアントマシンはユーザーのパスワードを平文で送信してサーバーへのバインドを実行します。このため、パスワードが漏洩しやすくなります。この認証方式を使用する主な利点は、すべてのディレクトリサーバーがこの方式をサポートしていること、および設定が容易であるという点です。
認証時にクライアントのパスワードは保護されますが、セッションは暗号化されません。Sun ONE Directory Server 5.1 を含むいくつかのディレクトリサーバーは、sasl/digest-MD5 認証方式もサポートします。digest-MD5 の主な利点は、認証時にパスワードが平文のままネットワーク上を流れないため、simple よりも安全であるという点です。digest-MD5 の詳細については、RFC 2831 を参照してください。digest-MD5 は、cram-MD5 のセキュリティが改善されたものと見なされます。
sasl/digest-MD5 を使用する場合、認証はセキュリティ保護されますがセッションは保護されません。
sasl/cram-MD5
この場合、LDAP セッションは暗号化されませんが、 sasl/cram-MD5 を使用して認証が行われるため、認証時にクライアントのパスワードが保護されます。
cram-MD5 認証方式の詳細については、RFC 2195 を参照してください。すべてのディレクトリサーバーがこの認証方式をサポートしているわけではありません。 たとえば、Sun ONE Directory Server 5.1 は cram-MD5 をサポートしません。
tls:simple
クライアントは、simple を使用してバインドを行い、セッションは暗号化されます。パスワードは保護されます。
tls: sasl/cram-MD5
sasl/cram-MD5 を使用して、LDAP セッションの暗号化およびクライアントによるディレクトリサーバーへの認証が行われます。
tls:sasl/digest-MD5
sasl/digest-MD5 を使用して、LDAP セッションの暗号化およびクライアントによるディレクトリサーバーへの認証が行われます。
Sun ONE Directory Server 5.1 で digest-MD5 を使用する場合、パスワードを平文で格納する必要があります。認証方式を sasl/digest-MD5 または tls:sasl/digest-MD5 に設定する場合、プロキシユーザーのパスワードを平文で格納する必要があります。平文で格納する場合には、userPassword 属性が適切な ACI を保持するようにして、読み取り不可にする必要があります。
認証メソッドを特定のサービスに対して serviceAuthenticationMethod 属性に指定できます。現在この機能をサポートしているサービスを次に示します。
passwd-cmd
このサービスは、passwd (1) により、ログインパスワードおよびパスワード属性の変更に使用されます。
keyserv
このサービスは、 chkey (1) および newkey (1M) ユーティリティにより、ユーザーの Diffie-Hellman 鍵ペアの作成および変更に使用されます。
pam_ldap
このサービスは、 pam_ldap(5) を使用したユーザーの認証に使用されます。
サービスが 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(5)
pam.conf(4) ファイルを変更していない場合、デフォルトディレクトリ pam_unix(5) が有効になっています。pam_unix(5) は従来の UNIX 認証モデルに従い、次のように動作します。
クライアントは、ネームサービスからユーザーの暗号化されたパスワードを取得します。
ユーザーは、パスワードの入力を求められます。
ユーザーのパスワードが暗号化されます。
クライアントは、暗号化された 2 つのパスワードを比較して、ユーザーを認証するかどうかを決定します。
パスワードは、平文を含む他の暗号化方式ではなく、UNIX crypt 形式で格納する必要がある
userPassword 属性は、ネームサービスから読み取り可能でなければならない
たとえば、資格レベルを匿名に設定する場合、すべてのユーザーに対してuserPassword 属性を読み取り可能にする必要があります。同様に、資格レベルを proxy に設定する場合、userPassword 属性の読み取りをプロキシユーザーに許可する必要があります。
pam_unix(5) は sasl 認証方式 digest-MD5 と互換性がありません。これは、Sun ONE Directory Server 5.1 では digest-MD5 を使用するためにパスワードを平文で格納する必要があるのに対し、pam_unix ではパスワードを crypt 形式で格納する必要があるためです。
pam_ldap(5)
pam_ldap(5) を使用する場合、ユーザーは LDAP サーバーにバインドします。認証方式は、pam_ldap の serviceAuthenticationMethod パラメタで定義されます (このパラメタが存在する場合)。それ以外の場合、authenticationMethod がデフォルトで使用されます。
pam_ldap(5) を使用して、ユーザーの識別情報および指定されたパスワードをサーバーにバインドできればユーザーが認証されたことになります。
pam_ldap(5) は userPassword 属性を読み取りません。このため、 pam_unix(5) を使用する他のクライアントが存在しない限り、userPassword 属性の読み取りアクセス権を付与する必要はありません。pam_ldap(5) は、認証方式 none をサポートしません。このため、クライアントが pam_ldap(5) を使用できるように、serviceAuthenticationMethod 属性または authenticationMethod 属性を定義する必要があります。
認証方式 simple を使用する場合、第三者がネットワーク上で userPassword 属性を読み取ることができます。
詳細については、pam_ldap に対応した pam.conf ファイルの例 を参照してください。
パスワードの変更には、passwd (1) を使用します。パスワードを変更するには、userPassword 属性をユーザーから書き込み可能にする必要があります。passwd-cmd 用の serviceAuthenticationMethod が、この操作の authenticationMethod を無効にすることに留意してください。使用する認証によっては、現行のパスワードの暗号化解除がネットワーク上で行われる場合があります。
pam_unix(5) の場合、UNIX crypt を使用して新規 userPassword 属性が暗号化されタグ付けされてから、LDAP への書き込みが行われます。このため、新規パスワードは、サーバーへのバインドに使用される認証方式に関係なく、ネットワーク上で暗号化されます。
pam_ldap の場合、パスワードの変更時に新規パスワードの暗号化解除が行われます。このため、機密性を保つために TLS を使用する必要があります。TLSを使用しない場合、userPassword が漏洩する危険性があります。
Sun ONE Directory Server 5.1 で、pam_ldap(5) を使用してパスワードを設定する場合、パスワードは serverStrorageScheme (タグ付けされていない状態) を使用して暗号化されます。passwordStorageScheme 属性の詳細については、『iPlanet Directory Server 5.1 管理者ガイド』のユーザーアカウントの管理に関する章を参照してください。
passwordStorageScheme 属性を設定する際、以下の点を考慮する必要があります。pam_unix を使用する NIS、NIS+、または他のクライアントがリポジトリとして LDAP を使用する場合、 passwordStorageScheme に対して crypt を実行する必要があります。また、Sun ONE Directory Server 5.1 で sasl/digest-MD5 に対して pam_ldap を使用する場合、passwordStorageScheme を平文に設定する必要があります。
LDAP ネームサービスは、Sun ONE Directory Server 5.1 でパスワードとアカウントのロックアウトポリシーをサポートする利点を有効に活用しています。pam_ldap(5) を構成して、ユーザアカウント管理をサポートすることが可能です。passwd(1) を正しい PAM 構成で使用すると、 Sun ONE Directory Server パスワードポリシーによるパスワードの構文規則を強化します。
pam_ldap(5) により、以下のパスワード管理機能がサポートされています。このパスワード管理機能は、 Sun ONE Directory Server 5.1 のパスワードとアカウントのロックアウトポリシー構成を利用しています。必要な機能を必要な数だけ利用できます。
古くなったり、有効期限の切れたパスワードを通知する
パスワードは、予定にしたがって変更する必要があります。パスワードを定められた期間内に変更しないとそのパスワードは無効になります。期限切れのパスワードでは、ユーザーが認証されません。
期限切れの警告期間内のログイン時には、常に警告メッセージを表示します。メッセージには期限切れまでの日数と時間が表示されます。
パスワードの構文チェック
新規パスワードは、最小文字数の条件を満たしている必要があります。また、ユーザーのディレクトリエントリにある uid、 cn、 sn および mail と同じ値をパスワードに設定することはできません。
パスワードの履歴チェック
パスワードの再利用はできません。以前使われていたパスワードに変更しようとすると、passwd(1) コマンドは失敗します。LDAP 管理者は、サーバーの履歴リストに保持するパスワードの数を設定することができます。
ユーザーアカウントのロックアウト
認証の失敗が設定された回数に達すると、そのユーザーアカウントはロックアウトされます。管理者がアカウントを非アクティブにした場合も、そのユーザーはロックアウトされます。アカウントのロックアウト期間が経過するか、管理者が再びアカウントをアクティブにするまで、認証は成功しません。
以上のパスワード管理機能は、 Solaris 9 にバンドルされた Sun ONE Directory Server 5.1 でのみ有効です。サーバー上のパスワードとアカウントのロックアウトポリシーについての詳細は、 『iPlanet Directory Server 5.1 管理者ガイド』の「ユーザーアカウントの管理」の章を参照してください。また、パスワード管理のために pam_ldap を構成した pam.conf ファイル例 も参照してください。
Sun ONE Directory Server 5.1 上でパスワードとアカウントのロックアウトポリシーを設定する前に、全てのホスト上で pam_ldap パスワード管理にもとづいた「最新の」 LDAP クライアントが使われていることを確認します。LDAP クライアントの「最新」バージョンは、Solaris 9 UR 2 に含まれています。
さらに、クライアントが正しい構成の pam.conf(4) ファイルを保持していることを確認します。正しい構成ファイルを保持していない場合、 LDAP ネームサービスは proxy やユーザーパスワードが期限切れの時に動作しません。
この章では、サーバーとクライアントの設定およびインストール処理を開始する前に実行する必要のある高度な計画について説明します。
この章の内容は次のとおりです。
LDAP クライアントプロファイルは、LDAP クライアントが使用する構成情報の集合体です。LDAP クライアントは、このプロファイルを使用して、サポートする LDAP サーバー上の LDAP ネームサービス情報にアクセスして、LDAP ネームサービスを提供しますこの章では、LDAP 構成の主要部分を使用して、LDAP ネームサービスのさまざまな分野の計画方法を説明します。その中には、ネットワークモデル、ディレクトリ情報ツリー、セキュリティモデル、さまざまなプロファイル属性のデフォルト値、およびデータ生成の準備が含まれます。
可用性およびパフォーマンスを考慮すると、企業規模のネットワークの各サブネットが LDAP サーバーを独自に保持して、サブネット内のすべての LDAP クライアントにサービスを提供する方法が最善です。これらのサーバーの 1 つだけをマスター LDAP サーバーにする必要があります。残りはすべてマスターサーバーの複製にできます。
ネットワーク構成を計画する前に、使用可能なサーバーの数、クライアントがサーバーにアクセスする方法、複数のサーバーへのアクセス順序について考慮する必要があります。サブネットごとに 1 つのサーバーが存在する場合、defaultServerList 属性を使用してすべてのサーバーのリストを作成し、LDAP クライアントからアクセス順序をソートおよび操作できます。速度またはデータ管理上の理由から、特定の順序でサーバーにアクセスする必要がある場合は、preferredServerList 属性を使用してサーバーへの固定されたアクセス順序を定義します。マスターサーバーをこれらのリストに配置しないことで、マスターサーバーへの負荷を軽減できます。
さらに、サーバーおよびネットワーク構成を計画する際に考慮するに値する 3 つの属性があります。bindTimeLimit 属性は TCP 接続要求のタイムアウト値の設定に、searchTimeLimit 属性は LDAP 検索操作のタイムアウト値の設定に、profileTTL 属性は LDAP クライアントによるサーバーからのプロファイルのダウンロード頻度の制御に、それぞれ使用できます。速度が遅いか不安定なネットワークの場合、 bindTimeLimit および searchTimeLimit 属性にデフォルト値より大きい値を設定することが必要な場合があります。配備の初期テスト段階で、profileTTL 属性値を引き下げて、頻繁に行われる LDAP サーバー内のプロファイルの変更をクライアントが取得するようにしてもよいでしょう。
前の章で説明したように、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 章「SunTM ONE Directory Server 5.1 の構成(手順) 」を参照してください。
複製サーバーを設定する場合、次の 3 つの方法が存在します。
単一マスター複製 (Single-master replication)
浮動マスター複製 (Floating-master replication)
複数マスター複製 (Multi-master replication)
「単一マスター」
単一マスター複製では、指定されたパーティションまたはパーティション化されていないネットワークに対して、1 つのマスターサーバーだけが、ディレクトリエントリの書き込み可能なコピーを保持します。複製サーバーは、ディレクトリエントリの読み込み専用コピーを保持します。複製とマスターの両方が検索、比較、およびバインド操作を実行できますが、書き込み操作を実行できるのはマスターサーバだけです。
単一マスター複製の不利な点は、マスターサーバーでシングルポイント障害が発生した場合です。マスターサーバーがダウンした場合、どの複製サーバーからも書き込み操作を実行できません。
「浮動マスター」
浮動マスターは、指定されたパーティション化されたネットワークまたはパーティション化されていないネットワークに対し、書き込み権限を保持するマスターサーバーは常に 1 つだけである点で、単一マスターを使用する場合と似ています。ただし浮動マスターを使用すると、マスターサーバーがダウンした場合、アルゴリズムにより複製が自動的にマスターサーバーに変化します。
浮動マスター複製の不利な点は、ネットワークがパーティション化され、どちらの側のパーティション上の複製もマスターになった場合、ネットワークを再結合する際、新規マスター間の調整が非常に複雑になり得ることです。
「複数マスター」
複数マスター複製では、ディレクトリエントリデータの独自の読み取り/書き込み複製を保持する、複数のマスターサーバーが存在します。複数マスターを使用すると、シングルポイント障害を防ぐことができますが、サーバー間で更新による競合が発生する可能性があります。つまり、2 つのマスター上でエントリの属性が同時に変更される場合、競合による障害の解決ポリシー (最後の書き込みを優先するなど) の適用が必要になります。
複製サーバーの設定方法については、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。
セキュリティモデルを計画する場合、最初に、LDAP クライアントが LDAP サーバーとの通信に使用する識別情報を考慮する必要があります。たとえば、強力な認証を使用してネットワーク上を流れるユーザーパスワードを保護するかどうか、また LDAP クライアントと LDAP サーバー間のセッションを暗号化して送信される LDAP データを保護する必要があるかなどを決定する必要があります。
セキュリティモデルの計画には、プロファイル内の credentialLevel および authenticationMethod 属性が使用されます。credentialLevel には、 匿名、プロキシ、および匿名プロキシの 3 つの資格レベルのうちの 1 つを指定できます。LDAP ネームサービスのセキュリティ概念については、LDAP ネームサービスのセキュリティモデル を参照してください。
セキュリティモデルを計画する際の主要な決定事項を次に示します。
LDAP クライアントは、どの資格レベルおよび認証方式を使用するか
TLS を使用するか
NIS や NIS+ との下位互換性を必要とするか。言い換えれば、クライアントは pam_unix または pam_ldap を使用するか
サーバーの passwordStorageScheme 属性をどのように設定するか
アクセス制御情報をどのように設定するか。ACI の詳細については、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。
前述の計画手順 (ネットワークモデル、DIT、およびセキュリティモデル) を理解することにより、次のプロファイル属性の値についてアイデアを得ることができるでしょう。
cn
defaultServerList
preferredServerList
bindTimeLimit
searchTimeLimit
profileTTL
defaultSearchBase
defaultSearchScope
serviceSearchDescriptor
attributeMap
objectclassMap
followReferrals
credentialLevel
authenticationMethod
serviceCredentialLevel
serviceAuthenticationMethod
上記の属性の中で、必須属性は cn、 defaultServerList、および defaultSearchBase だけです。これらの属性には、デフォルト値は存在しません。残りの属性はオプションであり、デフォルト値がないオプションも存在します。
LDAP クライアントの設定の詳細については、第 16 章「クライアントの設定手順 (手順)」 を参照してください。
LDAP ネームサービスデータを使用して、LDAP サーバーを生成する場合、適切な DIT およびスキーマを使用して LDAP サーバーを構成した後、新規 ldapaddent ツールを使用するのが最善です。このツールは、対応する /etc ファイルから LDAP コンテナ内にエントリを作成します。このツールを使用して、次のデータタイプ用のコンテナ内にデータを生成することができます。 aliases、auto_*、bootparams、ethers、group、hosts (IPv6 アドレスを含む)、netgroup、netmasks、networks、passwd、shadow、protocols、publickey、rpc、および services。
デフォルトでは、ldapaddent は標準入力からこのデータを読み取って、コマンド行で指定されたデータベースに関連付けられた LDAP コンテナに追加します。ただし、データを読み取る入力ファイルは、-f オプションを使用して指定できます。
エントリはクライアントの構成に基づき、ディレクトリ内に格納されます。このため、LDAP ネームサービスを使用するようにクライアントを構成する必要があります。
パフォーマンスを向上させるために推奨されているデータベースのロード順序を次に示します。
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 クライアントから抽出されることを想定しています。
idsconfig を使用し、Sun ONE Directory Server 5.1 が設定されているか確認します。
クライアントマシン上でスーパーユーザーになります。
そのマシンを LDAP クライアントに設定します。
# ldapclient init —a profileName=new —a \ domainName=west.example.com 192.168.0.0
データを指定してサーバーを生成します。
# ldapaddent —h 192.168.0.0 —D directory_manager —f /etc/hosts hosts
この例では、現在 ldapaddent が simple 認証方式を使用してバインドしているように、平文で directory_manager パスワードが送られます。
rpc.nisd 内の適切な設定を使用して、NIS+ データを保持するディレクトリサーバーを生成できます。第 19 章「NIS+ から LDAP への移行」を参照してください。
この章では、 Solaris LDAP ネームサービスクライアントのネットワークをサポートするための SunTM ONE Directory Server 5.1 (以前の名称は iPlanetTM Directory Server 5.1) の設定方法について説明します。この章の内容は、Sun ONE Directory Server 5.1 に固有の情報です。
Solaris LDAP クライアントで動作するよう Sun ONE Directory Server 5.1 を構成する前に、第 11 章に記載された手順をすべて実行する必要があります。
ディレクトリサーバー (LDAP サーバー) を、サーバー自身のクライアントにすることはできません。
この章の内容は次のとおりです。
サーバーのインストール処理時に定義する重要な変数を使用して、以下に示すようなチェックリストを作成してから、idsconfig を起動してください。記入用のチェックリスト で提供されるチェックリストを使用できます。
以下の情報は、以降の LDAP 関連の章に示されるすべての例の基礎になります。サンプルのドメインは、全国規模で店舗を展開する部品会社である Example, Inc. のものです。例の中では、その West Coast Division (ドメインは west.example.com) を対象に説明します。
変数 |
サンプルネットワークの定義 |
---|---|
インストールしたディレクトリサーバーインスタンスのポート番号 (デフォルト = 389) |
default |
サーバー名 |
ipdserver (完全指定ドメイン名 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 を含めることはできないことを意味します。
変数 |
サンプルネットワークの定義 |
---|---|
プロファイル名 |
WestUserProfile |
サーバーリスト (デフォルトはローカルサブネット) |
west.example.com または 192.168.0.0 |
優先されるサーバーリスト (優先順に記載) |
none |
検索範囲 (検索するディレクトリツリーレベルの数、「One」(デフォルト) または「Sub」) |
one (デフォルト) |
サーバーへのアクセスに使用する資格。デフォルトは匿名 |
proxy |
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 上でのインデックス作成の詳細、およびその使用によるパフォーマンス上のコストについては、『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。
次の例では、-n オプションでエントリをインデックス化するデータベースの名前を示し、 -s オプションでディレクトリサーバーのインスタンスを示します。
idsconfig により、デフォルト VLV インデックスがすべて作成されます。
directoryserver -s ipdserver vlvindex -n userRoot -T getgrent directoryserver -s ipdserver vlvindex -n userRoot -T gethostent directoryserver -s ipdserver vlvindex -n userRoot -T getnetent directoryserver -s ipdserver vlvindex -n userRoot -T getpwent directoryserver -s ipdserver vlvindex -n userRoot -T getrpcent directoryserver -s ipdserver vlvindex -n userRoot -T getspent |
サービス検索記述子 (SSD) を使用すると、LDAP 内の指定された操作のデフォルト検索要求を、ユーザーが定義した検索に変更できます。たとえば、これまでカスタマイズしたコンテナ定義や別のオペレーティングシステムで LDAP を使用してきたユーザーが、Solaris 9 に移行する場合などに、SSD は特に役に立ちます。SSD を使用すると、既存の LDAP データベースおよびデータを変更せずに、Solaris 9 LDAP ネームサービスを構成できます。
前出の 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 5.1 の構成時に必要な SSD を定義できます。プロンプト行は次のようになります。
Do you wish to setup Service Search Descriptors (y/n/h? y A Add a Service Search Descriptor D Delete a SSD M Modify a SSD P Display all SSD's H Help X Clear all SSD's Q Exit menu Enter menu choice: [Quit] a Enter the service id: passwd Enter the base: service ou=user,dc=west,dc=example,dc=com Enter the scope: one[default] A Add a Service Search Descriptor D Delete a SSD M Modify a SSD P Display all SSD's H Help X Clear all SSD's Q Exit menu Enter menu choice: [Quit] p Current Service Search Descriptors: ================================== Passwd:ou=Users,ou=west,ou=example,ou=com? Hit return to continue. A Add a Service Search Descriptor D Delete a SSD M Modify a SSD P Display all SSD's H Help X Clear all SSD's Q Exit menu Enter menu choice: [Quit] q |
idsconfig の実行には特別な権限は不要であり、LDAP ネームサービスクライアントになる必要もありません。idsconfig を実行する準備として、サーバーのインストール用チェックリストの作成 で説明したチェックリストを作成してください。idsconfig を、サーバーまたは LDAP ネームサービスクライアントマシンから 実行する必要はありません。ネットワーク上の任意の Solaris マシンから idsconfig を実行できます。
idsconfig は、Directory Manager のパスワードを平文で送信します。これを防ぐには、 idsconfig をクライアント上ではなく ディレクトリサーバー上で実行する必要があります。
ターゲットの Sun ONE Directory Server 5.1 が起動済みで実行中であることを確認します。
idsconfig を実行します。
# /usr/lib/ldap/idsconfig
表示される質問に答えます。ユーザー入力のデフォルトは「no」です。質問の詳細を表示する場合は次のように入力します。
h |
以下の idsconfig の実行例を参照する際、この章の冒頭の サーバーのインストール用チェックリストの作成 で示したサーバーおよびクライアントのチェックリスト内の定義を使用してください。以下は、デフォルト設定の多くを変更しない単純な設定の例です。クライアントプロファイルを変更する最も複雑な方法は、SSD を作成する方法です。詳細については、サービス検索記述子を使用してさまざまなサービスへのクライアントアクセスを変更するを参照してください。
プロンプトの後のキャリッジリターンは、Enter キーを押してデフォルトの設定を受け入れたことを意味します。
(sysadmin@test) [3:10pm] ns_ldap [31] % sh idsconfig.sh
It is strongly recommended that you BACKUP the directory server before running idsconfig.sh. Hit Ctrl-C at any time before the final confirmation to exit. Do you wish to continue with server setup (y/n/h)? [n] Y |
Enter the Sun ONE Directory Server's (Sun ONE Directory Server) hostname to setup: IPDSERVER |
Enter the port number for Sun ONE 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 Sun ONE Directory Server (current=3600): [-1] |
Do you want to modify the server sizelimit value (y/n/h)? [n] Y |
Enter the size limit for Sun ONE Directory Server (current=2000): [-1] |
Do you want to store passwords in "crypt" format (y/n/h)? [n] Y |
Do you want to setup a Service Authentication Methods (y/n/h)? [n] Client search time limit in seconds (h=help): [30] Profile Time To Live in seconds (h=help): [43200] |
Bind time limit in seconds (h=help): [10] 2 |
Do you wish to setup Service Search Descriptors (y/n/h)? [n] Summary of Configuration 1 Domain to serve : west.example.com 2 Base DN to setup : dc=west,dc=example,dc=com 3 Profile name to create : default 4 Default Server List : 192.168.0.0 5 Preferred Server List : 6 Default Search Scope : one 7 Credential Level : proxy 8 Authentication Method : simple 9 Enable Follow Referrals : TRUE 10 Sun ONE Directory Server Time Limit : -1 11 Sun ONE Directory Server Size Limit : -1 12 Enable crypt password storage : TRUE 13 Service Auth Method pam_ldap : 14 Service Auth Method keyserv : 15 Service Auth Method passwd-cmd: 16 Search Time Limit : 30 17 Profile Time to Live : 43200 18 Bind Limit : 2 19 Service Search Descriptors Menu Enter config value to change: (1-19 0=commit changes) [0] Enter DN for proxy agent:[cn=proxyagent,ou=profile,dc=west,dc=example,dc=com] Enter passwd for proxyagent: Re-enter passwd: |
WARNING: About to start committing changes. (y=continue, n=EXIT) Y |
1. Changed timelimit to -1 in cn=config. 2. Changed sizelimit to -1 in cn=config. 3. Changed passwordstoragescheme to "crypt" in cn=config. 4. Schema attributes have been updated. 5. Schema objectclass definitions have been added. 6. Created DN component dc=west. 7. NisDomainObject added to dc=west,dc=example,dc=com. 8. Top level "ou" containers complete. 9. Nis maps: auto_home auto_direct auto_master auto_shared processed. 10. ACI for dc=west,dc=example,dc=com modified to disable self modify. 11. Add of VLV Access Control Information (ACI). 12. Proxy Agent cn=proxyagent,ou=profile,dc=west,dc=example,dc=com added. 13. Give cn=proxyagent,ou=profile,dc=west,dc=example,dc=com read permission for password. 14. Generated client profile and loaded on server. 15. Processing eq,pres indexes: ipHostNumber (eq,pres) Finished indexing. uidNumber (eq,pres) Finished indexing. ipNetworkNumber (eq,pres) Finished indexing. gidnumber (eq,pres) Finished indexing. oncrpcnumber (eq,pres) Finished indexing. 16. Processing eq,pres,sub indexes: membernisnetgroup (eq,pres,sub) Finished indexing. nisnetgrouptriple (eq,pres,sub) Finished indexing. 17. Processing VLV indexes: getgrent vlv_index Entry created gethostent vlv_index Entry created getnetent vlv_index Entry created getpwent vlv_index Entry created getrpcent vlv_index Entry created getspent vlv_index Entry created idsconfig.sh: Setup of Sun ONE Directory Server server ipdserver is complete. Note: idsconfig has created entries for VLV indexes. Use the directoryserver(1m) script on ipdserver to stop the server and then enter the following vlvindex sub-commands to create the actual VLV indexes: directoryserver -s ipdserver vlvindex -n userRoot -T getgrent directoryserver -s ipdserver vlvindex -n userRoot -T gethostent directoryserver -s ipdserver vlvindex -n userRoot -T getnetent directoryserver -s ipdserver vlvindex -n userRoot -T getpwent directoryserver -s ipdserver vlvindex -n userRoot -T getrpcent directoryserver -s ipdserver vlvindex -n userRoot -T getspent |
サマリー画面で空欄になっているパラメータは設定されません。
idsconfig によるディレクトリの設定が完了したら、サーバー設定を完了してサーバーをクライアント対応にする前に、サーバー上で指定されたコマンドを実行する必要があります。
pam_unix を使用している場合、データを使用してディレクトリサーバーを生成する前に、パスワードを Unix Crypt 形式で格納するようにサーバーを構成する必要があります。pam_ldap を使用している場合、任意の形式でパスワードを格納できます。UNIX crypt 形式でパスワードを設定する方法については、Sun ONE Directory Server のドキュメントを参照してください。
ldapaddent(1M) は、LDAP ネームサービス用に構成済みのクライアントでのみ実行できます。
ldapaddent は、標準入力から (/etc/filename passwd など) データを読み取り、このデータをサービスに関連付けられたコンテナに配置します。クライアント構成により、デフォルトのデータ書き込み方法が決定されます。
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(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 コマンドを 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
LDAP ディレクトリのパスワード管理ポリシーを構成するために、ディレクトリサーバーコンソールや ldapmodify を使う方法については、『iPlanet Directory Server 5.1 管理者ガイド』 の「ユーザーアカウントの管理」の章を参照してください。 pam_ldap が正しく動作するには、パスワードとアカウントのロックアウトポリシーがサーバー上で正しく構成されている必要があります。
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 5.1 をもとに古くなったパスワードやアカウントの期限切れ情報を維持し、ユーザーに知らせます。ディレクトサーバーは、ユーザーアカウントを有効にするシャドウエントリから対応するデータを解釈しません。しかし、 pam_unix がシャドウデータを調査して、アカウントがロックされているか、パスワードが古くなっているかを判断します。LDAP ネームサービスやディレクトリサーバーはシャドウデータを維持しているわけではないので、 pam_unix はシャドウデータにもとづいたアクセスを許可するべきではありません。シャドウデータは proxy 識別情報を使って検出します。そのため、 proxy ユーザーは userPassword 属性へ読み取りアクセスすることができません。proxy ユーザーを userPassword へ読み取りアクセスさせないことにより、 pam_unix が無効なアカウントの妥当性検査を行わないようになります。
この章では、Solaris LDAP ネームサービスクライアントの設定方法について説明します。
この章の内容は次のとおりです。
Solaris クライアントで LDAP をネームサービスとして使用するためには、次の要件が満たされている必要があります。
クライアントのドメイン名が LDAP サーバーによって処理される
nsswitch.conf ファイルが、必要なサービスの LDAP を指している。nsswitch.conf ファイルについては、第 2 章「ネームサービススイッチ (概要)」を参照
クライアントが、その動作を定義するための特定のパラメータをすべて使って構成されている
ldap_cachemgr がクライアントで実行されている
クライアントが構成されているサーバーが 1 つ以上起動され、実行されている
ldapclient ユーティリティは、サーバーの起動を除き、上記の手順をすべて実行するので、LDAP クライアントを設定するための鍵となります。この章の後半では、ldapclient ユーティリティを使用して LDAP クライアントを設定する方法や、それ以外の各種 LDAP ユーティリティを使用して LDAP クライアントに関する情報を取得したり LDAP クライアントの状態をチェックしたりする方法について、例を挙げて説明します。
ldapclient(1M) は、Solaris オペレーティング環境で LDAP クライアントを設定するためのユーティリティです。ldapclient ユーティリティでは、サーバーがすでに適切なクライアントプロファイルで構成されていることを前提としています。サーバーをインストールして、適切なプロファイルで構成してからクライアントを設定する必要があります。
ldapclient を使用してクライアントを設定するには、次の 2 つの方法があります。
「プロファイル」
少なくとも、使用するプロファイルとドメインを含むサーバーアドレスを指定する必要があります。プロファイルが指定されていない場合は、デフォルトのプロファイルが使用されます。プロキシと認証データベースの情報を除いて、必要な情報はサーバーから入手できます。クライアントの資格レベルがプロキシまたは匿名プロキシである場合は、プロキシのバインド DN とパスワードを入力する必要があります。詳細については、クライアント資格レベルの割り当てを参照してください。
「手動」
クライアント自体でプロファイルを設定します。つまり、コマンド行からすべてのパラメータを定義します。このため、プロファイル情報はキャッシュファイルに格納されサーバーによってリフレッシュされることはありません。
クライアントを手動で構成することも可能ですが、お勧めしません。構成用のプロファイルを使用すると、クライアントの管理が容易になりコストも削減できます。
スーパーユーザーになります。
init を指定して ldapclient を実行します。
# ldapclient init -a profileName=new -a \
domainName=west.example.com 192.168.0.0
System successfully configured |
スーパーユーザーになります。
ldapclient を実行します (プロキシ値を定義します)。
# ldapclient init -a \ proxyDn=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com -a \ domainname=west.example.com -a profilename=pit1 -a \ proxypassword=test1234 192.168.0.0
System successfully configured |
使用するプロファイルがプロキシ用に設定されている場合は、-a proxyDn と -a proxypassword が必須です。 サーバーに保存されているプロファイルにはこの資格情報が含まれていないため、クライアントを初期設定するときは資格情報を入力する必要があります。この方法は、プロキシの資格情報をサーバーに保存していた従来の方法に比べて安全性が高くなります。
プロキシ情報は /var/ldap/ldap_client_cred の作成に使用され、それ以外の情報は/var/ldap/ldap_client_file に格納されます。
どちらのクライアント構成ファイルも直接編集しないでください。これらのファイルの内容を作成または変更する場合は、ldapclient を使用してください。
スーパーユーザーは、クライアントの構成を手動で行うことができます。ただし、この処理では多数のチェックが省略されるため、システムを正しく構成できないことがよくあります。また、プロファイルを使用するときのように一括に設定するのではなく、「マシンごとに」設定を変更する必要があります。
スーパーユーザーになります。
ldapclient manual を実行します。
# ldapclient manual —a domainName=dc=west.example.com \
—a credentialLevel=proxy —a defaultSearchBase=dc=west, \ dc=example, dc=com \
—a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \
—a proxyPassword=testtest 192.168.0.0
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 uninit コマンドは、クライアントのネームサービスを元の状態 (init、modify、または manual の最後の操作が行われる前の状態) に復元します。言い換えれば、最後に行われた手順を「元に戻します」。たとえば、profile1 を使用するようにクライアントを設定した後で profile2 を使用するように変更した場合、ldapclient uninit を実行すると、クライアントで profile1 を使用するように設定が元に戻ります。
cert7.db と key3.db の各ファイルには、どのユーザーも読み取り権が必要です。key3.db ファイルに非公開鍵を含めないようにしてください。
TLS を使用する場合は、必要なセキュリティデータベースをインストールしなければなりません。特に、cert7.db と key3.db の両ファイルは必須です。cert7.db ファイルには、信頼できる認証のデータベースが入ります。key3.db ファイルには、クライアントの鍵が入ります。LDAP ネームサービスクライアントではクライアントの鍵を使用しませんが、このファイルは必要です。
ldapclient を実行する前に、この節に記述されている必要なセキュリティデータベースファイルを設定およびインストールしておく必要があります。
これらのファイルを作成および管理する方法については、『iPlanet Directory Server 5.1 管理者ガイド』の 「SSL の管理」の「LDAP クライアントで SSL を利用するための構成」に関する節を参照してください。これらのファイルを構成したら、LDAP ネームサービスクライアントで使用できるように所定の場所にそれらを格納する必要があります。この場所を判断するために、属性 certificatePath が使用されます。この属性はデフォルトで /var/ldap です。
たとえば、Netscape Communicator を使用して必要な cert7.db ファイルと key3.db ファイルを設定した後で、それらのファイルをデフォルトの位置にコピーします。
# cp $HOME/.netscape/cert7.db /var/ldap
# cp $HOME/.netscape/key3.db /var/ldap
次に、すべてのユーザーに読み取り権を付与します。
# chmod 444 /var/ldap/cert7.db
# chmod 444 /var/ldap/key3.db
Netscape では、cert7.db とkey3.db の各ファイルを $HOME/.netscape ディレクトリで管理します。このため、それらのセキュリティデータベースを LDAP ネームサービスクライアントで使用する場合は、そのコピーをローカルファイルシステム上に格納する必要があります。
パスワード管理機能なしで pam_ldap を使うときは、pam_ldap に対応した pam.conf ファイルの例 のサンプルの pam.conf ファイルにしたがってください。 pam_ldap.so.1 を含む行をクライアントの /etc/pam.conf ファイルに追加します。 詳細については、pam.conf(4) のマニュアルページを参照してください。
パスワード管理機能のために 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) のマニュアルページを参照してください。
ldaplist は、LDAP サーバーから取得したネームサービス情報を LDIF フォーマットで表示する LDAP ユーティリティです。このユーティリティは、障害追跡に役立ちます。詳細については、ldaplist(1) のマニュアルページを参照してください。
ldaplist は、レコードを空行で区切って出力を表示します。この表示方法は、複数行にまたがる大きなレコードに有効です。
ldaplist の出力は、クライアントの構成によって変わります。たとえば、ns_ldap_search の値が one ではなく sub である場合は、ldaplist によって現在の検索 baseDN の下にあるエントリがすべて表示されます。
以下に ldaplist の出力例を示します。
# ldaplist
dn: ou=people,dc=west,dc=example,dc=com dn: ou=group,dc=west,dc=example,dc=com dn: ou=rpc,dc=west,dc=example,dc=com dn: ou=protocols,dc=west,dc=example,dc=com dn: ou=networks,dc=west,dc=example,dc=com dn: ou=netgroup,dc=west,dc=example,dc=com dn: ou=aliases,dc=west,dc=example,dc=com dn: ou=hosts,dc=west,dc=example,dc=com dn: ou=services,dc=west,dc=example,dc=com dn: ou=ethers,dc=west,dc=example,dc=com dn: ou=profile,dc=west,dc=example,dc=com dn: automountmap=auto_home,dc=west,dc=example,dc=com dn: automountmap=auto_direct,dc=west,dc=example,dc=com dn: automountmap=auto_master,dc=west,dc=example,dc=com dn: automountmap=auto_shared,dc=west,dc=example,dc=com |
ユーザーの passwd エントリなど特定の情報を表示する場合は、次のように getent を使用します。
# getent passwd user1
user1::30641:10:Joe Q. User:/home/user1:/bin/csh |
すべての属性を表示する場合は、-l オプションを指定して ldaplist コマンドを実行します。
# ldaplist -l passwd user1
dn: uid=user1,ou=People,dc=west,dc=example,dc=com uid: user1 cn: user1 uidNumber: 30641 gidNumber: 10 gecos: Joe Q. User homeDirectory: /home/user1 loginShell: /bin/csh objectClass: top objectClass: shadowAccount objectClass: account objectClass: posixAccount shadowLastChange: 6445 userPassword: {crypt}J6vlYXRU.sW8c |
クライアント環境では、必要に応じて 2 種類のカスタマイズを行うことができます。
/etc/nsswitch.conf ファイルを変更して、各サービスが情報を取得する場所をカスタマイズできます。デフォルトの設定は /etc/nsswitch.ldap に保存されており、クライアントの初期化時に ldapclient がこのファイルを使って /etc/nsswitch.conf ファイルを作成します。
/etc/resolv.conf ファイルを設定して DNS を使用可能にする場合は、次に示すように、DNS をhosts 行に追加します。
hosts: ldap dns [NOTFOUND=return] files |
どのサービスも変更できますが注意が必要です。変更したサービスのデータがサーバー上に生成されない場合、カスタマイズは無効になります。さらに、ファイルがデフォルトで設定されない場合もあります。
この章では、LDAP の構成で発生する問題とその解決方法を示します。
この節では、LDAP クライアント環境の状態判定に使用するさまざまなコマンドを紹介します。詳細については、一般的な問題とその解決方法について解説した、障害追跡に関する節を参照してください。使用可能なオプションの詳細については、マニュアルページも参照してください。
ldap_cachemgr デーモンは、常に実行中で適切に機能している必要があります。このデーモンが機能していない場合、意図した動作はまったく実行されません。ldap_cachemgr の動作を確認するには、次の 2 つの方法があります。
ps -ef を使用する
# ps -ef | grep ldap_cachemgr
-g オプションを ldap_cachemgr に渡す
この操作により、次の状態情報がダンプされます。この情報は問題を診断する際に役立ちます。
# /usr/lib/ldap/ldap_cachemgr -g
cachemgr configuration: server debug level 0 server log file "/var/ldap/cachemgr.log" number of calls to ldapcachemgr 19 cachemgr cache data statistics: Configuration refresh information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:43:28 Server information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:36:08 server: 192.168.0.0, status: UP server: 192.168.0.1, status: ERROR error message: Can't connect to the LDAP server Cache data information: Maximum cache entries: 256 Number of cache entries: 2 |
スーパーユーザーになり、ldapclient を list オプションを付けて実行します。
# ldapclient list
NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 192.168.0.0, 192.168.0.1 NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= TRUE NS_LDAP_SEARCH_SCOPE= one NS_LDAP_SEARCH_TIME= 30 NS_LDAP_SERVER_PREF= 192.168.0.0 NS_LDAP_PROFILE= pit1 NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,?sub NS_LDAP_SERVICE_SEARCH_DESC= group:ou=group,dc=west,dc=example,dc=com?one NS_LDAP_BIND_TIME= 5 |
/var/ldap ファイルは現在 ASCII 形式ですが、バイナリに変更される可能性があるため、このファイルに対して cat コマンドを実行すると問題が発生する可能性があります。この情報へのアクセスにサポートされている方式は、ldapclient list です。
クライアントが LDAP サーバーに対して通信を行なっていることを確認する最善の方法は、ldaplist コマンドを使用することです。引数を付けずに ldaplist だけを指定して実行すると、サーバー上のすべてのコンテナがダンプされます。この方法はコンテナが存在している限り可能で、コンテナを生成する必要がありません。最初の手順が成功したら、ldaplist passwd username または ldaplist hosts hostname を実行できますが、大量のデータが含まれている場合には、生成量の少ないサービスを選ぶか、head や more コマンドを使用してデータをパイプ処理することもできます。
前述のコマンドの大半は、LDAP クライアントであることを前提としています。クライアントを作成していない状態でサーバー上のデータをチェックする場合は、ldapsearch コマンドを使用します。次の例では、すべてのコンテナをリスト表示します。
# ldapsearch -h server1 -b "dc=west,dc=example,dc=com" -s one "objectclass=*"
|
LDAP の構成で発生する問題とそれらの解決方法について説明します。
Solaris オペレーティング環境 LDAP クライアントのバックエンドは、ホストの検索で、gethostbyname(3N) や getipnodebyname(3N) の場合と同様、完全指定ホスト名を返します。格納済みの名前が指定されている (1 つ以上のドットが含まれている) 場合、クライアントはその名前をそのまま返します。たとえば、格納されている名前が hostB.eng であれば、返される名前も hostB.eng です。
LDAP ディレクトリに格納された名前が指定されていない (ドットが 1 つも含まれない) 場合、クライアントのバックエンドは、その名前にドメイン部分を追加します。たとえば、格納されている名前が hostA であれば、返される名前は hostA.domainname となります。
DNS ドメイン名が LDAP ドメイン名とは異なる場合、格納されたホスト名が完全指定でない限り LDAP ネームサービスをホスト名に対して使用することはできません。
LDAP クライアントは、ログイン時に pam(3) モジュールを使用してユーザーを認証します。UNIXTM 標準の 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 データベースは、検索パフォーマンス向上にインデックスを使用します。インデックスが正しく作成されていない場合、大幅にパフォーマンスが低下することがあります。このマニュアルには、インデックスを作成する必要のある共通の属性セットを記述しています。また、独自のインデックスを追加して、パフォーマンスの向上を図ることができます。
init プロファイルオプションを使用しているときに、ldapclient がクライアントの初期化に失敗しました。失敗の原因は以下のとおりです。
コマンド行で不正なドメイン名が指定された
指定されたクライアントドメインのエントリポイントを表す nisDomain 属性が DIT (ディレクトリ情報ツリー) 内に設定されていない
アクセス制御情報がサーバー上で適正に設定されていないため、LDAP データベース内の匿名検索が許可されない
ldapclient コマンドに渡されたサーバーアドレスが間違っている。ldapsearch(1) を使用してサーバーのアドレスを確認する
ldapclient コマンドに渡されたプロファイル名が間違っている。ldapsearch(1) を使用して、DIT 内のプロファイル名を確認する
クライアントのネットワークインタフェースに対して snoop(1M) を実行して外向きのトラフィックを検査し、どのサーバーと通信しているかを確認する
ldap_cachemgr を -g オプションをつけて使用すると、現在のクライアント構成および統計を表示できるため、デバッグするのに便利です。たとえば、次のようになります。
# ldap_cachemgr —g
この結果、すでに説明したように、すべての LDAP サーバーの状態を含む現在のクライアント構成および統計が標準出力に出力されます。このコマンドを実行するのに、スーパーユーザーになる必要はありません。
ldapclient コマンドがハングアップした場合、Ctrl-C キーを押すと以前の環境を復元した後で終了します。この状況が発生する場合、サーバーが動作していることをサーバー管理者に確認してください。
プロファイルまたはコマンド行に指定されたサーバーリスト属性で、サーバー情報が適正であることを確認してください。
以前の Solaris リリースで LDAP ネームサービスを使用できますか
現在のところ、LDAP は Solaris 8 および Solaris 9 でのみサポートされています。Solaris 8 と Solaris 9 との相違点については、Solaris 9 LDAP ネームサービスの新機能 を参照してください。
Solaris LDAP ネームサービスでの DIT のデフォルト位置を教えてください
デフォルトのディレクトリ情報ツリー (DIT)を参照してください。
変数 |
_______ ネットワークの定義 |
---|---|
インストールしたディレクトリサーバーインスタンスのポート番号 (デフォルト = 389) | |
サーバー名 | |
複製サーバー (IP 番号 : ポート番号) | |
ディレクトリマネージャ [dn: cn=directory manager] | |
サービスされるドメイン名 | |
クライアント要求の処理がタイムアウトするまでの時間 (秒) | |
各検索要求で返されるエントリの最大数 |
表 18–2 クライアントプロファイルで定義する変数
変数 |
________ ネットワークの定義 |
---|---|
プロファイル名 | |
サーバーリスト (デフォルトはローカルサブネット) | |
優先されるサーバーリスト (優先順に記載) | |
検索範囲 (検索するディレクトリツリーレベルの数、「One」または「Sub」) | |
サーバーへのアクセスに使用する資格。デフォルトは匿名 | |
参照に従うか。(メインサーバーが利用不可能な場合に使用される、別のサーバーへのポインタ)。デフォルトは no | |
検索時にサーバーが情報を返すまでの待機制限時間 (秒、デフォルトは 30) | |
サーバーとの通信時のバインド制限時間 (秒、デフォルトは 30)。デフォルトは秒 | |
認証方式。デフォルトは none |
Solaris 9 クライアントは、Solaris 8 クライアント用に設定されたディレクトリサーバーと完全な互換性があります。ldapclient(1M) は、この種のプロファイルをダウンロードしてバージョン 1 のプロファイルを使用してクライアントを構成できます。ただし、Solaris 9 の新機能を利用して新規セキュリティモデルを使用するには、バージョン 2 のプロファイルを使用する必要があります。
サーバーは、旧クライアントと新クライアントの混在環境に対応します。このため、スキーママッピングが無効でバージョン 2 のプロファイルが serviceSearchDescriptors 内の特殊フィルタを使用しない構成になっている限り、どちらのクライアントでも同じ結果を得ることができます。サーバーがデフォルトスキーマを使用しない場合、Solaris 8 クライアントはスキーマを任意に対応づけできないため、旧クライアントはそのサーバーを利用できません。
考慮する必要のあるもう 1 つの追加変更は、Solaris 8 では ldap_cachemgr() を実行するクライアントは推奨されず、オプションであったのに対し、Solaris 9 では ldap_cachemgr() を「常に実行する必要がある」という点です。このデーモンは、クライアントが適正に動作するために「必須」です。
Solaris 9 はデフォルトで、Solaris 8 クライアントの使用する汎用の NIS マップスキーマではなく、automount エントリ用の新規スキーマを使用します。このため Solaris 9 ツールを使用してサーバーを設定した場合、Solaris 8 クライアントから automount エントリを表示できなくなります。サイトで Solaris 9 と Solaris 8 クライアントの両方に対応するサーバーを設定する場合、自動マウントエントリを追加する前に、プロファイルを作成してスキーマを以前のスキーマに対応づけてください。この操作により、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 |
Solaris には、LDAP 関連のコマンドセットが 2 つ存在します。1 つのセットは一般的な LDAP ツールで、LDAP ネームサービスを使用してクライアントを構成する必要はありません。もう 1 つのセットはクライアント上の共通 LDAP 構成を使用するため、クライアントがネームサービスに LDAP を使用する場合にのみ使用できます。
LDAP コマンド行ツールは、認証やバインドパラメータを含む、一般的なオプションセットをサポートします。
これらのコマンドを使用して、ディレクトリエントリを直接操作できます。ldapsearch(1)、ldapmodify(1)、ldapadd(1)、ldapdelete(1) の各ツールは、LDAP データ交換フォーマット (LDIF) と呼ばれる、ディレクトリ情報を表現する共通のテキストベースの書式をサポートしています。
ツール |
機能 |
---|---|
ldapaddent(1M) |
LDAP コンテナ内に、/etc 内のファイルに対応するエントリを作成する。このツールを使用して、ファイルからディレクトリを生成できる。たとえば、/etc/passwd 形式のファイルを読み込んで、ディレクトリ内に passwd エントリを生成する |
ldaplist(1) |
ディレクトリから、さまざまなサービスの内容をリスト表示するのに使用する |
idsconfig(1M) |
LDAP ネームサービスクライアント対応の Sun ONE Directory Server 5.1 の設定に使用する |
# # Authentication management # # login service (explicit because of pam_dial_auth) # login auth required pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_dial_auth.so.1 login auth sufficient pam_unix_auth.so.1 login auth required pam_ldap.so.1 try_first_pass # # rlogin service (explicit because of pam_rhost_auth) # rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth required pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth sufficient pam_unix_auth.so.1 rlogin auth required pam_ldap.so.1 try_first_pass # # rsh service (explicit because of pam_rhost_auth) # rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_authtok_get.so.1 rsh auth required pam_dhkeys.so.1 rsh auth sufficient pam_unix_auth.so.1 rsh auth required pam_ldap.so.1 try_first_pass # # PPP service (explicit because of pam_dial_auth) # ppp auth required pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_dial_auth.so.1 ppp auth sufficient pam_unix_auth.so.1 ppp auth required pam_ldap.so.1 try_first_pass # # Default definitions for Authentication management # Used when service name is not explicitly mentioned for authenctication # other auth required pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth sufficient pam_unix_auth.so.1 other auth required pam_ldap.so.1 try_first_pass # # passwd command (explicit because of a different authentication module) # passwd auth sufficient pam_passwd_auth.so.1 passwd auth required pam_ldap.so.1 try_first_pass # # cron service (explicit because of non-usage of pam_roles.so.1) # cron account required pam_projects.so.1 cron account required pam_unix_account.so.1 # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account required pam_unix_account.so.1 # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session required pam_unix_session.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password required pam_dhkeys.so.1 other password required pam_authtok_get.so.1 other password required pam_authtok_check.so.1 other password sufficient pam_authtok_store.so.1 other password required pam_ldap.so.1 # # Support for Kerberos V5 authentication (uncomment to use Kerberos) # #rlogin auth optional pam_krb5.so.1 try_first_pass #login auth optional pam_krb5.so.1 try_first_pass #other auth optional pam_krb5.so.1 try_first_pass #cron account optional pam_krb5.so.1 #other account optional pam_krb5.so.1 #other session optional pam_krb5.so.1 #other password optional pam_krb5.so.1 try_first_pass |
# 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 |
スキーマは、サーバーのディレクトリ内にエントリとして格納可能な情報タイプを記述した定義です。
ディレクトリサーバーが Solaris 9 LDAP ネームサービスクライアントをサポートするには、クライアントのスキーママッピング機能を使用してスキーマをマッピングしていない限り、この章で定義されたスキーマをサーバー内で構成する必要があります。
IETF により定義された 4 つの必須 LDAP スキーマ (RFC 2307 ネットワーク情報サービススキーマ、LDAP メールグループインターネットドラフト、および LDAP Internet Printing Protocol (IPP) ドラフトスキーマ) が存在します。ネーム情報サービスをサポートするには、これらのスキーマ定義をディレクトリサーバーに追加する必要があります。IETF Web サイト http://www.ietf.org で、さまざまな RFC にアクセスできます。
インターネットドラフトとは、最長 6 ヶ月間有効なドラフトの文書で、他の文書によっていつでも更新または廃止される可能性があります。
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)' ) |
( 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 )) |
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 プロジェクトスキーマ
アクセス制御および実行プロファイルスキーマに基づく役割
プリンタスキーマ
/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' ) |
( 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 ) ) |
( 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' ) |
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)) |
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 ) |
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 つ以上サポートする必要があります。
pam_unix を使用する場合、サーバーは UNIX 暗号形式 (crypt) でのパスワード保管をサポートする必要があります。
TLS を使用する場合、サーバーは SSL または TLS をサポートする必要があります。
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)) -------------- |
フィルタ (Filter) |
定義 |
---|---|
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) |
この章では、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 で対応づけられる
rpc.nisd の処理は、2 つの構成ファイルを使用して制御します。
/etc/default/rpc.nisd
LDAP サーバーと認証、NIS+ ベースドメイン、LDAP デフォルト検索ベース、例外処理、および rpc.nisd の一般的な構成に関する情報を含みます。このファイルは、LDAP マッピングが有効であるかどうかにかかわらず適用されます。
/var/nis/NIS+LDAPmapping
NIS+ データと LDAP との間のマッピング情報を含みます。テンプレートファイル (/var/nis/NIS+LDAPmapping.template) は、client_info.org_dir と timezone.org_dir 以外のすべての標準 NIS+ オブジェクトに対応しています。 client_info および timezone テーブルとNIS+LDAPmapping(4) のマニュアルページを参照してください。
構成とは、値を定義済みの属性に割り当てることです。構成ファイル以外に、構成属性を LDAP から読み込むこともできます (構成情報を LDAP に格納する を参照)。また、rpc.nisd コマンドの -x オプションに構成属性を指定することもできます。複数の場所で同じ属性が指定されている場合、優先順位 (高から低) は次のとおりです。
rpc.nisd -x オプション
構成ファイル
LDAP
NIS+ と LDAP のマッピングの構成によっては、新しい LDAP 属性とオブジェクトクラスをいくつか作成しなければならないことがあります。次の例では、これらの作成方法として、 ldapadd コマンドの入力として使用できる LDIF データを指定する方法を示します。LDIF データを含むファイルを作成してから、ldapadd(1) を起動します。
# ldapadd -D bind-DN —f ldif -file
この方法は、Sun ONETM Directory Server 5.1 で機能します。また、その他の LDAP サーバーでも機能することがあります。
ただし、defaultSearchBase、 preferredServerList、および authenticationMethod 属性を除き、この章で使用されているオブジェクト識別子 (OID) は、SYNTAX 仕様と同様に、説明用に挙げているだけです。OID の基準はありません。任意の OID を使用できます。
NIS+ データを LDAP リポジトリに格納するために必要な構成の概要については、NIS+LDAPmapping(4) のマニュアルページを参照してください。 ここでは、構成ファイルの編成について詳細に説明します。
/etc/default/rpc.nisd ファイルに値を割り当てるときは、すべて attributeName=value タイプとします。
次の属性は、 rpc.nisd の一般的な構成を制御します。また、LDAP マッピングが有効かどうかにかかわらず、アクティブになります。 これらの属性は通常、デフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。
nisplusNumberOfServiceThreads
nisplusThreadCreationErrorAction
nisplusThreadCreationErrorAttempts
nisplusThreadCreationErrorTimeout
nisplusDumpErrorAction
nisplusDumpErrorAttempts
nisplusDumpErrorTimeout
nisplusResyncService
nisplusUpdateBatching
nisplusUpdateBatchingTimeout
次の属性は、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
defaultSearchBase
LDAP DIT 内で、RFC 2307 に準拠したネームサービスデータのコンテナが配置される場所。コンテナ DN の完全な検索ベースを個別に指定しなかった場合は、この場所がデフォルトで使用されます。詳細については、nisplusLDAPobjectDN を参照してください。
nisplusLDAPbaseDomain
NIS+ オブジェクト仕様 (nisplusLDAPdatabaseIdMapping を参照) を完全指定しなかった場合は、このデフォルト NIS+ ドメイン名が使用されます。
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
nisplusLDAPmatchFetchAction
このパラメータでは、NIS+ 照合処理のために、LDAP データを事前に取得するかどうかを決定します。ほとんどの場合、この値はデフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。
この構成の名前は、rpc.nisd(1M) の -m オプションを使用して変更できます。NIS+LDAPmapping ファイルは、NIS+ および LDAP マッピングのマスタースイッチとして機能します。
マッピングファイルに対してデフォルト以外の名前を使用する場合は、/etc/init.d/rpc ブートスクリプトを編集して、rpc.nisd 起動行にそのマッピングファイル名を指定する必要があります。
LDAP に対応づける NIS+ オブジェクトごとに、 NIS+LDAPmapping ファイルに 2 - 5 個の属性を指定します。指定する属性値は、オブジェクトとデフォルト値によって異なります。
別名は、オブジェクトがほかのマッピング属性で使用されるときに設定する必要があります。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 をそのテーブルのエントリに使用することを定義します。
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 には、対応づけられた 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 には、NIS+ データを LDAP に対応づけるときのルールを指定します。LDAP から NIS+ データへのマッピングルールは、nisplusLDAPcolumnFromAttribute に指定します。
nisplusLDAPcolumnFromAttribute には、LDAP データを NIS+ に対応づけるときのルールを指定します。
エントリマッピングの完全な構文については、 NIS+LDAPmapping(4) のマニュアルページを参照してください。ここでは、わかりやすい例をいくつか挙げます。
NIS+ rpc.org_dir テーブルには、cname、name、numbe、および comment という列が含まれます。たとえば、NIS+ RPC プログラム番号 (100300) に対して、正規名として nisd が指定され、別名として rpc.nisd と nisplusd が指定されているとします。このエントリは、rpc.org_dir の次の NIS+ エントリを使用して表現できます。
nisd nisd 100300 NIS+ server nisd rpc.nisd 100300 NIS+ server nisd nisplusd 100300 NIS+ server |
defaultSearchBase の値を dc=some,dc=domain と想定します。対応する LDAP は、ldapsearch(1) を実行すると次のように表示されます。
cn=nisd,ou=Ppc,dc=some,dc=domain cn=nisd cn=rpc.nsid cn=nisplusd oncrocnumber=100300 description=NIS+ server objectclass=oncRpc objectclass=top |
この例は、NIS+ および LDAP が単純に 1 対 1 で対応づけられている場合です。この場合、NIS+ から LDAP へのマッピング属性値は、次のようになります。
nisplusLDAPattributeFromColumn \ rpc: dn=("cn=%s,", name), \ cn=cname, \ cn=name, \ oncRpcNumber=number, \ description=comment |
このエントリの DN として、cn=%s が構成されます。cname 列の値が %s に代入されます。
cn=nisd, |
値がコンマで終了しているため、 nisplusObjectDN の読み込みベース値が付加され、次のようになります。
cn=nisd,ou=Rpc,dc=some,dc=domain |
oncRpcNumber 属性および description 属性の値には、対応する NIS+ 列の値が代入されます。rpc.nisd によって、複数の NIS+ エントリが 1 つの LDAP エントリに収集され、異なる name 列値を表す複数の cn 値が生成されます。
同様に、LDAP から NIS+ へのマッピングは、次のようになります。
nisplusLDAPcolumnFromAttribute \ rpc: cname=cn, \ (name)=(cn), \ number=oncRpcNumber, \ comment=description |
この例では、oncRpcNumber および description の値が、対応する NIS+ 列に割り当てられます。 (cn) で示される複数値列 cn は、(name) で示される name 列値にマップされています。name 列は複数値列でないため、rpc.nisd によって cn 値ごとに 1 つの NIS+ エントリが作成されます。
最後に、削除に使用するルールセットの例を、nisplusLDAPattributeFromColumn 値を使って説明します。
nisplusLDAPattributeFromColumn \ user_attr_del: dn=("uid=%s,", name), \ SolarisUserQualifier=, \ SolarisAttrReserved1=, \ SolarisAttrReserved2=, \ SolarisAttrKeyValue= |
すでに述べたように、user_attr.org_dir データは、 ほかのテーブル (passwd.org_dir など) のアカウント情報と、 ou=People コンテナを共有しています。user_attr.org_dir テーブルのエントリが削除されたときに、 ou=People エントリ全体を削除したいとはおそらく考えないでしょう。この例ではエントリ全体を削除する代わりに、user_attr.org_dir エントリが削除されたときに、SolarisUserQualifier 、SolarisAttrReserved1、SolarisAttrReserved2 、および SolarisAttrKeyValue 属性が存在する場合、次のルールに指定されている ou=People エントリから削除されます。
dn=("uid=%s,", name) |
これ以外の LDAP エントリは変更されません。
NIS+ から LDAP への移行シナリオの例を挙げます。
すべての NIS+ クライアントを 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 データのマージ を参照してください。
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 属性を参照してください。
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+ データのバックアップを /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) が存在する場所) を含める
手順 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 にリダイレクトします。
# ldapdelete —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 デーモンが LDAP リポジトリを使用する場合は、適切なマッピングファイルを指定します。
rpc.nisd デーモンを NIS (YP) エミュレーションに対応させる場合は、-Y オプションを指定します。
# /usr/sbin/rpc.nisd -m mappingfile [ -Y ]
手順 10 のアップロードコマンドから、-x nisplusLDAPinitialUpdateOnly=yes を省略することもできます。省略した場合、アップロードが完了すると、rpc.nisd デーモンは NIS+ データの提供を開始します。
NIS+ マスターだけが、データを LDAP に書き込むことができます。NIS+ 複製は、NIS+ マスターから更新を取得するか (LDAP から取得する場合を含む) 、LDAP サーバーから直接データを読み込みます。この 2 つの方法を組み合わせることもできます。つまり、NIS+ 複製を使用するときは、主に 2 つの方法があります。
NIS+ 複製は変更せずに使用し、更新データは NIS+ マスターから取得する
この方法の場合は、NIS+ マスター以外は、LDAP サーバーと接続する必要がないため、構成が単純になります。従来の複製関係も変更されません。つまり、 新しいデータはまずマスターに反映され、次に複製に反映されます。ネームサービスのデータを従来どおり NIS+ が管理するときは、ほとんどの場合、この方法が最も便利な方法です。ただし、LDAP と NIS+ 複製サーバーとの間のパスが長くなります。
NIS+ 複製は、更新データを NIS+ マスターから取得しないで、LDAP から直接取得する
この場合、複製のデータの更新は、LDAP から取得したデータのルックアップトラフィックおよび TTL に基づいて、NIS+ マスターの更新前または更新後に行われます。この方法はより複雑ですが、LDAP がネームサービスリポジトリを管理するときは、便利な方法です。NIS+ データに対する直接の更新は、ほとんどまたはまったく発生しません。
NIS+ 複製が特定の NIS+ ディレクトリに含まれる 1 つ以上のオブジェクトのデータを LDAP から取得しているときは、nisping(1M) によって出力される更新タイムスタンプが NIS+ マスターおよび NIS+ 複製間のデータの整合性を示しているとは限りません。たとえば、NIS+ ディレクトリ dir1 に table1 および table2 テーブルが含まれているとします。 複製が table1 および table2 のデータを NIS+ マスターから取得しているときは、次のようなタイムスタンプが出力されます。
# nisping dir1
Master server is "master.some.domain." Last update occurred at Mon Aug 5 22:11:09 2002 Replica server is "replica.some.domain." Last Update seen was Mon Aug 5 22:11:09 2002 |
これらのタイムスタンプは、マスターおよび複製のデータが完全に一致していることを示しています。しかし、複製が table1 または table2、あるいはその両方のデータを LDAP から取得しているとします。この場合、この出力には、複製がマスターから NIS_PING を受け取り、再同期化のタイムスタンプをシステム管理用に更新したことだけが示されます。LDAP に対応づけられているテーブルのデータは、次のどちらかの場合、NIS+ マスター上のデータと異なることがあります。
LDAPデータが NIS+ マスター上のデータと異なる
期限切れではないが、LDAP と同期がとれていない複製のキャッシュに NIS+ データベースのデータが格納されている
このようなデータの不一致を許容できない場合は、NIS+ 複製が常に NIS+ マスターからデータを取得するようにします。NIS+ マスターが常に LDAP からデータを取得するように構成した場合は、複製を変更する必要はありません。
rpc.nisd デーモンの LDAP マッピングでは、LDAP プロトコルバージョン 3 を使用して LDAP サーバーと対話します。 デフォルトのマッピング構成 ( /var/nis/NIS+LDAPmapping.template) では、LDAP サーバーが RFC 2307 の拡張版 に準拠していることを前提としています。RFC は、 http://www.ietf.org/rfc.html から入手できます。 NIS+ データと LDAP データとのマッピングは、NIS+LDAPmapping(4) を使用して変更できます。ただし、LDAP のデータ編成が RFC 2307 の規定に準拠していることを、基本的な前提としています。
たとえば、LDAP クライアントと NIS+ クライアントとの間でアカウント情報を共有するには、UNIX crypt 書式のアカウント (ユーザー) パスワードを LDAP サーバーに格納できるようにする必要があります。LDAP サーバーをこのように構成できない場合でも、アカウントを含む NIS+ データを LDAP に格納することはできます。 その場合、NIS+ ユーザーと LDAP bindDN との間でアカウント情報を完全に共有することはできません。
Sun ONE Directory Server 5.1 のインストール、設定、および管理の詳細については、「iPlanetTM Directory Server 5.1 Collection」を参照してください。
Sun ONE Directory Server バージョン 5.1 を構成して、LDAP クライアントが LDAP をネームサービスとして使用できる ようにするには、idsconfig(1M) を使用します。idsconfig(1M) を使用して設定した構成は、NIS+ で LDAP データリポジトリを使用する場合にも適しています。
Sun ONE Directory Server 5.1 以外の 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 |
承認されていないアクセスからパスワードを格納するファイルを確実に保護してください。
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+ オブジェクトを 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) に適しています。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+ テーブルエントリを LDAP データから作成するときは、そのエントリオブジェクトが存在するテーブルオブジェクトの対応する値を使用して、所有者、グループ、アクセス権、および TTL を初期化する必要があります。環境によっては、これらの NIS+ エントリ属性を個別に設定する必要があります。たとえば、rpc.nispasswdd(1M) デーモンを使用しない環境では、この操作が必要になります。ユーザー自身が NIS+ パスワードを変更して、cred.org_dir テーブルに格納されている Diffie-Hellman キーを再暗号化できるようにするには、passwd.org_dir および cred.org_dir エントリの所有者をそのユーザーに設定し、その所有者に変更権限を割り当てる必要があります。
1 つ以上の NIS+ テーブルエントリの所有者、グループ、アクセス権、または TTL を 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 ) ) |
cred.org_dir マッピングで、新しく作成した nisplusNetname 属性および nisplusPrincipalName 属性を使用できるようにする必要があります。テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template では、この目的に対応した行がコメントになっています。 credlocal、creduser、および crednode データベース ID については、 nisplusObjectDN、nisplusLDAPattributeFromColumn 属性、および nisplusLDAPcolumnFromAttribute 属性の値を参照してください。マッピングファイルの編集が終了したら、 rpc.nisd デーモンを再起動します。マッピングファイルがデフォルトでない場合は、-m オプションを追加してください。また、rpc.nisd デーモンを NIS (YP) エミュレーションに対応させる場合は、 -Y オプションを追加してください。
# pkill rpc.nisd
# /usr/sbin/rpc.nisd -m mapping-file [-Y]
RFC 2307 では、NIS+ の client_info.org_dir および timezone.org_dir テーブルに保存する情報は規定していません。このため、これらのテーブルのマッピングは、テンプレートマッピングファイル (/var/nis/NIS+LDAPmapping.template) ではデフォルトで無効になっています。client_info および timezone の情報を LDAP に保存する場合は、LDAP サーバーのマニュアルを参照しながら、以降の節で説明する新しい属性とオブジェクトクラスを作成します。
次のような属性とオブジェクトクラスを作成し、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 への移行シナリオ を参照してください。
次のような属性とオブジェクトクラスを作成し、タイムゾーンデータのコンテナを作成します。推奨コンテナ名は 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 オブジェクトクラスの必須属性が cn で、オプション属性が nodeInventory と nodeOwner であるとします。nodeInfo オブジェクトクラスは、この例のための仮想クラスで、RFC では定義されていません。
既存の 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
NIS+ および LDAP の構成情報は、構成ファイルとコマンド行で格納できますが、構成属性は LDAP にも格納できます。構成情報が多くの NIS+ サーバーによって共有され、定期的に変更される場合は、LDAP に格納すると便利です。
構成属性を LDAP に格納するには、LDAP サーバーのマニュアルを参照して、次の新しい属性とオブジェクトクラスを作成します。構成情報は、 rpc.nisd コマンド行または /etc/default/rpc.nisd の nisplusLDAPconfigDN 値に指定された場所に存在することが前提となっています。また、cn が nisplusLDAPbaseDomain 値であることも前提です (LDAP から構成情報を読み込む前に、rpc.nisd デーモンに認識されているため)。
LDIF データは、ldapadd(1) に適用できます。属性とオブジェクトクラス OID は、例として挙げています。
defaultSearchBase、preferredServerList 、およびauthenticationMethod 属性は、「DUA config」スキーマの原案に準拠しています。このスキーマは、IETF 標準となる見込みです。NIS+LDAPmapping(4) で使用する場合は、次の定義で十分です。
dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' \ DESC 'Default LDAP base DN used by a DUA' \ EQUALITY distinguishedNameMatch \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' \ DESC 'Preferred LDAP server host addresses to be used by a DUA' \ EQUALITY caseIgnoreMatch \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' \ DESC 'Identifies the authentication method used to connect to the DSA'\ EQUALITY caseIgnoreMatch \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) |
NIS+ および LDAP の構成属性は、次のようになっています。
dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.0 \ NAME 'nisplusLDAPTLS' \ DESC 'Transport Layer Security' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.1 \ NAME 'nisplusLDAPTLSCertificateDBPath' \ DESC 'Certificate file' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.2 \ NAME 'nisplusLDAPproxyUser' \ DESC 'Proxy user for data store/retrieval' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.3 \ NAME 'nisplusLDAPproxyPassword' \ DESC 'Password/key/shared secret for proxy user' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.4 \ NAME 'nisplusLDAPinitialUpdateAction' \ DESC 'Type of initial update' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.5 \ NAME 'nisplusLDAPinitialUpdateOnly' \ DESC 'Exit after update ?' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.6 \ NAME 'nisplusLDAPretrieveErrorAction' \ DESC 'Action following an LDAP search error' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.7 \ NAME 'nisplusLDAPretrieveErrorAttempts' \ DESC 'Number of times to retry an LDAP search' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.8 \ NAME 'nisplusLDAPretrieveErrorTimeout' \ DESC 'Timeout between each search attempt' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.9 \ NAME 'nisplusLDAPstoreErrorAction' \ DESC 'Action following an LDAP store error' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.10 \ NAME 'nisplusLDAPstoreErrorAttempts' \ DESC 'Number of times to retry an LDAP store' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.11 \ NAME 'nisplusLDAPstoreErrorTimeout' \ DESC 'Timeout between each store attempt' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.12 \ NAME 'nisplusLDAPrefreshErrorAction' \ DESC 'Action when refresh of NIS+ data from LDAP fails' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.13 \ NAME 'nisplusLDAPrefreshErrorAttempts' \ DESC 'Number of times to retry an LDAP refresh' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.14 \ NAME 'nisplusLDAPrefreshErrorTimeout' \ DESC 'Timeout between each refresh attempt' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.15 \ NAME 'nisplusNumberOfServiceThreads' \ DESC 'Max number of RPC service threads' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.16 \ NAME 'nisplusThreadCreationErrorAction' \ DESC 'Action when a non-RPC-service thread creation fails' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.17 \ NAME 'nisplusThreadCreationErrorAttempts' \ DESC 'Number of times to retry thread creation' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.18 \ NAME 'nisplusThreadCreationErrorTimeout' \ DESC 'Timeout between each thread creation attempt' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.19 \ NAME 'nisplusDumpErrorAction' \ DESC 'Action when an NIS+ dump fails' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.20 \ NAME 'nisplusDumpErrorAttempts' \ DESC 'Number of times to retry a failed dump' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.21 \ NAME 'nisplusDumpErrorTimeout' \ DESC 'Timeout between each dump attempt' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.22 \ NAME 'nisplusResyncService' \ DESC 'Service provided during a resync' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.23 \ NAME 'nisplusUpdateBatching' \ DESC 'Method for batching updates on master' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.24 \ NAME 'nisplusUpdateBatchingTimeout' \ DESC 'Minimum time to wait before pinging replicas' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.25 \ NAME 'nisplusLDAPmatchFetchAction' \ DESC 'Should pre-fetch be done ?' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.26 \ NAME 'nisplusLDAPbaseDomain' \ DESC 'Default domain name used in NIS+/LDAP mapping' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.27 \ NAME 'nisplusLDAPdatabaseIdMapping' \ DESC 'Defines a database id for an NIS+ object' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.28 \ NAME 'nisplusLDAPentryTtl' \ DESC 'TTL for cached objects derived from LDAP' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.29 \ NAME 'nisplusLDAPobjectDN' \ DESC 'Location in LDAP tree where NIS+ data is stored' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.30 \ NAME 'nisplusLDAPcolumnFromAttribute' \ DESC 'Rules for mapping LDAP attributes to NIS+ columns' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.18.31 \ NAME 'nisplusLDAPattributeFromColumn' \ DESC 'Rules for mapping NIS+ columns to LDAP attributes' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.42.2.27.5.42.42.19.0 NAME 'nisplusLDAPconfig' \ DESC 'NIS+/LDAP mapping configuration' \ SUP top STRUCTURAL MUST ( cn ) \ MAY ( preferredServerList $ defaultSearchBase $ authenticationMethod $ nisplusLDAPTLS $ nisplusLDAPTLSCertificateDBPath $ nisplusLDAPproxyUser $ nisplusLDAPproxyPassword $ nisplusLDAPinitialUpdateAction $ nisplusLDAPinitialUpdateOnly $ nisplusLDAPretrieveErrorAction $ nisplusLDAPretrieveErrorAttempts $ nisplusLDAPretrieveErrorTimeout $ nisplusLDAPstoreErrorAction $ nisplusLDAPstoreErrorAttempts $ nisplusLDAPstoreErrorTimeout $ nisplusLDAPrefreshErrorAction $ nisplusLDAPrefreshErrorAttempts $ nisplusLDAPrefreshErrorTimeout $ nisplusNumberOfServiceThreads $nisplusThreadCreationErrorAction $ nisplusThreadCreationErrorAttempts $ nisplusThreadCreationErrorTimeout $ nisplusDumpErrorAction $ nisplusDumpErrorAttempts $ nisplusDumpErrorTimeout $ nisplusResyncService $ nisplusUpdateBatching $ nisplusUpdateBatchingTimeout $ nisplusLDAPmatchFetchAction $ nisplusLDAPbaseDomain $ nisplusLDAPdatabaseIdMapping $ nisplusLDAPentryTtl $ nisplusLDAPobjectDN $ nisplusLDAPcolumnFromAttribute ! $ nisplusLDAPattributeFromColumn ) ) |
次の LDIF データを含むファイルを作成します。実際の検索ベースを searchBase に、完全指定ドメイン名を domain に代入します。
dn: cn=domain,searchBase
cn: domain
objectClass: top objectClass: nisplusLDAPconfig
上のファイルを ldapadd(1) の入力として使用し、NIS+ および LDAP の構成エントリを作成します。最初は、エントリは空になっています。ldapmodify(1) を使用して、構成属性を追加します。たとえば、nisplusNumberOfServiceThreads 属性に「32」を設定するには、ldapmodify(1) の入力として次のファイルを作成します。
dn: cn=domain, searchBase nisplusNumberOfServiceThreads: 32