test

Sun Directory Services 3.1 Administration Guide

Chapter 2 Sun Directory Services Components and Architecture

Sun Directory Services offers a global directory and naming service. The product contains:

The Sun Directory Services also offer the following security features:

This chapter provides an overview of the Sun Directory Services architecture and describes the product components. It also provides an overview of security features in Sun Directory Services.

Sun Directory Services Architecture

Sun Directory Services offers access to directory information through a number of different protocols:

Sun Directory Services also includes the following Java tools that you can run as applets in any Java-enabled web browser, or as applications:

Figure 2-1 Sun Directory Services Architecture

Graphic

In Figure 2-1, the items shown in dashed boxes are not part of the Sun Directory Services product. They indicate the types of applications that can use information stored in the directory.

Sun Directory Services Components

This section briefly describes the components of the Sun Directory Services. When necessary, cross-references to sections that provide in-depth information on the component are provided.

LDAP Server

The Lightweight Directory Access Protocol (LDAP) is a lighter version of the Directory Access Protocol defined in the X.500 standards, particularly suited to TCP/IP networks.

Sun Directory Services 3.1 implements RFC 2251 Lightweight Directory Access Protocol (v3), the LDAPv3 standard which provides the following enhancements over LDAP v2:

The LDAP server function is performed by the dsservd daemon. The dsservd daemon is the component that accesses the database files that hold the directory information, and communicates with directory clients using the LDAP protocol.

LDAP Replication Service

The replication service supplied with the Sun Directory Services enables you to set up a replication strategy for your directory service. You can use replication to share the load of client requests over several servers, and also to reduce overall communication costs by keeping network traffic local.

Replication can apply to a subtree, a particular entry, or a subset of attributes of an entry in the Directory Information Tree.

Sun Directory Services provides two replication daemons, dspushd and dspulld. The dspushd daemon pushes updates from the master server to the slave server, whereas the dspulld daemon pulls updates from the master. With the former, the master server manages the replication schedule, whereas with the latter, the slave manages the replication schedule. The communication protocol used by both daemons is LDAP.

Sun Directory Services also includes an NIS replication process associated with the NIS server.

NIS Server

The Network Information System (NIS) is a naming service that offers a way of identifying and locating users and resources on the network.

The NIS server provided with the Sun Directory Services overcomes some of the limitations of a classic NIS naming service, namely:

The NIS server component of the Sun Directory Services can replace an existing NIS server to integrate easily into an existing NIS network. This is done by transferring the information stored in NIS tables on the NIS server into the LDAP directory database. This avoids duplication of user and host information in several databases.

All the information held in NIS tables is mapped onto LDAP object classes and attributes. This mapping can be configured for a particular environment.

The NIS server function of the Sun Directory Services is performed by the dsservd daemon. This component responds to NIS requests from user applications. For example, during an rlogin operation, it converts the hostname to the IP address of the remote machine.

As in the standard NIS environment, users can change their password using the passwd command.

The dsservd daemon can act as an NIS master or an NIS slave. As a master, it propagates NIS tables to a slave NIS server. As a slave, it receives propagation requests from a NIS server.

Replication between an LDAP/NIS server and a legacy NIS server is performed using the dsypxfrd daemon. For details on how NIS replication is performed by Sun Directory Services, see "Propagating NIS Tables".

Chapter 6, Using the Directory as an NIS Server explains how to integrate the Sun Directory Services into an existing NIS network, and describes the NIS-to-LDAP information mapping.

RADIUS Server

The RADIUS server component provides user authentication and accounting services. Remote Access Dialup User Service (RADIUS) is the protocol used by Network Access Servers (NAS) to authenticate remote users who connect to the network.The information provided to the NAS in the access request is checked against the information stored in the directory.

All NAS devices available on the market can be configured to use the RADIUS server in Sun Directory Services to authenticate remote users.

The RADIUS server function is performed by the dsradiusd daemon. A full description of the RADIUS architecture is provided in Chapter 7, Using the RADIUS Server.

Administration Console

The Admin Console is a Java tool that enables you to configure, maintain, and monitor the Sun Directory Services. You can use the Admin Console from any machine on your network if there is an HTTP server on the machine where you have installed the Sun Directory Services. If you do not have an HTTP server, you can download the Sun WebServerTM free of charge from http://www.sun.com/webserver.

If you do not have a web server colocated with the directory server, you can view the Admin Console locally by pointing a browser at the HTML files, or you can use the application version of the Admin Console.

Refer to "Displaying the Admin Console".

Configuration Files

Directory configuration information is stored in a set of configuration files:

Three versions of these files are stored:

The directory server daemon, dsservd, reads the current configuration when it is started. If you change the configuration while dsservd is running, you must either click the Refresh button in the Admin Console Status section, or restart the dsservd daemon for the configuration to be re-read.

