Which of the following are authentication types supported by the LDAP bind operation?

Directory Server provides a central repository for storing and managing information. Almost any kind of information can be stored, from identity profiles and access privileges to information about application and network resources, printers, network devices and manufactured parts. Information stored in Directory Server can be used for the authentication and authorization of users to enable secure access to enterprise and Internet services and applications. Directory Server is extensible, can be integrated with existing systems, and enables the consolidation of employee, customer, supplier, and partner information.

Directory Server provides the foundation for the new generation of e-business applications and Web services, with a centralized and distributed data repository that can be used in your intranet or over your extranet with your trading partners.

This chapter describes the basic concepts you must understand before attempting to design and deploy Directory Server. This chapter is divided into two sections:

What Is a Directory Service?

This section defines Directory Services and enterprise-wide directory services, in addition to clarifying the differences between directories and databases. It examines the major roles played by directories and establishes exactly where Sun Java System Directory Server fits into the Directory Service picture. This section is divided into the following parts:

About Directory Services

Directory services are an essential part of today's network-centric computing infrastructure. Directory-enabled applications now power almost all the mission critical processes of an enterprise, including resource planning, value chain management, security and firewalls, and resource provisioning. Directory services also provide the foundation for deployment of e-business and extranet applications. So what exactly is a Directory Service?

A directory service is the collection of software and processes that store information about your enterprise, subscribers, or both. An example of a directory service is the Domain Name System (DNS), which is provided by DNS servers. A DNS server stores the mappings of computer host names and other forms of domain name to IP addresses. A DNS client sends questions to a DNS server about these mappings (e.g. what is the IP address of test.example.com?). Thus, all of the computing resources (hosts) become clients of the DNS server. The mapping of host names enables users of the computing resources to locate computers on a network, using host names rather than complex numerical IP addresses.

Whereas the DNS server stores only two types of information: names and IP addresses, an LDAP directory service can store information on many other kinds of real-world and conceptual objects. Sun Java System Directory Server stores all of these types of information in a single, network-accessible repository. You may for example want to store physical device information, employee information (name, E-mail address), contract or account information (name, delivery dates, contract numbers, etc.), authentication information, manufactured production information. It is worth noting that although a directory service can be considered an extension of a database, directory services generally have the following characteristics:

• Hierarchical naming model
  A hierarchical naming model uses the concept of containment to reduce ambiguity between names and simplify administration. The name for most objects in the directory is relative to the name of some other object which conceptually contains it. For example, the name of an object representing an employee of a particular company contains the name of the object representing the company, and the name of the company might contain the name of the objects representing the country where the company operates, e.g. cn=John Smith, o=Example Corporation, c=US. Together the names of all objects in the directory service form a tree, and each Directory Server holds a branch of that tree, which in the Sun Java System Directory Server documentation is also referred to as a suffix.
• Extended search capability
  Directory services provide robust search capabilities, allowing searches on individual attributes of entries.
• Distributed information model
  A directory service enables directory data to be distributed across multiple servers within a network.
• Shared network access
  While databases are defined in terms of APIs, directories are defined in terms of protocols. Directory access implies network access by definition. Directories are designed specifically for shared access among applications. This is achieved through the object-oriented schema model. By contrast, most databases are designed for use only by particular applications and do not encourage data sharing.
• Replicated data
  Directories support replication (copies of directory data on more than one server) which make information systems more accessible and more resistant to failure.
• Datastore optimized for reads
  The storage mechanism in a directory service is generally designed to support a high ratio of reads to writes.
• Extensible schema
  The schema describes the type of data stored in the directory. Directory services generally support the extension of schema, meaning that new data types can be added to the directory.

About Enterprise-Wide Directory Services

Directory Server provides enterprise-wide directory services, meaning it provides information to a wide variety of applications. Until recently, many applications came bundled with their own proprietary user databases, with information about the users specific to that application. While a proprietary database can be convenient if you use only one application, multiple databases become an administrative burden if the databases manage the same information.

For example, suppose your network supports three different proprietary E-mail systems, each system with its own proprietary directory service. If users change their passwords in one directory, the changes are not automatically replicated in the others. Managing multiple instances of the same information results in increased hardware and personnel costs, a problem referred to as the n+ 1 directory problem.

