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

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

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

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

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

対象読者

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

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

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

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

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

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

推奨される前提知識

前述の概念についての詳細、また一般的な LDAP とディレクトリサービスの導入について知りたい場合は、次の文書を参照してください。

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

  この本には LDAP ディレクトリサービスの扱い方に関する詳細だけでなく、LDAP を配備する上で役に立つケーススタディが書かれています。配備事例には、大規模な大学、多国籍企業、そしてエクストラネットを使った企業などがあります。

• 『Sun Java System Directory Server 配備ガイド』は Sun Java Enterprise System の文書に収められています。

  このマニュアルでは、基本的なディレクトリ計画 (ディレクトリ設計、スキーマ設計、ディレクトリツリー、トポロジ、複製、およびセキュリティーを含む) が説明されています。最後の章では、単純で小規模な配備計画と、複雑な世界に広がる配備計画の両方のシナリオを説明しています。

• 『Sun Java System Directory Server 管理ガイド』は Sun Java Enterprise System の文書に収められています。

その他の前提条件

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

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

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

LDAP ネームサービスの利点

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

• LDAP を使用すると、異なる複数のネームサービス間でデータを共有できる。

• LDAP により、データの集中的なリポジトリ (格納場所) が提供される。

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

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

LDAP ネームサービスの欠点

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

• Solaris 8 以前のクライアントはサポートしていない。

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

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

• NIS クライアントとネイティブな LDAP クライアントは、同一のクライアントマシン上で共存できない。

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

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

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

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

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

• 「LDAP での完全指定ドメイン名の使用」

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

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

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

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

• 「ldap_cachemgr デーモン」

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

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

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

% ldaplist -l hosts myhost

hosts

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

% ldaplist -l passwd user1

passwd

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

% ldaplist -l services name

services

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

% ldaplist -l group mygroup

group

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

% ldaplist -l netgroup mynetgroup

netgroup

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

% ldaplist -l networks 200.20.20.0

networks

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

% ldaplist -l netmasks 201.20.20.0

netmasks

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

% ldaplist -l rpc ypserv

rpc

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

% ldaplist -l protocols tcp

protocols

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

% ldaplist -l bootparams myhost

bootparams

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

% ldaplist -l ethers myhost

ethers

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

% ldaplist -l publickey myhost

publickey

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

% ldaplist -l aliases myname

aliases

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

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

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

west.example.net

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

server.west.example.net

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

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

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

デフォルトの LDAP スキーマ

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

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

スキーママッピングは、注意深くかつ一貫した方法で使用する必要があります。マッピングされた属性の構文が、マッピング先の属性との一貫性を保持していることを確認してください。つまり、単一値の属性が単一値の属性にマッピングされ、属性の構文が一致しており、マッピングされたオブジェクトクラスが適正な必須 (通常はマッピングされた) 属性を保持することを確認します。

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

SSD の説明

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

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

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

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

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

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

特定のサービスタイプに複数のコンテナを関連付けることも可能です。次の例では、サービス検索記述子が 3 つのコンテナでパスワードエントリを検索することを指定しています。

例の末尾の「,」は、SSD の相対ベースに defaultSearchBase が付加されることを意味します。

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

スキーママップ

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

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

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

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

この属性の書式は、service:attribute-name=mapped-attribute-name です。

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

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

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

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

attributemap: gecos=cn sn title

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

objectClass マップ

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

objectclassMap: passwd:posixAccount=myUnixAccount

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

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

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

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

次の表に、Solaris LDAP クライアントのプロファイル属性を示します。このプロファイル属性は、idsconfig の実行時に自動的に設定されます。クライアントプロファイルを手動で設定する方法については、「クライアントを手動で初期設定する」と idsconfig(1M) のマニュアルページを参照してください。

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

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

Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが使用できます。詳細は、「enableShadowUpdate スイッチ」を参照してください。

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

ldap_cachemgr デーモン

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

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

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

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

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

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

• Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが true に設定されている場合、構成した管理者資格にアクセスし、shadow データの更新を実行します。

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

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

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

はじめに

Solaris LDAP ネームサービスは、LDAP リポジトリを 2 つの異なる方法で使用できます。1 つは、ネームサービスと認証サービスの両方のソースとして使用する方法です。もう 1 つは、厳密にネームデータのソースとして使用する方法です。この節では、LDAP リポジトリをネームサービスと認証サービスの両方のソースとして使用する場合の、クライアント識別情報、認証方式、pam_ldap と pam_unix モジュール、およびアカウント管理の概念について説明します。また、LDAP ネームサービスを Kerberos 環境 (『Solaris のシステム管理 (セキュリティサービス)』のパート VI「Kerberos サービス」) および pam_krb5(5) モジュールと組み合わせて使用する方法についても説明します。

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に Directory Server への認証を実行せずに、アカウントの管理およびユーザーのアカウント状態の取得を実行できるようになりました。Directory Server 上でこの機能を制御するのは、1.3.6.1.4.1.42.2.27.9.5.8 です。これは、デフォルトで有効になっています。

この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

Kerberos を認証システムとして使用し、LDAP ネームシステムに統合する場合は、Kerberos を利用して企業内でシングルサインオン (SSO) 環境を実現できます。また、ユーザーまたはホストごとに LDAP ネームデータのクエリー検索を実行する際にも、同じ識別システムを使用できます。

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

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

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

Kerberos を認証に使用する場合、および LDAP ネームサービス内の認証も有効にする場合 (ユーザー別の認証方式で必要)、Kerberos は二重の機能を提供できます。ディレクトリへの認証に、サーバーへの Kerberos 認証、および主体 (ユーザーまたはホスト) に対する Kerberos 識別情報が使用されます。これにより、システムの認証に使用されるのと同じユーザー識別情報がディレクトリの認証にも使用され、検索と更新が実行されます。管理者は、必要に応じ、アクセス制御情報 (ACI) をディレクトリ内で使用して、ネームサービスで得られる結果を制限できます。

Transport Layer Security (TLS)

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

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

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

TLS を使用する場合は、必要なセキュリティーデータベースをインストールしなければなりません。具体的には証明書ファイルと鍵データベースファイルが必要です。たとえば、Netscape Communicator の古いデータベースフォーマットを使用する場合、cert7.db と key3.db の 2 つのファイルが必要です。あるいは、Mozilla の新しいデータベースフォーマットを使用する場合、cert8.db、key3.db、および secmod.db の 3 つのファイルが必要です。cert7.db ファイルまたは cert8.db ファイルには、信頼された証明書が入ります。key3.db ファイルには、クライアントの鍵が入ります。LDAP ネームサービスクライアントがクライアントの鍵を使用しない場合でも、このファイルは必要です。secmod.db ファイルには、PKCS#11 などのセキュリティーモジュールが入ります。このファイルは、古いフォーマットを使用する場合には必要ありません。

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

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

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

• anonymous

• proxy

• proxy anonymous

• self (このマニュアルでは「ユーザー別」と呼ぶ)

匿名 (anonymous)

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

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

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

プロキシ (Proxy)

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

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

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

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

匿名プロキシ(proxy anonymous)

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

ユーザー別 (Per User)

ユーザー別 (self) の認証では、ディレクトリサーバーの認証時に Kerberos 識別情報 (主体) を使用して各ユーザーまたは各システムの検索が実行されます。ユーザー別の認証では、システム管理者は、アクセス制御情報 (ACI)、アクセス制御リスト (ACL)、役割、グループ、またはその他のディレクトリアクセス制御機構を使用して、特定のユーザーまたはシステムの特定のネームサービスデータへのアクセスを許可または拒否できます。

ユーザー別のモードを設定する場合は、このモードを表す設定値「self」を使用します。

ユーザー別の認証モデルを使用するには、Kerberos シングルサインオンサービスを配備する必要があります。また、配備に使用する 1 つ以上のディレクトリサーバーで SASL および SASL/GSSAPI 認証機構をサポートする必要があります。Kerberos では、ホスト名の検索に LDAP ではなく、ファイルおよび DNS を使用することを前提としているため、この環境には DNS を配備するようにしてください。また、ユーザー別の認証を使用するには、nscd を有効にする必要があります。この構成では、nscd デーモンはオプションの構成要素ではありません。

enableShadowUpdate スイッチ

Solaris 10 10/09 リリース以降では、クライアントで enableShadowUpdate スイッチが true に設定されている場合、管理者資格がシャドウデータの更新に使用されます。シャドウデータは、ディレクトリサーバーの shadowAccount オブジェクトクラスに格納されます。管理者資格は、「ローカルのクライアント属性」で説明しているように、adminDN および adminPassword 属性の値によって定義されます。これらの管理者資格は、それ以外の目的には使用されません。

管理者資格のプロパティーは Proxy 資格のプロパティと類似しています。管理者資格の場合、シャドウデータを読み取ったり更新するには、ユーザーはゾーンのすべての特権を持つか、root の有効な UID を持っている必要があるという例外があります。管理者資格は、ディレクトリへのバインドが許可されるエントリに割り当てることができます。ただし、LDAP サーバーのディレクトリマネージャー識別情報 (cn=Directory Manager) には同じものを使用しないでください。

管理者資格が設定されたこのエントリは、ディレクトリ内のシャドウデータに対する十分な読み取りおよび書き込みアクセスを持っている必要があります。エントリはシステムごとに共有されるリソースであるため、adminDN および adminPassword 属性はクライアントごとに構成する必要があります。暗号化された adminPassword はローカルのクライアントに格納されます。パスワードには、クライアント用に構成された認証方式と同じ方式が使用されます。管理者資格は、シャドウデータの読み取りと更新を行うために、特定のシステムのすべてのユーザーおよびプロセスによって使用されます。

資格の保存

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

同様に、シャドウデータの更新が有効になるようにクライアントを構成し、クライアント資格レベルが self ではない場合、クライアントは adminDN および adminPassword 属性を /var/ldap/ldap_client_cred ファイルに保存します。adminPassword の値も暗号化され、ldap_cachemgr デーモンプロセスによってのみ使用されます。

ユーザー別の認証を使用するようクライアントを構成している場合、認証時に各主体 (各ユーザーまたはホスト) 用の Kerberos 識別情報および Kerberos チケット情報が使用されます。この環境では、ディレクトリサーバーは Kerberos 主体を DN にマッピングします。この DN の認証には、Kerberos 資格が使用されます。次に、ディレクトリサーバーは、必要に応じアクセス制御情報 (ACI) 機構を使用して、ネームサービスデータへのアクセスを許可または拒否します。この状況では、ディレクトリサーバーの認証に Kerberos チケット情報が使用されます。システムが、認証 DN またはパスワードをシステムに保存することはありません。したがって、この種類の構成では、クライアントを ldapclient コマンドを使用して初期化するときに、adminDN および adminPassword 属性を指定する必要はありません。

認証方式の選択

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

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

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

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

• none

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

• simple

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

• sasl/digest-MD5

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

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

  ---

  注 –

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

  ---

• sasl/cram-MD5

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

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