If you make a modification to the configuration, the files in the current directory are copied to the previous directory. The files are copied only once, and not after every change, so that you have a copy of the configuration that was in effect before you made any modifications.

The Admin Console saves your changes in the configuration files in the current directory whenever you click Apply. If you are working in the main window in the browser, when you click Apply, you are prompted to stop and restart the daemon. However, if you are working in a sub window, after you click Apply, you must remember to stop and restart the daemon for your changes to take effect.

The Status section in the Admin Console displays a message indicating when the configuration for a service has changed. This indicates that the service needs to be restarted or refreshed for the changes to be taken into account.

Java Directory Editor (Deja)

Deja is a tool that provides a way to modify and browse the directory content. The search, read, and write permissions granted to a user are determined during the login phase. Deja can run as an applet displayed through the HotJava browser, or locally as an application.

For a complete description of Deja and how to use it, refer to the Sun Directory Services 3.1 User's Guide.

Btree Database

The database provided with Sun Directory Services is a proprietary Berkeley Btree database, optimized for directory access. It can hold up to 1 million entries.

A number of command-line utilities are provided for managing the information in the database and reclaiming disk space. Refer to "Data Management" for information on these utilities.

Web Gateway

The web gateway provides an end-user interface to an LDAP directory from any web browser. You can use this interface to browse the directory, to search for and read entries, and to modify some directory information.

The web gateway works as an HTTP server. It must be located on the same machine as the LDAP directory server dsservd. The web gateway uses configurable templates to display directory information to users.

The web gateway daemon is dswebd. For information on starting, stopping, and configuring the web gateway, refer to Chapter 10, Managing the Directory Services. For information on using the web gateway, refer to Sun Directory Services 3.1 User's Guide.

Administration Utilities

Sun Directory Services is supplied with a complete set of tools for administering the directory service software and the directory content, including monitoring and statistics. The tasks that you can perform with these commands are described in "Data Management", and "Directory Maintenance".

A generic data loading utility, dsimport, is also provided. It converts any text database, including NIS tables, to LDAP objects using a configurable mapping mechanism. For details on dsimport, refer to Chapter 5, Loading and Maintaining Directory Information.

Equally, you can back up the directory information base by exporting its contents to a file using the dsexport utility.

SNMP Agents

The Sun Directory Services is provided with two SNMP agents:

For the full list of management statistics you can obtain from the SNMP agents, refer to "Monitoring Directory Services with SNMP".

Sun Directory Services Security

The Sun Directory Services provide security protocols in the LDAP server and password encryption mechanisms. However, when the Admin Console is used remotely, the communication between the client machine and the server machine is not encrypted. In this case, authentication is provided by the login procedure alone.

Security Protocols in the LDAP Server

The LDAP server supports the following security protocols:

These security features are optional. By default, clients bind to the directory using a simple bind in Insecure mode.

SASL

The SASL protocol is used to provide strong authentication in the bind process through an exchange of tokens. Sun Directory Services supports the CRAM MD5 authentication mechanism. It also supports the EXTERNAL mechanism when the SSL library is installed on the server, and the server is configured to support TLS security.

Secure Socket Layer (SSL)

The SSL protocol is used to provide secure connections between the directory server and directory clients.

The Sun Directory Services implementation of SSL functions in two modes:

The SSL on Specific Port mode uses a dedicated port, by default port 636. With the TLS security mode, at any time during an LDAP session you can use the Start TLS extended operation to open a secure connection. When using the Start TLS operation, the client can perform:

Both the TLS and SSL on Specific Port modes require an SSL key to authenticate the server. This key is specified using the IP address of the host machine. In both modes it is also possible to configure the server to authenticate clients.

SSL security is available only if the SSL and SKI (Sun Certificate Manager) libraries are available on the server where Sun Directory Services is installed. For details on prerequisites, refer to the installation instructions.

Note -

Due to legal restrictions in certain countries, SSL is not available worldwide.

RADIUS Server Encryption

The RADIUS server provided with Sun Directory Services is fully compliant with RFC 2138 Remote Authentication Dial In User Service that defines the RADIUS protocol. In the RADIUS protocol, passwords passed between the Network Access Server (NAS) and the RADIUS server are encrypted. The encryption mechanism is MD5 XORing with a shared secret.

Password Encryption

Directory entries can contain user password attributes that are used to authenticate the user to the directory. By default, the values of such attributes are stored in a protected format, identified by the keyword {sunds} in the server configuration file. The encryption algorithm permits the use of the CRAM-MD5 authentication mechanism.

You can also encrypt user passwords using the crypt(3) encryption algorithm, which is the algorithm commonly applied to passwords stored in the /etc/passwd file. This algorithm is incompatible with the CRAM-MD5 authentication mechanism. This encryption method is identified by the keyword {crypt} in the server configuration file.

See "Configuring Security" for details of how to specify whether or not passwords are stored in an encrypted format.