An enterprise-wide directory service solves the n+ 1 directory problem by providing a single, centralized repository of directory information that any application can access. However, giving a wide variety of applications access to the directory requires a network-based means of communicating between the applications and the directory. Directory Server provides two ways in which applications can access its enterprise-wide directory:

• Lightweight Directory Access Protocol (LDAP)
• Directory Services Markup Language (DSML)

About LDAP

LDAP provides a common language that client applications and servers use to communicate with one another. LDAP-based applications can easily search, add, delete and modify directory entries. LDAP is a "lightweight" version of the Directory Access Protocol (DAP) defined in the ISO/ITU-T X.500 standard. DAP gives any application access to the directory via an extensible and robust information framework, but at an expensive administrative cost. DAP does not use the Internet standard TCP/IP protocol and has complicated directory-naming conventions. LDAP preserves the best features of DAP while reducing administrative burdens. LDAP uses an open directory access protocol running over TCP/IP and uses simplified encoding methods. It retains the X 500 standard data model and can support millions of entries for a comparatively modest investment in hardware and network infrastructure.

About DSML

DSML is a markup language that enables you to represent directory entries and commands in XML. This means that XML-based applications using HTTP can take advantage of directory services while staying within the existing web infrastructure. Directory Server implements version 2 of the DSML standard (DSMLv2). For detail regarding the restrictions and extensions to the DSML standard refer to the Directory Server Administration Reference.

Tuned for Enterprise and e-business Directory Roles

Online directories that support LDAP have become critical components of e-business infrastructure, supporting identity and risk management in several important roles. They provide a dynamic and flexible means of storing information and retrieving it over the internet, and can of course be configured to use the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols for authenticated and encrypted communications. As protected repositories of personal information, LDAP directories are also a key component for the personalized delivery of services to users of the directory and personalized treatment of information contained in the directory. Directories have the following three primary roles to play, each of which have very different deployment characteristics:

• Network Operating System (NOS) Directory

A NOS is a distributed operating system that manages multiple requests concurrently in a multiuser environment. It consists of clients and servers configured so that client machines can access the drivers on servers as if they were local drives on the client machine, and servers can handle requests from the client to share files and applications as well as network devices such as printers or faxes.

A NOS directory is used to administer a NOS allowing intranet users to log in once for all network file and printing requirements. The user population for a NOS directory ranges from 20 to 20,000 users, The NOS directory provides a single point of integrated administration and management for the network and the most important characteristics of this directory role are the tight integration with the NOS and sophisticated management tools for clients and servers.

An enterprise directory provides a global repository for shared information about people, organizations, and devices, including white/yellow pages, organization charts, seating charts, information about network devices such as routers, etc. It is important for an enterprise directory to provide flexible ways of organizing data and flexible management tools that can accommodate heterogeneous application environments or autonomous business units (through delegated administration). The user population for an enterprise directory tends to range from between 20,000 and 200,000 users.

An e-business directory maintains information about customers, trading partners, and suppliers, which involves making the information available to an extranet as necessary and appropriate. The user population for an e-business directory is typically millions of users, and in addition to the flexible management tools required the NOS and enterprise directories, e-business directories require a high degree of reliability and scalability to be able to rapidly accommodate millions of users.

The deployment characteristics of each role vary hugely, and as we will see throughout this Technical Overview, Sun Java System Directory Server is very much tuned for the enterprise and e-business directory roles, in that it provides a single directory service infrastructure for both enterprise and e-business applications and services. Sun Java System Directory Server is a mature LDAP directory solution which supports open standards, and it's carrier-grade design provides the extreme scalability, performance, and high availability required by large enterprise and e-business directories that support millions of users.

What Is Directory Server?

This section provides an overview of Sun Java System Directory Server by way of an introduction to the following chapters which outline the benefits to be gained from Directory Server in terms of performance, availability, scalability, security, and manageability. This section is divided into the following parts:

Directory Server and Java Enterprise System