• sasl/GSSAPI

  この認証方式は、ユーザー別の検索を有効にする場合に、self 資格モードとともに使用されます。クライアントの資格を使用するために割り当てられたユーザー別の nscd は、sasl/GSSAPI 方式およびクライアントの Kerberos 資格を使用して、ディレクトリサーバーへのバインドを実行します。ディレクトリサーバーでは、アクセスをユーザー別に制御できます。

• tls:simple

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

• tls:sasl/cram-MD5

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

• tls:sasl/digest-MD5

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

Sun Java System Directory Server で 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) を使用したユーザーの認証に使用されます。

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

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

ユーザー別のモードでは、「pam_krb5 サービスモジュール」 (pam Kerberos) が認証サービスとして使用されます。この操作モードでは、ServiceAuthenticationMethod は不要です。

enableShadowUpdate スイッチを true に設定した場合、ldap_cachemgr デーモンは passwd-cmd の serviceAuthenticationMethod パラメータに定義された認証方式を使用して LDAP サーバーにバインドします (この認証方式が定義されている場合)。このパラメータが存在しない場合、authenticationMethod が使用されます。デーモンは認証方式 none を使用しません。

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

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

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

PAM フレームワークを使用することで、pam_unix、pam_krb5、pam_ldap などの中からサーバー認証サービスを選択できます。

ユーザー別の認証方式を使用する場合、上記の 3 つの認証サービスの中で最も強力な pam_krb5 を有効にする必要があります。pam_krb5(5) および『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

ユーザー別の認証が有効でない場合でも、pam_krb5 認証システムを使用できます。プロキシまたは匿名の資格レベルを使用してディレクトリサーバーのデータにアクセスする場合、ディレクトリデータへのアクセスをユーザーごとに制限することはできません。

匿名またはプロキシ認証方式を使用する場合は、pam_unix を使用するよりも、柔軟性の向上、より強力な認証方式、およびアカウント管理機能を備えた、pam_ldap を使用することをお勧めします。

pam_unix サービスモジュール

pam.conf(4) ファイルを変更していない場合、デフォルトで pam_unix の機能が有効になっています。

pam_unix モジュールは削除されたので、Solaris ではサポートされていません。その他のサービスモジュールによって、同等またはそれ以上の機能が提供されます。したがって、このマニュアルでは、pam_unix は pam_unix モジュールではなくその同等の機能を指します。

pam_unix と同等の機能を提供するモジュールは、次のとおりです。

pam_unix は従来の UNIX 認証モデルに従い、次のように動作します。

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

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

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

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

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

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

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

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

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

Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが true に設定されていると、pam_unix でアカウント管理がサポートされます。リモート LDAP ユーザーアカウントのコントロールは、passwd および shadow ファイルに定義されたローカルユーザーアカウントに適用されるコントロールと同じように適用されます。enableShadowUpdate モードでは、LDAP アカウントについてはシステムが更新を行い、パスワードの有効期限管理とアカウントのロックのために LDAP サーバー上のシャドウデータを使用します。ローカルアカウントのシャドウデータはローカルクライアントシステムに適用されるのに対して、LDAP ユーザーアカウントのシャドウデータはすべてのクライアントシステムのユーザーに適用されます。

パスワードの履歴チェックは、ローカルクライアントに対してのみサポートされ、LDAP ユーザーアカウントに対してはサポートされません。

pam_krb5 サービスモジュール

pam_krb5(5) および『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

pam_ldap サービスモジュール

pam_ldap を実装すると、ユーザーは pam_ldap の serviceAuthenticationMethod パラメータに定義された認証方式を使用して LDAP サーバーにバインドします (このパラメータが存在する場合)。このパラメータが存在しない場合、authenticationMethod が使用されます。

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

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に Directory Server への認証を実行せずに、アカウントの管理およびユーザーのアカウント状態の取得を実行できるようになりました。Directory Server 上でこの機能を制御するのは、1.3.6.1.4.1.42.2.27.9.5.8 です。これは、デフォルトで有効になっています。

この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

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

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

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

次の表に、pam_unix、pam_ldap、および pam_krb5 の主な相違点を示します。

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

パスワードを変更するには、passwd コマンドを使用します。enableShadowUpdate スイッチが true に設定されていない場合、userPassword 属性がユーザーによって書き込み可能である必要があります。enableShadowUpdate スイッチが true に設定されている場合、管理者資格で userPassword 属性を更新できる必要があります。passwd-cmd 用の serviceAuthenticationMethod が、この操作の authenticationMethod を無効にすることに留意してください。使用する認証方式によっては、現行のパスワードの暗号化解除がネットワーク上で行われる場合があります。

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

enableShadowUpdate スイッチが true に設定されている場合、ユーザーのパスワードが変更されると、pam_unix も関連するシャドウ情報を更新します。pam_unix は、ローカルユーザーのパスワードが変更されたときに pam_unix が更新するローカル shadow ファイル内の同じ shadow フィールドを更新します。

Solaris 10 ソフトウェアリリース以降、pam_ldap ではパスワード更新がサポートされません。pam_ldap パスワード更新機能は、以前に推奨されていた pam_authtok_store と server_policy オプションによって置き換えられます。pam_authtok_store を使用すると、新しいパスワードは平文で LDAP サーバーに送信されます。このため、機密性を保つために TLS を使用する必要があります。TLSを使用しない場合、新しい userPassword が漏洩する危険性があります。Sun Java System Directory Server でタグ付けされていないパスワードを設定すると、passwordStorageScheme 属性を使用してパスワードが暗号化されます。passwordStorageScheme の詳細については、ご使用のバージョンの Sun Java System Directory Server の『管理者ガイド』のユーザーアカウントの管理に関する節を参照してください。

passwordStorageScheme 属性を設定する際、次の構成上の問題を考慮する必要があります。pam_unix を使用する NIS、NIS+、またはほかのクライアントがリポジトリとして LDAP を使用する場合、passwordStorageScheme に対して crypt を実行する必要があります。また、Sun Java System Directory Server で sasl/digest-MD5 に対して pam_ldap を使用する場合、passwordStorageScheme を平文に設定する必要があります。

アカウント管理

アカウントおよびパスワードの管理システムとして pam_krb5 を選択すると、アカウント、パスワード、アカウントロックアウト、およびアカウント管理のその他の詳細情報がすべて Kerberos 環境により管理されます。pam_krb5(5) および『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

pam_krb5 を使用しない場合は、LDAP ネームサービスを構成して、Sun Java System Directory Server のパスワードおよびアカウントロックアウトポリシーのサポートを活用できます。pam_ldap(5) を構成して、ユーザーアカウント管理をサポートすることが可能です。passwd(1) を正しい PAM 構成で使用すると、Sun Java System Directory Server パスワードポリシーによるパスワードの構文規則が適用されます。

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

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

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

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

• パスワードの構文チェック

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

• パスワードの履歴チェック

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

• ユーザーアカウントのロックアウト

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

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

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

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

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に Directory Server への認証を実行せずに、アカウントの管理およびユーザーのアカウント状態の取得を実行できるようになりました。Directory Server 上でこの機能を制御するのは、1.3.6.1.4.1.42.2.27.9.5.8 です。これは、デフォルトで有効になっています。

この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

pam_unix を使用したアカウント管理

Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが使用できます。enableShadowUpdate を true に設定すると、LDAP はアカウント管理のファイルネームサービスと同じ機能を提供します。

クライアントで enableShadowUpdate スイッチが true に設定されている場合、ローカルアカウントで使用可能なアカウント管理機能が LDAP アカウントでも使用できます。この機能には、パスワードの有効期限管理、アカウントの有効期限管理および通知、ログインに失敗したアカウントのロックなどが含まれます。また、passwd コマンドの -dluNfnwx オプションが LDAP でサポートされるようになりました。これにより、passwd コマンドの完全な機能と、ファイルネームサービスの pam_unix* モジュールが LDAP ネームサービスでサポートされます。enableShadowUpdate スイッチは、ファイルと LDAP スコープの両方に定義されたユーザーに対して一貫したアカウント管理を実装する 1 つの方法を提供します。

ユーザーが自身のアカウント管理データを変更するのを防ぐため、また、パスワードポリシーを回避するために、LDAP サーバーは、サーバー上にあるユーザー自身のシャドウデータに対するユーザーの書き込みアクセスを防止するように構成されています。管理者資格を持つ管理者は、クライアントシステムに対してシャドウデータの更新を実行します。しかし、この構成は、ユーザーによるパスワードの変更が必要な pam_ldap モジュールと競合してしまいます。したがって、pam_ldap と pam_unix によるアカウント管理には互換性がありません。

同じ LDAP ネームドメインで pam_ldap と pam_unix の両方を使用しないでください。すべてのクライアントが pam_ldap を使用するか、またはすべてのクライアントが pam_unix を使用します。この制限により、専用の LDAP サーバーが必要になる場合があります。たとえば、Web または電子メールアプリケーションでは、ユーザーが LDAP サーバー上にあるパスワードを変更する必要がある場合があります。

また、enableShadowUpdate の実装では、管理者資格 (adminDN と adminPassword ) が、各クライアント上にローカルで格納されている必要があります。adminPassword は暗号化されており、ldap_cachemgr デーモンによって /var/ldap/ldap_client_cred ファイルからのみ読み取りが可能ですが、管理者資格を保護するために細心の注意が必要です。管理者資格を保護するために、サーバーのディレクトリマネージャー (cn=directory manager) とは異なる情報を使用してください。別の保護方法としては、serviceAuthenticationMethod を構成する際に、passwd-cmd サービスに対して tls:simple またはより保護されたレベルを使用します。このようにすることで、adminPassword の値が平文で送信されず、漏洩に対して脆弱になりません。

pam_ldap をアカウント管理に対して使用するのとは異なり、pam_unix をアカウント管理に対して使用する場合は、/etc/pam.conf ファイルの変更は必要ありません。デフォルトの /etc/pam.conf ファイルで十分です。

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

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

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

• 「LDAP の計画の概要」

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

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

• 「LDAP と複製サーバー」

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

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

• 「LDAP データ生成の計画」

LDAP の計画の概要

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

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

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

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

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

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

LDAP ネームサービスは、デフォルトのディレクトリ情報ツリー (DIT) および関連するデフォルトのスキーマを保持します。たとえば、ou=people コンテナには、ユーザーアカウント、パスワード、およびシャドウ情報が含まれます。ou=hosts コンテナには、ネットワーク内のシステムに関する情報が含まれます。ou=people コンテナ内の各エントリは、objectclass の posixAccount および shadowAccount のエントリになります。

デフォルト DIT は、巧みに設計されたディレクトリ構造であり、オープンな標準に基づいています。これは、ほとんどのネームサービスのニーズに応えるもので、変更せずに使用することが推奨されています。デフォルト DIT の使用を選択する場合、決定する必要があるのは、ディレクトリツリー内のどのノード (起点識別名) から、指定されたドメインのネームサービス情報を検索するかという点だけです。このノードは、defaultSearchBase 属性を使用して指定されます。さらに、defaultSearchScope 属性を設定して、ネームサービスが実行する検索範囲をクライアントに指定することもできます。検索範囲には、識別名 (DN) 内の 1 レベルだけを検索するか (one)、DN 内のサブツリー全体を選択するか (sub) を指定できます。

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

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

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

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

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

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

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

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

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

