LDAP System Administration [Electronic resources] نسخه متنی

2.2 What Is an Attribute?

The
concepts of attribute types and attribute syntax were mentioned
briefly in the previous chapter. Attribute types and the associated
syntax rules are similar to variable and data type declarations found
in many programming languages. The comparison is not that big of a
stretch. Attributes are used to hold values. Variables in programs
perform a similar taskthey store information.

When
a variable is declared in a program, it is defined to be of a certain
data type. This data type specifies what type of information can be
stored in the variable, along with certain other rules, such as how
to compare the variable's value to the data stored
in another variable of the same type. For example, declaring a 16-bit
integer variable in a program and then assigning it a value of
1,000,000 would make no sense (the maximum value represented by a
signed 16-bit integer is 32,767). The data type of a 16-bit integer
determines what data can be stored. The data type also determines how
values of like type can be compared. Is 3 < 5? Yes, of course it
is. How do you know? Because there exists a set of rules for
comparing integers with other integers. The syntax of LDAP attribute
types performs a similar function as the data type in these examples.

Unlike variables, however, LDAP attributes can be
multivalued. Most procedural
programming languages today enforce "store and
replace" semantics of variable assignment, and so my
analogy falls apart. That is, when you assign a new value to a
variable, its old value is replaced. As you'll see,
this isn't true for LDAP; assigning a new value to
an attribute adds the value to the list of values the attribute
already has. Here's the LDIF listing for the
ou=devices,dc=plainjoe,dc=org entry from Figure 2-1; it demonstrates the purpose of multivalued
attributes:

# LDIF listing for dn: ou=devices,dc=plainjoe,dc=org
dn: ou=devices,dc=plainjoe,dc=org
objectclass: organizationalUnit
ou: devices
telephoneNumber: +1 256 555-5446
telephoneNumber: +1 256 555-5447
description: Container for all network enabled 
devices existing within the plainjoe.org domain

Note that the description attribute spans two lines. Line continuation in LDIF is implemented by leaving exactly one space at the beginning of a line. LDIF does not require a backslash (\) to continue one line to the next, as is common in many Unix configuration files.

The LDIF file lists two values for the
telephoneNumber attribute. In real life,
it's common for an entity to be reachable via two or
more phone numbers. Be aware that some attributes can contain only a
single value at any given time. Whether an attribute is single- or
multivalued depends on the attribute's definition in
the server's schema. Examples of single-valued
attributes include an entry's country
(c), displayable name
(displayName), or a user's Unix
numeric ID (uidNumber).

2.2.1 Attribute Syntax

An
attribute type's definition lays the groundwork for
answers to questions such as, "What type of values
can be stored in this attribute?",
"Can these two values be
compared?", and, if so, "How should
the comparison take place?"

Continuing with our telephoneNumber example,
suppose you search the directory for the person who owns the phone
number 555-5446. This may seem easy when you first think about it.
However, RFC 2252 explains that a telephone number can contain
characters other than digits (0-9) and a hyphen (-). A telephone
number can include:

a-z

A-Z

0-9

Various punctuation characters such as commas, periods, parentheses,
hyphens, colons, question marks, and spaces

555.5446 or 555 5446 are also correct matches to 555-5446. What about
the area code? Should we also use it in a comparison of phone
numbers?

Attribute type definitions include
matching rules that tell an LDAP server how to make
comparisonswhich, as we've seen,
isn't as easy as it seems. In Figure 2-3, taken from RFC 2256, the
telephoneNumber attribute has two associated
matching rules. The telephoneNumberMatch rule is
used for equality comparisons. While RFC 2552 defines
telephoneNumberMatch as a whitespace-insensitive
comparison only, this rule is often implemented to be
case-insensitive as well. The
telephoneNumberSubstringsMatch rule is used for
partial telephone number matchesfor example, when the search
criteria includes wildcards, such as
"555*5446".

Figure 2-3. telephoneNumber attribute type definition

The SYNTAX keyword specifies the
object identifier (OID) of
the encoding rules used for storing and transmitting values of the
attribute type. The number enclosed by curly braces ({ }) specifies
the minimum recommended maximum length of the
attribute's value that a server should support.

Figure 2-4. Private enterprise OID number space

2.2.2 What Does the Value of the objectClass Attribute Mean?

All entries in an LDAP directory must have an
objectClass attribute, and this attribute
must have at least one value. Multiple values for the
objectClass attribute are both possible and common
given certain requirements, as you shall soon see. Each
objectClass value acts as a template for the data
to be stored in an entry. It defines a set of attributes that must be
present in the entry and a set of optional attributes that may or may
not be present.

Let's go back and reexamine the LDIF representation
of the ou=devices,dc=plainjoe,dc=org entry:

# LDIF listing for dn: ou=devices,dc=plainjoe,dc=org
dn: ou=devices,dc=plainjoe,dc=org
objectclass: organizationalUnit
ou: devices
telephoneNumber: +1 256 555-5446
telephoneNumber: +1 256 555-5447
description: Container for all network enabled 
devices existing within the plainjoe.org domain

In this case, the entry's
objectClass is an
organizationalUnit. (The schema definition for
this is illustrated by two different representations in Figure 2-5.) The listing on the right shows the actual
definition of the objectClass from RFC 2256; the
box on the left summarizes the required and optional attributes.

Figure 2-5. organizationalUnit object class

Here's how to understand an
objectClass definition:

An objectClass possesses an OID, just like
attribute types, encoding syntaxes, and matching rules.

The keyword MUST denotes
a set of attributes that must be present in any instance of this
object. In this case, "present"
means "possesses at least one
value."

To represent a zero-length attribute value in LDIF syntax, the attribute name must be followed by a colon and zero or more spaces, and then a CR or CF/LF. For example, the following LDIF line stores a zero-length description: description:<ENTER>

The keyword MAY defines a
set of attributes whose presence is optional in an instance of the
object.

The keyword SUP specifies
the parent object from which this object was derived. A derived
object possesses all the attribute type requirements of its parent.
Attributes can be derived from other attributes as well, inheriting
the syntax of its parent as well as matching rules, although the
latter can be locally overridden by the new attribute. LDAP objects
do not support multiple inheritance; they have a single parent
object, like Java objects.

It is possible for two object classes to have common attribute
members. Because the attribute type namespace is flat for an entire
schema, the telephoneNumber attribute belonging to
an organizationalUnit is the same attribute type
as the telephoneNumber belonging to some other
object class, such as a person (which is covered
later in this chapter).