Sun Java System Directory Server provides a central repository for storing and managing intranet and Internet information such as identity profiles (employees, customers, suppliers, etc.), user credentials (public key certificates, passwords, and pin numbers), access privileges, application resource information, and network resource information. Directory Server is now delivered as a component product of the Sun Java Enterprise System, Sun's software infrastructure that provides the services needed to support enterprise-strength applications distributed across a network or Internet environment. For further information on Sun Java Enterprise System, and on the concepts underlying distributed enterprise applications and distributed service infrastructures see the Directory Server Technical Overview..

Directory Server Architecture Overview

When you install Directory Server, the following components are installed on your machine:

• An LDAP server for processing requests.
• Sun Java System Administration Server.
• Sun Java System Server Console for managing Directory Server.
• Command-line tools for starting and stopping the server, importing and exporting data in the database, database re-indexing, account inactivation and deactivation, LDIF merges, kernel tuning, and replication management.
• Front ends responsible for LDAP and DSMLv2.
• Agent responsible for responding to Simple Network Management Protocol (SNMP) queries about the state of the server.
• Plug-ins for server functions, such as access control and replication.
• An initial directory information tree, consisting of server configuration and sample enterprise data.

Without adding other client programs, Directory Server can provide the foundation for an intranet or extranet. Every Sun Java System server uses the directory as a central repository for shared server information, such as employee, customer, supplier, and partner data.

You can use Directory Server to manage extranet user-authentication, create access control, set up user preferences, and centralize user management. In hosted environments, partners, customers, and suppliers can manage their own areas of the directory, reducing administrative costs. We will examine the following items in more detail and expand on some of the more advanced architecture features of Directory Server:

LDAP and DSML Front Ends

The server front ends of Sun Java System Directory Server manage communications with directory client programs. Directory Server functions as a daemon and multiple client programs can communicate with the server using LDAP over TCP/IP or DSMLv2 over HTTP/SOAP. These connections can be made secure using the Secure Socket Layer over Transport Layer Security (SSL/TLS), depending on whether the client negotiates the use of TLS for the connection.

Multiple clients can bind to the server at the same time over the same network because Directory Server is a multi-threaded application. As your directory services grow to include larger numbers of entries or larger numbers of clients spread out geographically, they also include multiple Directory Servers placed in strategic locations around the network or organization. You can also distribute your Directory Servers to conform with data protection regulations and to provide high availability.

Another advantage of Directory Server is that it implements LDAP natively, thereby avoiding the performance and management overheads associated with having a gateway on top of an X.500 directory, and with relational databases.

Support for Industry Communication Standards

Directory Server supports two standard communication protocols: LDAP version 3 and DSML version 2.

LDAP Version 3

Directory Server supports LDAP versions 3 (RFC 2251), the definitive Internet Proposed Standard protocol for accessing directory information. LDAP was invented by the Internet research community and provides a common language that client applications and servers use to communicate with one another. LDAP-based applications can easily authenticate, search, add, delete, and modify directory entries.

Directory Server supports LDAP search filters as outlined in RFC 2254, including the following: presence, equality, inequality, substring, approximate match (for phonetic matching), greater than, less than, Boolean combinations of the previous filters using the and (&), or (|), and not (!) operators.

Directory Server also supports LDAP version 3 search references (also known as smart referrals), which allow the directory to refer a query to another directory. It also implements LDAP URL formats as outlined in RFC 2255. Directory Server uses LDAP Data Interchange Format (LDIF) for exchanging directory information (RFC 2849).

DSML Version 2

As we have seen in the About DSML section, DSML is a markup language that enables you to represent directory entries and commands in XML. Directory Server implements version 2 of the DSML standard (DSMLv2). DSML enables developers to combine the power of XML in presenting and manipulating data with the scalability, security, availability, and information management strengths of Directory Server.

Because DSML is not an access protocol, Directory Server uses HTTP and the SOAP version 1.1 to transport the DSML content. Directory Server supports DSML natively, providing very high throughput performance as opposed to the gateway design used with other LDAP directories.

Using DSML over HTTP/SOAP, you can create applications that do not rely on LDAP, allowing non-LDAP clients to interact with your directory data. This allows you to create and implement a new generation of Web services that interface with Directory Server through XML.