適切なディレクトリ接尾辞の選択方法については、Sun Java System Directory Server (以前の名称は Sun ONE Directory Server) のマニュアルを参照してください。

LDAP と複製サーバー

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

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

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

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

「単一マスター」

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

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

「浮動マスター」

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

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

「複数マスター」

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

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

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

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

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

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に Directory Server への認証を実行せずに、アカウントの管理およびユーザーのアカウント状態の取得を実行できるようになりました。Directory Server 上でこの機能を制御するのは、1.3.6.1.4.1.42.2.27.9.5.8 です。これは、デフォルトで有効になっています。

この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

企業全体のシングルサインオンソリューションとして pam_krb5 および Kerberos を有効にする場合、セッション開始時にのみログインパスワードを必要とするシステムを設計できます。詳細については、『Solaris のシステム管理 (セキュリティサービス)』を参照してください。一般に、Kerberos を有効にする場合には、DNS も有効にする必要があります。詳細については、このマニュアルの DNS に関する章を参照してください。

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

• Kerberos およびユーザー別の認証を使用するか。

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

• TLS を使用するか。

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

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

• アクセス制御情報をどのように設定するか。

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

• アカウント管理を実行するために、クライアントが pam_unix または pam_ldap を使用するか。

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

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

• cn

• defaultServerList

• preferredServerList

• bindTimeLimit

• searchTimeLimit

• profileTTL

• defaultSearchBase

• defaultSearchScope

• serviceSearchDescriptor

• attributeMap

• objectclassMap

• followReferrals

• credentialLevel

• authenticationMethod

• serviceCredentialLevel

• serviceAuthenticationMethod

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

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

LDAP データ生成の計画

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. クライアントマシンで、スーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

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

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

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

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

   パスワードの入力を求められます。

   この例では、ldapaddent は、プロファイル「new」で設定されている認証方式を使用します。「simple」を選択した場合、パスワードは平文で送信されます。詳細については、ldapaddent(1M) のマニュアルページを参照してください。

第 11 章 LDAP クライアントと Sun Java System Directory Server の設定 (手順)

この章では、Sun Java System Directory Server (以前の名称は Sun ONE Directory Server) を構成して、Solaris LDAP ネームサービスクライアントのネットワークをサポートする方法について説明します。この情報は、Sun Java System Directory Server に固有の情報です。ディレクトリサーバーのインストールおよび構成については、Sun Java Enterprise System に収められている Sun Java System Directory Server のマニュアルを参照してください。

Sun Java System Directory Server を構成して Solaris LDAP クライアントを使用する前に、Sun Java System Directory Server に付属するインストールおよび構成のマニュアルで説明されているすべての手順を実行しておく必要があります。

ディレクトリサーバー (LDAP サーバー) をそのクライアントとして使用することはできません。

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

• 「idsconfig を使用した Sun Java System Directory Server の構成」

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

• 「idsconfig の実行」

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

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

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

• 「ディレクトリサーバーを構成してアカウント管理を有効にする」

• 「Sun Java System Directory Server の移行」

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

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

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

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

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

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

属性インデックス

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

membernisnetgroup

pres,eq,sub

nisnetgrouptriple

pres,eq,sub

ipHostNumber

pres,eq,sub

uidNumber

pres,eq

gidNumber

pres,eq

ipNetworkNumber

pres,eq

automountkey

pres,eq

oncRpcNumber

pres,eq

スキーマ定義

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

インデックス表示の使用

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

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

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

idsconfig は、複数の VLV インデックスのエントリを作成します。サーバーを停止し、実際の VLV インデックスを作成するには、directoryserver スクリプトを使用してください。詳細については、idsconfig(1M) および directoryserver(1M) のマニュアルページを参照してください。idsconfig によって作成された VLV エントリと、実行する必要がある、対応する directoryserver コマンドの構文を確認するには、idsconfig コマンドの出力を参照してください。idsconfig 出力の例は、「idsconfig 設定の例」を参照してください。

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

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

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

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

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

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

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

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

  Q  Exit menu
Enter menu choice: [Quit] p

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

Hit return to continue.

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

  Q  Exit menu
Enter menu choice: [Quit] q

idsconfig の実行

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

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

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

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

2. idsconfig を実行します。

   # /usr/lib/ldap/idsconfig

   この章の冒頭の 「サーバーのインストール用チェックリストの作成」で示した、サーバーおよびクライアントのチェックリストの定義を使用した idsconfig の実行例として、例 11–1 を参照してください。

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

   ユーザー入力のデフォルトは「no」です。質問の詳細を表示する場合は、

   h

   と入力します。すると、簡単なヘルプが表示されます。

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

idsconfig 設定の例

この節では、多くのデフォルト値を使用した基本的な idsconfig 設定の例を示します。クライアントプロファイルを変更する最も複雑な方法は、SSD を作成する方法です。詳細については、「サービス検索記述子を使用してさまざまなサービスへのクライアントアクセスを変更する」を参照してください。

プロンプトの後ろにある [ ] 内のデータは、そのプロンプトのデフォルト値を表しています。デフォルト値を使用する場合は、Return キーを押します。

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

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

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

次の例では、サーバーインスタンスが LDAP サーバーに作成された直後に、idsconfig ユーティリティーが実行されます。

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

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

Do you wish to continue with server setup (y/n/h)? [n] y
Enter the JES Directory Server's  hostname to setup: myserver
Enter the port number for iDS (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]
  Checking LDAP Base DN ...
  Validating LDAP Base DN and Suffix ...
  No valid suffixes were found for Base DN dc=west,dc=example,dc=com
Enter suffix to be created (b=back/h=help): [dc=west,dc=example,dc=com]
Enter ldbm database name (b=back/h=help): [west]
  sasl/GSSAPI is not supported by this LDAP server
Enter the profile name (h=help): [default] WestUserProfile
Default server list (h=help): [192.168.0.1]
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
  4  self
  5  self proxy
  6  self 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
  6  sasl/GSSAPI
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]
Do you want to modify the server timelimit value (y/n/h)? [n] y
Enter the time limit for iDS (current=3600): [-1]
Do you want to modify the server sizelimit value (y/n/h)? [n] y
Enter the size limit for iDS (current=2000): [-1]
Do you want to store passwords in "crypt" format (y/n/h)? [n] y
Do you want to setup a Service Authentication Methods (y/n/h)? [n]
Client search time limit in seconds (h=help): [30]
Profile Time To Live in seconds (h=help): [43200]
Bind time limit in seconds (h=help): [10]
Do you want to enable shadow update (y/n/h)? [n]
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
         Suffix to create          : dc=west,dc=example,dc=com
         Database to create        : west
  3  Profile name to create        : WestUserProfile
  4  Default Server List           : 192.168.0.1
  5  Preferred Server List         :
  6  Default Search Scope          : one
  7  Credential Level              : proxy
  8  Authentication Method         : simple
  9  Enable Follow Referrals       : FALSE
 10  iDS Time Limit                : -1
 11  iDS Size Limit                : -1
 12  Enable crypt password storage : TRUE
 13  Service Auth Method pam_ldap  :
 14  Service Auth Method keyserv   :
 15  Service Auth Method passwd-cmd:
 16  Search Time Limit             : 30
 17  Profile Time to Live          : 43200
 18  Bind Limit                    : 10
 19  Enable shadow update          : FALSE
 20  Service Search Descriptors Menu

