test

Sun Directory Services 3.1 Administration Guide

Chapter 1 Introduction to Directory Concepts

This section provides information on:

Directory Information

The information held in the directory consists of entries and alias entries, which provide the information base, and of infrastructure information, which determines how the information base is structured.

Directory Entries

A directory entry is a set of attributes and their values. Every entry has an object class attribute, which specifies the kind of object the entry describes and defines the set of attributes it contains. For a given object class, some attributes are mandatory and some are optional. For example, the object class country is described by the mandatory attribute countryName, and the optional attributes description and searchGuide.

The schema defines the attributes that are mandatory and optional for an entry of a given object class. It also defines an inheritance hierarchy. All object classes inherit the characteristics of their superior object class. For example, the object class organizationalPerson is a subclass of the Person object class. It inherits the mandatory and optional attributes from the Person object class.

All object classes inherit from the object class top. The object class top contains the mandatory attribute objectClass. This ensures that all entries have an object class attribute.

There are two types of object classes: structural and auxiliary. A structural object class defines the type of entry. An entry can have only one structural object class. An auxiliary object class is not sufficient to define alone a type of entry, but can be specified in addition to a structural object class. For example, the auxiliary object class uidObject can be used to assign a uid to any entry in the directory.

Distinguished Name and Relative Distinguished Name

Directory information is hierarchical, with entries organized in a tree structure. Each entry has a parent entry and can have child entries. The top of the hierarchy is known as the root entry.

An entry is identified by its distinguished name (DN). A distinguished name is a sequence of attributes and values. The first attribute and its value provide the entry's relative distinguished name (RDN). The rest of the sequence is the distinguished name of the parent entry. A distinguished name is unique throughout the whole directory service.

Figure 1-1 shows an example of how directory information is structured, with the DNs and RDNs of the shaded entries.

Figure 1-1 Directory Information Structure

Graphic

The attributes that can be part of a DN are called naming attributes. In the default schema provided with Sun Directory Services, the naming attributes are:

Aliasing

You can define an alias entry. An alias entry is identified by a distinguished name (DN). It contains the name of the directory entry it represents (the aliased object name). The alias entry and the entry it represents must be under the same root entry. For the full definition of the alias object class, refer to "Object Class Reference".

For bind and search operations, you can specify that the directory should translate an alias DN to the DN of the actual entry. This is known as dereferencing the alias. For other operations, you need to treat the alias entry as an ordinary entry and not dereference it, for example, when you modify the RDN of the alias entry itself, not of the aliased object.

Alias Entries and Searching

The result of a search or read operation involving an alias entry differs depending on whether or not you dereference the alias. Alias dereferencing is specified by the LDAP client. There are four possible settings for the alias dereference flag:

For example, suppose your directory contains the following pair of entries:

cn=Stan Smith, role=Personnel Administrator, ou=Personnel, o=XYZ, c=US 

with attributes:  

objectclass=orgPerson 

 

cn=Stan Smith 

 

telephoneNumber=123 456 7890 

 

mail=dtmail 

 

 

cn=personnel, o=XYZ, c=US 

with attributes: 

objectclass=alias 

objectclass=aliasObject 

 

cn=personnel 

aliasedObjectName="cn=Stan Smith, role=Personnel Administrator, ou=Personnel, o=XYZ, c=US" 

With alias dereferencing when searching, if you search for the telephone number of cn=personnel in the subtree o=XYZ, c=US, you will see Stan Smith's telephone number. With no alias dereferencing, you would not see any telephone number.

Defining aliases for roles is particularly useful when the person occupying a role changes frequently (the duty network manager for out-of-hours calls, for example), so that users always query the same entry. You can change the value of the aliasedObjectName with a script that runs on a schedule and calls ldapmodify to make the changes.

See the ldapsearch(1) man page for details of how to specify how alias dereferencing is used in ldapsearch.

Alias Entries and Authentication

To perform certain operations on the directory, users need to be authenticated. This is the case for modifications of directory content, or for reading the userPassword attribute of an entry. The level of access permitted is established during the bind process. For details, refer to "Binding to the Directory".

The DN supplied in a bind request can be the DN of an alias entry. With alias dereferencing, the user binds with the DN contained in the aliasedObjectName of the alias entry, and is granted the access rights defined for the entry with that DN.

Alias dereferencing during a bind operation is a configuration choice that needs to be made for the LDAP server. If aliases are not being dereferenced and the user binds with the DN of an alias entry, access is denied because the password attribute is not present. This also means that if you allow alias dereferencing, you allow users to bind without a password.

For information on specifying alias dereferencing for Sun Directory Services, refer to "Configuring LDAP Parameters".

Directory Structure

In a general-purpose directory, you have to decide what information you want to store, and how that information will be organized. The information in the global directory can be physically located on a number of different servers. However, it fits into a single overall tree structure.

Directory Information Tree

Information in the directory is organized in a tree structure, called the Directory Information Tree (DIT). The structure of a DIT usually reflects very closely the structure of the information it contains. For example, a directory containing entries for people in a corporation could be organized by division or by location. In general, DIT structures are organizational, geographical, or include both organizational and geographical factors. However, another possibility is to organize the DIT structure according to internet domains. The logical organization of the DIT into naming contexts is discussed in Chapter 3, Planning a Directory Service.

