RFC2307 日本語訳
2307 An Approach for Using LDAP as a Network Information Service. L.Howard. March 1998. (Format: TXT=41396 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Howard Request for Comments: 2307 Independent Consultant Category: Experimental March 1998
コメントを求めるワーキンググループL.ハワード要求をネットワークでつないでください: 2307年の独立しているコンサルタントカテゴリ: 実験的な1998年3月
An Approach for Using LDAP as a Network Information Service
ネットワーク情報サービスとしてLDAPを使用するためのアプローチ
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 [X500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them.
このドキュメントは、ライトウェイト・ディレクトリ・アクセス・プロトコル[RFC2251]でそれらを決議できるようにTCP/IPに関連する実体とUNIXシステムをX.500[X500]エントリーに写像するために実験メカニズムについて説明します。 1セットの属性タイプとオブジェクトのクラスはそれらを解釈するための特別な基準と共に提案されます。
The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success.
意志は組織的なnameserviceとしてLDAPの展開を促進することです。 提案されたソリューションは全くインターネットの規格として意図しません。 むしろ、全体的な合意が適切なソリューションに関してそのような問題に現れることが望まれています、結局規格の採用に通じて。 提案されたメカニズムは何らかの成功で既に実装されました。
1. Background and Motivation
1. バックグラウンドと動機
The UNIX (R) operating system, and its derivatives (specifically, those which support TCP/IP and conform to the X/Open Single UNIX specification [XOPEN]) require a means of looking up entities, by matching them against search criteria or by enumeration. (Other operating systems that support TCP/IP may provide some means of resolving some of these entities. This schema is applicable to those environments also.)
実体を見上げる手段を必要として、それらを合わせると評価基準か列挙で捜されるUNIX(R)オペレーティングシステム、およびその派生物(明確にX/Open Single UNIX仕様[XOPEN]にTCP/IPをサポートして、従うもの)。 (TCP/IPをサポートする他のオペレーティングシステムはこれらの実体のいくつかを決議するいくつかの手段を提供するかもしれません。 この図式はそれらの環境にも適切です。)
These entities include users, groups, IP services (which map names to IP ports and protocols, and vice versa), IP protocols (which map names to IP protocol numbers and vice versa), RPCs (which map names to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS
これらの実体はユーザを含んでいます、グループ、IPサービス(逆もまた同様ですIPポートとプロトコルへのどの地図名)、IPプロトコル(逆もまた同様にIPプロトコル番号に名前を写像する)、RPCs(逆もまた同様にONC Remote Procedure Call[RFC1057]番号に名前を写像する)、NIS
Howard Experimental [Page 1] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[1ページ]RFC2307
netgroups, booting information (boot parameters and MAC address mappings), filesystem mounts, IP hosts and networks, and RFC822 mail aliases.
netgroups、穂ばらみ情報(パラメタとMACアドレス・マッピングをブートする)、ファイルシステムマウント、IPホスト、ネットワーク、およびRFC822は別名を郵送します。
Resolution requests are made through a set of C functions, provided in the UNIX system's C library. For example, the UNIX system utility "ls", which enumerates the contents of a filesystem directory, uses the C library function getpwuid() in order to map user IDs to login names. Once the request is made, it is resolved using a "nameservice" which is supported by the client library. The nameservice may be, at its simplest, a collection of files in the local filesystem which are opened and searched by the C library. Other common nameservices include the Network Information Service (NIS) and the Domain Name System (DNS). (The latter is typically used for resolving hosts, services and networks.) Both these nameservices have the advantage of being distributed and thus permitting a common set of entities to be shared amongst many clients.
UNIXシステムCのライブラリに提供された1セットのC機能を通して解決要求をします。 例えば、UNIXシステムユーティリティ"ls"(ファイルシステムディレクトリのコンテンツを列挙する)は、ユーザIDをログイン名に写像するのにCライブラリ関数getpwuid()を使用します。 いったん要求をすると、"nameservice"を使用することで、どれがクライアントライブラリによってサポートされるかと決議します。 最も簡単では、nameserviceはローカルのファイルシステムにおけるCライブラリによって開かれて、捜されるファイルの収集であるかもしれません。 他の一般的なnameservicesはNetwork情報Service(NIS)とドメインネームシステム(DNS)を含んでいます。 (後者はホスト、サービス、およびネットワークを決議するのに通常使用されます。) これらのnameservicesの両方には、分配されていて、その結果、一般的なセットの実体が多くのクライアントの中で共有されることを許可する利点があります。
LDAP is a distributed, hierarchical directory service access protocol which is used to access repositories of users and other network- related entities. Because LDAP is often not tightly integrated with the host operating system, information such as users may need to be kept both in LDAP and in an operating system supported nameservice such as NIS. By using LDAP as the the primary means of resolving these entities, these redundancy issues are minimized and the scalability of LDAP can be exploited. (By comparison, NIS services based on flat files do not have the scalability or extensibility of LDAP or X.500.)
LDAPはユーザの倉庫にアクセスするのに使用される分配された階層化ディレクトリサービスアクセス・プロトコルです、そして、他のネットワークは実体を関係づけました。 LDAPがしばしばしっかりホスト・オペレーティング・システムと統合されるというわけではないので、LDAPとオペレーティングシステムで保たれるユーザが、必要があるかもしれない情報はNISなどのnameserviceをサポートしました。 これらの実体を決議するプライマリ手段としてLDAPを使用することによって、これらの冗長問題を最小にします、そして、LDAPのスケーラビリティを利用できます。 (比較で、平坦なファイルに基づくNISサービスはLDAPかX.500のスケーラビリティか伸展性を持っていません。)
The object classes and attributes defined below are suitable for representing the aforementioned entities in a form compatible with LDAP and X.500 directory services.
以下で定義されたオブジェクトのクラスと属性はLDAPとX.500ディレクトリサービスとのコンパチブルフォームに前述の実体を表すのに適当です。
2. General Issues
2. 一般答弁
2.1. Terminology
2.1. 用語
The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [RFC2119].
“MUST"、“SHOULD"、および「5月」が本書では使用したキーワードは[RFC2119]で説明されるように解釈されることです。
For the purposes of this document, the term "nameservice" refers to a service, such as NIS or flat files, that is used by the operating system to resolve entities within a single, local naming context. Contrast this with a "directory service" such as LDAP, which supports extensible schema and multiple naming contexts.
このドキュメントの目的、NISか平坦なファイルなどのサービスへの参照という用語"nameservice"のときに、それは、単一の、そして、ローカルの命名関係の中で実体を決議するのにオペレーティングシステムで使用されます。 LDAPなどの「ディレクトリサービス」に対してこれを対照してください。(LDAPは広げることができる図式と複数の命名が文脈であるとサポートします)。
Howard Experimental [Page 2] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[2ページ]RFC2307
The term "NIS-related entities" broadly refers to entities which are typically resolved using the Network Information Service. (NIS was previously known as YP.) Deploying LDAP for resolving these entities does not imply that NIS be used, as a gateway or otherwise. In particular, the host and network classes are generically applicable, and may be implemented on any system that wishes to use LDAP or X.500 for host and network resolution.
「NIS関連の実体」という用語はNetwork情報Serviceを使用することで通常決議されている実体について広く言及します。 (NISは以前に、YPとして知られていました。) これらの実体を決議するためにLDAPを配布するのは、NISがゲートウェイとして中古であるか、またはそうでないのを含意しません。 ホストとネットワークのクラスは、特に、一般的に適切であり、ホストとネットワーク解決にLDAPかX.500を使用したがっているどんなシステムの上でも実装されるかもしれません。
The "DUA" (directory user agent) refers to the LDAP client querying these entities, such as an LDAP to NIS gateway or the C library. The "client" refers to the application which ultimately makes use of the information returned by the resolution. It is irrelevant whether the DUA and the client reside within the same address space. The act of the DUA making this information to the client is termed "republishing".
「デュア」(ディレクトリユーザエージェント)はこれらの実体について質問しているLDAPクライアントを示します、ニーシゲートウェイかCライブラリへのLDAPのように。 「クライアント」は結局解決で返された情報を利用するアプリケーションを示します。 DUAとクライアントが同じアドレス空間の中に住んでいるか否かに関係なく、それは無関係です。 DUAがこの情報をクライアントに作る行為は「再刊」と呼ばれます。
To avoid confusion, the term "login name" refers to the user's login name (being the value of the uid attribute) and the term "user ID" refers to he user's integer identification number (being the value of the uidNumber attribute).
混乱、「ログイン名」がユーザのログイン名を示す(uid属性の値です)用語、および「ユーザID」が示す用語を避ける、彼、ユーザの整数識別番号(uidNumber属性の値であり)。
The phrases "resolving an entity" and "resolution of entities" refer respectively to enumerating NIS-related entities of a given type, and matching them against a given search criterion. One or more entities are returned as a result of successful "resolutions" (a "match" operation will only return one entity).
「実体を決議します」と「実体の解決」という句はそれぞれ与えられたタイプのNIS関連の実体を列挙して、与えられた検索評価基準に対してそれらを合わせるのを示します。 1つ以上の実体がうまくいっている「解決」の結果、返されます(「マッチ」操作は1つの実体しか返さないでしょう)。
The use of the term UNIX does not confer upon this schema the endorsement of owners of the UNIX trademark. Where necessary, the term "TCP/IP entity" is used to refer to protocols, services, hosts, and networks, and the term "UNIX entity" to its complement. (The former category does not mandate the host operating system supporting the interfaces required for resolving UNIX entities.)
UNIXという用語の使用はUNIX商標の所有者の裏書きをこの図式に与えません。 必要であるところでは、「TCP/IP実体」という用語が、「UNIX実体」というプロトコル、サービス、ホスト、ネットワーク、および用語を1の補数に差し向けるのに使用されます。 (前のカテゴリは、インタフェースをサポートするホスト・オペレーティング・システムがUNIX実体を決議するのに必要であることを強制しません。)
The OIDs defined below are derived from iso(1) org(3) dod(6) internet(1) directory(1) nisSchema(1).
iso(1) org(3) dod(6)インターネット(1)ディレクトリ(1)nisSchema(1)から以下で定義されたOIDsを得ます。
2.2. Attributes
2.2. 属性
The attributes and classes defined in this document are summarized below.
本書では定義された属性とクラスは以下へまとめられます。
The following attributes are defined in this document:
以下の属性は本書では定義されます:
uidNumber
gidNumber
gecos
homeDirectory
uidNumber gidNumber gecos homeDirectory
Howard Experimental [Page 3] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[3ページ]RFC2307
loginShell
shadowLastChange
shadowMin
shadowMax
shadowWarning
shadowInactive
shadowExpire
shadowFlag
memberUid
memberNisNetgroup
nisNetgroupTriple
ipServicePort
ipServiceProtocol
ipProtocolNumber
oncRpcNumber
ipHostNumber
ipNetworkNumber
ipNetmaskNumber
macAddress
bootParameter
bootFile
nisMapName
nisMapEntry
loginShell shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag memberUid memberNisNetgroup nisNetgroupTriple ipServicePort ipServiceProtocol ipProtocolNumber oncRpcNumber ipHostNumber ipNetworkNumber ipNetmaskNumber macAddress bootParameter bootFile nisMapName nisMapEntry
Additionally, some of the attributes defined in [RFC2256] are required.
さらに、[RFC2256]で定義された属性のいくつかが必要です。
2.3. Object classes
2.3. オブジェクトのクラス
The following object classes are defined in this document:
以下のオブジェクトのクラスは本書では定義されます:
posixAccount
shadowAccount
posixGroup
ipService
ipProtocol
oncRpc
ipHost
ipNetwork
nisNetgroup
nisMap
nisObject
ieee802Device
bootableDevice
posixAccount shadowAccount posixGroup ipService ipProtocol oncRpc ipHost ipNetwork nisNetgroup nisMap nisObject ieee802Device bootableDevice
Additionally, some of the classes defined in [RFC2256] are required.
さらに、[RFC2256]で定義されたクラスのいくつかが必要です。
Howard Experimental [Page 4] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[4ページ]RFC2307
2.4. Syntax definitions
2.4. 構文定義
The following syntax definitions [RFC2252] are used by this schema. The nisNetgroupTripleSyntax represents NIS netgroup triples:
以下の構文定義[RFC2252]はこの図式によって使用されます。 nisNetgroupTripleSyntaxはNIS netgroup三重を表します:
( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax'
DESC 'NIS netgroup triple' )
(nisSchema.0.0NAME'nisNetgroupTripleSyntax'DESC'NIS netgroup三重')
Values in this syntax are represented by the following:
この構文による値は以下によって表されます:
nisnetgrouptriple = "(" hostname "," username "," domainname ")"
hostname = "" / "-" / keystring
username = "" / "-" / keystring
domainname = "" / "-" / keystring
「nisnetgrouptripleが等しい、「(」 「ホスト名」、ユーザ名、」、」 ドメイン名、」、)、」 ホスト名=、「「/「-」/keystringユーザ名=、「「/「-」/keystringドメイン名=、「「/「-」/keystring」
X.500 servers may use the following representation of the above syntax:
X.500サーバは上の構文の以下の表現を使用するかもしれません:
nisNetgroupTripleSyntax ::= SEQUENCE {
hostname [0] IA5String OPTIONAL,
username [1] IA5String OPTIONAL,
domainname [2] IA5String OPTIONAL
}
nisNetgroupTripleSyntax:、:= 系列ホスト名[0]IA5String OPTIONAL、ユーザ名[1]IA5String OPTIONAL、ドメイン名[2]IA5String OPTIONAL
The bootParameterSyntax syntax represents boot parameters:
bootParameterSyntax構文はブーツパラメタを表します:
( nisSchema.0.1 NAME 'bootParameterSyntax'
DESC 'Boot parameter' )
(nisSchema.0.1NAME'bootParameterSyntax'DESC'ブーツパラメタ')
where:
どこ:
bootparameter = key "=" server ":" path
key = keystring
server = keystring
path = keystring
「bootparameter=キーは「」 サーバと等しいです」」 経路=keystringをkeystringするサーバ=をkeystringする経路キー=
X.500 servers may use the following representation of the above syntax:
X.500サーバは上の構文の以下の表現を使用するかもしれません:
bootParameterSyntax ::= SEQUENCE {
key IA5String,
server IA5String,
path IA5String
}
bootParameterSyntax:、:= 系列主要なIA5String、サーバIA5String、経路IA5String
Values adhering to these syntaxes are encoded as strings by LDAP servers.
これらの構文を固く守る値がストリングとしてLDAPサーバによってコード化されます。
Howard Experimental [Page 5] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[5ページ]RFC2307
3. Attribute definitions
3. 属性定義
This section contains attribute definitions to be implemented by DUAs supporting this schema.
このセクションはこの図式をサポートするDUAsによって実装される属性定義を含みます。
( nisSchema.1.0 NAME 'uidNumber'
DESC 'An integer uniquely identifying a user in an
administrative domain'
EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.0NAME'uidNumber'DESC'管理ドメインで唯一ユーザを特定する整数'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.1NAME'gidNumber'DESC'管理ドメインで唯一グループを特定する整数'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.2NAME'gecos'DESC'GECOS分野; 一般名'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.3NAME'homeDirectory'DESC'ホームディレクトリへの絶対パス'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.4NAME'loginShell'DESC'ログインシェルへの経路'EQUALITY caseExactIA5Match SYNTAX'IA5String'SINGLE-VALUE)
( nisSchema.1.5 NAME 'shadowLastChange'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.5の平等のintegerMatchの構文の'整数'ただ一つの名前'shadowLastChange'価値)
( nisSchema.1.6 NAME 'shadowMin'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.6の平等のintegerMatchの構文の'整数'ただ一つの名前'shadowMin'価値)
( nisSchema.1.7 NAME 'shadowMax'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.7の平等のintegerMatchの構文の'整数'ただ一つの名前'shadowMax'価値)
( nisSchema.1.8 NAME 'shadowWarning'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.8の平等のintegerMatchの構文の'整数'ただ一つの名前'shadowWarning'価値)
( nisSchema.1.9 NAME 'shadowInactive'
(nisSchema.1.9は'shadowInactive'を命名します。
Howard Experimental [Page 6] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[6ページ]RFC2307
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
平等のintegerMatchの構文の'整数'ただ一つの価値)
( nisSchema.1.10 NAME 'shadowExpire'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.10の平等のintegerMatchの構文の'整数'ただ一つの名前'shadowExpire'価値)
( nisSchema.1.11 NAME 'shadowFlag'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.11の平等のintegerMatchの構文の'整数'ただ一つの名前'shadowFlag'価値)
( nisSchema.1.12 NAME 'memberUid'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String' )
(nisSchema.1.12名前'memberUid'平等caseExactIA5MatchサブストリングcaseExactIA5SubstringsMatch構文'IA5String')
( nisSchema.1.13 NAME 'memberNisNetgroup'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String' )
(nisSchema.1.13名前'memberNisNetgroup'平等caseExactIA5MatchサブストリングcaseExactIA5SubstringsMatch構文'IA5String')
( nisSchema.1.14 NAME 'nisNetgroupTriple'
DESC 'Netgroup triple'
SYNTAX 'nisNetgroupTripleSyntax' )
(nisSchema.1.14NAME'nisNetgroupTriple'DESC'Netgroupの三重の'SYNTAX'nisNetgroupTripleSyntax')
( nisSchema.1.15 NAME 'ipServicePort'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.15の平等のintegerMatchの構文の'整数'ただ一つの名前'ipServicePort'価値)
( nisSchema.1.16 NAME 'ipServiceProtocol'
SUP name )
(nisSchema.1.16NAME'ipServiceProtocol'SUP名)
( nisSchema.1.17 NAME 'ipProtocolNumber'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.17の平等のintegerMatchの構文の'整数'ただ一つの名前'ipProtocolNumber'価値)
( nisSchema.1.18 NAME 'oncRpcNumber'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
(nisSchema.1.18の平等のintegerMatchの構文の'整数'ただ一つの名前'oncRpcNumber'価値)
( nisSchema.1.19 NAME 'ipHostNumber'
DESC 'IP address as a dotted decimal, eg. 192.168.1.1,
omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' )
(nisSchema.1.19NAME'ipHostNumber'DESC'IPがaドット付き10進法、例えば、192.168として.1を扱う、先行ゼロ'EQUALITY caseIgnoreIA5Match SYNTAX'IA5String128'を省略することでの.1
( nisSchema.1.20 NAME 'ipNetworkNumber'
DESC 'IP network as a dotted decimal, eg. 192.168,
(ドット付き10進法、例えば、192.168としてのnisSchema.1.20NAME'ipNetworkNumber'DESC'IPネットワーク、'
Howard Experimental [Page 7] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[7ページ]RFC2307
omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )
先行ゼロのEQUALITY caseIgnoreIA5Match SYNTAX'IA5String128'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 )
(ドット付き10進法、例えば、255.255としてのnisSchema.1.21NAME'ipNetmaskNumber'DESC'IPネットマスク、.255 先行ゼロ'EQUALITY caseIgnoreIA5Match SYNTAX'IA5String128'SINGLE-VALUEを省略することでの.0
( 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}' )
(DESC'MACが最大限度で扱うnisSchema.1.22NAME'macAddress'、コロンが例えば十六進法記法を切り離した、92:90、00:00:: ee: e2'EQUALITY caseIgnoreIA5Match SYNTAX'IA5String128'、)
( nisSchema.1.23 NAME 'bootParameter'
DESC 'rpc.bootparamd parameter'
SYNTAX 'bootParameterSyntax' )
(nisSchema.1.23NAME'bootParameter'DESC'rpc.bootparamdパラメタ'SYNTAX'bootParameterSyntax')
( nisSchema.1.24 NAME 'bootFile'
DESC 'Boot image name'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' )
(nisSchema.1.24NAME'bootFile'DESC'ブーツイメージ名'EQUALITY caseExactIA5Match SYNTAX'IA5String')
( nisSchema.1.26 NAME 'nisMapName'
SUP name )
(nisSchema.1.26NAME'nisMapName'SUP名)
( nisSchema.1.27 NAME 'nisMapEntry'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String{1024}' SINGLE-VALUE )
(nisSchema.1.27の名前の'nisMapEntry'平等caseExactIA5MatchサブストリングcaseExactIA5SubstringsMatch構文'IA5String1024'ただ一つの価値)
4. Class definitions
4. クラス定義
This section contains class definitions to be implemented by DUAs supporting the schema.
このセクションは図式をサポートするDUAsによって実装されるクラス定義を含みます。
The rfc822MailGroup object class MAY be used to represent a mail group for the purpose of alias expansion. Several alternative schemes for mail routing and delivery using LDAP directories, which are outside the scope of this document.
rfc822MailGroupオブジェクトのクラスは、別名拡張の目的のためにメールグループを代表するのに使用されるかもしれません。 このドキュメントの範囲の外にあるLDAPディレクトリを使用するメールルーティングと配送のいくつかの代替の体系。
( 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.0NAME、'POSIX属性とのアカウントのposixAccount'SUPの最高AUXILIARY DESC'抽象化'がそうしなければならない、(cn$uid$uidNumber$gidNumber$homeDirectory)5月(userPassword$loginShell$gecos$記述)
Howard Experimental [Page 8] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[8ページ]RFC2307
( 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 ) )
('シャドウパスワードのための追加属性'がuidしなければならないAUXILIARY DESCがそうするnisSchema.2.1NAME'shadowAccount'SUP先端(userPassword$shadowLastChange$shadowMin shadowMax$shadowWarning$shadowInactive$shadowExpire$shadowFlag$記述))
( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
DESC 'Abstraction of a group of accounts'
MUST ( cn $ gidNumber )
MAY ( userPassword $ memberUid $ description ) )
(nisSchema.2.2NAME'posixGroup'SUPはSTRUCTURAL DESCを上回っている'aの抽象化が分類するアカウント'がそうしなければならない、(cn$gidNumber)5月(userPassword$memberUid$記述)
( 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.3NAME'ipService'SUPはSTRUCTURAL DESCを上回っています。'インターネットプロトコルが修理する抽象化'。 IPポートとプロトコル(tcpかudpなどの)を1つ以上の名前に写像します。 'cn属性の顕著な値はサービスの正準な名前を指示すること'がそうしなければならない、(cn$ipServicePort$ipServiceProtocol)5月(記述))
( 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 $ description )
MAY description )
( nisSchema.2.4NAME'ipProtocol'SUPは'IPの抽象化は議定書の中で述べる'STRUCTURAL DESCを上回っています。 1つ以上へのプロトコル番号が命名する地図。 'cn属性の顕著な値はプロトコルの正準な名前を指示すること'がそうしなければならない、(cn$ipProtocolNumber$記述)5月の記述)
( 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.5NAME'oncRpc'SUPはSTRUCTURAL DESCを上回っています。'オープンのNetwork Computing(ONC)[RFC1057]リモートなProcedure Call(RPC)結合の抽象化'。 このクラスはONC RPC番号を名前に写像します。 'cn属性の顕著な値はRPCサービスの正準な名前を指示すること'がそうしなければならない、(cn$oncRpcNumber$記述)5月の記述)
( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY
(nisSchema.2.6NAME'ipHost'SUPは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 ) )
DESC、'ホスト、IPデバイスの抽象化'。 cn属性の顕著な値はホストの正準な名前を指示します。 デバイスSHOULD、構造的なクラスのものがそうしなければならないように使用されて、(cn$ipHostNumber)はそうするかもしれません(l$記述$マネージャ)。
( 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'
nisSchema.2.7NAME'ipNetwork'SUPはネットワークについてSTRUCTURAL DESC'抽象化を上回っています。(cn属性の顕著な値はネットワークの正準な名前を指示します'
Howard Experimental [Page 9] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[9ページ]RFC2307
MUST ( cn $ ipNetworkNumber )
MAY ( ipNetmaskNumber $ l $ description $ manager ) )
(cn$ipNetworkNumber)5月でなければならない(ipNetmaskNumber$l$記述$マネージャ)
( 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.8NAME'nisNetgroup'SUPは'aの抽象化はnetgroupする'STRUCTURAL DESCを上回っています。 参照するかもしれない、他のnetgroupsに、5月(nisNetgroupTriple$memberNisNetgroup$記述)はcnされていなければなりません。)
( nisSchema.2.09 NAME 'nisMap' SUP top STRUCTURAL
DESC 'A generic abstraction of a NIS map'
MUST nisMapName
MAY description )
(nisSchema.2.09NAME'nisMap'SUPがNIS地図についてSTRUCTURAL DESC'Aジェネリック抽象化を上回っている、'、nisMapName5月の記述)でなければならない
( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL
DESC 'An entry in a NIS map'
MUST ( cn $ nisMapEntry $ nisMapName )
MAY description )
(nisSchema.2.10NAME'nisObject'SUPがSTRUCTURAL DESCを上回っている、'NIS地図におけるエントリー'はそうしなければなりません(cn$nisMapEntry$nisMapName) 5月の記述)。
( 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.11NAME'ieee802Device'SUP先端AUXILIARY DESC'MACアドレス; デバイスSHOULDが構造的なクラスとして使用されているデバイス'5月の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.12NAME'bootableDevice'SUP先端AUXILIARY DESC'ブーツパラメタ; デバイスSHOULDが構造的なクラスとして使用されているデバイス'5月の(bootFile$bootParameter))
5. Implementation details
5. 実装の詳細
5.1. Suggested resolution methods
5.1. 提案された解決メソッド
The preferred means of directing a client application (one using the shared services of the C library) to use LDAP as its information source for the functions listed in 5.2 is to modify the source code to directly query LDAP. As the source to commercial C libraries and applications is rarely available to the end-user, one could emulate a supported nameservice (such as NIS). (This is also an appropriate opportunity to perform caching of entries across process address spaces.) In the case of NIS, reference implementations are widely available and the RPC interface is well known.
機能のための情報源が5.2で記載したようにLDAPを使用するクライアントアプリケーション(Cライブラリの共有されたサービスを利用する1つ)を向ける都合のよい手段は直接LDAPについて質問するようにソースコードを変更することです。 エンドユーザにとって、商業Cライブラリとアプリケーションへのソースがめったに手があいていないとき、1つはサポートしているnameservice(NISなどの)を見習うかもしれません。 (また、これはプロセスアドレス空間の向こう側にエントリーのキャッシュを実行する適切な機会です。) NISの場合では、参照実装は広く利用可能です、そして、RPCインタフェースはよく知られています。
The means by which the operating system is directed to use LDAP is implementation dependent. For example, some operating systems and C libraries support end-user extensible resolvers using dynamically loadable libraries and a nameservice "switch". The means in which the DUA locates LDAP servers is also implementation dependent.
オペレーティングシステムがLDAPを使用するよう指示される手段は実装に依存しています。 例えば、いくつかのオペレーティングシステムとCライブラリは、ダイナミックに「負荷-可能」ライブラリとnameservice「スイッチ」を使用することでエンドユーザの広げることができるレゾルバをサポートします。 また、DUAがLDAPサーバの場所を見つける手段も実装に依存しています。
Howard Experimental [Page 10] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[10ページ]RFC2307
5.2. Affected library functions
5.2. 影響を受けるライブラリ関数
The following functions are typically found in the C libraries of most UNIX and POSIX compliant systems. An LDAP search filter [RFC2254] which may be used to satisfy the function call is included alongside each function name. Parameters are denoted by %s and %d for string and integer arguments, respectively. Long lines are broken.
以下の機能はほとんどのUNIXとPOSIX対応することのシステムのC図書館で通常見つけられます。ファンクションコールを満たすのに使用されるかもしれないLDAP検索フィルタ[RFC2254]はそれぞれの機能名と並んで含まれています。 パラメタはストリングと整数議論のためにそれぞれ%sと何%dも指示されます。 長い系列は壊れています。
getpwnam() (&(objectClass=posixAccount)(uid=%s))
getpwuid() (&(objectClass=posixAccount)
(uidNumber=%d))
getpwent() (objectClass=posixAccount)
getpwnam()((objectClass=posixAccount)(uid=%s))getpwuid()((objectClass=posixAccount)(uidNumber=%d))getpwent()(objectClass=posixAccount)
getspnam() (&(objectClass=shadowAccount)(uid=%s))
getspent() (objectClass=shadowAccount)
getspnam()((objectClass=shadowAccount)(uid=%s))getspent()(objectClass=shadowAccount)
getgrnam() (&(objectClass=posixGroup)(cn=%s))
getgrgid() (&(objectClass=posixGroup)
(gidNumber=%d))
getgrent() (objectClass=posixGroup)
getgrnam()((objectClass=posixGroup)(cn=%s))getgrgid()((objectClass=posixGroup)(gidNumber=%d))getgrent()(objectClass=posixGroup)
getservbyname() (&(objectClass=ipService)
(cn=%s)(ipServiceProtocol=%s))
getservbyport() (&(objectClass=ipService)
(ipServicePort=%d)
(ipServiceProtocol=%s))
getservent() (objectClass=ipService)
getservbyname()((objectClass=ipService)(cn=%s)(ipServiceProtocol=%s))getservbyport()((objectClass=ipService)(ipServicePort=%d)(ipServiceProtocol=%s))getservent()(objectClass=ipService)
getrpcbyname() (&(objectClass=oncRpc)(cn=%s))
getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d))
getrpcent() (objectClass=oncRpc)
getrpcbyname()((objectClass=oncRpc)(cn=%s))getrpcbynumber()((objectClass=oncRpc)(oncRpcNumber=%d))getrpcent()(objectClass=oncRpc)
getprotobyname() (&(objectClass=ipProtocol)(cn=%s))
getprotobynumber() (&(objectClass=ipProtocol)
(ipProtocolNumber=%d))
getprotoent() (objectClass=ipProtocol)
getprotobyname()((objectClass=ipProtocol)(cn=%s))getprotobynumber()((objectClass=ipProtocol)(ipProtocolNumber=%d))getprotoent()(objectClass=ipProtocol)
gethostbyname() (&(objectClass=ipHost)(cn=%s))
gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s))
gethostent() (objectClass=ipHost)
gethostbyname()((objectClass=ipHost)(cn=%s))gethostbyaddr()((objectClass=ipHost)(ipHostNumber=%s))gethostent()(objectClass=ipHost)
getnetbyname() (&(objectClass=ipNetwork)(cn=%s))
getnetbyaddr() (&(objectClass=ipNetwork)
(ipNetworkNumber=%s))
getnetent() (objectClass=ipNetwork)
getnetbyname()((objectClass=ipNetwork)(cn=%s))getnetbyaddr()((objectClass=ipNetwork)(ipNetworkNumber=%s))getnetent()(objectClass=ipNetwork)
setnetgrent() (&(objectClass=nisNetgroup)(cn=%s))
setnetgrent()((objectClass=nisNetgroup)(cn=%s))
Howard Experimental [Page 11] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[11ページ]RFC2307
5.3. Interpreting user and group entries
5.3. ユーザとグループエントリーを解釈します。
User and group resolution is initiated by the functions prefixed by getpw and getgr respectively. The uid attribute contains the user's login name. The cn attribute, in posixGroup entries, contains the group's name.
ユーザとグループ解決はgetpwとgetgrによってそれぞれ前に置かれた機能によって開始されます。 uid属性はユーザのログイン名を含んでいます。 posixGroupエントリーでは、cn属性がグループの名前を保管しています。
The account object class provides a convenient structural class for posixAccount, and SHOULD be used where additional attributes are not required.
アカウントオブジェクトのクラスは便利な構造的なクラスをposixAccount、およびSHOULDに供給します。追加属性は必要でないところで使用されてください。
It is suggested that uid and cn are used as the RDN attribute type for posixAccount and posixGroup entries, respectively.
RDNがposixAccountのためのタイプとposixGroupエントリーを結果と考えるときuidとcnが使用されているとそれぞれ示唆されます。
An account's GECOS field is preferably determined by a value of the gecos attribute. If no gecos attribute exists, the value of the cn attribute MUST be used. (The existence of the gecos attribute allows information embedded in the GECOS field, such as a user's telephone number, to be returned to the client without overloading the cn attribute. It also accommodates directories where the common name does not contain the user's full name.)
望ましくは、アカウントのGECOS分野はgecos属性の値で決定します。 gecos属性が全く存在していないなら、cn属性の値を使用しなければなりません。 (gecos属性の存在はcn属性を積みすぎないでクライアントに返すためにユーザの電話番号などのGECOS分野に埋め込まれた情報を許容します。 また、それは一般名がユーザのフルネームを含まないディレクトリに対応します。)
An entry of class posixAccount, posixGroup, or shadowAccount without a userPassword attribute MUST NOT be used for authentication. The client should be returned a non-matchable password such as "x".
認証にuserPassword属性のないクラスposixAccount、posixGroup、またはshadowAccountのエントリーを使用してはいけません。 「x」などの非整合のパスワードをクライアントに返すべきです。
userPassword values MUST be represented by following syntax:
構文に従うことでuserPassword値を表さなければなりません:
passwordvalue = schemeprefix encryptedpassword
schemeprefix = "{" scheme "}"
scheme = "crypt" / "md5" / "sha" / altscheme
altscheme = "x-" keystring
encryptedpassword = encrypted password
passwordvalue=schemeprefix encryptedpassword schemeprefixは「「計画してください」」という体系=「地下室」/「md5"/"sha"/altscheme altscheme=「x」keystring encryptedpassword=暗号化されたパスワード」と等しいです。
The encrypted password contains of a plaintext key hashed using the algorithm scheme.
暗号化されたパスワードが含んでいる、アルゴリズム体系を使用することで論じ尽くされた平文キーについて。
userPassword values which do not adhere to this syntax MUST NOT be used for authentication. The DUA MUST iterate through the values of the attribute until a value matching the above syntax is found. Only if encryptedpassword is an empty string does the user have no password. DUAs are not required to consider encryption schemes which the client will not recognize; in most cases, it may be sufficient to consider only "crypt".
認証にこの構文を固く守らないuserPassword値を使用してはいけません。 デュアは値までの属性の値を通して上の構文が見つけられるマッチングを繰り返さなければなりません。 encryptedpasswordが空のストリングである場合にだけ、ユーザには、パスワードが全くありませんか? DUAsはクライアントが認めない暗号化体系を考える必要はありません。 多くの場合、「地下室」だけ、を考えるのは十分であるかもしれません。
Below is an example of a userPassword attribute:
以下に、userPassword属性に関する例があります:
userPassword: {crypt}X5/DBrWPOQQaI
userPassword: 地下室X5/DBrWPOQQaI
Howard Experimental [Page 12] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[12ページ]RFC2307
A future standard may specify LDAP v3 attribute descriptions to represent hashed userPasswords, as noted below. This schema MUST NOT be used with LDAP v2 DUAs and DSAs.
将来の規格は、論じ尽くされたuserPasswordsを表すために以下に述べられるようにLDAP v3属性記述を指定するかもしれません。 LDAP v2 DUAsとDSAsと共にこの図式を使用してはいけません。
attributetype = attributename sep attributeoption
attributename = "userPassword"
sep = ";"
attributeoption = schemeclass "-" scheme
schemeclass = "hash" / altschemeclass
scheme = "crypt" / "md5" / "sha" / altscheme
altschemeclass = "x-" keystring
altscheme = keystring
「"userPassword"attributetype=attributename sep attributeoption attributename=sep=」;、」 altschemeclass体系=attributeoption=schemeclass「-」体系schemeclass=「ハッシュ」/「地下室」/「md5"/"sha"/altscheme altschemeclass=「x」keystring altscheme=keystring」
Below is an example of a userPassword attribute, represented with an LDAP v3 attribute description:
以下に、LDAP v3属性記述で表されたuserPassword属性に関する例があります:
userPassword;hash-crypt: X5/DBrWPOQQaI
userPassword;、ハッシュ地下室: X5/DBrWPOQQaI
A DUA MAY utilise the attributes in the shadowAccount class to provide shadow password service (getspnam() and getspent()). In such cases, the DUA MUST NOT make use of the userPassword attribute for getpwnam() et al, and MUST return a non-matchable password (such as "x") to the client instead.
DUA MAYは、シャドウパスワードサービスを提供するのにshadowAccountのクラスで属性を利用します。(getspnam()とgetspent())。 そのような場合、デュアは、getpwnam()他にuserPassword属性を利用してはいけなくて、代わりに、非整合のパスワード(「x」などの)をクライアントに返さなければなりません。
5.4. Interpreting hosts and networks
5.4. ホストとネットワークを解釈します。
The ipHostNumber and ipNetworkNumber attributes are defined in preference to dNSRecord (defined in [RFC1279]), in order to simplify the DUA's role in interpreting entries in the directory. A dNSRecord expresses a complete resource record, including time to live and class data, which is extraneous to this schema.
ipHostNumberとipNetworkNumber属性はdNSRecord([RFC1279]では、定義される)に優先して定義されます、ディレクトリにおけるエントリーを解釈することにおけるDUAの役割を簡素化するために。 dNSRecordはこの図式に異質な生きる時間とクラスデータを含む完全なリソース記録を言い表します。
Additionally, the ipHost and ipNetwork classes permit a host or network (respectively) and all its aliases to be represented by a single entry in the directory. This is not necessarily possible if a DNS resource record is mapped directly to an LDAP entry. Implementations that wish to use LDAP to master DNS zone information are not precluded from doing so, and may simply avoid the ipHost and ipNetwork classes.
さらに、ipHostとipNetworkのクラスは、ホストかネットワーク(それぞれ)とそのすべての別名がディレクトリにおける単一のエントリーで代理をされるのを可能にします。 DNSリソース記録が直接LDAPエントリーに写像されるなら、これは必ず可能であるというわけではありません。 DNSがゾーン情報であるとマスタリングするのにLDAPを使用するという願望をある実装は、そうするのを妨げないで、単にipHostとipNetworkのクラスを避けるかもしれません。
This document redefines, although not exclusively, the ipNetwork class defined in [RFC1279], in order to achieve consistent naming with ipHost. The ipNetworkNumber attribute is also used in the siteContact object class [ROSE].
これは再定義を記録して、排他的ではありませんが、ipNetworkのクラスは、ipHostとの一貫した命名を達成するために中で[RFC1279]を定義しました。 また、ipNetworkNumber属性はsiteContactオブジェクトのクラス[ローズ]に使用されます。
Howard Experimental [Page 13] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[13ページ]RFC2307
The trailing zeros in a network address MUST be omitted. CIDR-style network addresses (eg. 192.168.1/24) MAY be used.
ネットワーク・アドレスの末尾のゼロを省略しなければなりません。 CIDR-スタイルネットワーク・アドレス、(例えば、192.168 .1/24) 使用されるかもしれません。
Hosts with IPv6 addresses MUST be written in their "preferred" form as defined in section 2.2.1 of [RFC1884], such that all components of the address are indicated and leading zeros are omitted. This provides a consistent means of resolving ipHosts by address.
.1セクション2.2[RFC1884]、アドレスのすべての成分が示されるようなもの、および先行ゼロで定義されるようにそれらの「都合のよい」フォームにアドレスを書かなければならないIPv6のホストは省略されます。 これはアドレスでipHostsを決議する一貫した手段を提供します。
5.5. Interpreting other entities
5.5. 他の実体を解釈します。
In general, a one-to-one mapping between entities and LDAP entries is proposed, in that each entity has exactly one representation in the DIT. In some cases this is not feasible; for example, a service which is represented in more than one protocol domain. Consider the following entry:
一般に、実体とLDAPエントリーの間の1〜1つのマッピングが提案されます、各実体がDITにまさに1つの表現を持っているので。 いくつかの場合、これは可能ではありません。 例えば1つ以上のプロトコルドメインに表されるサービス。 以下のエントリーを考えてください:
dn: cn=domain, dc=aja, dc=com
cn: domain
cn: nameserver
objectClass: top
objectClass: ipService
ipServicePort: 53
ipServiceProtocol: tcp
ipServiceProtocol: udp
dn: cnはドメイン、dc=aja、dc=com cnと等しいです: ドメインcn: ネームサーバobjectClass: 最高objectClass: ipService ipServicePort: 53ipServiceProtocol: tcp ipServiceProtocol: udp
This entry MUST map to the following two (2) services entities:
このエントリーは以下の2(2)サービスに実体を写像しなければなりません:
domain 53/tcp nameserver
domain 53/udp nameserver
ドメイン53/tcpネームサーバドメイン53/udpネームサーバ
While the above two entities may be represented as separate LDAP entities, with different distinguished names (such as cn=domain+ipServiceProtocol=tcp, ... and cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent them as a single entry. (If a service is represented in multiple protocol domains with different ports, then multiple entries are required; multivalued RDNs may be used to distinguish them.)
上の2つの実体が別々のLDAP実体として表されるかもしれませんが、異なった分類名(cn=ドメイン+ipServiceProtocol=tcp(cn=ドメイン+ipServiceProtocol=udp)などの)に、単一のエントリーとしてそれらを表すのは便利です。 (サービスが異なったポートがある複数のプロトコルドメインに表されるなら、当時の多回入国が必要です; 多値のRDNsは彼らを区別するのに使用されるかもしれません。)
With the exception of userPassword values, which are parsed according to the syntax considered in section 5.2, any empty values (consisting of a zero length string) are returned by the DUA to the client. The DUA MUST reject any entries which do not conform to the schema (missing mandatory attributes). Non-conforming entries SHOULD be ignored while enumerating entries.
userPassword値を除いて、どんな空の値(ゼロ長ストリングから成る)もDUAによってクライアントに返されます。(セクション5.2で考えられた構文によると、値は分析されます)。 デュアは図式(なくなった義務的な属性)に従わない少しのエントリーも拒絶しなければなりません。 非の従うエントリーSHOULD、エントリーを列挙している間、無視されてください。
The nisObject object class MAY be used as a generic means of representing NIS entities. Its use is not encouraged; where support for entities not described in this schema is desired, an appropriate
nisObjectオブジェクトのクラスはNIS実体を表すジェネリック手段として使用されるかもしれません。 使用は奨励されません。 この図式で説明されなかった実体のサポートが望まれているところ、適切
Howard Experimental [Page 14] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[14ページ]RFC2307
schema should be devised. Implementors are strongly advised to support end-user extensible mappings between NIS entities and object classes. (Where the nisObject class is used, the nisMapName attribute may be used as a RDN.)
図式は工夫されるべきです。 作成者がNISの間のエンドユーザの広げることができるマッピングに実体とオブジェクトのクラスをサポートするように強くアドバイスされます。 (nisObjectのクラスが使用されているところでは、nisMapName属性はRDNとして使用されるかもしれません。)
5.6. Canonicalizing entries with multi-valued naming attributes
5.6. マルチ評価された命名属性でエントリーをCanonicalizingします。
For entities such as hosts, services, networks, protocols, and RPCs, where there may be one or more aliases, the respective entry's relative distinguished name SHOULD be used to determine the canonical name. Any other values for the same attribute are used as aliases. For example, the service described in section 5.5 has the canonical name "domain" and exactly one alias, "nameserver".
ホストや、サービスや、ネットワークや、プロトコルや、RPCsなどの実体において、正準な名前を決定するのにおいて使用されてください。(そこに、1つ以上の別名、それぞれのエントリーの相対的な分類名SHOULDがあるかもしれません)。 同じ属性のためのいかなる他の値も別名として使用されます。 例えば、セクション5.5で説明されたサービスは「ドメイン」という正準な名前とまさに1つの別名、「ネームサーバ」を持っています。
The schema in this document generally only defines one attribute per class which is suitable for distinguishing an entity (excluding any attributes with integer syntax; it is assumed that entries will be distinguished on name). Usually, this is the common name (cn) attribute. This aids the DUA in determining the canonical name of an entity, as it can examine the value of the relative distinguished name. Aliases are thus any values of the distinguishing attribute (such as cn) which do not match the canonical name of the entity.
一般に、図式は本書では実体を区別するのに適当なクラスあたり1つの属性しか定義しません(整数構文があるどんな属性を除いて; エントリーが名前で区別されると思われます)。 通常、これは一般名(cn)属性です。 これは実体の正準な名前を決定する際にDUAを支援します、相対的な分類名の値を調べることができるとき。 その結果、別名は実体の正準な名前に合っていない区別属性(cnなどの)のあらゆる値です。
In the event that a different attribute is used to distinguish the entry, as may be the case where these object classes are used as auxiliary classes, the entry's canonical name may not be present in the RDN. In this case, the DUA MUST choose one of the non- distinguished values to represent the entity's canonical name. As the directory server guarantees no ordering of attribute values, it may not be possible to distinguish an entry deterministically. This ambiguity SHOULD NOT be resolved by mapping one directory entry into multiple entities.
そうであるかもしれないようにこれらのオブジェクトのクラスが補助のクラスとして使用される異なった属性がエントリーを区別するのに使用される場合、エントリーの正準な名前はRDNに存在していないかもしれません。 この場合、デュアは、実体の正準な名前を表すために非顕著な値の1つを選ばなければなりません。 ディレクトリサーバが属性値の注文でないのを保証するとき、決定論的にエントリーを区別するのは可能でないかもしれません。 このあいまいさSHOULD NOT、1つのディレクトリエントリを複数の実体に写像することによって、決議されてください。
6. Implementation focus
6. 実装焦点
A NIS server which uses LDAP instead of local files has been developed which supports the schema defined in this document.
ローカルファイルの代わりにLDAPを使用するNISサーバを開発してあります(本書では定義された図式をサポートします)。
A reference implementation of the C library resolution code has been written for the Free Software Foundation. It may support other C libraries which support the Name Service Switch (NSS) or the Information Retrieval Service (IRS).
Cライブラリ解決コードの参照実装はフリーソフトウェア基金のために書かれています。 それは、他のCがName Service Switch(NSS)か情報Retrieval Service(IRS)をサポートするライブラリであるとサポートするかもしれません。
The author has made available a freely distributable set of scripts which parses local databases such as /etc/passwd and /etc/hosts into a form suitable for loading into an LDAP server.
作者はLDAPサーバにロードするのに適当なフォームに/etc/passwdや/etc/hostsなどのローカルのデータベースを分析するスクリプトの自由に配置可能なセットを利用可能にしました。
Howard Experimental [Page 15] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[15ページ]RFC2307
7. Security Considerations
7. セキュリティ問題
The entirety of related security considerations are outside the scope of this document. It is noted that making passwords encrypted with a widely understood hash function (such as crypt()) available to non- privileged users is dangerous because it exposes them to dictionary and brute-force attacks. This is proposed only for compatibility with existing UNIX system implementations. Sites where security is critical SHOULD consider using a strong authentication service for user authentication.
このドキュメントの範囲の外に関連するセキュリティ問題の全体があります。 広く理解されているハッシュで暗号化されたパスワードを作るのが機能するのが有名です。(辞書と全数探索法に彼らを暴露するので、非特権ユーザにとって、利用可能な地下室())としてのそのようなものは危険です。 これは既存のUNIXシステムの実現との互換性のためだけに提案されます。 セキュリティが重要なSHOULDが、ユーザー認証に強い認証サービスを使用すると考えるということであるサイト。
Alternatively, the encrypted password could be made available only to a subset of privileged DUAs, which would provide "shadow" password service to client applications. This may be difficult to enforce.
あるいはまた、特権があるDUAsの部分集合だけが暗号化されたパスワードを入手するかもしれません。(DUAsはクライアントアプリケーションに対する「影」パスワードサービスを提供するでしょう)。 これは実施するのが難しいかもしれません。
Because the schema represents operating system-level entities, access to these entities SHOULD be granted on a discretionary basis. (There is little point in restricting access to data which will be republished without restriction, however.) It is particularly important that only administrators can modify entries defined in this schema, with the exception of allowing a principal to change their password (which may be done on behalf of the user by a client bound as a superior principal, such that password restrictions may be enforced). For example, if a user were allowed to change the value of their uidNumber attribute, they could subvert security by equivalencing their account with the superuser account.
図式がオペレーティングシステムレベル実体を表すので、実体SHOULDにこれらにアクセスしてください。任意ベースでは、与えます。 (しかしながら、制限なしで再刊されるデータへのアクセスを制限するのは無意味です。) 管理者だけがこの図式で定義されたエントリーを変更できるのは、特に重要です、元本がそれらのパスワードを変えるのを許容するのを除いて(クライアントがユーザを代表してどれをするかもしれないかはパスワード制限を励行されることができるように、優れた元本として付きました)。 例えば、ユーザがそれらのuidNumber属性の値を変えることができるなら、彼らは、「スーパー-ユーザ」アカウントとのそれらのアカウントをequivalencingすることによって、セキュリティを打倒するかもしれないでしょうに。
A subtree of the DIT which is to be republished by a DUA (such as a NIS gateway) SHOULD be within the same administrative domain that the republishing DUA represents. (For example, principals outside an organization, while conceivably part of the DIT, should not be considered with the same degree of authority as those within the organization.)
DUA(NISゲートウェイなどの)SHOULDによって再刊されることになっているDITの下位木は同じくらい中のそうです。再刊DUAが表す管理ドメイン。 (例えば、多分間の組織の外における校長はDITを離れさせて、組織の中のそれらへの同じ度合いの権威で考えるべきではありません。)
Finally, care should be exercised with integer attributes of a sensitive nature (particularly the uidNumber and gidNumber attributes) which contain zero-length values. DUAs MAY treat such values as corresponding to the "nobody" or "nogroup" user and group, respectively.
最終的に、ゼロ・レングス値を含む敏感な本質(特にuidNumberとgidNumber属性)の整数属性に従って、注意が行われるべきです。 DUAsは「一人も」か"nogroup"ユーザにとって、同じくらい対応するそのような値を扱って、それぞれ分類するかもしれません。
8. Acknowledgements
8. 承認
Thanks to Leif Hedstrom of Netscape Communications Corporation, Michael Grant and Rosanna Lee of Sun Microsystems Inc., Ed Reed of Novell Inc., and Mark Wahl of Critical Angle Inc. for their valuable contributions to the development of this schema. Thanks to Andrew Josey of The Open Group for clarifying the use of the UNIX trademark, and to Tim Howes and Peter J. Cherny for their support.
この図式の開発への彼らの有価約因をネットスケープ社のリーフ・ヘッドストロム、サン・マイクロシステムズのマイケル・グラントとロザンナ・リー、ノベル株式会社のエド・リード、およびCritical Angle Inc.のマーク・ウォールをありがとうございます。 彼らのサポートをUNIX商標の使用をはっきりさせるためのTheOpenGroupのアンドリューJoseyと、そして、ティム・ハウズとピーターJ.Chernyをありがとうございます。
Howard Experimental [Page 16] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[16ページ]RFC2307
UNIX is a registered trademark of The Open Group.
UNIXはTheOpenGroupの登録商標です。
9. References
9. 参照
[RFC1057]
Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol
Specification Version 2", RFC 1057, June 1988.
[RFC1057]サン・マイクロシステムズ・インク、「RPC:」 遠隔手続き呼び出し: 1988年6月に仕様バージョン2インチ、RFC1057について議定書の中で述べてください。
[RFC1279]
Kille, S., "X.500 and Domains", RFC 1279, November 1991.
[RFC1279] Killeと、S.と、「X.500とドメイン」、RFC1279、11月1991日
[RFC1884]
Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
[RFC1884] Hinden、R.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC1884、1995年12月。
[RFC2119]
Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のための主要なワーズ」、BCP14、RFC2119、1997年3月。
[RFC2251]
Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ウォール、M.、ハウズ、T.、およびS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[RFC2252]
Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[RFC2252] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[RFC2254]
Howes, T., "The String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[RFC2254] ハウズ、T.、「LDAP検索フィルタのストリング表現」、RFC2254、1997年12月。
[RFC2256]
Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[RFC2256] ウォール、M.、「LDAPv3"、RFC2256、1997年12月との使用のためのX.500(96)ユーザSchemaのSummary。」
[ROSE]
M. T. Rose, "The Little Black Book: Mail Bonding with OSI
Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc.,
1992.
[上昇しました] M.T.ローズ、「少ない黒人が以下を予約します」。 「OSIディレクトリサービスに固着するメール」、ISBN0-13-683210-5、新米のホールのInc.、1992。
[X500]
"Information Processing Systems - Open Systems Interconnection -
The Directory: Overview of Concepts, Models and Service",
ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988.
[X500]、「情報処理システム--オープン・システム・インターコネクション--ディレクトリ:、」 「概念の、そして、モデルの、そして、サービスの概要」、ISO/IEC JTC1/SC21、国際規格9594-1、1988。
Howard Experimental [Page 17] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[17ページ]RFC2307
[XOPEN]
ISO/IEC 9945-1:1990, Information Technology - Portable Operating
Systems Interface (POSIX) - Part 1: Systems Application
Programming Interface (API) [C Language]
情報技術--携帯用のオペレーティングシステムインタフェース(POSIX)--[XOPEN]ISO/IEC9945-1:1990、第1部: システムアプリケーションプログラミングインターフェース(API)[C言語]
10. Author's Address
10. 作者のアドレス
Luke Howard PO Box 59 Central Park Vic 3145 Australia
ルークハワードPO Box59セントラルパークヴィク3145・オーストラリア
EMail: lukeh@xedoc.com
メール: lukeh@xedoc.com
Howard Experimental [Page 18] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[18ページ]RFC2307
A. Example entries
A。 例のエントリー
The examples described in this section are provided to illustrate the schema described in this memo. They are not meant to be exhaustive.
このメモで説明された図式を例証するためにこのセクションで説明された例を提供します。 それらが徹底的であることが意味されません。
The following entry is an example of the posixAccount class:
以下のエントリーはposixAccountのクラスに関する例です:
dn: uid=lester, dc=aja, dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
uid: lester
cn: Lester the Nightfly
userPassword: {crypt}X5/DBrWPOQQaI
gecos: Lester
loginShell: /bin/csh
uidNumber: 10
gidNumber: 10
homeDirectory: /home/lester
dn: uid=lester、dc=aja、dc=com objectClass: 最高objectClass: objectClassを説明してください: posixAccount uid: lester cn: レスターナイトフライuserPassword: 地下室X5/DBrWPOQQaI gecos: レスターloginShell: /bin/csh uidNumber: 10gidNumber: 10homeDirectory: /home/lester
This corresponds the UNIX system password file entry:
これは対応しています。UNIXシステムパスワードはエントリーをファイルします:
lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
lester:X5/DBrWPOQQaI:10:10:レスター:/home/lester:/bin/sh
The following entry is an example of the ipHost class:
以下のエントリーはipHostのクラスに関する例です:
dn: cn=peg.aja.com, dc=aja, dc=com
objectClass: top
objectClass: device
objectClass: ipHost
objectClass: bootableDevice
objectClass: ieee802Device
cn: peg.aja.com
cn: www.aja.com
ipHostNumber: 10.0.0.1
macAddress: 00:00:92:90:ee:e2
bootFile: mach
bootParameter: root=fs:/nfsroot/peg
bootParameter: swap=fs:/nfsswap/peg
bootParameter: dump=fs:/nfsdump/peg
dn: cn=peg.aja.com、dc=aja、dc=com objectClass: 最高objectClass: デバイスobjectClass: ipHost objectClass: bootableDevice objectClass: ieee802Device cn: peg.aja.com cn: www.aja.com ipHostNumber: 10.0.0.1 macAddress: 00:00:92:90:ee: e2 bootFile: mach bootParameter: 根=fs: /nfsroot/peg bootParameter: =fs: /nfsswap/peg bootParameterを交換してください: ダンプ=fs: /nfsdump/peg
This entry represents the host canonically peg.aja.com, also known as www.aja.com. The Ethernet address and four boot parameters are also specified.
このエントリーはまた、www.aja.comとして知られているホストcanonically peg.aja.comを表します。 また、イーサネット・アドレスと4つのブーツパラメタが指定されます。
Howard Experimental [Page 19] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[19ページ]RFC2307
An example of the nisNetgroup class:
nisNetgroupのクラスに関する例:
dn: cn=nightfly, dc=aja, dc=com
objectClass: top
objectClass: nisNetgroup
cn: nightfly
nisNetgroupTriple: (charlemagne,peg,dunes.aja.com)
nisNetgroupTriple: (lester,-,)
memberNisNetgroup: kamakiriad
dn: cn=nightfly、dc=aja、dc=com objectClass: 最高objectClass: nisNetgroup cn: nightfly nisNetgroupTriple: (charlemagne、釘、dunes.aja.com) nisNetgroupTriple: (lester、-、) memberNisNetgroup: kamakiriad
This entry represents the netgroup nightfly, which contains two triples (the user charlemagne, the host peg, and the domain dunes.aja.com; and, the user lester, no host, and any domain) and one netgroup (kamakiriad).
このエントリーはnetgroup nightflyを表して、どれが2を含んでいるかは3倍になります。そして、(ユーザcharlemagne、ホストが最高値を越える、ドメインdunes.aja.com;、ユーザlester、ホストがなく、およびどんなドメインも) そして、1netgroup(kamakiriad)。
Finally, an example of the nisObject class:
最終的にnisObjectのクラスに関する例:
dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com
objectClass: top
objectClass: nisMap
nisMapName: tracks
dn: nisMapNameは道と等しく、dcは砂丘、dc=aja、dc=com objectClassと等しいです: 最高objectClass: nisMap nisMapName: 道
dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com
objectClass: top
objectClass: nisObject
cn: Maxine
nisMapName: tracks
nisMapEntry: Nightfly$4
dn: cnはマクシーンと等しく、nisMapNameは道と等しく、dcは砂丘、dc=aja、dc=com objectClassと等しいです: 最高objectClass: nisObject cn: マクシーンnisMapName: 道のnisMapEntry: ナイトフライ4ドル
This entry represents the NIS map tracks, and a single map entry.
このエントリーはNIS地図道、および単一の地図エントリーを表します。
Howard Experimental [Page 20] RFC 2307 Using LDAP as a Network Information Service March 1998
1998年3月にネットワーク情報サービスとしてLDAPを使用するハワード実験的な[20ページ]RFC2307
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Howard Experimental [Page 21]
ハワードExperimentalです。[21ページ]
一覧
スポンサーリンク