Enter config value to change: (1-20 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. Database west successfully created.
  7. Suffix dc=west,dc=example,dc=com successfully created.
  8. NisDomainObject added to dc=west,dc=example,dc=com.
  9. Top level "ou" containers complete.
  10. automount maps: auto_home auto_direct auto_master auto_shared processed.
  11. ACI for dc=west,dc=example,dc=com modified to disable self modify.
  12. Add of VLV Access Control Information (ACI).
  13. Proxy Agent cn=proxyagent,ou=profile,dc=west,dc=example,dc=com added.
  14. Give cn=proxyagent,ou=profile,dc=west,dc=example,dc=com read permission 
      for password.
  15. Generated client profile and loaded on server.
  16. Processing eq,pres indexes:
      uidNumber (eq,pres)   Finished indexing.
      ipNetworkNumber (eq,pres)   Finished indexing.
      gidnumber (eq,pres)   Finished indexing.
      oncrpcnumber (eq,pres)   Finished indexing.
      automountKey (eq,pres)   Finished indexing.
  17. Processing eq,pres,sub indexes:
      ipHostNumber (eq,pres,sub)   Finished indexing.
      membernisnetgroup (eq,pres,sub)   Finished indexing.
      nisnetgrouptriple (eq,pres,sub)   Finished indexing.
  18. Processing VLV indexes:
      west.example.com.getgrent vlv_index   Entry created
      west.example.com.gethostent vlv_index   Entry created
      west.example.com.getnetent vlv_index   Entry created
      west.example.com.getpwent vlv_index   Entry created
      west.example.com.getrpcent vlv_index   Entry created
      west.example.com.getspent vlv_index   Entry created
      west.example.com.getauhoent vlv_index   Entry created
      west.example.com.getsoluent vlv_index   Entry created
      west.example.com.getauduent vlv_index   Entry created
      west.example.com.getauthent vlv_index   Entry created
      west.example.com.getexecent vlv_index   Entry created
      west.example.com.getprofent vlv_index   Entry created
      west.example.com.getmailent vlv_index   Entry created
      west.example.com.getbootent vlv_index   Entry created
      west.example.com.getethent vlv_index   Entry created
      west.example.com.getngrpent vlv_index   Entry created
      west.example.com.getipnent vlv_index   Entry created
      west.example.com.getmaskent vlv_index   Entry created
      west.example.com.getprent vlv_index   Entry created
      west.example.com.getip4ent vlv_index   Entry created
      west.example.com.getip6ent vlv_index   Entry created

idsconfig: Setup of iDS server myserver is complete.


Note: idsconfig has created entries for VLV indexes.

      For DS5.x, use the directoryserver(1m) script on myserver
      to stop the server.  Then, using directoryserver, follow the
      directoryserver examples below to create the actual VLV indexes.

      For DS6.x, use dsadm command delivered with DS6.x on myserver
      to stop the server.  Then, using dsadm, follow the
      dsadm examples below to create the actual VLV indexes.

  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getgrent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.gethostent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getnetent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getpwent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getrpcent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getspent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getauhoent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getsoluent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getauduent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getauthent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getexecent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getprofent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getmailent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getbootent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getethent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getngrpent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getipnent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getmaskent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getprent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getip4ent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getip6ent

  <install-path>/bin/dsadm reindex -l -t west.example.com.getgrent <directory-instance-path> 
   dc=west,dc=example,dc=com
  <install-path>/bin/dsadm reindex -l -t west.example.com.gethostent <directory-instance-path> 
   dc=west,dc=example,dc=com
  .
  .
  .
  <install-path>/bin/dsadm reindex -l -t west.example.com.getip6ent <directory-instance-path> 
   dc=west,dc=example,dc=com

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

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

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

ldapaddent(1M) は LDAP クライアント上でのみ実行できます。LDAP ネームサービス用のクライアントの構成方法については、第 12 章LDAP クライアントの設定 (手順)を参照してください。

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

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

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

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

プリンタエントリの管理

プリンタの追加

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

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

lpget の使用

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

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

# lpget -n ldap list
myprinter:
	dn=myprinter,ou=printers,dc=mkt,dc=example,dc=com
	bsdaddr=printsvr.example.com,myprinter,Solaris
	description=HP LaserJet (PS)

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

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

   # ldapclient genprofile \ -a profileName=myprofile \ -a defaultSearchBase=dc=west,dc=example,dc=com \ -a "defaultServerList=192.168.0.1 192.168.0.2:386" \

   > myprofile.ldif

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

   # ldapadd -h 192.168.0.1 -D “cn=directory manager” -f myprofile.ldif

ディレクトリサーバーを構成してアカウント管理を有効にする

Solaris 10 10/09 リリース以降では、pam_ldap を使用するクライアントと pam_unix を使用するクライアントに対してアカウント管理を実装できます。

同じ LDAP ネームドメインで pam_ldap と pam_unix の両方を使用しないでください。すべてのクライアントが pam_ldap を使用するか、またはすべてのクライアントが pam_unix を使用します。この制限により、専用の LDAP サーバーが必要になる場合があります。

pam_ldap を使用するクライアントの場合

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

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に Directory Server への認証を実行せずに、アカウントの管理およびユーザーのアカウント状態の取得を実行できるようになりました。Directory Server 上でこの機能を制御するのは、1.3.6.1.4.1.42.2.27.9.5.8 です。これは、デフォルトで有効になっています。

この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

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

pam_unix を使用するクライアントの場合

Solaris LDAP クライアントがアカウント管理に対して pam_unix を使用できるようにするには、シャドウデータの更新を有効にするようにサーバーを設定する必要があります。この機能は、Solaris 10 10/09 リリース以降で使用できます。pam_ldap アカウント管理とは異なり、pam_unix は追加の構成手順が必要がありません。すべての構成は、idsconfig ユーティリティーを実行して行うことができます。基本的な idsconfig の実行については、例 11–1を参照してください。

次に 2 つの idsconfig 実行の出力を示します。

最初の idsconfig 実行では、既存のクライアントプロファイルを使用します。

# /usr/lib/ldap/idsconfig

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

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

Do you wish to continue with server setup (y/n/h)? [n] y
Enter the JES Directory Server's  hostname to setup: myserver
Enter the port number for iDS (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]
  Checking LDAP Base DN ...
  Validating LDAP Base DN and Suffix ...
  sasl/GSSAPI is not supported by this LDAP server

Enter the profile name (h=help): [default] WestUserProfile

Profile 'WestUserProfile' already exists, it is possible to enable
shadow update now. idsconfig will exit after shadow update
is enabled. You can also continue to overwrite the profile
or create a new one and be given the chance to enable
shadow update later.

Just enable shadow update (y/n/h)? [n] y
Add the administrator identity (y/n/h)? [y]
Enter DN for the administrator: [cn=admin,ou=profile,dc=west,dc=example,dc=com]
Enter passwd for the administrator: 
Re-enter passwd: 
  ADDED: Administrator identity cn=admin,ou=profile,dc=west,dc=example,dc=com.
         Proxy ACI LDAP_Naming_Services_proxy_password_read does not 
         exist for dc=west,dc=example,dc=com.
  ACI SET: Give cn=admin,ou=profile,dc=west,dc=example,dc=com read/write access 
           to shadow data.
  ACI SET: Non-Admin access to shadow data denied.

  Shadow update has been enabled.

2 つ目の idsconfig 実行では、後で使用するための新しいプロファイルを作成します。出力の一部のみが表示されています。

# /usr/lib/ldap/idsconfig

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

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

Do you wish to continue with server setup (y/n/h)? [n] y
Enter the JES Directory Server's  hostname to setup: myserver
Enter the port number for iDS (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]
  Checking LDAP Base DN ...
  Validating LDAP Base DN and Suffix ...
  sasl/GSSAPI is not supported by this LDAP server

Enter the profile name (h=help): [default] WestUserProfile-new
Default server list (h=help): [192.168.0.1]
.
.
.
Do you want to enable shadow update (y/n/h)? [n] y

              Summary of Configuration

  1  Domain to serve               : west.example.com
  2  Base DN to setup              : dc=west,dc=example,dc=com
         Suffix to create          : dc=west,dc=example,dc=com
  3  Profile name to create        : WestUserProfile-new
.
.
.
 19  Enable shadow update          : TRUE
.
.
.
Enter DN for the administrator: [cn=admin,ou=profile,dc=west,dc=example,dc=com]
Enter passwd for the administrator:
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.
.
.
.
  11. ACI for dc=test1,dc=mpklab,dc=sfbay,dc=sun,dc=com modified to 
      disable self modify.
.
.
.
  15. Give cn=admin,ou=profile,dc=west,dc=example,dc=com write permission for shadow.
...

Sun Java System Directory Server の移行

Sun Java System Directory Server 5.1 (以前の名称は Sun ONE Directory Server) リリースと Sun Java System Directory Server 5.2 リリース間のスキーマ変更が実装されました。ldapaddent コマンドは、ethers/bootparams のエントリに objectclass: device を追加します。したがって、LDAP コマンドを使用してディレクトリデータを Sun Java System Directory Server 5.1 から 5.2 に移行する場合、ldapaddent -d を使用してデータをエクスポートし、ldapaddent を使用してデータをインポートする必要があります。あるいは、Sun Java System Directory Server ツール db2ldif および ldif2db を使用してデータを移行する場合、データの移行の前にすべてのパッチを Sun Java System Directory Server 5.2 に適用する必要があります。パッチを適用しないと、データのインポートに失敗する可能性があります。

Sun Java System Directory Server 5.2 の構成については、Sun Java Enterprise System に収められている Sun Java System Directory Server のマニュアルを参照してください。

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

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

• 「LDAP クライアント設定の前提条件」

• 「LDAP とサービス管理機能」

• 「LDAP クライアントの初期化」

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

• 「LDAP クライアント環境のカスタマイズ」

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

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

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

• nsswitch.conf ファイルが、必要なサービスの LDAP を指している

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

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

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

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

LDAP とサービス管理機能

LDAP クライアントサービスは、サービス管理機能を使用して管理されます。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。

• このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。

  ---

  ヒント –

  -t オプションを使用してサービスを一時的に無効化すると、そのサービス構成に対していくらかの保護を提供できます。-t オプションを指定してサービスを無効にした場合、リブート後に元の設定が復元されます。-t オプションを指定しないでサービスを無効にした場合、リブート後もそのサービスは無効のままです。

  ---

• LDAP クライアントサービスに対する障害管理リソース識別子 (FMRI) は、svc:/network/ldap/client:<instance> です。

• svcs コマンドを使用することによって、LDAP クライアントおよび ldap_cachemgr の状態を照会できます。

  • svcs コマンドと出力の例を、次に示します。

    # svcs \*ldap\* STATE STIME FMRI online 15:43:46 svc:/network/ldap/client:default

  • svcs -l コマンドと出力の例を、次に示します。次に示す出力を得るには、FMRI でインスタンス名を使用する必要があります。

    # svcs -l network/ldap/client:default fmri svc:/network/ldap/client:default enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 1598 dependency require_all/none file://localhost/var/ldap/ldap_client_file (-) dependency require_all/none svc:/network/initial (online) dependency require_all/none svc:/system/filesystem/minimal (online)

• デーモンの存在は ps コマンドを使用して確認できます。

  # ps -e | grep slapd root 23320 1 0 Aug 27 ? 16:30 ./ns-slapd -D \ /usr/iplanet/ds5/slapd-lastrev -i /usr/iplanet/ds5/slapd-lastrev/ root 25367 25353 0 15:35:19 pts/1 0:00 grep slapd

  ---

  注 –

  -f オプションを ps で使用しないでください。このオプションはユーザー ID を名前に変換しようとするため、より多くのネームサービス検索が失敗する可能性があります。

  ---

LDAP クライアントの初期化

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

Solaris オペレーティングシステムは、NIS クライアントとネイティブな LDAP クライアントが同一のクライアントマシン上に共存する構成をサポートしません。

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

• 「プロファイル」

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

  Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが使用できます。シャドウデータの更新を有効にするには、管理者資格 (adminDN と adminPassword) を入力する必要があります。

• 「手動」

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

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

   # ldapclient init \ -a profileName=new \ -a domainName=west.example.com 192.168.0.1 System successfully configured

ユーザー別の資格を使用する

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

ユーザー別の資格を使用してクライアントを初期化する方法

始める前に

ユーザー別の資格を使用してクライアントを設定する前に、次の項目が構成済みである必要があります。

• 1 つ以上の Kerberos KDC サーバーが構成され、稼働している

• DNS、DNS サーバーへのクライアントアクセス、および 1 つ以上の DNS サーバーが構成され、稼働している

• クライアントマシン上の Kerberos が構成され、有効にされている

• Kerberos クライアントのインストールプロファイルが存在している。次にプロファイルの例を示す

  # cat /usr/tmp/krb5.profile REALM SPARKS.COM KDC kdc.example.com ADMIN super/admin FILEPATH /usr/tmp/krb5.conf NFS 1 DNSLOOKUP none

• LDAP サーバーがインストールおよび構成され、sasl/GSSAPI がサポートされている

• 適切な識別情報マッピング構成が存在する

• ディレクトリサーバーおよび KDC 用の Kerberos ホスト主体が KDC 内で設定されている

• 使用するディレクトリサーバー DIT 上で idsconfig が稼働している

• ユーザー別の適切な gssapi プロファイル (gssapi_EXAMPLE.COM など) が作成済みである

  次に、idsconfig で表示されるユーザー別プロファイルの例の一部を示します。

  # /usr/lib/ldap/idsconfig Do you wish to continue with server setup (y/n/h)? [n] y Enter the iPlanet Directory Server's (iDS) hostname to setup: kdc.example.com Enter the port number for iDS (h=help): [389] <Enter your port> Enter the directory manager DN: [cn=Directory Manager] <Enter your DN> Enter passwd for cn=Directory Manager : <Enter your password> Enter the domainname to be served (h=help): [example.com] <Enter your domain> Enter LDAP Base DN (h=help): [dc=example,dc=com] <Enter your DN> GSSAPI is supported. Do you want to set up gssapi:(y/n) [n] y Enter Kerberos Realm: [EXAMPLE.COM] EXAMPLE.COMYou can create a sasl/GSSAPI enabled profile with default values now. Do you want to create a sasl/GSSAPI default profile ? [n] y Enter. the profile name (h=help): [gssapi_EXAMPLE.COM] <Enter> GSSAPI setup is done. ...

• 必須のユーザー主体が鍵配布センター (KDC) 内に存在する

• クライアントマシン上で、次に示すようなコマンドにより、クライアントプロファイルを使って Kerberos が初期化される

  # /usr/sbin/kclient -p /usr/tmp/krb5.profile

• /etc/nsswitch.ldap が、hosts および ipnodes 用の dns を使用するように構成される。必要に応じ、エディタを使用してこのファイルを次のように修正します。

  host: files dns ipnodes: files dns

• /etc/resolv.conf が構成され、dns サービスが稼働している。詳細は、このマニュアルの DNS に関する章を参照してください。

• ディレクトリサーバー DIT が、(少なくとも) このクライアントマシンのユーザー、クライアントホスト、および必須の auto_home LDAP エントリで読み込み済みである。ldapaddent を使用してエントリを追加する方法については、このマニュアルのほかの節を参照してください。

1. ldapclient init を実行し、gssapi プロファイルを使用してクライアントを初期化します。

   # /usr/sbin/ldapclient init -a profilename=gssapi_SPARKS.COM -a \ domainname=example.com 9.9.9.50

2. ユーザーとしてログインを試みます。

   kinit -p user を実行します。

   ユーザーのログインセッションで ldaplist -l passwd user を実行します。「userpassword」が表示されるはずです。

   一方、ldaplist -l passwd bar を実行すると、userpassword なしでエントリを取得できます。デフォルトでは、root はすべてのユーザーの userpassword を引き続き表示できます。

ユーザー別の資格の使用について

• syslog でメッセージ libsldap: Status: 7 Mesg: openConnection: GSSAPI bind failed - 82 Local error が表示される場合、Kerberos が初期化されていないか、チケットの有効期限が切れていることが考えられます。klist を実行して、表示される内容を確認します。kinit -p foo または kinit -R -p foo を実行して、再度試みてください。

• 必要に応じて、pam_krb5.so.1 を /etc/pam.conf に追加することで、ログイン時に kinit を自動的に実行できます。

• 次に例を示します。

  login auth optional pam_krb5.so.1 rlogin auth optional pam_krb5.so.1 other auth optional pam_krb5.so.1

• ユーザーが kinit され、syslog メッセージに Invalid credential が表示される場合は、原因として、ホストのエントリ (root) かユーザーエントリが LDAP ディレクトリ内に存在しない、またはマッピング規則が正しくないことが考えられます。

• ldapclient init の実行時に、LDAP プロファイルに self/ sasl/GSSAPI 構成が含まれるかどうかがチェックされます。/etc/nsswitch.ldap のチェックに失敗する場合の一般的な原因は、dns が host: および ipnodes: に追加されていないことです。

• DNS クライアントが有効でないために失敗する場合は、svcs -l dns/client を実行して、/etc/resolv.conf が存在しないのか、単に無効になっているのかを確認します。これを有効にするには、svcadm enable dns/client を実行します。

• sasl/GSSAPI バインドが原因でチェックが失敗する場合は、syslog で問題の箇所を確認します。

詳細については、このマニュアルのほかの箇所および『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

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

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

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

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

LDAP でのシャドウ更新を有効にする

Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが使用できます。

クライアントを初期化してシャドウデータの更新を有効にする方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

2. enableShadowUpdate スイッチを設定し、管理者資格を定義するには、ldapclient コマンドを実行します。

   • 既に実行中のクライアントを更新するには、次のコマンドを使用します。

     # ldapclient mod -a enableShadowUpdate=TRUE \ -a adminDN=cn=admin,ou=profile,dc=west,dc=example,dc=com \ -a adminPassword=admin-password System successfully configured

   • クライアントを初期化するには、次のコマンドを使用します。

     # ldapclient init \ -a adminDN=cn=admin,ou=profile,dc=west,dc=example,dc=com \ -a adminPassword=admin-password -a domainName=west.example.com \ -a profileName=WestUserProfile \ -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \ -a proxyPassword=i<proxy_password> \ 192.168.0.1 System successfully configured

3. 構成を検証するには、/var/ldap/ldap_client_cred ファイルの内容を表示します。

   出力には、次のような行を含むべきです。

   # cat /var/ldap/ldap_client_cred NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788f8eb85de11 NS_LDAP_ENABLE_SHADOW_UPDATE= TRUE NS_LDAP_ADMIN_BINDDN= cn=admin,ou=profile,dc=west,dc=example,dc=com NS_LDAP_ADMIN_BINDPASSWD= {NS1}4a3788f8c053434f

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

2. ldapclient manual を実行してクライアントを初期化します。

   # ldapclient manual \ -a domainName=dc=west.example.com \ -a credentialLevel=proxy \ -a defaultSearchBase=dc=west,dc=example,dc=com \ -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \ -a proxyPassword=testtest 192.168.0.1

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

2. ldapclient mod コマンドを使用して、認証方法を simple に変更します。

   # ldapclient mod -a authenticationMethod=simple

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

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

注意事項

LDAP クライアント設定には、mod サブコマンドでは変更できない属性があります。たとえば、profileName 属性や profileTTL 属性は変更できません。これらの属性を変更するには、「プロファイルを使用してクライアントを初期化する」で説明されているように、ldapclient init コマンドを使用して新しいプロファイルを作成します。「クライアントを手動で初期設定する」で説明されているように、ldapclient manual コマンドを実行することもできます。

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

2. ldapclient uninit を実行します。

   # ldapclient uninit System successfully recovered

TLS のセキュリティーの設定

セキュリティーデータベースファイルは、すべてのユーザーから読み取れるようにする必要があります。key3.db に非公開鍵を含めないようにしてください。

TLS を使用する場合は、必要なセキュリティーデータベースをインストールしなければなりません。具体的には証明書ファイルと鍵データベースファイルが必要です。たとえば、Netscape Communicator の古いデータベースフォーマットを使用する場合、cert7.db と key3.db の 2 つのファイルが必要です。あるいは、Mozilla の新しいデータベースフォーマットを使用する場合、cert8.db、key3.db、および secmod.db の 3 つのファイルが必要です。cert7.db ファイルまたは cert8.db ファイルには、信頼された証明書が入ります。key3.db ファイルには、クライアントの鍵が入ります。LDAP ネームサービスクライアントがクライアントの鍵を使用しない場合でも、このファイルは必要です。secmod.db ファイルには、 PKCS#11 などのセキュリティーモジュールが入ります。このファイルは、古いフォーマットを使用する場合には必要ありません。

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

これらのファイルを作成および管理する方法については、ご使用のバージョンの Sun Java System Directory Server の『管理者ガイド』の「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 ディレクトリで管理し、Mozilla は cert8.db ファイル、key3.db ファイル、および secmod.db ファイルを $HOME/.mozilla のサブディレクトリで管理します。このため、それらのセキュリティーデータベースを LDAP ネームサービスクライアントで使用する場合は、そのコピーをローカルファイルシステム上に格納する必要があります。

PAM を構成する

pam_ldap は、LDAP の認証およびアカウント管理用 PAM モジュールオプションの 1 つです。pam_ldap で現在サポートされている機能の詳細については、pam_ldap(5) のマニュアルページと付録 A Solaris 10 ソフトウェアの DNS、NIS、および LDAP の更新を参照してください。

ユーザー別モードと自己資格オプションの両方を選択した場合は、PAM Kerberos pam_krb5(5) pam モジュールも有効にする必要があります。詳細については、pam_krb5(5) のマニュアルページおよび『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

UNIX policy を使用するための PAM の構成

UNIX policy を使用するように PAM を構成するには、「pam_ldap に対応した pam.conf ファイルの例」に示す例に従ってください。pam_ldap.so.1 を含む行をクライアントの /etc/pam.conf ファイルに追加します。詳細については、pam.conf(4) のマニュアルページを参照してください。

LDAP server_policy を使用するための PAM の構成

LDAP server_policy を使用するように PAM を構成するには、「アカウント管理のために pam_ldap を構成した 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 オプションを追加します。

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に Directory Server への認証を実行せずに、アカウントの管理およびユーザーのアカウント状態の取得を実行できるようになりました。Directory Server 上でこの機能を制御するのは、1.3.6.1.4.1.42.2.27.9.5.8 です。これは、デフォルトで有効になっています。

この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

• binding 管理フラグ

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

• server_policy オプション

  server_policy オプションによって、pam_unix_auth、 pam_unix_account、および pam_passwd_auth は LDAP 名前空間で検出されたユーザーを無視し、pam_ldap による認証やアカウント検証が可能になります。pam_authtok_store は、新しいパスワードを暗号化せずに LDAP サーバーに渡します。そのため、パスワードはサーバー上で構成されるパスワードの暗号化方式に基づいたディレクトリに保存されます。詳細については、pam.conf(4) および pam_ldap(5) のマニュアルページを参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# ldaplist -l passwd user1dn: 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

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

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

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

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

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

LDAP で DNS を有効にする

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

hosts:      ldap dns [NOTFOUND=return] files

推奨構成を次に示します。

hosts: files dns

ipnodes: files dns

ユーザー別の認証を使用する場合、sasl/GSSAPI および Kerberos 機構は dns ネームサービスが構成され、有効になっていることを前提に動作します。詳細については、この管理ガイドの DNS に関する章を参照してください。

第 13 章 LDAP のトラブルシューティング (参照情報)

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

LDAP サービスはサービス管理機能によって管理されます。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。LDAP でこの機能を使用する場合の詳細については、「LDAP とサービス管理機能」を参照してください。この機能の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。

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

以降の節では、LDAP クライアント環境の状態判定に使用するさまざまなコマンドを紹介します。使用可能なオプションの詳細については、マニュアルページも参照してください。

サービス管理機能の概要は、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。

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

ldap_cachemgr デーモンは、常に実行中で適切に機能している必要があります。このデーモンが機能していない場合、システムは動作しません。LDAP クライアントを起動すると、ldap_cachemgr デーモンが自動的に起動します。したがって、ldap_cachemgr が実行されていない場合は、LDAP クライアントが使用不能になります。LDAP クライアントがオンラインであるかどうかを確認する 2 つの方法を次に示します。

• svcs コマンドを使用します。

  # svcs \*ldap\* STATE STIME FMRI disabled Aug_24 svc:/network/ldap/client:default

  または

  # svcs -l network/ldap/client:default fmri svc:/network/ldap/client:default enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 1598 dependency require_all/none file://localhost/var/ldap/ldap_client_file (-) dependency require_all/none svc:/network/initial (online) dependency require_all/none svc:/system/filesystem/minimal (online)

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

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

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

スーパーユーザーになるか、同等の役割になり、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.1, 192.168.0.10
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.1
NS_LDAP_PROFILE= pit1
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:ou=group,dc=west,dc=example,dc=com?one
NS_LDAP_BIND_TIME= 5

/var/ldap ファイルは現在 ASCII 形式ですが、バイナリに変更される可能性があるため、このファイルを連結すると問題が発生する可能性があります。この情報へのアクセスにサポートされている方式は、ldapclient list です。詳細については、ldapclient(1M) のマニュアルページを参照してください。

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

クライアントが LDAP サーバーに対して通信を行なっていることを確認する最善の方法は、ldaplist コマンドを使用することです。引数を付けずに ldaplist だけを指定して実行すると、サーバー上のすべてのコンテナがダンプされます。この方法はコンテナが存在している限り可能で、コンテナを生成する必要がありません。詳細については、ldaplist(1) のマニュアルページを参照してください。

最初の手順が成功したら、ldaplist passwd username または ldaplist hosts hostname を実行できますが、大量のデータが含まれている場合には、生成量の少ないサービスを選ぶか、head や more コマンドを使用してデータをパイプ処理することもできます。

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

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

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

Solaris 9 およびそれ以前のリリースでは、ldapsearch コマンドはデフォルトで、非標準のテキスト表現で出力を生成していました。それより後の Solaris リリースの ldapsearch のデフォルト出力は、RFC-2849 で定義されている業界標準の LDIF フォーマットです。ldapsearch のすべてのバージョンで、-L オプションを使用することによって LDIF フォーマットを出力できます。

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

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

未解決のホスト名

Solaris プラットフォームの LDAP クライアントバックエンドは、ホストの検索で、gethostbyname() や getaddrinfo() で返されるホスト名のような、完全指定ホスト名を返します。格納済みの名前が指定されている (1 つ以上のドットが含まれている) 場合、クライアントはその名前をそのまま返します。たとえば、格納されている名前が hostB.eng であれば、返される名前も hostB.eng です。

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

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

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

ログインできない

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

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

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

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

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

5. パスワードが定義されていない

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

6. LDAP サーバーに到達することができない

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

   # /usr/lib/ldap/ldap_cachemgr -g

7. pam.conf の構成が不正である

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

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

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

11. アカウント管理をサポートするように pam_ldap が構成されている場合は、次のいずれかの原因でログインに失敗します。

    • ユーザーのパスワード期限が切れている

    • ログインを何回も行ったために、ユーザーアカウントがロックされる

    • 管理者がユーザーアカウントを非アクティブにした

    • rsh、rlogin、ssh、sftp などのパスワードを使用しないプログラムによってユーザーがログインしようとした

12. ユーザー別の認証および sasl/GSSAPI を使用している場合、一部の Kerberos コンポーネントまたは pam_krb5 構成が正しく設定されません。この問題を解決する方法については、『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

検索が遅い

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

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

profileName 属性を指定して init オプションを使用すると、ldapclient がクライアントの初期化に失敗することがあります。考えられる失敗の原因は次のとおりです。

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

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

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

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

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

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

デバッグに ldap_cachemgr を使用する

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

# ldap_cachemgr -g

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

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

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

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

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

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

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

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

3. 「LDAP コマンド」

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

5. 「アカウント管理のために pam_ldap を構成した pam.conf ファイル例」

6. 「LDAP 用の IETF スキーマ」

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

8. 「Solaris スキーマ」

9. 「LDAP 用の Internet Printing Protocol 情報」

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

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

記入用のチェックリスト

LDAP のアップグレード情報

この節では、Solaris 8 リリースから Solaris 9 以降のリリースにアップグレードする際の考慮事項について説明します。

互換性

Solaris 9 以降の Solaris ソフトウェアリリースで構成されたクライアントは、バージョン 1 のプロファイルのみに対応する Solaris 8 クライアント用に設定されたディレクトリサーバーと完全な互換性があります。ただし、Solaris 9 以降のリリースで導入された新しい機能を利用し、新しいセキュリティーモデルを使用するには、バージョン 2 のプロファイルを使用する必要があります。

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

ldap_cachemgr デーモンの実行

Solaris 9 リリース以降では、ldap_cachemgr デーモンを常に実行している必要があります。このデーモンは、クライアントが適正に動作するために「必須」です。サービス管理機能の svcadm コマンドを使用して LDAP クライアントを起動すると、ldap_cachemgr デーモンが自動的に起動します。詳細については、ldap_cachemgr(1M) のマニュアルページを参照してください。

新しい automount スキーマ

Solaris 9 リリース以降、Solaris ソフトウェアは、automount エントリ用の新しいスキーマをデフォルトで使用します。この新しいスキーマは、Solaris 8 クライアントが使用していた汎用の NIS マップスキーマに置き換わります。このため Solaris 9 以降のソフトウェアツールを使用してサーバーを設定した場合、Solaris 8 クライアントから automount エントリを表示できなくなります。サイトで Solaris 8 クライアントとそれ以降の Solaris ソフトウェアクライアントの両方に対応するサーバーを設定する場合、自動マウントエントリを追加する前に、プロファイルを作成してスキーマを以前のスキーマに対応づけてください。この操作により、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

pam_ldap の変更点

Solaris 10 OS リリースでは、pam_ldap が次に示すように変更されました。詳細については、pam_ldap(5) のマニュアルページも参照してください。

• 以前サポートされていた use_first_pass および try_first_pass のオプションは、Solaris 10 ソフトウェアリリースでサポートされなくなりました。このオプションは不要のため pam.conf から削除しても問題はなく、そのままにしておいても構いません。将来のリリースで削除されることもあります。

• パスワードプロンプトに対応する必要があります。これは、認証およびパスワードモジュールのスタックで pam_ldap の前に pam_authtok_get をスタックし、passwd サービスの auth スタックに pam_passwd_auth を含めることによって行います。

• 以前サポートされていたパスワード更新機能は、以前使用が推奨されていた、pam_authtok_store と server_policy オプションにこのリリースで置き換わります。

このリリースにアップグレードしても、既存の pam.conf ファイルは自動的に更新されず、上記の変更は反映されません。既存の pam.conf ファイルに pam_ldap の構成が含まれる場合は、アップグレード後で CLEANUP ファイルによって通知できます。pam.conf ファイルを調べて、必要に応じて変更してください。

パスワードプロンプトおよびパスワード更新を主とする上記の変更に対して完全な自動更新ができないのは、同じスタックで使用されるその他のモジュールとの関係のためと、Sun 以外のモジュールがあるためです。

詳細については、pam_passwd_auth(5)、pam_authtok_get(5)、pam_authtok_store(5)、および pam.conf(4) のマニュアルページを参照してください。

LDAP コマンド

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

一般的な LDAP ツール

LDAP コマンド行ツールは、認証やバインドパラメータを含む、一般的なオプションセットをサポートします。次のツールは、LDAP データ交換フォーマット (LDIF) というディレクトリ情報を表現する共通のテキストベース書式をサポートします。これらのコマンドを使用して、ディレクトリエントリを直接操作できます。

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

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

#
# 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 required		pam_unix_cred.so.1
login	auth sufficient		pam_unix_auth.so.1
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 required		pam_unix_cred.so.1
rlogin	auth sufficient		pam_unix_auth.so.1
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_cred.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 sufficient		pam_unix_auth.so.1
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 required		pam_unix_cred.so.1
other	auth sufficient		pam_unix_auth.so.1
other	auth required		pam_ldap.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd	auth sufficient		pam_passwd_auth.so.1
passwd	auth required		pam_ldap.so.1
#
# cron service (explicit because of non-usage of pam_roles.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_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 requisite	pam_authtok_get.so.1
other	password requisite	pam_authtok_check.so.1
other	password required	pam_authtok_store.so.1
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#

アカウント管理のために pam_ldap を構成した pam.conf ファイル例

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に Directory Server への認証を実行せずに、アカウントの管理およびユーザーのアカウント状態の取得を実行できるようになりました。Directory Server 上でこの機能を制御するのは、1.3.6.1.4.1.42.2.27.9.5.8 です。これは、デフォルトで有効になっています。

この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

#
# 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_unix_cred.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 required         pam_unix_cred.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_cred.so.1
rsh     auth binding          pam_unix_auth.so.1 server_policy
rsh     auth required         pam_ldap.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 required         pam_unix_cred.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_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 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 and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#

LDAP 用の IETF スキーマ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メールエイリアススキーマ

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

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

メールエイリアス属性を次に示します。

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

メールエイリアス objectClass を次に示します。

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

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

DUAConfSchemaOID は、1.3.6.1.4.1.11.1.3.1 です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Solaris スキーマ

Solaris プラットフォームに必要なスキーマを次に示します。

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

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

• プリンタスキーマ

Solaris プロジェクトスキーマ

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

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

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

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

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

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

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

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

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

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

役割によるアクセス制御属性を次に示します。

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

役割によるアクセス制御 objectClassses を次に示します。

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

LDAP 用の Internet Printing Protocol 情報

以降の節では、Internet Printing Protocol と Sun プリンタの属性と ObjectClasses について説明します。

Internet Print Protocol (IPP) 属性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Internet Print Protocol (IPP) ObjectClasses

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

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

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

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

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

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

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

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

Sun プリンタ属性

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


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

Sun プリンタ ObjectClasses

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

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

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

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

• 仮想リスト表示制御

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

  anonymous

  simple

  sasl/cram-MD5

  sasl/digest-MD5

  sasl/GSSAPI

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

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

sasl/GSSAPI を使用する場合、サーバーは SASL、GSSAPI、Kerberos 5 認証をサポートする必要があります。ネットワーク上の GSS 暗号化のサポートは、オプションです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 「NIS から LDAP への移行サービスの設定」

• 「Sun Java System Directory Server を使用した NIS から LDAP への移行の最良の実践原則」

• 「NIS から LDAP への移行に関する制限」

• 「NIS から LDAP への移行のトラブルシューティング」

• 「NIS に戻す方法」

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

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

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

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

• LDAP ディレクトリ情報ツリー (DIT) 内に NIS マップをインポートする

• NIS の速度および拡張性を維持しつつ、クライアントから DIT 情報にアクセスする

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

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

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

• 「この章の対象読者」

• 「NIS から LDAP への移行サービスを使用しない場合」

• 「NIS から LDAP への移行サービスがユーザーに与える影響」

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

• 「NIS から LDAP への移行コマンド、ファイル、およびマップ」

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

NIS から LDAP への移行用ツールとサービス管理機能

NIS と LDAP のサービスはサービス管理機能によって管理されます。これらのサービスに関する有効化、無効化、再起動などの管理アクションは、svcadm コマンドを使用して実行できます。svcs コマンドを使用してサービスの状態を照会できます。LDAP および NIS での SMF の使用の詳細については、「LDAP とサービス管理機能」および「NIS とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。

この章の対象読者

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

• NIS の概要については、第 4 章ネットワーク情報サービス (NIS) (概要)。

• LDAP の概要については、第 8 章LDAP ネームサービスの紹介 (概要/リファレンス)。

NIS から LDAP への移行サービスを使用しない場合

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

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

  このような環境では、N2L サーバーは、過度に複雑な NIS マスターサーバーとして機能します。

• NIS ソースファイルを変更するツール (yppasswd 以外のツール) で NIS マップを管理している環境。

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

• NIS クライアントのない環境。

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

NIS から LDAP への移行サービスがユーザーに与える影響

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

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

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

N2L サービスの実装に関連する用語を次に示します。

NIS から LDAP への移行コマンド、ファイル、およびマップ

N2L の移行に関連して 2 つのユーティリティー、2 つの構成ファイル、および 1 つのマッピングがあります。

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

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

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

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

NIS から LDAP への移行時に、yppasswdd デーモンは、N2L 固有のマップ ageing.byname を使用して、 DIT でのパスワード有効期限情報の読み取りと書き込みを行います。パスワード有効期限を使用していない場合は、ageing.byname マッピングは無視されます。

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

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

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

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

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

• システムで LDAP ディレクトリサーバーを構成していること

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

  その他の (他社製の) の LDAP サーバーが、N2L サービスで動作する場合もありますが、Sun はそれらをサポートしていません。Sun Java System Directory Server または Sun 互換サーバー以外の LDAP サーバーを使用している場合は、N2L サービスを設定する前に、RFC 2307 (またはその後継) スキーマをサポートするようにサーバーを手動で構成してください。

• nsswitch.conf ファイルで少なくとも hosts エントリおよび ipnodes エントリに対して、検索順序として nis の前に files がリストされていることを確認すること

• N2L マスターサーバーと LDAP サーバーのアドレスが、N2L マスターサーバー上の hosts ファイルまたは ipnodes ファイルに存在することを確認すること。ローカルホスト名を解決するためのシステムの構成方法に応じて、サーバーアドレスは hosts ファイル、ipnodes ファイル、またはその両方にリストされる必要があります。

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

NIS から LDAP への移行サービスの設定

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

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

• 作成する構成ファイルの名前 (デフォルト = /etc/default/ypserv)

• LDAP の構成情報を格納する DN (デフォルト = ypserv)

• LDAP との間でデータをマッピングするための優先サーバーリスト

• LDAP との間でデータをマッピングするための認証方式

• LDAP との間でデータをマッピングするための TLS (Transport Layer Security)

• LDAP との間でデータを読み書きするためのプロキシのユーザーバインド DN

• LDAP との間でデータを読み書きするためのプロキシのユーザーパスワード

• LDAP バインド動作のタイムアウト値 (秒単位)

• LDAP 検索動作のタイムアウト値 (秒単位)

• LDAP 変更動作のタイムアウト値 (秒単位)

• LDAP 追加動作のタイムアウト値 (秒単位)

• LDAP 削除動作のタイムアウト値 (秒単位)

• LDAP サーバーでの検索動作の制限時間 (秒単位)

• LDAP サーバーでの検索動作の制限サイズ (バイト単位)

• N2L が LDAP 照会に従うかどうか

• LDAP 検索のエラー処理、検索試行回数、および各試行間のタイムアウト (秒単位)

• 格納のエラー処理、検索試行回数、および各試行間のタイムアウト (秒単位)

• マッピングファイル名

• auto_direct マップのマッピング情報を生成するかどうか

  スクリプトは、マッピングファイル内の適切な位置にカスタムマップについての情報を配置します。

• ネーミングコンテキスト

• パスワードの変更を有効にするかどうか

• 任意のマップのデフォルトの TTL 値を変更するかどうか

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

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

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

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

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

2. NIS マスターサーバーで、スーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

3. NIS マスターサーバーを N2L サーバーに変換します。

   # inityp2l

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

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

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

   NISLDAPmapping ファイルにリストされたすべてのマップの配備に必要な情報がすでに DIT 内に存在する場合、DIT は完全に初期化されています。

   • 初期化されていない場合、手順 5 を続行して手順 6 をスキップします。

   • 初期化されている場合、手順 5 をスキップして手順 6 に進みます。

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

   DIT が完全に初期化されていない場合に限って、次の手順を実行してください。

   1. 以前の NIS マップが最新の状態になっていることを確認してください。

      # cd /var/yp # make

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

   2. NIS デーモンを停止します。

      # svcadm disable network/nis/server:default

   3. 以前のマップを DIT にコピーしてから、マップ用の N2L サポートを初期化します。

      # ypserv -Ir

      ypserv が終了するまで待ちます。

      ---

      ヒント –

      元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。

      ---

   4. NIS デーモンを起動し、デーモンが新しいマップを使用していることを確認します。

      # svcadm enable network/nis/server:default

      これで、標準マップでの N2L サービスの設定を完了します。手順 6 を行う必要はありません。

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

   DIT が完全に初期化され、手順 5 をスキップした場合に限って、次の手順を実行してください。

   1. NIS デーモンを停止します。

      # svcadm disable network/nis/server:default

   2. DIT 内の情報に従って NIS マップを初期化します。

      # ypserv -r

      ypserv が終了するまで待ちます。

      ---

      ヒント –

      元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。

      ---

   3. NIS デーモンを起動し、デーモンが新しいマップを使用していることを確認します。

      # svcadm enable network/nis/server:default

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

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

• 「サポートされる標準マッピング」にリストされていないマップがある

• RFC 2307 とは異なるマッピングで LDAP にマップしたい標準の NIS マップがある

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

2. NIS マスターサーバーで、スーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

3. NIS マスターサーバーを N2L サーバーに構成します。

   # inityp2l

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

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

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

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

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

   NISLDAPmapping ファイルにリストされたすべてのマップの配備に必要な情報がすでに DIT 内に存在する場合、DIT は完全に初期化されています。

   • 初期化されていない場合、手順 6、手順 8、および手順 9 を完了します。

   • 初期化されている場合、手順 6 をスキップして、手順 7、手順 8、および手順 9 を完了します。

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

   1. 以前の NIS マップが最新の状態になっていることを確認してください。

      # cd /var/yp # make

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

   2. NIS デーモンを停止します。

      # svcadm disable network/nis/server:default

   3. 以前のマップを DIT にコピーしてから、マップ用の N2L サポートを初期化します。

      # ypserv -Ir

      ypserv が終了するまで待ちます。

      ---

      ヒント –

      元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。

      ---

   4. NIS デーモンを起動し、デーモンが新しいマップを使用していることを確認します。

      # svcadm enable network/nis/server:default

   5. 手順 7 をスキップして、手順 8 から続行します。

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

   DIT が完全に初期化されている場合に限って、この手順を実行します。

   1. NIS デーモンを停止します。

      # svcadm disable network/nis/server:default

   2. DIT 内の情報に従って NIS マップを初期化します。

      # ypserv -r

      ypserv が終了するまで待ちます。

      ---

      ヒント –

      元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。

      ---

   3. NIS デーモンを起動し、デーモンが新しいマップを使用していることを確認します。

      # svcadm enable network/nis/server:default

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

   エントリが間違っている場合、LDAP ネームサービスクライアントからはそのエントリを見つけられません。

   # ldapsearch -h server -s sub -b "ou=servdates, dc=..." \ "objectclass=servDates"

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

   次に、makedbm を使用して servdate.bynumber マップの内容を確認する方法の例を示します。

   # makedbm -u LDAP_servdate.bynumber plato: 1/3/2001 johnson: 2/4/2003,1/3/2001 yeats: 4/4/2002 poe: 3/3/2002,3/4/2000

   出力結果が期待どおりの内容であれば、NIS から LDAP への移行は成功です。

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

カスタムマップの例

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

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

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

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

変更前:

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

変更後:

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

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

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

元は、次のようでした。

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

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

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

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

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

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

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

nisLDAPentryTtl servdate.bynumber:1800:5400:3600

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

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

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

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

Sun Java System Directory Server を使用した NIS から LDAP への移行の最良の実践原則

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

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

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

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

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

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

• Sun Java System Directory Server では、 nsslapd-sizelimit 属性を 50000 以上、または -1 に設定する必要があります。idsconfig(1M) のマニュアルページを参照してください。

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

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

標準マップ用 VLV

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

• Sun Java System Directory Server を使用している場合

• 標準マップを RFC 2307 LDAP エントリにマッピングしている場合

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

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

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

• Sun Java System Directory Server を使用している場合

• 大規模なカスタムマップがあるか、非標準の DIT 位置にマップされる標準のマップがある場合

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

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

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

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

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

dn: cn=config
nsslapd-timelimit: -1

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

LDAP での Sun Java System Directory Server の構成の詳細については、第 11 章LDAP クライアントと Sun Java System Directory Server の設定 (手順)を参照してください。

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

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

1. たとえば、クライアント検索照会に返されるエントリの最大数を増やすには、次の属性を修正します。

   dn: cn=config nsslapd-sizelimit: -1

2. クライアント検索照会で確認されるエントリの最大数を増やすには、次の属性を修正します。

   dn: cn=config, cn=ldbm database, cn=plugins, cn=config nsslapd-lookthroughlimit: -1

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

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

LDAP での Sun Java System Directory Server の構成の詳細については、第 11 章LDAP クライアントと Sun Java System Directory Server の設定 (手順)を参照してください。

NIS から LDAP への移行に関する制限

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

NIS から LDAP への移行のトラブルシューティング

この節では、トラブルシューティングの 2 つの領域を説明します。

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

• 「NIS から LDAP への移行に関する問題」

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

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

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

Administrative limit exceeded

エラー番号: 11




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




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

Invalid DN Syntax

エラー番号: 34




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




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

Object class violation

エラー番号: 65




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

• 見つからない属性のエントリを作成する NISLDAPmapping ファイルのバグ

• 存在しないオブジェクトへの AUXILIARY 属性の追加の試み

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




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

Can't contact LDAP server

エラー番号: 81




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




対策 :

• ypserv ファイルを再構成して、正しい LDAP ディレクトリサーバーを指定します。

• LDAP サーバーが実行中であることを確認するには、ディレクトリサーバーでスーパーユーザーになるか、同等の役割になり、次のように入力します。

  # pgrep -l slapd

Timeout

エラー番号: 85




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




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

NIS から LDAP への移行に関する問題

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

NISLDAPmapping ファイルのデバッグ

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

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

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




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




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

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

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




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

• LDAP サーバーと通信できない

• NIS マップまたは DIT 内のエントリが、指定されたマッピングと互換性がない

• LDAP サーバーへの読み書きの試みがエラーを返す




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

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

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




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




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

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

   Sun Java System Directory Server を使用している場合は、directoryserver startconsole を実行して管理コンソールを起動します。

2. 新しく生成されたマップと元のマップを比較して、/var/yp ディレクトリの N2L バージョンの NIS マップに期待どおりのエントリが含まれていることをチェックします。必要に応じてエントリを修正します。

   # cd /var/yp/domainname # makedbm -u test.byname # makedbm -u LDAP_test.byname

   マップの出力をチェックする場合は、次のことに注意してください。

   • 両方のファイルでのエントリの順序が異なる可能性

     出力を比較する前に、sort コマンドを使用します。

   • 両方のファイルでの空白の使い方が異なる可能性

     出力を比較するときに、diff -b コマンドを使用します。

NIS マップの処理順序

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




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

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




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

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

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

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

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




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




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

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

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




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




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

# svcadm disable network/nis/server:default # rm /var/run/yp_maplock /var/run/yp_mapupdate # svcadm enable network/nis/server:default

N2L のデッドロックの問題

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




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

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

1. NIS クライアントが IP アドレスの検索を試みます。

2. N2L サーバーが、hosts エントリは最新ではないことを検出します。

3. N2L サーバーが LDAP からの hosts エントリの更新を試みます。

4. N2L サーバーは、ypserv から LDAP サーバーの名前を取得してから、libldap を使用して検索を実行します。

5. libldap は、ネームサービススイッチを呼び出して、LDAP サーバー名の IP アドレスへの変換を試みます。

6. ネームサービススイッチの設定に基づき、N2L サーバーへの NIS 呼び出しを行い、デッドロックが発生します。




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

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

NIS に戻す方法

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

2. NIS デーモンを停止します。

   # svcadm disable network/nis/server:default

3. N2L を無効にします。

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

   # mv /var/yp/NISLDAPmapping backup_filename

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

   # NOPUSH=1

5. 以前のソースに基づいて、NIS マップの新しいセットを作成します。

   # cd /var/yp # make

6. (オプション) N2L バージョンの NIS マップを削除します。

   # rm /var/yp/domainname/LDAP_*

7. NIS デーモンを起動します。

   # svcadm enable network/nis/server:default

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

2. NIS デーモンを停止します。

   # svcadm disable network/nis/server:default

3. DIT に基づいてマップを更新します。

   # ypserv -r

   ypserv が終了するまで待ちます。

4. N2L を無効にします。

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

   # mv /var/yp/NISLDAPmapping backup_filename

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

   # ypmap2src

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

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

8. (オプション) N2L バージョンのマッピングファイルを削除します。

   # rm /var/yp/domainname/LDAP_*

9. NIS デーモンを起動します。

   # svcadm enable network/nis/server:default

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

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

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

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

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

LDAP に対するデータのマッピングは、構成ファイルの柔軟な構文を使用して行います。client_info.org_dir および timezone.org_dir 以外のすべての標準 NIS+ テーブルは、テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template で対応できます。ほとんどの NIS+ インストールのテーブルは、変更する必要がないか、わずかな変更で済みます(「client_info および timezone テーブル (NIS+ から LDAP への移行)」 と timezone.org_dir については、client_info and timezone Tables (NIS+ to LDAP)を参照)。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) のマニュアルページを参照してください。マッピングファイルの名前を変更するときは、/lib/svc/method/nisplus ファイルを編集します。詳細については、「NIS+ から LDAP への移行用ツールとサービス管理機能」を参照してください。

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