Data Stores and Naming Contexts

The directory information is divided into naming contexts. A naming context is a subtree of the directory, and is identified by the DN of the entry at the top of the subtree. A naming context is stored in a physical data store. A data store can hold more than one naming context. A directory server can contain more than one data store.

The naming contexts that identify the data store are called data store suffixes in the Sun Directory Services Admin Console.

When dividing the DIT into naming contexts and data stores to be held on individual servers, you need to take account of the following:

The Sun Directory Services data store can hold up to four data store suffixes, and one million entries. If you need to store more entries, you can install several data stores, on one or several servers, and create referrals between them. For more information on using Sun Directory Services to store more than one million entries, refer to "Referrals".

Infrastructure Information

Infrastructure information determines how the components of a directory service behave and how directory entry information is interpreted. It includes the directory schema, knowledge information, and component configuration information.

Schema

The directory schema is the set of rules that describes the data that can be stored in the directory. It defines the types of entries permitted, their attribute structure, and the syntax of the attributes. Sun Directory Services contains a pre-defined schema, which you can modify, with certain restrictions. See "Modifying the Schema" for details of how to modify the schema.

Knowledge Information and Referrals

A directory server uses knowledge information to pass requests for information to other servers. The knowledge information held by a directory server is a reference to a directory server holding other naming contexts. When a server receives a request for information, it checks whether it can respond to the request using the information in the local data store. If it cannot, it checks the referral defined for the data store, and returns the details of an alternate directory server to the directory client. The client can then send the request to the other directory server. Some clients contact the alternate server automatically, so the referral mechanism is transparent to the user. Other clients return the referral information to the user.

See "Example: Naming Contexts in XYZ Corporation" for an example of how referrals are used.

Access Control

Access to information in the directory is controlled by a set of rules that determine what operations a user can perform on a particular entry or attribute. The permission level granted to the user depends on the authentication information provided by the user. It also depends on the specific rules defined by the directory administrator for a particular entry or attribute.

Permission Levels

There are five permission levels for directory information. From the least privileged to the most privileged, they are:

Note -

When you are granted permission for a given level of operation, you are implicitly granted all lower levels of permission. For example, read permission implies that search and compare permissions are granted too.

Defining Rules for Entries and Attributes

Access control rules define which users are granted which permission for a given set of entries or attributes. For example, you can give a user read permission for all attributes except password in all entries, and compare permission for password attributes.

You can define the set of entries or attributes to which an access control rule applies by using:

For example, you could define the following access control rules:

The access control rules are applied in sequence, so the order in which they are listed is important. You must state the most specific rules first, with more general rules afterward. "Configuring Access Control" explains how to define an access control rule using the configuration tool, and how to specify the order of rules.

Binding to the Directory

Depending on the access control rules defined for the directory, for certain operations, you need to bind to the directory. Binding means authenticating yourself by providing your DN and password. This process determines the permission level you are granted for the duration of the connection.

For example, with the default set of access control rules, you have write permission to your password in your directory entry. When you bind with the DN and password of an entry, you are identified by the keyword self for that entry. With an anonymous bind, you have search, and read permissions for all entries and attributes except the password attribute, for which you have compare permission. These are the permissions granted to users identified by the keyword everyone or *.

Default Access Control Rules

The default access controls defined at installation are as follows:

These rules are applied in order, starting with the most specific followed by the more general rules.

Example 1-1 shows how the default access controls are defined in the directory server configuration file /etc/opt/SUNWconn/ldap/current/dsserv.acl.conf.

Example 1-1 Default Access Controls

access to attrs=userPassword	by self write
	by * compare

# Radius ACLs
access to attrs=chapPassword, radiusLoginPasswd, radiusPppPasswD,
radiusSlipPasswd
	by self write
	by * compare

access to attrs=sharedKey
	by self write
	by * compare

# dsyppasswdd ACLs
access to attrs=userPassword
	by self write
	by * compare

access to attrs=gecos,loginShell
	by self write

# SIMS ACLs
access to attrs=cn, dataSource, homeDirectory, mail, mailHost,
mailQuota, objectStatus, preferredRfc822Recipient, rfc822Mailbox,
uid
	by self read
	by * read

# Default ACLs
access to filter="joinable=TRUE" attrs=member,entry
	by dnattr=member selfwrite

access to * by self read

For information on configuring access control rules for Sun Directory Services, refer to "Configuring Access Control".

Replication

You can share between several directory servers the load of processing requests generated by directory service clients for the same information. This is done by defining a replica, or slave, server to provide an alternative access point to the directory service for clients. A master naming context can have more than one replica naming context. Figure 1-2 shows a master server with two replica servers. Replication is the process by which changes in the master data store are propagated to all the replica naming contexts. You can replicate an entire naming context, a subtree, or a particular entry. You can replicate the entire content of an entry or you can specify a subset of attributes to be replicated.

Figure 1-2 Master and Replica Servers

Graphic

Using replication has the following advantages:

Note -

You could provide the same partial view of directory information with appropriate access controls. However, using a partial replica on a dedicated machine ensures that you are not providing access to your entire network. For extra security, you could connect the replica server to your network only while the replication update is in progress.

The costs of using replication are: