Ldap Schema Viewer
Objectclass : ipHost
ID: nisSchema.2.6
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.
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.
BNC Syntax: 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 )
rfc2307
Extends objectClass:
Attributes:
Requires :
May Have:
Comments
Attribute: cn
(based on attribute name)
Description:
This is the X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person's full name.
BNC Syntax: 2.5.4.3 NAME 'cn' SUP name
rfc2256
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Description: IP address as a dotted decimal, eg. 192.168.1.1, omitting leading zeros
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.
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.
BNC Syntax: nisSchema.1.19 NAME 'ipHostNumber' DESC 'IP address as a dotted decimal, eg. 192.168.1.1, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128}
rfc2307
ID : 1.3.6.1.4.1.1466.115.121.1.26
The encoding of a value in this syntax is the string value itself.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String'
rfc2252
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax: 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
rfc2252
Attribute: l
(based on attribute name)
Description:
This attribute contains the name of a locality, such as a city, county or other geographic region (localityName).
Example:
Bale
B\c3ale (with a T.61 encoded accented character) Basel
Basilea
Basle
BNC Syntax: 2.5.4.7 NAME 'l' SUP name
rfc1617
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Description:
This attribute contains a human-readable description of the object.
A short informal explanation of special interests of a person or organisation. Overlap with businessCategory, organizationalStatus and title should be avoided.
Example:
Networking, distributed systems, OSI, implementation.
BNC Syntax: 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
rfc1617
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Description:
BNC Syntax: 0.9.2342.19200300.100.1.10 NAME 'manager' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
rfc2798
Syntax: DN
ID : 1.3.6.1.4.1.1466.115.121.1.12
Values in the Distinguished Name syntax are encoded to have the representation defined in [5]. Note that this representation is not reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as the CHOICE of any DirectoryString element in an RDN is no longer known.
Examples (from [5]):
CN=Steve Kille,O=Isode Limited,C=GB
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
CN=Before\0DAfter,O=Test,C=GB
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
SN=Lu\C4\8Di\C4\87
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN'
rfc2252
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax: 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
rfc2252
Description:
An LDAP server implementation SHOULD recognize the attribute types described in this section. The values of the objectClass attribute describe the kind of object which an entry represents. The objectClass attribute is present in every entry, with at least two values. One of the values is either "top" or "alias".
BNC Syntax: 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
rfc2256
Syntax: OID
ID : 1.3.6.1.4.1.1466.115.121.1.38
Values in the Object Identifier syntax are encoded according to the BNF in section 4.1 for "oid".
Example:
1.2.3.4
cn
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID'
rfc2252
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
If the client supplies a filter using an objectIdentifierMatch whose
matchValue oid is in the "descr" form, and the oid is not recognized
by the server, then the filter is Undefined.
BNC Syntax: 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
rfc2252
|