• コンテナ

  すべての関連エントリが格納される 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 つの構成ファイルを使用して、rpc.nisd 処理を制御します。

• /etc/default/rpc.nisd

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

• /var/nis/NIS+LDAPmapping

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

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

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

2. 構成ファイル

3. LDAP

NIS+ から LDAP への移行用ツールとサービス管理機能

NIS+ から LDAP への移行に関連するコマンド行管理タスクの大部分は、サービス管理機能によって管理されます。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。

• NIS+ から LDAP への移行サービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できる

  ---

  ヒント –

  -t オプションを使用してサービスを一時的に無効化すると、そのサービス構成に対していくらかの保護を提供できます。-t オプションを指定してサービスを無効にした場合、リブート後に元の設定が復元されます。-t オプションを指定しないでサービスを無効にした場合、リブート後もそのサービスは無効のままです。

  ---

• NIS+ の障害管理リソース識別子 (FMRI) は、svc:/network/rpc/nisplus: <instance> です。LDAP クライアントサービスの FMRI は、svc:/network/ldap/client: <instance> です。

• svcs コマンドを使用して NIS+ の状態を照会できる。

  • svcs コマンドと出力の例を、次に示します。

  # svcs \*nisplus\* STATE STIME FMRI online Sep_01 svc:/network/rpc/nisplus:default