The DSML front end of Directory Server is not a full web or application server. In this version of Directory Server it only accepts SOAP operations for requests conforming to the DSML specification. Because the DSML front end is a core component of the directory, all native access controls apply. As a consequence, any all security rules that you previously defined for LDAP also apply to DSML, including simple authentication, SSL authentication, and Access Control Instructions (ACIs).

Directory Server Plug-in Extensibility

Directory Server relies on plug-ins for many key features. A plug-in is a way to add, enable, and configure functionality to the core server. For example plug-ins are included to support referential integrity and uniqueness constraints.

Plug-ins extend Directory Server functionality by adding pre or post operational functionality. You can add new intelligence to operations, giving you the ability to adapt your directory to other applications, changing business requirements, partners' needs, and so on.

The plug-in API is fully documented in this release of Directory Server, enabling you to create your own custom plug-ins. Refer to the Directory Server Plug-in Developer's Guide for help on how to develop plug-ins, upgrade existing plug-ins and explore sample plug-ins and the Directory Server Plug-in Developer's Reference for details about particular data structures, functions, parameter, and block semantics. Sun Professional Services and other organizations can help you to develop custom plug-ins. For information about what Sun Professional Services has to offer, refer to:

http://www.sun.com/service/sunps/sunone

Sun Java System Directory Server Resource Kit

The Sun Java System Directory Server Resource Kit (DSRK) provides tools and APIs for deploying, accessing, tuning, and maintaining your Directory Server. These utilities will help you implement and maintain more robust solutions based on LDAP, the Lightweight Directory Access Protocol.

The first two components of the DSRK are the LDAP SDKs (Software Development Kits) for C and Java™ programming languages. These SDKs make it simple to write client applications for your directory, and these APIs expose all of the functions for connecting to an LDAP directory and accessing or modifying its entries. Use them to design and integrate directory functionality into your applications at the programmatic level.

The third component of the Sun Java System Directory Server Resource Kit is the set of tools and scripts that make a directory accessible through a command-line shell. The wide range of tools can be used for simple directory access, performance testing, and for the maintenance of Directory Servers. These tools are themselves based on the LDAP SDKs, and they were created to help development teams to test and validate Directory Server. It is also worth noting that the commands that run these tools can be used to write scripts to automate all of these tasks.

For more information refer to the Directory Server Resource Kit Tools Reference.

Java Naming and Directory Interface™ (JNDI)

The Java Naming and Directory Interface (JNDI) is a standard extension to the Java platform, providing applications based on Java technology with a unified interface to multiple naming and directory services. You can build powerful and portable directory-enabled applications using this industry standard. This technology supports accessing Directory Server using LDAP and DSML v2 from Java applications. General information about JNDI is available from:

http://java.sun.com/products/jndi

A JNDI Tutorial containing detailed descriptions and examples of how to use JNDI is available at:

http://java.sun.com/products/jndi/tutorial

Directory Information Tree

Directory Server contains a basic directory information tree at installation time. This tree mirrors the tree model used by most file systems, with the tree's root, or first entry, appearing at the top of the hierarchy. The root of this tree is called the root suffix. At installation time the directory contains three subtrees under the root suffix:

where cn stands for Common Name. This subtree contains information about the server's internal configuration.

where o stands for organization. This subtree contains the configuration information of other Sun Java System servers, such as Sun Java System Administration Server which takes care of authentication and all actions that cannot be performed through LDAP (such as starting or stopping Directory Server). This subtree name originates from a legacy version of the product.

During installation, a user database is created by default which is called UserRoot. An example name for the suffix stored on this user database might be o=UserRoot. You can choose to populate this database at installation time, or at a later stage. You can build on the default directory tree to add any data relevant to your directory installation. In Figure 2-1, the o=UserRoot suffix has been renamed to dc=example,dc=com, and additional subtrees have been added to reflect the organizational hierarchy.

Figure 2-1 Sample Directory Tree

• dc refers to the domain component
• ou refers to the organizational unit

For further detail about the directory information tree refer to the Directory Server Deployment Planning Guide.

Multiple Database Design and Large Cache Support

