mirror of
https://github.com/samba-team/samba.git
synced 2024-12-24 21:34:56 +03:00
1180 lines
40 KiB
Plaintext
1180 lines
40 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group L. Howard
|
|||
|
Request for Comments: 2307 Independent Consultant
|
|||
|
Category: Experimental March 1998
|
|||
|
|
|||
|
|
|||
|
An Approach for Using LDAP as a Network Information Service
|
|||
|
|
|||
|
Status of this 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.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (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.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
1. Background and Motivation
|
|||
|
|
|||
|
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.)
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 1]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
netgroups, booting information (boot parameters and MAC address
|
|||
|
mappings), filesystem mounts, IP hosts and networks, and RFC822 mail
|
|||
|
aliases.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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.)
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
2. General Issues
|
|||
|
|
|||
|
2.1. Terminology
|
|||
|
|
|||
|
The key words "MUST", "SHOULD", and "MAY" used in this document are
|
|||
|
to be interpreted as described in [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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 2]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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".
|
|||
|
|
|||
|
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).
|
|||
|
|
|||
|
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).
|
|||
|
|
|||
|
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.)
|
|||
|
|
|||
|
The OIDs defined below are derived from iso(1) org(3) dod(6)
|
|||
|
internet(1) directory(1) nisSchema(1).
|
|||
|
|
|||
|
2.2. Attributes
|
|||
|
|
|||
|
The attributes and classes defined in this document are summarized
|
|||
|
below.
|
|||
|
|
|||
|
The following attributes are defined in this document:
|
|||
|
|
|||
|
uidNumber
|
|||
|
gidNumber
|
|||
|
gecos
|
|||
|
homeDirectory
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 3]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
2.3. Object classes
|
|||
|
|
|||
|
The following object classes are defined in this document:
|
|||
|
|
|||
|
posixAccount
|
|||
|
shadowAccount
|
|||
|
posixGroup
|
|||
|
ipService
|
|||
|
ipProtocol
|
|||
|
oncRpc
|
|||
|
ipHost
|
|||
|
ipNetwork
|
|||
|
nisNetgroup
|
|||
|
nisMap
|
|||
|
nisObject
|
|||
|
ieee802Device
|
|||
|
bootableDevice
|
|||
|
|
|||
|
Additionally, some of the classes defined in [RFC2256] are required.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 4]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
2.4. Syntax definitions
|
|||
|
|
|||
|
The following syntax definitions [RFC2252] are used by this schema.
|
|||
|
The nisNetgroupTripleSyntax represents NIS netgroup triples:
|
|||
|
|
|||
|
( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax'
|
|||
|
DESC 'NIS netgroup triple' )
|
|||
|
|
|||
|
Values in this syntax are represented by the following:
|
|||
|
|
|||
|
nisnetgrouptriple = "(" hostname "," username "," domainname ")"
|
|||
|
hostname = "" / "-" / keystring
|
|||
|
username = "" / "-" / keystring
|
|||
|
domainname = "" / "-" / keystring
|
|||
|
|
|||
|
X.500 servers may use the following representation of the above
|
|||
|
syntax:
|
|||
|
|
|||
|
nisNetgroupTripleSyntax ::= SEQUENCE {
|
|||
|
hostname [0] IA5String OPTIONAL,
|
|||
|
username [1] IA5String OPTIONAL,
|
|||
|
domainname [2] IA5String OPTIONAL
|
|||
|
}
|
|||
|
|
|||
|
The bootParameterSyntax syntax represents boot parameters:
|
|||
|
|
|||
|
( nisSchema.0.1 NAME 'bootParameterSyntax'
|
|||
|
DESC 'Boot parameter' )
|
|||
|
|
|||
|
where:
|
|||
|
|
|||
|
bootparameter = key "=" server ":" path
|
|||
|
key = keystring
|
|||
|
server = keystring
|
|||
|
path = keystring
|
|||
|
|
|||
|
X.500 servers may use the following representation of the above
|
|||
|
syntax:
|
|||
|
|
|||
|
bootParameterSyntax ::= SEQUENCE {
|
|||
|
key IA5String,
|
|||
|
server IA5String,
|
|||
|
path IA5String
|
|||
|
}
|
|||
|
|
|||
|
Values adhering to these syntaxes are encoded as strings by LDAP
|
|||
|
servers.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 5]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
3. Attribute definitions
|
|||
|
|
|||
|
This section contains attribute definitions to be implemented by DUAs
|
|||
|
supporting this schema.
|
|||
|
|
|||
|
( 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'
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 6]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
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'
|
|||
|
EQUALITY caseIgnoreIA5Match
|
|||
|
SYNTAX 'IA5String{128}' )
|
|||
|
|
|||
|
( nisSchema.1.20 NAME 'ipNetworkNumber'
|
|||
|
DESC 'IP network as a dotted decimal, eg. 192.168,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 7]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
omitting leading zeros'
|
|||
|
EQUALITY caseIgnoreIA5Match
|
|||
|
SYNTAX 'IA5String{128}' 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 )
|
|||
|
|
|||
|
4. Class definitions
|
|||
|
|
|||
|
This section contains class definitions to be implemented by DUAs
|
|||
|
supporting the schema.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
( 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 ) )
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 8]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
( 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 $ description )
|
|||
|
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 ) )
|
|||
|
|
|||
|
( 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'
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 9]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
MUST ( cn $ ipNetworkNumber )
|
|||
|
MAY ( 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.09 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 ) )
|
|||
|
|
|||
|
5. Implementation details
|
|||
|
|
|||
|
5.1. Suggested resolution methods
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 10]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
5.2. Affected library functions
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
getpwnam() (&(objectClass=posixAccount)(uid=%s))
|
|||
|
getpwuid() (&(objectClass=posixAccount)
|
|||
|
(uidNumber=%d))
|
|||
|
getpwent() (objectClass=posixAccount)
|
|||
|
|
|||
|
getspnam() (&(objectClass=shadowAccount)(uid=%s))
|
|||
|
getspent() (objectClass=shadowAccount)
|
|||
|
|
|||
|
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)
|
|||
|
|
|||
|
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)
|
|||
|
|
|||
|
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)
|
|||
|
|
|||
|
setnetgrent() (&(objectClass=nisNetgroup)(cn=%s))
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 11]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
5.3. Interpreting user and group entries
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
The account object class provides a convenient structural class for
|
|||
|
posixAccount, and SHOULD be used where additional attributes are not
|
|||
|
required.
|
|||
|
|
|||
|
It is suggested that uid and cn are used as the RDN attribute type
|
|||
|
for posixAccount and posixGroup entries, respectively.
|
|||
|
|
|||
|
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.)
|
|||
|
|
|||
|
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 values MUST be represented by following syntax:
|
|||
|
|
|||
|
passwordvalue = schemeprefix encryptedpassword
|
|||
|
schemeprefix = "{" scheme "}"
|
|||
|
scheme = "crypt" / "md5" / "sha" / altscheme
|
|||
|
altscheme = "x-" keystring
|
|||
|
encryptedpassword = encrypted password
|
|||
|
|
|||
|
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".
|
|||
|
|
|||
|
Below is an example of a userPassword attribute:
|
|||
|
|
|||
|
userPassword: {crypt}X5/DBrWPOQQaI
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 12]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
attributetype = attributename sep attributeoption
|
|||
|
attributename = "userPassword"
|
|||
|
sep = ";"
|
|||
|
attributeoption = schemeclass "-" scheme
|
|||
|
schemeclass = "hash" / altschemeclass
|
|||
|
scheme = "crypt" / "md5" / "sha" / altscheme
|
|||
|
altschemeclass = "x-" keystring
|
|||
|
altscheme = keystring
|
|||
|
|
|||
|
|
|||
|
Below is an example of a userPassword attribute, represented with an
|
|||
|
LDAP v3 attribute description:
|
|||
|
|
|||
|
userPassword;hash-crypt: 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.
|
|||
|
|
|||
|
5.4. Interpreting hosts and networks
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 13]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
The trailing zeros in a network address MUST be omitted. CIDR-style
|
|||
|
network addresses (eg. 192.168.1/24) MAY be used.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
5.5. Interpreting other entities
|
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
dn: cn=domain, dc=aja, dc=com
|
|||
|
cn: domain
|
|||
|
cn: nameserver
|
|||
|
objectClass: top
|
|||
|
objectClass: ipService
|
|||
|
ipServicePort: 53
|
|||
|
ipServiceProtocol: tcp
|
|||
|
ipServiceProtocol: udp
|
|||
|
|
|||
|
This entry MUST map to the following two (2) services entities:
|
|||
|
|
|||
|
domain 53/tcp nameserver
|
|||
|
domain 53/udp nameserver
|
|||
|
|
|||
|
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.)
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 14]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
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.)
|
|||
|
|
|||
|
5.6. Canonicalizing entries with multi-valued naming attributes
|
|||
|
|
|||
|
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".
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
6. Implementation focus
|
|||
|
|
|||
|
A NIS server which uses LDAP instead of local files has been
|
|||
|
developed which supports the schema defined in this document.
|
|||
|
|
|||
|
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).
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 15]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
7. Security Considerations
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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.)
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
8. Acknowledgements
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 16]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
UNIX is a registered trademark of The Open Group.
|
|||
|
|
|||
|
9. References
|
|||
|
|
|||
|
[RFC1057]
|
|||
|
Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol
|
|||
|
Specification Version 2", RFC 1057, June 1988.
|
|||
|
|
|||
|
[RFC1279]
|
|||
|
Kille, S., "X.500 and Domains", RFC 1279, November 1991.
|
|||
|
|
|||
|
[RFC1884]
|
|||
|
Hinden, R., and S. Deering, "IP Version 6 Addressing
|
|||
|
Architecture", RFC 1884, December 1995.
|
|||
|
|
|||
|
[RFC2119]
|
|||
|
Bradner, S., "Key Words for use in RFCs to Indicate Requirement
|
|||
|
Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[RFC2251]
|
|||
|
Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
|
|||
|
Protocol (v3)", RFC 2251, December 1997.
|
|||
|
|
|||
|
[RFC2252]
|
|||
|
Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
|
|||
|
Directory Access Protocol (v3): Attribute Syntax Definitions",
|
|||
|
RFC 2252, December 1997.
|
|||
|
|
|||
|
[RFC2254]
|
|||
|
Howes, T., "The String Representation of LDAP Search Filters",
|
|||
|
RFC 2254, December 1997.
|
|||
|
|
|||
|
[RFC2256]
|
|||
|
Wahl, M., "A Summary of the X.500(96) User Schema for use with
|
|||
|
LDAPv3", RFC 2256, December 1997.
|
|||
|
|
|||
|
[ROSE]
|
|||
|
M. T. Rose, "The Little Black Book: Mail Bonding with OSI
|
|||
|
Directory Services", ISBN 0-13-683210-5, Prentice-Hall, 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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 17]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
[XOPEN]
|
|||
|
ISO/IEC 9945-1:1990, Information Technology - Portable Operating
|
|||
|
Systems Interface (POSIX) - Part 1: Systems Application
|
|||
|
Programming Interface (API) [C Language]
|
|||
|
|
|||
|
10. Author's Address
|
|||
|
|
|||
|
Luke Howard
|
|||
|
PO Box 59
|
|||
|
Central Park Vic 3145
|
|||
|
Australia
|
|||
|
|
|||
|
EMail: lukeh@xedoc.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 18]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
A. Example entries
|
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
This corresponds the UNIX system password file entry:
|
|||
|
|
|||
|
lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
|
|||
|
|
|||
|
The following entry is an example of the ipHost class:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 19]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
An example of the nisNetgroup class:
|
|||
|
|
|||
|
dn: cn=nightfly, dc=aja, dc=com
|
|||
|
objectClass: top
|
|||
|
objectClass: nisNetgroup
|
|||
|
cn: nightfly
|
|||
|
nisNetgroupTriple: (charlemagne,peg,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).
|
|||
|
|
|||
|
Finally, an example of the nisObject class:
|
|||
|
|
|||
|
dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com
|
|||
|
objectClass: top
|
|||
|
objectClass: nisMap
|
|||
|
nisMapName: tracks
|
|||
|
|
|||
|
dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com
|
|||
|
objectClass: top
|
|||
|
objectClass: nisObject
|
|||
|
cn: Maxine
|
|||
|
nisMapName: tracks
|
|||
|
nisMapEntry: Nightfly$4
|
|||
|
|
|||
|
This entry represents the NIS map tracks, and a single map entry.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Howard Experimental [Page 20]
|
|||
|
|
|||
|
RFC 2307 Using LDAP as a Network Information Service March 1998
|
|||
|
|
|||
|
|
|||
|
Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (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.
|
|||
|
|
|||
|
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]
|
|||
|
|