• svcs -l コマンドと出力の例を、次に示します。次に示す出力を得るには、FMRI でインスタンス名を使用する必要があります。

  # svcs -l network/rpc/nisplus:default fmri svc:/network/rpc/nisplus:default enabled false state disabled next_state none restarter svc:/system/svc/restarter:default dependency require_all/none svc:/network/rpc/keyserv (online)

• デーモンの存在は ps コマンドを使用して確認できます。

  # ps -e | grep rpc.nisd root 23320 1 0 Aug 27 ? 16:30 ./ns-slapd -D \ /usr/iplanet/ds5/slapd-lastrev -i /usr/iplanet/ds5/slapd-lastrev/ root 25367 25353 0 15:35:19 pts/1 0:00 grep slapd

  ---

  注 –

  -f オプションを ps で使用しないでください。このオプションはユーザー ID を名前に変換しようとするため、より多くのネームサービス検索が失敗する可能性があります。

  ---

NIS+ から LDAP への移行で SMF を使用しない場合

通常、/usr/sbin/rpc.nisd デーモンは、svcadm コマンドを使用して管理します。ただし、rpc.nisd デーモンは、-x nisplusLDAPinitialUpdateOnly=yes を指定して起動すると、指定された初期更新アクションを実行して終了します。つまり、rpc.nisd はデーモン化されません。-x nisplusLDAPinitialUpdateOnly=yes を指定した上で、サービス管理機能を使用してはなりません。それ以外の場合で、rpc.nisd デーモンを起動、停止または再起動するときにはいつでも SMF を使用できます。