The multiple database architecture of Directory Server supports distributed naming contexts, providing large scalability to support millions of users on a single system, improved backup and restore, load balancing, and simplified administration. The multiple database design also provides a method for partitioning the directory data to simplify replication.

Directory Server can run as a 64-bit application on Solaris SPARC®. This Directory Server, using the large cache allows you to attain improved performance for high-volume deployments.

Sun Cluster Agent 3.1 Support

The Sun Cluster Agent is a high availability agent that provides LDAP service failover. It is bundled with Directory Server and on certain hardware and deployment configurations, can be used to improve the availability of Sun Java System services provided by multiple servers. For more information on how to install the Agent see the Directory Server Installation and Migration Guide.

Directory Server Data Storage

By default, Directory Server uses a single database to store the directory tree. This database can manage millions of entries. The default database supports advanced methods of backing up and restoring data.

Since Directory Server supports multiple databases you can also distribute data across the databases, enabling the server to store more data than can be held in a single database.

The following sections describe how a directory database stores data.

About Directory Entries

LDAP Data Interchange Format (LDIF) is a standard text-based format for describing directory entries. An entry is a group of lines in an LDIF file that contains information about an object, such as a person in your organization or a printer on your network. Information about the entry is represented in the LDIF file by a set of attributes and their values. Each entry has an object class attribute that specifies the kind of object the entry describes and defines the set of additional attributes it contains. Each attribute describes a particular trait of an entry.

For example, an entry might have the object class organizationalPerson, indicating that the entry represents a person within a particular organization. This object class allows the givenname and telephoneNumber attributes. The values assigned to these attributes give the name and phone number of the person represented by the entry.

Directory Server also uses read-only attributes that are either calculated by the server, or for certain server functions such as access control, set by the administrator. These attributes are called operational attributes.

Entries are stored in a hierarchical structure in the directory tree. In LDAP, you can query an entry and request all entries below it in the directory tree. This subtree is called the base distinguished name, or base DN. For example, if you make an LDAP search request specifying a base DN of ou=people,dc=example,dc=com, the search operation examines only the ou=people subtree in the dc=example,dc=com directory tree.

Note that not all entries are automatically returned in response to an LDAP search. For instance, entries of the ldapsubentry object class are not returned in response to normal search requests. An ldapsubentry entry represents an administrative object, for example the entries that are used internally by Directory Server to define a role or a class of service. To receive these entries, clients must search specifically for entries of the ldapsubentry object class.

Distributing Directory Data

When you store various parts of a tree in separate databases, your directory can process client requests in parallel, improving performance. You can also store databases on different machines, to improve performance further. We examine in further detail the various data distribution options provided in Chapter 5, "Directory Server Scalability".

Directory Server Data Management

The database is the basic unit of storage, performance, replication, and indexing. A variety of operations can be performed on a database, including importing, exporting, backing up, restoring, and indexing.

These command line utilities are subcommands of the directoryserver command. For more information see the Directory Server Man Page Reference.

Importing Data

Directory Server provides three methods for importing data:

• Importing from the Directory Server Console.

You can use the Directory Server Console to append data to all of your databases, including database links.

You can use the Directory Server Console to import data to one database. This method overwrites any data contained by the database.

• Importing data from the command line.

You can import data using the command-line utilities ldif2db, ldif2db-task, and ldif2ldap.

Exporting Data

You can use LDIF to export database entries from your databases. LDIF is a standard format described in RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification."

Exporting data can be useful for the following:

• Backing up the data in your database
• Copying your data to another Directory Server
• Exporting your data to another application
• Repopulating databases after a change to your directory topology

You can use the Directory Server Console or the command-line utilities db2ldif and db2ldif-task to export data.

Backing Up and Restoring Data

You can use Directory Server Console or the db2bak or db2bak-task command line utilities to back up directory data. Both methods allow you to perform a backup while the server is running, which prevents you having a period during which the directory is not accessible.

You can restore data from a previously generated backup using Directory Server Console or the command-line utilities bak2db or bak2db-task. Restoring databases overwrites any existing database files. While restoring databases, the server must be running. However, the databases are unavailable for processing operations during the restore.

