Part IV Advanced Deployment Topics

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

• Chapter 13, Using LDAP-Based Naming With Solaris covers LDAP-Based Naming.

• Chapter 14, Deploying a Virtual Directory covers the virtualization functionality of Directory Proxy Server.

• Chapter 15, Designing a Deployment With Synchronized Data covers deployments that use Identity Synchronization for Windows.

Chapter 13 Using LDAP-Based Naming With Solaris

This chapter provides an overview of the LDAP naming service that is provided with the Solaris^TM 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?

• Migrating From NIS to LDAP

• Migrating From NIS+ to LDAP

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:

• DNS, the Domain Name System

• /etc files, the original UNIX® naming system

• NIS, the Network Information Service

• NIS+, the Network Information Service Plus

• LDAP, the Lightweight Directory Access Protocol

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:

• Enables you to consolidate information by replacing application-specific databases, which reduces the number of distinct databases to be managed

• Allows data to be shared by different naming services

• Provides a central repository for data

• Allows for more frequent data synchronization between master servers and replicas

• Is multi-platform and multi-vendor compatible

The LDAP naming service has the following restrictions:

• Clients prior to Solaris 8 are not supported.

• Setting up and managing an LDAP naming service is more complex and requires careful planning.

• An NIS client and a Native LDAP client cannot coexist on the same client machine.

The Solaris OS supports LDAP naming in conjunction with Sun Java System Directory Server, as well as other LDAP directory servers. Although using Sun Java System 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:

• Import of NIS maps into the LDAP DIT

• Client access to DIT information with the speed and extensibility of NIS

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 Java System Directory Server Enterprise Edition 6.2 Reference. Procedural information about setting up a virtual directory is provided in Chapter 23, Directory Proxy Server Virtualization, in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.

This chapter covers the following topics:

• When to Use a Virtual Directory

• Typical Virtual Directory Scenarios

When to Use a Virtual Directory

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

• Client applications require an aggregated view of entries across multiple data repositories.

  For example, you might have several directory servers that contain the same users, but different data. The virtual directory can be used to create a single view of a user's entry across all directories. The virtual directory can also provide a single point of administration for each individual directory.

  Types of data repositories that are supported include LDAP directories, Java Database Connectivity (JDBC^TM) compliant sources such as MySQL, and LDIF flat files.

• Separate data stores are required for user credentials and application specific data.

  For example, an application might have specific data that you do not want to be stored in a corporate directory. The virtual directory enables you to separate the data but make it appear as one source for applications. This simplifies application development and data management because applications do not need to know the details of the data infrastructure. In addition, changes to backend data sources can be abstracted from applications.

• Your enterprise has acquired another company, or merged with another company.

  The virtual directory enables the two company directories to be merged so that they appear as a single directory. For example, imagine you have two directories, dc=example,dc=com and dc=acquisition,dc=com. You also have client applications that need both directories to look like dc=example,dc=com.

• Client applications require database tables to be displayed in the format of a DIT hierarchy.

• Read and write operations are required to multiple data repositories.

• Multiple field join criteria with dissimilar attribute names are required.

• Client applications require support for multi-valued attributes across directories and databases from multiple LDAP or JDBC backends.

• Attribute renaming, DN rewriting, and attribute value rewriting for DN syntax attributes are required.

• Multiple client applications require different views of a single data repository.

Typical Virtual Directory Scenarios

This section provides simple scenarios that show 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 Java System Directory Server Enterprise Edition 6.2 Administration Guide.

Connecting User Identities From Different Data Sources

Example.com stores uses three different data repositories to store user data. Example.com'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.

Example.com 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

Merging New Corporate Data Into an Existing Directory Structure

In this scenario, Example.com acquires a new company, Acquisition.com. The new company stores its user data in its own Directory Server. For management purposes, Example.com wants to retain this directory structure. However, certain client applications need to see the use data from Acquisition.com as if it were user data from Example.com.

The following diagram illustrates how the virtual directory provides a virtualized merge of the acquired company's data into the existing directory structure.

Figure 14–2 Merging User Data From Acquired Directory

Acquisition.com's directory is seen as a separate branch under the ou=people branch. The DNs of the entry's in Acquisition.com's directory are transformed when they are viewed through the virtual directory.

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 http://docs.sun.com/coll/isw_04Q3. 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

• Synchronization direction of passwords. If passwords are synchronized from Directory Server to Active Directory or in both directions, install the High Encryption Pack on Windows 2000. This installation enables 128-bit SSL, which is required when setting passwords in Active Directory over LDAP.

• Synchronizing the creation of new users. If Identity Synchronization for Windows does not synchronize the creation of new users, you must run the idsync resync command periodically to establish links between newly created users. Changes to newly created users are not synchronized until the users are explicitly linked by running idsync resync.

• Population size. While Identity Synchronization for Windows places no upper limit on the number of users that can be synchronized, the total number of users impacts the deployment. The primary impact is on the idsync resync command that must be run before synchronization is started. If more than 100,000 users are synchronized, run the idsync resync command in batches. This batch mode ensures optimal performance and limits the load on Sun Java System Message Queue.

• Performance requirements. The performance of Identity Synchronization for Windows is limited more by the synchronization rate than by the total number of users. The only exception to this requirement is when you run the idsync resync command.

• Expected peak modification rate. An Identity Synchronization for Windows deployment with a Core and two connectors that are running on the same system can easily sustain a modification rate of 10 synchronizations per second. If the required synchronization rate exceeds this rate, higher performance is achieved by distributing Identity Synchronization for Windows across multiple machines. For example, the connectors can be installed on a separate machine from the Identity Synchronization for Windows Core.

• Number of Windows domains to be synchronized. If more than one Windows domain is to be synchronized, the activedirectorydomainname attribute or the USER_NT_DOMAIN_NAME attribute must be synchronized to a Directory Server attribute. This synchronization is required to resolve ambiguity between Synchronization User List definitions.

• Number of Directory Server masters, hubs, and read-only replicas in the deployment. In a deployment with multiple Directory Servers, the Identity Synchronization for Windows Directory Server plug-in must be enabled on each master, each hub, and each read-only replica. When configuring Identity Synchronization for Windows, one Directory Server master is designated as the preferred master. The Directory Server connector detects and applies changes at the preferred master while the master is running. If this server is down, the connector can optionally apply changes at a second master. The Retro Changelog plug-in must be enabled on the preferred master. This master should be on the same LAN as the Identity Synchronization for Windows Core.

• Security. If the Directory Server or the Active Directory connectors connect to Directory Server or Active Directory over SSL, SSL must be enabled on these servers. If the connectors are configured to accept only trusted certificates, extra configuration steps must be taken. These steps import the appropriate Certificate Authority certificates into the connectors’ certificate databases. If SSL is required between the Directory Server plug-in and Active Directory, SSL must be enabled in Directory Server. In addition, the Certificate Authority certificate that is used to sign the Active Directory SSL certificate must be imported into the Directory Server’s certificate database.

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