次の例は、-x nisplusLDAPinitialUpdateOnly=yes を指定した rpc.nisd です。

# /usr/sbin/rpc.nisd -m mappingfile \
-x nisplusLDAPinitialUpdateAction=from_ldap \
-x nisplusLDAPinitialUpdateOnly=yes

/lib/svc/method/nisplus ファイルの変更

rpc.nisd デーモンをサービス管理機能によって起動するときに特定のオプションを含める場合、svcprop コマンドを使用するか、/lib/svc/method/nisplus ファイルを変更できます。svcprop コマンドの使用方法の詳細については、svcprop(1) のマニュアルページを参照してください。/lib/svc/method/nisplus ファイルを変更する手順を次に示します。

/lib/svc/method/nisplus ファイルの変更方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

2. NIS+ サービスを停止します。

   # svcadm disable network/rpc/nisplus:default

3. /lib/svc/method/nisplus ファイルを開きます。

   任意のエディタを使用してください。

4. ファイルを編集して必要なオプションを追加します。

   変更前:

   if [ -d /var/nis/data -o -d /var/nis/$hostname ]; then /usr/sbin/rpc.nisd || exit $

   変更後:

   if [ -d /var/nis/data -o -d /var/nis/$hostname ]; then /usr/sbin/rpc.nisd -Y -B || exit $?

   この例では、-Y および -B オプションが rpc.nisd に追加され、起動時に自動的に実装されます。