Indexing Data

Depending on the size of your databases, searches performed by client applications can take a lot of time and resources. You can use indexes to improve search performance. Indexes are files stored in the directory databases. Separate index files are maintained for each database in the directory. Each file is named according to the attribute it indexes. The index file for a particular attribute can contain multiple types of indexes, allowing you to maintain several types of index for each attribute. For example, a file called givenName.db3 contains all the indexes for the givenName attribute.

Depending on the types of applications using your directory, you will use different types of index. Different applications may frequently search for a particular attribute, or may search your directory in a different language, or may require data in a particular format. For more information on how to use indexes to improve your Directory Server performance see Chapter 3, "Directory Server Performance".

Directory Server Schema

In addition to its prescriptive properties, Directory schema can maintain the integrity of the data stored in your directory by imposing constraints on the size, range, and format of data values. You decide what types of entries your directory contains (people, devices, organizations, and so forth) and the attributes available to each entry.

The predefined schema included with Directory Server contains both the standard LDAP schema as well as additional application-specific schema to support the features of the server. While this schema meets most directory needs, you may need to extend it with new object classes and attributes to accommodate the unique needs of your directory.

The following sections describe the format, standard attributes, and object classes included in the Sun standard schema.

Schema Format

Directory Server bases its schema format on version 3 of the LDAP protocol (LDAPv3). This protocol requires Directory Servers to publish their schemas through LDAP itself, allowing directory client applications to retrieve the schema and adapt their behavior based on it. The global set of schema for Directory Server can be found in the entry named cn=schema. In addition, it uses a private field in the schema entries called X-ORIGIN, which describes where the schema entry was defined originally. For example, if a schema entry is defined in the standard LDAPv3 schema, the X-ORIGIN field refers to RFC 2252. For example, the standard person object class appears in the schema as follows:

objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso
$ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 2256' )

This schema entry states the object identifier, or OID, for the class (2.5.6.6), the name of the object class (person), a description of the class (Standard Person Object Class), then lists the required attributes (objectclass, sn, and cn) and the allowed attributes (description, seeAlso, telephoneNumber, and userPassword).

Standard Attributes

Attributes hold specific data elements such as a name or a fax number. Directory Server represents data as attribute-data pairs, a descriptive attribute associated with a specific piece of information. For example, the directory can store a piece of data such as a person's name in a pair with the standard attribute, in this case commonName (cn). So, an entry for a person named Charlene Daniels has the following attribute-data pair:

cn: Charlene Daniels

In fact, the entire entry is represented as a series of attribute-data pairs. The entire entry for Charlene Daniels might appear as follows:

dn: uid=cdaniels, ou=people, dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Charlene Daniels
sn: Daniels
givenName: Charlene
givenName: Charlie
mail: [email protected]

Notice that the entry for Charlene contains multiple values for some of the attributes. The attribute givenName appears twice, each time with a unique value. The object classes that appear in this example are explained in the next section, "Standard Object Classes."

In the schema, each attribute definition contains the following information:

• An object identifier (OID) for the attribute
• A text description of the attribute
• The OID of the attribute syntax
• Indications of whether the attribute is single-valued or multi-valued, whether the attribute is for the directory's own use, the origin of the attribute, and any additional matching rules associated with the attribute.

For example, the cn attribute definition appears in the schema as follows:

attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

The SYNTAX is the OID of the syntax for values of the attribute. For more information about the LDAPv3 schema format, refer to the LDAPv3 Attribute Syntax Definitions document (RFC 2252).

Standard Object Classes

Object classes are used to group related information. Typically, an object class represents something real, such as a person or a fax machine. Before you can use an object class and its attributes in your directory, it must be identified in the schema. The directory recognizes a standard list of object classes by default.

Each directory entry belongs to one or more object classes. Once you place an object class identified in your schema on an entry, you are telling Directory Server that the entry can have a certain set of attribute values and must have another, usually smaller, set of attribute values.

What are three ways to authenticate to an LDAP Server?

Which of these are common ways to authenticate LDAP?

Which component of an LDAP entry contains the unique entry name?

What are examples of centralized management?