LDAP ディレクトリの NIS 情報
LDAP ディレクトリにインポートする NIS 情報は、標準の NIS ファイルやユーザー独自のファイルから抽出します。Sun Directory Services では、標準の NIS 情報から LDAP 属性へマッピングが可能です。デフォルトの nis.mapping ファイルには、次の NIS ファイルの情報をマッピングする方法が記載されています。
-
aliases
-
bootparams
-
ethers
-
group
-
hosts
-
netgroup
-
networks
-
passwd
-
protocols
-
rpc
-
ypservers
デフォルトの nis.mapping ファイルには、次の標準 NIS ファイルと、NIS Makefile にリストされている独自の NIS ファイルに対するマッピング定義はありません。これらのファイルに対するマッピング定義は、dsypinstall を実行して NIS サービスを初期設定すると自動的に作成されます。
-
auto_home
-
auto_master
-
netid
-
netmasks
-
publickey
-
services
-
timezone
これらのファイルと独自のファイルに対するマッピング定義は総称的なもので、どのマップでも同じです。違いはマップ名だけです。
表 6-2 は、LDAP エントリの種類と場所を NIS マップごとに示します。nis.mapping ファイルのマッピング定義を構成する方法については、「NIS 情報のマッピング」を参照してください。
表 6-2 NIS または LDAP マッピングの要約|
NIS ソースファイル |
NIS マップ |
作成されるエントリのオブジェクトクラス |
作成されるエントリの名前付きコンテキスト |
|---|---|---|---|
|
/etc/mail/aliases |
mail.aliases, mail.byaddr |
nisMailAlias |
ou=Aliases, ou=Services |
|
/etc/bootparams |
bootparams |
bootableDevice |
ou=Hosts, ou=Services |
|
/etc/ethers |
ethers.byaddr, ethers.byname |
ieee802Device |
ou=Hosts, ou=Services |
|
/etc/group |
group,byname, group.bygid |
posixGroup |
ou=Group, ou=Services |
|
/etc/hosts |
hosts.byaddr, hosts.byname |
ipHost |
ou=Hosts, ou=Services |
|
/etc/netgroup |
netgroup |
nisNetGroup |
ou=Netgroup, ou=Services |
|
netgroup.byhost |
nisObject |
ou=netgroup.byhost, ou=Services |
|
|
netgroup.byuser |
nisObject |
ou=netgroup.byuser, ou=Services |
|
|
/etc/networks |
networks.byname, networks.byaddr |
ipNetwork |
ou=Networks, ou=Services |
|
/etc/passwd |
passwd.byname, passwd.byuid |
posixAccount |
ou=People |
|
/etc/protocols |
protocols.byname, protocols.bynumber |
ipProtocol |
ou=Protocols, ou=Services |
|
/etc/rpc |
rpc.bynumber |
oncRpc |
ou=rpc, ou=Services |
|
/var/yp/binding/domainName |
ypservers |
sunNisServer |
ou=ypservers, ou=Services |
|
makefile にリストされているその他のすべてのマップ |
mapName |
nisObject |
ou=mapName, ou=Services |
NIS 名前付きコンテキスト
LDAP ディレクトリにインポートされる情報は、NIS の初期設定段階で、図 6-4 のツリー構造に従って編成されます。この図で ou=mapName は、nis.mapping ファイルに定義されていないマップ (たとえば、services.byname) を表します。
図 6-4 NIS 情報のツリー構造
このツリー構造を必要に応じて構成するには、マッピングファイル /etc/opt/SUNWconn/ldap/current/mapping/nis.mapping を変更します。
NIS 情報のマッピング
NIS テーブルのエントリから LDAP 属性へマッピングするための情報は、/etc/opt/SUNWconn/ldap/current/mapping/nis.mapping ファイルに定義します。このファイルは、各 NIS テーブルのマッピング情報を定義する個別のセクションに分割されます。ファイルの始めには構成情報を定義する「Common」セクションがあり、すべてのテーブルに適用されます。
nis.mapping ファイルは、次の構成要素によって使用されます。
-
dsimport ユーティリティ。NIS ファイルから情報を抽出し、LDAP ディレクトリのエントリに変換する場合
-
dsexport ユーティリティ。LDAP エントリから情報を抽出し、NIS ファイルを元の書式で復元する場合
-
dsservd デーモン。LDAP エントリを NIS テーブルのエントリに変換する場合。dsservd デーモンは、LDAP データベースにあるすべての NIS テーブルの最新コピーを維持し、従来の NIS スレーブからの同期要求に応じます。
-
dsypxfrd デーモン。同期要求で指定されたテーブルがマッピングファイルでサポートされているかどうかを検査する場合
nis.mapping ファイルのマッピング定義では、次の項目を指定します。
-
ディレクトリにエントリを作成する場合に使われるオブジェクトクラスと属性
-
エントリがその下に作成される名前付きコンテキスト
-
エントリの検索でディレクトリサーバーが大文字と小文字を区別するかどうか
オブジェクトクラスと属性
NIS ファイルから作成するエントリのオブジェクトクラスと属性は、そのテーブル用のマッピング定義の「Import」または「Build」セクションにリストされます。「Build」セクションの LDAP 属性に割り当てる値は、テーブル定義の他のセクションに指定したトークンからとられます。
NIS Makefile にリストされているファイルのうち、nis.mapping ファイルに特定のマッピング定義がないものには、総称マッピングが適用されます。このマッピングでは、ファイルから NIS キーと NIS 値の情報が抽出され、次の総称的な NISobject オブジェクトクラスに基づいて次のようにエントリが作成されます。
|
cn |
nisKey (LDAP 検索で大文字と小文字を区別する) |
|
sunNisKey |
nisKey |
|
nisMapEntry |
nisValue |
|
nisMapName |
makefile で宣言されたマップ名 |
|
objectClass |
top |
|
nisSunObject |
マッピングファイルに記述されたすべての標準 NIS テーブルに対して作成されるオブジェクトクラスと属性を次に示します。ここでは、aliases ファイルのマッピングだけを詳しく説明します。
aliases
aliases ファイルのエントリは、通常、次の書式になっています。
aliasname: mailaddress1, mailaddress2, mailaddress3...
nis.mapping ファイルでは、この行のマッピングは次のようになっています。
Table: mail.aliases
...
Import:
Extract:
LINE =>$aliasNameT:$aliasListT
Condense:
rfc822mailMembersT=string2instances($aliasListT,",")
trimrfc822mailMembersT=trim($rfc822mailMembersT)
objectClassT=string2instances("top nisMailAlias", " ")
Build:
dn=cn=$aliasNameT,$BASE_DN
cn=$aliasNameT
rfc822mailMember=$trimrfc822mailMembersT
objectClass=$objectClassT
「Extract」セクションのキーワード LINE は、aliases ファイルの行の初期分解を表します。aliases ファイルでコロン以外の句読記号で別名と別名リストを区切っている場合は、ファイル書式に合わせて LINE 定義を変更する必要があります。
「Condense」セクションの rfc822mailMembersT のトークン定義では、別名リストの次の段階の分解を行います。aliases ファイルでコンマ以外の句読記号で別名リストの各要素を区切っている場合は、ファイル書式に合わせてトークン定義を変更する必要があります。
trimrfc822mailMemberT のトークン定義では、別名リストに対して前に行なった string2instances 操作の結果から不要な空白を取り除きます。
objectClassT のトークン定義では、nisMailAlias オブジェクトクラスの継承階層を指定します。
「Build」セクションでは、cn 属性と属性値を BASE_DN トークンと結合してエントリの識別名を作成します。BASE_DN トークンは、そのエントリを入れる名前付きコンテキストを表します。
rfc822mailMember 属性と objectClass 属性には複数の値が入ります。string2instances 操作によって得られた各値に対し、これらの属性が 1 つ発生します。
たとえば、ドメイン France.XYZ.com の aliases ファイルに次の行があるとします。
dir-team: pdurand, jdupond, asantini, msmith, dphilippe, smartin
aliases ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=dir-team, ou=Aliases, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は、次のようになります。
|
cn |
dir-team |
|
rfc822mailMember |
pdurand |
|
jdupond |
|
|
asantini |
|
|
msmith |
|
|
dphilippe |
|
|
smartin |
|
|
objectClass |
top |
|
nisMailAlias |
bootparams
bootparams ファイルのエントリは、通常、次の書式になっています。
hostname parameter1 parameter2 parameter3...parameterx
たとえば、France.XYZ.com ドメインの bootparams ファイルに次の行があるとします。
camembert root=server1:/export/camembert/root ¥ swap=server1:/export/camembert/swap ¥ domain=France.XYZ.com
bootparams ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=camembert, ou=Host, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は、次のようになります。
|
cn |
camembert |
|
bootParameter |
root=server1:/export/roquefort/root |
|
swap=server1:/export/roquefort/swap |
|
|
domain=France.XYZ.com |
|
|
objectClass |
top |
|
device |
|
|
bootableDevice |
ホスト camembert には、/etc/ethers と /etc/hosts にもエントリがあります。しかし、LDAP ディレクトリでは、ホスト camembert のエントリは 1 つだけで、他のすべての属性は ethers テーブルマッピングと hosts テーブルマッピングから派生したものです。ホスト camembert 用に作成された LDAP ディレクトリには、いくつかのオブジェクトクラスがあります。このうち、1 つは継承した構造体オブジェクトクラス device で、3 つは補助オブジェクトクラス bootableDevice、ieee802Device、ipHost です。
「ethers」と 「hosts」の例の場合、LDAP ディレクトリに作成されるホスト camembert の完全なエントリは、次のようになります。
|
cn |
camembert |
|
bertie |
|
|
bootParameter |
root=server1:/export/roquefort/root |
|
swap=server1:/export/roquefort/swap |
|
|
domain=France.XYZ.com |
|
|
macAddress |
0:1:23:aa:bb:cc |
|
ipHostNumber |
123.456.789.1 |
|
description |
SS5 Pierre's Desktop |
|
objectClass |
top |
|
device |
|
|
bootableDevice |
|
|
ieee802Device |
|
|
ipHost |
bootparams ファイルから camembert のエントリを削除すると、camembert のディレクトリエントリが更新され、bootableDevice オブジェクトクラスとそのオブジェクトクラス固有の bootParameter 属性が削除されます。
ethers
ethers ファイルのエントリは、通常、次の書式になっています。
ethernetaddress machinename
たとえば、ドメイン France.XYZ.com の ethers ファイルに次の行があるとします。
0:1:23:aa:bb:cc camembert
ethers ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=camembert, ou=Hosts, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。
|
cn |
camembert |
|
macAddress |
0:1:23:aa:bb:cc |
|
objectClass |
top |
|
device |
|
|
ieee802Device |
ホスト camembert には /etc/bootparams ファイルと /etc/hosts ファイルにもエントリがある場合があります。これらのファイルから作成される LDAP ディレクトリの完全なエントリの詳細は、「bootparams」を参照してください。
group
group ファイルのエントリは、通常、次の書式になっています。
groupname:password:groupidnumber:listofmembers
たとえば、ドメイン France.XYZ.com の group ファイルに次の行があるとします。
sysadmin:yai957KJwXrjc:10:bgreen, hgrant, dbrown
group ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=sysadmin, ou=Group, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。
|
cn |
sysadmin |
|
gidNumber |
10 |
|
memberUid |
bgreen |
|
hgrant |
|
|
dbrown |
|
|
userPassword |
{crypt}yai957KJwXrjc |
|
objectClass |
top |
|
posixGroup |
hosts
hosts ファイルのエントリは、通常、次の書式になっています。
ipaddress hostname hostaliasnames #hostdescription
たとえば、ドメイン France.XYZ.com の hosts ファイルに次の行があるとします。
123.456.789.1 camembert bertie # SS5 Pierre's Desktop
hosts ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=camembert, ou=Hosts, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。
|
cn |
camembert |
|
bertie |
|
|
ipHostNumber |
123.456.789.1 |
|
description |
SS5 Pierre's Desktop |
|
objectClass |
top |
|
device |
|
|
ipHost |
ホスト camembert には /etc/bootparams ファイルと /etc/ethers ファイルにもエントリがある場合があります。これらのファイルから作成される LDAP ディレクトリの完全なエントリの詳細は、「bootparams」を参照してください。
netgroup
netgroup ファイルのエントリは、通常、次の書式になっています。
netgroupname grouptriple grouptriple grouptriple grouptriple
grouptriple の書式は (hostname, username, domainname) です。
たとえば、ドメイン France.XYZ.com の netgroup ファイルに次の行があるとします。
printers¥ (bordeaux,-,France.XYZ.com)¥ (bourgogne,-,France.XYZ.com)¥ (sauternes,-,France.XYZ.com)
netgroup ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=printers, ou=netgroup, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。
|
cn |
printers |
|
nisNetGroupTriple |
bordeaux,-,France.XYZ.com |
|
bourgogne,-,France.XYZ.com |
|
|
sauternes,-,France.XYZ.com |
|
|
objectClass |
top |
|
nisNetGroup |
networks
networks ファイルのエントリは、通常、次の書式になっています。
networkname networkaddress networkalias #description
たとえば、ドメイン France.XYZ.com の networks ファイルに次の行があるとします。
XYZ-eng 123.456.789 eng #engineering subnetwork
networks ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=XYZ-eng, ou=networks, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。
|
cn |
XYZ-eng |
|
eng |
|
|
ipNetworkNumber |
123.456.789 |
|
description |
engineering subnetwork |
|
objectClass |
top |
|
ipNetwork |
passwd
passwd ファイルのエントリは、通常、次の書式になっています。
userid:userPasswd:uidnumber:gidnumber:gecos:homeDir:shell
passwd ファイルに関連付けられた shadow ファイルがある場合、そのファイルの書式は、通常、次のようになっています。
userid:userPasswd:::::::
passwd ファイルと shadow ファイルのユーザー ID は同じですが、ユーザーのパスワードは、実際には passwd ファイルではなく shadow ファイルに格納されます。
たとえば、ドメイン France.XYZ.com の passwd ファイルに Pierre Durand に対する次の行があるとします。
pdurand:x:12345:67:Pierre Durand - Project Manager:/home/pdurand:/bin/csh
ユーザーパスワードの代わりに x があるのは、実際のパスワードが shadow ファイルに格納されていることを示します。shadow ファイルには、Pierre Durand に対し次の行があります。
pdurand:yai957KJwXrjc:::::::
passwd ファイルと shadow ファイルのこれらの行から作成されるディレクトリエントリの識別名は、uid=pdurand, ou=People, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。
|
cn |
Pierre Durand |
|
uid |
pdurand |
|
userPassword |
{crypt}yai957KJwXrjc |
|
uidNumber |
12345 |
|
gidNumber |
67 |
|
gecos |
Pierre Durand - Project Manager |
|
homeDirectory |
/home/pdurand |
|
loginshell |
/bin/csh |
|
objectClass |
top |
|
account |
|
|
posixAccount |
protocols
protocols ファイルのエントリは、通常、次の書式になっています。
protocolname protocolnumber protocolalias #description
たとえば、ドメイン France.XYZ.com の protocols ファイルに次の行があるとします。
tcp 0 TCP_Protocol #Transmission Control Protocol
protocols ファイルのこの行から作成されるディレクトリエントリの識別名は、ou=protocols, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。
|
cn |
tcp |
|
TCP_Protocol |
|
|
ipProtocolNumber |
0 |
|
description |
Transmission Control Protocol |
|
objectClass |
top |
|
ipProtocol |
rpc
rpc ファイルのエントリは、通常、次の書式になっています。
programname programnumber protocolalias #description
たとえば、ドメイン France.XYZ.com の rpc ファイルに次の行があるとします。
yppasswdd 100123 yppasswd
rpc ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=yppasswdd, ou=rpc, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。
|
cn |
yppasswdd |
|
yppasswd |
|
|
oncRpcNumber |
100123 |
|
objectClass |
top |
|
oncRpc |
ypservers
NIS 環境では、ドメインの NIS サーバーのリストが ypservers ファイルに入っています。
たとえば、ドメイン France.XYZ.com の ypservers ファイルに次のリストがあるとします。
brie camembert emmental gorgonzola roquefort
このファイルにリストされているサーバーごとにディレクトリエントリが作成されます。たとえば、サーバー brie 用に作成されるエントリの識別名は、cn=brie, ou=ypservers, ou=Services, dc=France, dc=XYZ, dc=com になります。また、サーバー brie のエントリは次のようになります。
|
cn |
brie |
|
objectClass |
top |
|
sunNisServer |
NIS 情報に対する ACL
LDAP ディレクトリの NIS 情報は、特別な ACL のセットで保護されます。これらの ACL は dsserv.acl.conf ファイルに入っています。このファイルの一部を次に示します。
# NIS ACLs
access to attrs=userPassword
by self write
by * compare
access to attrs=gecos,loginShell
by self write
デフォルトでは、ユーザーは自分のエントリのすべての属性に対し読み込みアクセス権を持っているが、書き込みアクセス権があるのは、userPassword、gecos、loginShell 属性に対してだけです。
名前付きコンテキストの構成
NIS サービスの初期設定で NIS エントリ用に作成する名前付きコンテキストは、nis.mapping ファイルにキーワード BASE_DN で指定します。この基本識別名は、各マップに固有の組織単位 (ou) と通常いくつかのマップに共通の rootTree トークンとを結合したものです。
たとえば、networks マップから作成するエントリ用の名前付きコンテキストは、nis.mapping ファイルの次の 2 つの行で定義します。
rootTreeT=ou=Services,$NAMING_SUFFIX||ou=Services,$DC_NAMING BASE_DN=ou=Networks,$rootTreeT
networks ファイルから作成するディレクトリエントリは、ou=Networks, ou=Services の名前付きコンテキストに作成されます。
ネーミング構造として NAMING_SUFFIX キーワードを選択するか、DC_NAMING キーワードを選択するかは構成で指定します。DC_NAMING キーワードではドメイン構成要素 (DC) 接尾辞を使用します。このネーミング構造でエントリを作成すると、その識別名の接尾辞は dc=XYZ, dc=com の書式になります。インポートプロセスでは dsypinstall プロセスで指定するドメイン名から DC ネーミング接尾辞がとられるため、NIS サービスを初期設定するときのネーミング構造には、デフォルトでこの方法が使用されます。
これとは異なる接尾辞を使用する場合は、nis.mapping ファイルの始めにあるフロントエンドの「Common」セクションで、NAMING_SUFFIX キーワードのコメントを解除する必要があります。NAMING_SUFFIX キーワードの値を変更して、NIS エントリを作成する接尾辞または名前付きコンテキストを指定します。指定する値は、データ格納にある有効な名前付きコンテキストでなければなりません。名前付きコンテキストの作成方法については、「データ格納の作成と変更」を参照してください。
nis.mapping ファイルの DOMAIN_NAME キーワードはコメント化しないでください。このキーワードには、dsypinstall プロセスで指定したドメイン名が入っています。これは、サーバーが NIS サービスを行うときに使用します。
大文字と小文字の区別
通常、検索を行う属性に大文字と小文字の区別があれは (ces 構文)、ディレクトリサーバーは大文字と小文字を区別して検索します。同様に、検索を行う属性に大文字と小文字の区別がなければ (cis 構文)、検索する際に大文字と小文字は区別されません。
しかし、nis.mapping ファイルでテーブルのマッピング定義にキーワード CASE_SENSITIVE=yes を指定すれば、属性構文に対し大文字と小文字の区別を強制的に適用できます。
たとえば、uid 属性 が cis 構文を持っている場合、セキュリティのために大文字と小文字の区別を強制する必要があります。したがって、nis.mapping ファイルの passwd.byname 定義には、CASE_SENSITIVE キーワードが指定されています。
Table: passwd.byname Common: MAP_NAME=passwd.byname # The LDAP attribute used to store the key (uid) is case insensitive! CASE_SENSITIVE=yes
- © 2010, Oracle Corporation and/or its affiliates