5. /lib/svc/method/nisplus ファイルを保存して終了します。

6. NIS+ サービスを開始します。

   # svcadm enable network/rpc/nisplus:default

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

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

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

この方法は、Sun Java System Directory Server で機能します。また、その他の LDAP サーバーでも機能することがあります。

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

NIS+ から LDAP への移行の開始前に必要な処置

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

/etc/default/rpc.nisd ファイル

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

一般的な構成

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

• nisplusNumberOfServiceThreads

• nisplusThreadCreationErrorAction

• nisplusThreadCreationErrorAttempts

• nisplusThreadCreationErrorTimeout

• nisplusDumpErrorAction

• nisplusDumpErrorAttempts

• nisplusDumpErrorTimeout

• nisplusResyncService

• nisplusUpdateBatching

• nisplusUpdateBatchingTimeout

LDAP からの構成データ

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

• nisplusLDAPconfigDN

• nisplusLDAPconfigPreferredServerList

• nisplusLDAPconfigAuthenticationMethod

• nisplusLDAPconfigTLS

• nisplusLDAPconfigTLSCertificateDBPath

• nisplusLDAPconfigProxyUser

• nisplusLDAPconfigProxyPassword

サーバーの選択

• preferredServerList

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

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

認証とセキュリティー

• authenticationMethod

• nisplusLDAPproxyUser

• nisplusLDAPproxyPassword

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

• nisplusLDAPTLS

• nisplusLDAPTLSCertificateDBPath

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

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

• defaultSearchBase

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

• nisplusLDAPbaseDomain

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

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

• nisplusLDAPbindTimeout

• nisplusLDAPmodifyTimeout

• nisplusLDAPaddTimeout

• nisplusLDAPdeleteTimeout

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

• nisplusLDAPsearchTimeout

• nisplusLDAPsearchTimeLimit

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

• nisplusLDAPsearchSizeLimit

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

• nisplusLDAPfollowReferral

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

エラー処理

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

• nisplusLDAPinitialUpdateAction

• nisplusLDAPinitialUpdateOnly

• nisplusLDAPretrieveErrorAction

• nisplusLDAPretrieveErrorAttempts

• nisplusLDAPretrieveErrorTimeout

• nisplusLDAPstoreErrorAction

• nisplusLDAPstoreErrorAttempts

• nisplusLDAPstoreErrorTimeout

• nisplusLDAPrefreshErrorAction

• nisplusLDAPrefreshErrorAttempts

• nisplusLDAPrefreshErrorTimeout

一般的な LDAP 処理の制御

• nisplusLDAPmatchFetchAction

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

/var/nis/NIS+LDAPmapping ファイル

デフォルトの NIS+LDAPmapping ファイルは、NIS+ および LDAP マッピングのマスタースイッチとして機能します。

デフォルト以外のマッピングファイルを使用する場合、-m mappingfile オプションを使用して /lib/svc/method/nisplus スクリプトを編集し、rpc.nisd 行にマッピングファイル名を指定する必要があります。詳細については、「NIS+ から LDAP への移行用ツールとサービス管理機能」を参照してください。

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

nisplusLDAPdatabaseIdMapping 属性

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

たとえば、次のように指定します。

nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir

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

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

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

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

nisplusLDAPentryTtl 属性

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

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

nisplusLDAPentryTtl	rpc_table:21600:43200:43200

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

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

nisplusLDAPentryTtl	rpc:1800:3600:3600

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

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

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

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

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

nisplusLDAPobjectDN 属性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nisplusLDAPattributeFromColumn 属性

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

nisplusLDAPcolumnFromAttribute 属性

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

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

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

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

defaultSearchBase の値を dc=some,dc=domain とすると、対応する LDAP エントリは、ldapsearch(1) で次のように表示されます。

dn: cn=nisd,ou=Ppc,dc=some,dc=domain
cn: nisd
cn: rpc.nsid
cn: nisplusd
oncRpcNumber: 100300
description: NIS+ server
objectClass: oncRpc

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

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

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

cn=nisd,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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