Sun Directory Server Enterprise Edition 7.0 Deployment Planning Guide

Part IV Advanced Deployment Topics

This part discusses specialized deployment topics. It includes the following chapters:

Chapter 13 Using LDAP-Based Naming With Solaris

This chapter provides an overview of the LDAP naming service that is provided with the SolarisTM Operating System (Solaris OS). The naming services supported by the Solaris OS are described in detail in Part I, About Naming and Directory Services, in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

This chapter covers the following topics:

Why Use an LDAP-Based Naming Service?

A naming service stores information in a central place, which enables users, machines, and applications to communicate across the network. This information can include, for example, machine (host) names and addresses, user names, passwords, access permissions, group membership, and printers. Without a central naming service, each machine would have to maintain its own copy of this information. Naming service information can be stored in files, maps, or database tables. If you centralize all data, administration becomes easier.

The Solaris OS supports the following naming services:

However, Sun's strategic direction is to move to LDAP-based naming services.

The LDAP naming service has the following advantages over other naming services:

The LDAP naming service has the following restrictions:

The Solaris OS supports LDAP naming in conjunction with Sun Directory Server, as well as other LDAP directory servers. Although using Sun Directory Server is recommended, it is not required.

Migrating From NIS to LDAP

Moving from NIS to LDAP is a two-step process that involves data migration and client migration. The Solaris OS provides the NIS-to-LDAP transition service (N2L service), which accomplishes both steps.

The N2L service replaces existing NIS daemons on the NIS master server with NIS-to-LDAP transition daemons. The N2L service also creates an NIS-to-LDAP mapping file on that server. The mapping file specifies the mapping between NIS map entries and equivalent Directory Information Tree (DIT) entries in LDAP. An NIS master server that has gone through this transition is referred to as an N2L server.

The NIS slave servers continue to function in the usual manner. The slave servers periodically update their data from the N2L server as if the N2L server were a regular NIS master. A script, inityp2l, assists with the initial setup of these configuration files. When the N2L server has been established, you can maintain N2L by directly editing the configuration files.

The N2L service supports the following:

For details on how to migrate from NIS to LDAP, see Chapter 15, Transitioning From NIS to LDAP (Overview/Tasks), in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Migrating From NIS+ to LDAP

Although you can keep NIS+ data synchronized with LDAP, such synchronization has previously required an external agent. However, the NIS+ daemon now enables you to use an LDAP server as a data repository for NIS+ data. This feature enables NIS+ and LDAP clients to share the same naming service information. The transition from using NIS+ as the main naming service to using LDAP for the same role is therefore easier.

For details on how to migrate from NIS+ to LDAP, see Chapter 16, Transitioning From NIS+ to LDAP, in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Chapter 14 Deploying a Virtual Directory

The virtual directory is an advanced feature of Directory Proxy Server that aggregates information, in real time, from multiple data repositories. This chapter describes how you can use a virtual directory in a Directory Server Enterprise Edition deployment.

The architectural concepts of a virtual directory are described in Chapter 18, Directory Proxy Server Virtualization, in Sun Directory Server Enterprise Edition 7.0 Reference. Procedural information about setting up a virtual directory is provided in Chapter 22, Directory Proxy Server Virtualization, in Sun Directory Server Enterprise Edition 7.0 Administration Guide.

This chapter covers the following topics:

When to Use a Virtual Directory

Virtual directory features can be deployed if your directory service has any of the following requirements:

Typical Virtual Directory Scenario

This section provides a simple scenario that shows how a virtual directory answers specific business requirements. For more complex sample scenarios, and for details of virtual directory configuration, see Sample Virtual Configurations in Sun Directory Server Enterprise Edition 7.0 Administration Guide.

Connecting User Identities From Different Data Sources stores uses three different data repositories to store user data.'s Directory Server contains the bulk of the user data. User email addresses are stored in an Active Directory, and HR data is stored in a MySQL database. has several client applications that require a complete view of all user data. The following diagram illustrates how the virtual directory provides a complete view of a user's identity to the client application.

Figure 14–1 Virtual View of Aggregated Data From Multiple Repositories

Figure shows user data taken from multiple sources

Chapter 15 Designing a Deployment With Synchronized Data

Identity Synchronization for Windows is a component of Directory Server Enterprise Edition that synchronizes user account information, including passwords, between Directory Server and Windows. Both Windows Active Directory and Windows NT are supported. Identity Synchronization for Windows helps build a scalable and security-enriched password synchronization solution for an enterprise of any size.

For complete documentation on Identity Synchronization for Windows, see If you are planning to use Identity Synchronization for Windows in your deployment, you must address the issues that are described in this chapter.

Identity Synchronization for Windows Deployment Considerations

For detailed deployment scenarios that incorporate Identity Synchronization for Windows, see Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide.